When we create a pull request and link a work item, after the PR is completed the status of the work items are automatically changed to "invalid". How can we change that behavior to a different status?
In a recent update to Azure DevOps, you can now customize work item state when pull request is merged.
When you create a PR, in the description, you can set the state value
of the linked work items. You must follow the specific syntax.
{state value}: #ID When you merge the PR, the system reads through
the description and updates the work item state accordingly. In the
follow example we set work items #300 and #301 to Resolved, #323 and
#324 to Closed.
The Set work item state in pull request feature is also works for custom states. Here is my sample:
Add a custom state to task.
Create a new pull request and add the Description like:
Ready for QA: #id
Create pull request and complete the merge. Do not check "Complete linked work items after merging" option.
Now, the status of my task has been updated to Ready for QA.
In addition, the product group is still improving this feature. If you have any concern or suggestions, you can share it in this suggestion ticket and this one.
Related
The Azure DevOps Board works with pull requests. The stories are always automatically set to the status "Closed" at the PR, as desired. The problem now is that the status of the work item bug is set to "Resolved" instead of "Closed" after the PR, which means that the item is no longer visible on the board.
I have tried to correct a setting in the PR, as well as in the process settings of the board, however I can't find a suitable place how this can be solved.
If the item bug is moved manually on the board, it has the status "closed" as expected.
Settings: We use a copy of the "Agile" process for the project.
Question: How do I configure the project/board so that a bug that is closed by the PR has the status "Closed" instead of "resolved"?
How do I configure the project/board so that a bug that is closed by the PR has the status "Closed" instead of "resolved"?
I am afraid that there is no out-of-box method can custom the work item state when completing the Pull Request.
For a workaround, you can disable the option: Complete associated work items after merging when completing Pull Request.
Then you can modify the Pull Request description with the following format: Closed: #workitemid
For example:
Then when you complete the pull request, the work item state will change to closed.
For more detailed info, you can refer to this doc: Set work item state in pull request
I can fully understand your requirement. Here is an existing Suggestion ticket about the feature request: Ability to configure target work item state after completing PR
I need to show the GitHub action badge for the current running branch, instead, it is limited to one branch(default or specified).
As the "Adding a workflow status badge" mentions, displaying the status of a workflow run for a specific branch or event is only done using the branch and event query parameters in the URL.
But those parameters are fixed. Modifying them would mean updating the README every time a new action is running.
Said action can get the name of the branch it operates on (see "How to get the current branch within GitHub Actions?")
But you would then need to combine that action with, for instance, github-update-readme in order to include the right URL for the badge:
^^^^^^^^^^
(value computed from the previous step by your main action)
In Azure Devops, I can add markdown in a pull request's description to automatically change a linked ticket's state once the pr is completed, like this:
NewState: #TicketNumber
for example:
Committed: #1000
Is there a way to also change the assignee? I have tried:
#PersonName: #TicketNumber
but it didn't apply the change.
You can try using the work item rules to do this.
For example, you can create the rule as when the work item state is changed to completed (Closed, Done, Completed, etc.), set the assignee to the specified user.
To view more details, you can see "Add a rule to a work item type".
However, this method will always assign the work item to the same user who is specified in the rule whenever the work item state is changed to completed.
If you want to dynamically set the assignee according to the user you mentioned in the description, this methods is not available. In this situation, you can try to set up a pipeline with the following steps:
Try to get the linked work item ID, and the account information (username and email address) of the user you want to assign the work item to.
Try using the API "Work Items - Update" to changed the assignee.
I am using SendGrid email extension to trigger a custom email notification after the CI/CD process is complete in VSTS. This email task has HTML content in it which includes some content fetched using standard build/release variables (https://learn.microsoft.com/en-us/vsts/build-release/concepts/definitions/build/variables?tabs=batch).
How do I include associated code changes, check-in comments and linked work items for a particular release in the custom email? Are there any variables I can use? Any work around?
There aren’t the built-in variables that can get code changes, check-in comments and linked work items.
You can get them through REST API during build or release:
Get build changes and work items through Get Build Changes REST API (Build id variable: Build.BuildId during build or Release.Artifacts.{Artifact alias}.BuildId during release) Note: using Build.SourceVersion to get latest version)
Git: Get commit message through Get a batch of commits by a list of commit IDs REST API
TFVC: Get check-in comment through Get list of changesets by a list of IDS REST API
To get changed items, you can use get commit with changed items or Get list of changes in a changeset REST API.
No API to get detail code changes, but you may refer to this related issue: Lines of Code modified in each Commit in TFS rest api. How do i get?
Assuming TFS (which isn't specified in the question or tags), you could also call tf.exe directly to get some of that info. If you don't care about the output format, then the output of the following command produces a report of the Changeset details.
tf vc changeset <changeset id> /loginType:OAuth /login:.,<token> /noprompt
Where <changeset id> is the numeric Build.SourceVersion, and <token> is the System.AccessToken.
Comments and source code edits listing are included in the report.
Note: the agent job has to be given the "Allow scripts to access the OAuth token" permission (check box on the Agent Job properties).
See the updated link below for details on how to access the build variables. Same content as in the question, but new link. Both currently work.
https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml
Is there a way to trigger an automatic, custom tagging of a repository every time a pull request is merged in github ? for example...
After merging "pull request 8", id like to automatically tag the repository at that state as "$Major_Version.$pr_id".
The result might be "0.1.8".
Is this possible?
Worst case, if someone hasn't written a thing to do that yet, is to use the post-receive webhooks https://help.github.com/articles/post-receive-hooks
You'd need an internet-visible web server to do this, and some code to recognize the merge (it will have two parents) and see if it mentions a pull-request.