I am using WorkItem Updater task in pipeline to update workitems automatically onces deloyment is done in release pipeline.
But I am getting "No workitems found to update" message but there is a workitem linked with build & release and it is not updating.
could anyone please give me pointer to resolve this issue. Thank you
Issue with updating Wokitem status using WorkItem Updater
I have test this extension on my side, and it works fine.
Since you do not share the configuration of your task and the info of the linked workitem, I could only provide you the troubleshooting steps to resolve this issue or you could update your question with those info.
As test demo, I have set the WorkItem Updater like below:
Then I created a workitem and set the state to Active.
Enable the CI for the pipeline and modify the file in the repo, submit the change with link the new created workitem.
The build will be triggered and the build log shows it successful:
So, if you get the message "No workitems found to update", please make sure the linked workitem match the filter for the configuration of your task.
I'm having the same issue. It finds the work-items based on the filter conditions, however its not updating the status.
enter image description here
enter image description here
Related
So, I have had build verification for our repos set up for months and today I had a coworker come to me saying that it wasn't running, and his PR couldn't get to main. Upon further inspection the field for what pipeline to run in the build verification policy for the main branch was empty. I reassigned the build pipeline and saved, however If I refresh the page and go back into the policy the field is empty again. Can anyone provide any insight?
Here is an image of the field in question:
Also before it is asked, The pipeline exists, so does the yaml file it is associated with, and it can be run independently of the build verification policy on our PRs.
Thanks!
I want to have my build pipeline configured such a way that when ever my pipeline fails there is a bug created for the same. I cannot find an option to select this configuration for a particular branch. Can someone help me with this.
I want to create a bug whenever my build pipeline fails in azure devops. And i want to have it configured for a particular branch
There is an option Create a work item on failure on the pipeline Options tab.
If the build pipeline fails, it can automatically create a work item to track getting the problem fixed.
But we could not configurate it for a particular branch for this option, but we could create a new pipeline with trigger filter Branch specification:
In this case, only the particular branch build failed, it will create a bug.
With the classic build pipelines and classic triggers, it was easy enough to track builds that were triggered by completion of other builds by just polling for builds requested by the same user.
Now, with resource triggers, the requested by property switching to the build service account instead of the original author of the triggering commit.
I have been going through the documentation to try and find another way to see triggered builds from the original build ID but have not found anything.
There is an "Associated Pipelines" tab on the build summary page that at least has the pipelines containing the triggered builds, but I cannot find anything to get that by API either.
According to your description, you can first call the REST API to get all the running build pipelines in the definition, and then use the powershell script to loop check the id in the parameter triggeredByBuild in the request body in the specific build so that you can see triggered builds from the original buildId.
Note: The id marked in the attachment is the original buildId that triggered another build pipeline.
We're running Ranorex-Tests in our Release Pipeline and reporting the test results at the end via the Publish test results task. Issue is that our Ranorex Pipeline is pretty much handcrafted and I can't seem to find how I can pass the branch name when reporting test results using Publish test results. All tests show only "no associated branch". Anyone got an idea how I can manually enter the branch name when I'm publishing the test results?
Screenshot "no associated branch" branch message
The Publish test results task doesn't have the input to pass branch info. Instead I think your release pipeline should add artifact source to resolve that message:
This is my page:
The branch info is always passed via the artifact source option. No matter what the source is, pipeline run or Git Repo, they always have corresponding branch info. (What you met is just a message, it doesn't really affect your test/release)
We are migrating from old XAML build definition to new TFS 2015 build. In old we have gated-check in that is working fine. In new one we have such option on "Triggers" tab. However I want use commit ID that trigger build.
The variable $(Build.SourceVersion) is responsible for this, but for gated-check in it is not being set.
It looks right, because commit was not accepted by TFS yet.
The question is how to grab this commit ID either during gated-check in or following CI ?
Should I create just another build for gated check-in that just compile our solution and only if succeeded will trigger CI ?
There is no way to get the changeset id that hasn't checked in during gated check-in. Please check the screenshot below, checking in gated changes is in the very last step in the build process, which can't be controlled. After the build completes, the variable $(Build.SourceVersion) will update automatically. So we are not able to get the changeset id that hasn't checked in until the build completes.
You would need to use TFS REST API to get the build that has completed, then fetch the "sourceVersion":
GET http://{instance}/DefaultCollection/{project}/_apis/build/builds/{buildId}?api-version={version}
So far, I end up with not clean workaround, but it were accepted by our management.
I created two build definitions: one for gated-check in, one for CI.
Once someone checked in something gated check-in fires. If it completed successfully, CI build would be triggered. Please note corresponding checkbox on UI:
This is not so clean solution, but it works for me.