I have a Task Group that I created out of a set of build tasks. I am able to edit the tasks quite well, but i now realise i will need to add another parameter to the task group. How do I go about doing that?
Task group parameters are automatically created based on the variables used in the tasks. If you reference a new variable in a task that's within a task group, it will pop up.
In addition to the accepted answer, if you want to add parameters that are not directly referenced by tasks within the tasks group (e.g. to use in a config file token replacement task) then you can export your task group, edit the .json file then import it back in. The parameters are in an inputs array near the end of file. You can also hide parameters here if you only want to use them internally to the task group by setting a default value and adding a 'visibleRule' property, see this article for details: https://medium.com/objectsharp/how-to-hide-a-task-group-parameter-b95f7c85870c
This will create a new task group rather than updating your current task group. If you want to update the task group, you can use this REST API:
https://learn.microsoft.com/en-us/rest/api/azure/devops/distributedtask/taskgroups/update?view=azure-devops-rest-5.1
Related
I'm working on an integration between Azure Pipelines and ServiceNow's change management module. To achieve that the ServiceNow Change Management extension has been installed and configured according to this documentation page. In Azure DevOps we are using multistage yaml pipelines, which should create standard preapproved changes in ServiceNow.
The connection itself between the two applications works fine, I managed to put together a pipeline that creates change requests, waits until their status changes and then closes them. However, I'd like to pass some values set in the pipeline runs to the created change requests and I couldn't find a way to do it.
First I added a service connection to our Azure DevOps project, and created the ServiceNow check for it. I experimented a little with adding different expressions to it, like setting the short description to ${{ parameters.shortDescription }}, or defining a variable in the pipeline as ShortDescription: ${{ parameters.shortDescription }} and using that variable in the check as $(ShortDescription) or $[ variables.ShortDescription ]. Unfortunately none of these expressions got resolved. I also realized it is possible to use the predefined variables, but the values I'd like to set are not possible to describe by predefined variables. For example, selecting an assignment group would be pretty straightforward from a parameter defined as a list, but impossible to select from predefined variables.
So as a next idea, I tried to link a variable group to the check and update the variables through logging commands. Even though the variables from the group got resolved, they only showed the values I set them through the UI as a static default value. The dynamic values set via the logging commands were not visible. I played around some time and verified that I can update the definition of the variable groups through Azure CLI or REST API, so I can add new variables or update existing ones. Thus I tried to add a new variable to the linked group during the pipeline run named as ShortDescription_$(Build.BuildId). Even though it got added properly, I could not use it within the check, because it required double variable resolution, like $(ShortDescription_$(Build.BuildId)) and this expression was not resolved, not even partly. It remained $(ShortDescription_$(Build.BuildId)).
Then I started thinking about using only one variable from the group with a static name (e.g. ShortDescription) for all pipeline runs. However, I feel it would create a race condition and could cause some inconsistencies.
So as a last resort, I tried to put together an extension with an Agent and a ServerGate task, which are capable of storing the values I want to pass to change request and reading the stored values in an agentless environment. The problem here is, that the second task is not visible as a check for service connections. It's there as a release pipeline gate and looks good there, but I can't utilize it that way. Based on a question I found, this does not seem to be the problem with my task. To verify it, I copied the content of the same ServiceNow check I used before, and added it to my extension as a contribution with a different task id. And it did not show up as the question stated.
Which means now I can either
create a change request through my custom server task (as the ServerGate task can be used properly in yaml if it is changed to a Server task), but that way I can't wait for the state change of the ServiceNow ticket, or
create the change request in a separate stage where I want to use it, update it first in the same stage where I created it via the first-party check and wait for the state change in the stage where I would normally create it.
The second can work, but it has its own problems, like having misleading values stored in the changed request for the stage id field, or not having multiple change requests created for multiple run attempts of the deployment stage. Also I feel like it's not how the extension's task and check should be used.
Unfortunately, I'm out of ideas how this dynamic value passing can be achieved, if it's possible to do so in the first place. Could you please help me by sharing ideas, or pointing out errors in my attempts?
I am using the release pipeline classic editor and have a requirement of passing an output variable generated in a task to multiple jobs in the same stage or to outside stages. Currently, this output variable is available only inside the same job and I have to write the same task in multiple jobs and stages and I feel it is a redundancy. Is there any way to implement it?.
In the Classic editor, I am afraid that output variables in a different job is not feasible. Please refer to this document .
As a workaround , you can use variables across jobs and stages via variable groups.
First define the variable in the variable group, then update the variable group through rest api or azure cli, and replace the defined variable with the value of the variable generated by the task.
PUT https://dev.azure.com/{organization}/{project}/_apis/distributedtask/variablegroups/{groupId}?api-version=5.1-preview.1
Here is a case about update variable group with powershell script.
Another workaround : You can share values across all of the stages by using release pipeline variables. The solution is updating the Release Definition for the Release Pipeline variable in the Stage where the variable is set.
Define a variable in the release definition Variable.
Use REST API Definitions - Update to update the value of the
release definition variable in the agent job.
Use the updated value of the release definition variable in the next
agent job.
The details info about using REST API to update the value of the release definition variable, you can follow this ticket.
For detailed steps and guide, please refer to this blog .
We are using a task group for all of our builds. Some of the steps pick variables from variable groups and some variables are just system varibles like $(Get-Date).
When editing the task group all variables detected in the build steps are listed under the parameter section and concequently all builds will also show this list of varibles for the corresponding task group.
However in our case we would only like to display three of the variables. We would like variables such as $(Get-Date), some configuration variables and variables from the library variable group not to be listed since the user should not be able to edit these parameters.
Is there a way to choose which parameters will be listed under the task group or in the corresponding builds?
It seems that there is no way to control which parameter should be listed under task groups.
But there is way to control who have the permission to edit these parameters.
If it is acceptable to you, You can modify the security of the task group, which allows you to control the edit permission for individual user and also groups.
After you deny a user's permission to edit the task group. User will get an error when he tries to change the parameter.
I have more than 35 projects in an organization in Azure DevOps. These are the solutions of a Single product. Right now I am creating build and release pipelines for each project one by one.
If I create a pipeline for a single project and release the build, I want devops to create pipeline & releases builds for all the other projects(in the same organization) together at once.
For eg, There are projects A,B,C & D. If I create a release pipeline for Project A, will Devops automatically Release build for other projects "B,C & D" in the same organization at the same time.
We need to avoid creating pipelines for each projects one by one. Is this possible and is there any scripting or configuration to achieve this?
Thanks in Advance.
The process of setting up multiple release definitions with the exact same tasks can be very time consuming and difficult to manage -- fortunately, our team solved this problem using Task Groups!
Task Groups allow you to bundle multiple steps into a single "group", parameterize them, and then invoke them like a single step. You can also edit the Task Group at any time which will cascade to all places where it's used.
The other consideration is that you can bundle your custom variables into Variable Groups and reuse them between Release Definitions. Having your configuration reusable also has the benefit of only having to edit a single item.
I'd recommend:
Create a single release definition as a golden reference example.
Add your build steps for a single stage/environment
Once you're happy with this release definition, multi-select the steps you want to bundle into a group, open the context menu and select the option to convert to a Task Group. This will remove the steps from your release and move them to the Task Group.
Customize the Task Group with the appropriate parameters and then save it.
Modify your release definition to use the Task group parameters.
Add the additional stages to your environment, and add your custom Task Group to each parameterizing with configuration specific to the environment.
Once you're happy with the Release Definition -- use the Clone feature to create 34 more instances.
The same approach can be applied to builds.
We are creating deployments with TFS 2018.3. If I click on tasks in a deployment and create a Task Group out if it, it recognizes the used parameters but if I change parameter usage in an already existing Task Group, or edit the newly create group, parameter changes are not applied to the parameter list in the group.