I want to update a Pipeline with the Definitions - Update REST API call.
That works fine, but when I want to add a custom task (self made build pipeline task extension) then I struggeling to find the correct task reference id:
Invoke-RestMethod : {"$id":"1","innerException":null,"message":"The pipeline is not valid. A task is missing. The pipeline references a task called '7f1fe94f-b811-4ba1-9d6a-b6c27de758d7'. This
usually indicates the task isn't installed, and you may be able to install it from the Marketplace: https://marketplace.visualstudio.com. (Task version 1.*, job 'Job_1', step ''.),Job Job_1: Step
has an invalid task definition reference. A valid task definition reference must specify either an ID or a name and a version specification with a major version
specified.","typeName":"Microsoft.TeamFoundation.DistributedTask.Pipelines.PipelineValidationException,
Microsoft.TeamFoundation.DistributedTask.WebApi","typeKey":"PipelineValidationException","errorCode":0,"eventId":3000}
I check out the registrationId of my custom task with the Installed Extensions - List REST API call. But it is not the correct one. (7f1fe94f-b811-4ba1-9d6a-b6c27de758d7)
I also add the custom task manually to a pipeline and read out the correct task refernce id with the Definitions - Get REST API call. I could find the id in:
$pipeline.process.phases.steps.task.id -> 2c7efb3e-3267-4ac6-addc-86e88a6dab34
But how can I read out this id without adding the custom task manually?
This id is obviously dynamic and changes everytime when the custom task get installed, so there must be a way to get this refernce.
The task id has not changed every time when the custom task gets installed, but he existed in task.json of the task:
{
"id": "2f159376-f4dk-4311-a49c-392f9d534113",
"name": "TaskName",
"friendlyName": "Task Name",
Another option is to use this api:
https://dev.azure.com/{organiztion}/_apis/distributedtask/tasks
You will get a long list of all the tasks, search your task and you will see the id.
Related
A certain task generates a ##[warning] and has a warning status.
It causes the final status of stage to be an orange exclamation mark.
I want to suppress this so that the stage will show as succeeded (green check).
Is there a way to achieve this?
Ive looked at the options at the task itself, but it only has ContinueOnError
*Edit:
Im talking about the Azure App Configuration Extension.
I've even delved into the path of updating the Build Result via REST API
but to unfortunaly, the PATH method doesn't seem to update the build result.
Update from OP
It's a known limitation/bug of task:
Azure DevOps Extension: Azure AppConfiguration - Partial Complete
Currently, by default the build result is "Failed" if anything failed to compile/build, "Partially Succeeded" if there are any unit test failures,ContinueOnError checked, and "Succeeded" otherwise.
It causes the final status of stage to be an orange exclamation mark.
According to your description, that task showing as "Partially succeeded" may due to you checked "Continue on error" option.
Continue on error (partially successful)
Select this option if you want subsequent tasks in the same job to
possibly run even if this task fails. The build or deployment will be
no better than partially successful. Whether subsequent tasks run
depends on the Run this task setting.
Please refer to this document for more info: Task control options
I want to create a task group where Azure Resource Manager Connection is filled with a parameter:
However, this is not possible to do in portal as a validation force to fill it with working value. So I tried to export the task group as json and them modify it and import but then I got this message saving release pipeline:
Is there a way to overcome this? I understood that this is security check (which btw doesn't work in yaml pipelines becauce there you can use Azure Reource Manager connection even if you not allowed). However, in this way it limits usage of task group to a single connection.
EDIT:
Kevin thank you for your anser. I tired it but it didn't work for me.
So I have the connection rg-the-code-manual:
I created a variablewith it:
But when I tried to use it I have a validation error:
Based on my test, when I set the variable as the Azure Resource Manager Connection name, I could reproduce the same issue.
For example:
To solve this issue, you need to set the variable value in release pipeline.
Then you could save the release pipeline successfully.
On the other hand, you could also set the default value for the variable in Task Group.
In this case, the task group will use the default value in release pipeline. And the parameter will also exist in the task group task, you could directly select the value in the drop downlist.
Note: you need to make sure that the Service connection name is valid.
I have three artifacts in my Azure DevOps Release pipeline with the following source aliases: _Client, _Database, _WebApp.
_Client is the primary artifact. I want to include each artifact's build number in the Release name.
I have used the following expression in "Release name format" under "Options" tab.
Release-$(rev:r) for Core Build-$(Release.Artifacts._WebApp.BuildNumber), Db Build-$(Release.Artifacts._Databaes.BuildNumber), Client Build-$(Release.Artifacts_Client.BuildNumber)
I expected it to name the release as "Release-74 for Core Build-29.0.0.69, Db Build-1.0.0.29, Client Build-2.1.0.34
Instead, it names it as "Release-74 for Core Build-$(Release.Artifacts._WebApp.BuildNumber), Db Build-$(Release.Artifacts._Database.BuildNumber), Client Build-$(Release.Artifacts._Client.BuildNumber)"
In initialize job log, it does show the artifacts and their respective build numbers as follows:
[RELEASE_ARTIFACTS__DATABASE_BUILDNUMBER] --> [1.0.0.29]
[RELEASE_ARTIFACTS__CLIENT_BUILDNUMBER] --> [2.1.0.34]
[RELEASE_ARTIFACTS__WEBAPP_BUILDNUMBER] --> [29.0.0.69]
[RELEASE_RELEASENAME] --> [Release-74 for Core Build-29.0.0.69, Db Build-1.0.0.29, Client Build-2.1.0.34]
Is it because it can't resolve the artifact build numbers while creating the pipeline or perhaps there is another way to achieve this?
The same behavior in my release, it looks like the Artifacts variable got their value only after the release will start, so it's impossible to put them in the release name.
As a workaround, you can add a simple command-line task that use the logging command to update the release name:
echo ##vso[release.updatereleasename]Release-$(rev:r) for Core Build-$(Release.Artifacts._WebApp.BuildNumber), Db Build-$(Release.Artifacts._Databaes.BuildNumber), Client Build-$(Release.Artifacts._Client.BuildNumber)
We have a number of tasks that we carry out every time we create a new GIT repository in our project, and I would like to know if there's a way to script (PowerShell or any other method) these out. for e.g. every these are the steps we follow everytime we create a new repo
Create a new GIT repo
Create a Build pipeline for Build validations during
pull request
Add branch policies to Master including a step to validate build using the above build
Create a Build pipeline for releases
Create a Release pipeline
Is there a way to script repetitive tasks in Azure DevOps?
Of course yes! As Daniel said in comment, just use REST API can achieve these all. But since the steps you want to achieve are little much, the script might be little complex.
Create a new GIT repo
If you also want to use API to finish this step, it needs 3 steps to finish that( Since this does not be documented in doc, I will described it very detailed ):
Step1: Create the validation of importing repository
POST https://dev.azure.com/{org name}/{project name}/_apis/git/import/ImportRepositoryValidations?api-version=5.2-preview.1
Request body:
{
"gitSource":
{
"url":"${ReposURL}",
"overwrite":false
},
"tfvcSource":null,
"username":"$(username}"/null,
"password":"${pw}"/"${PAT}"/null
}
Step2: Create the new repos name
POST https://dev.azure.com/{org name}/{project name}/_apis/git/Repositories?api-version=5.2-preview.1
Request body:
{
"name":"${ReposName}",
"project":
{
"name":"{project name}",
"id":"{this project id}"
}
}
Step3: Import repos
POST https://dev.azure.com/{org name}/{project name}/_apis/git/repositories/{the new repos name you create just now}/importRequests?api-version=5.2-preview.1
Request body:
{
"parameters":
{
"deleteServiceEndpointAfterImportIsDone":true,
"gitSource":
{
"url":"${ReposURL}",
"overwrite":false
},
"tfvcSource":null,
"serviceEndpointId":null
}
}
In these script, you can set variables in Variable tab, then use ${} to get them in the script.
Create a Build pipeline for Build validations during pull request
This step you'd better finish manually, because you can configure more about tasks and trigger with UI. If still want use API, refer to this doc: create build definition. There has detailed sample you can try with.
Add branch policies to Master including a step to validate build using the above build
This API still be documented in doc: create build policy. Just refer to that, and ensure use the correct policy type and the corresponding buildDefinitionId.
Create a Build pipeline for releases
This still recommend you finish manually, same with the step3 you mentioned.
Create a Release pipeline
See this doc: create release.
Note: For some parameter which will be used many times, you can set it as variable. For the parameter which need get from previous API response, you can define a variable to get its value then pass this variable into the next API to use.For e.g. :
$resultT= $result.Headers.ETag
Write-Host "##vso[task.setvariable variable=etag;]$resultT"
Now, you can directly use the $(etag) in the next API.
In a certain Jenkins config, I wish to trigger another configuration as post build action.
I want to pass as one of the parameters the current build status.
IE: a string / int that represents the status (SUCCESS/FAIL/UNSTABLE).
I have 2 options to create post build triggers:
Using the join plugin
Using the trigger parameterized build in post build actions
I wish there was some kind of accessible env variable at end of run...
Have any idea?
Thanks!
Here is a simple solution that will answer most cases:
Use 'Trigger Parameterized Build' plugin, and set two triggers -
'Stable or unstable but not fail'
'Fail'
Each of those triggers should run the same job - let's call it 'JOB_B'.
For each of the triggers, pass whatever parameters you like, and also pass a user-defined value:
for trigger '1' use: JOB_A_STATUS=SUCCESS
for trigger '2' use: JOB_A_STATUS=FAIL
Now, all you need to do is test the value of ${JOB_A_STATUS} from JOB_B, to see if it is set to 'SUCCESS' or 'FAIL'.
Note this solution does not distinguish between 'stable' and 'unstable', but only knows the difference between 'fail' and 'success'.
Good luck!
You can check for status using Groovy script in post-build step via Groovy Post-Build plugin that can access Jenkins internals via Jenkins Java API. The plugin provides the script with variable manager that can be used to access important parts of the API (see Usage section in the plugin documentation).
For example, this is how you can output build result to build console:
def result = manager.build.result
manager.listener.logger.println "And the result is: ${result}"
Now, you can instead use that value to create a properties file and pass that file to Parameterized Trigger post-build step (it has such an option).
One caveat: I am not sure if it is possible to arrange post-build steps to execute in a particular order to ensure that Groovy post-build step runs before the Parameterized Trigger step.