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.
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 our organization, we use azure devops integrated with servicenow. In devops we need to create feature that must be an child of an epic. If no epic is found as parent, we need populate a alert to add a parent to the feature.
Currently, azure devops does not provide a field about the parent related link, so we cannot directly set the process rule for the parent related link.
As a workaround, we can first create a custom field named setEpicAsParent for the feature work item type to populate a alert to add a parent to the feature.
Organization settings -> Process -> choose the inherited process -> choose Feature work item type -> New field:
Then add a custom rule like below:
When a feature item is created, the user needs to select true in the setEpicAsParent field, otherwise the item cannot be saved.
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.
When a user does not have rights to publish a page, he sees "Request publication" button in Touch UI editor mode. When he clicks on "Request Publication", the workflow "Request for activation" starts and go to the admin's inbox. I want the page to go to some other group for publishing. How can I achieve this?
As shown in the image above, you can change the user/group to be anyone/anything in your instance.
You just need to change properties of default "Request for Activation" workflow.
However, it is recommended to make a new workflow of your own so that upgrades and patches don't revert your changes.
On the /libs/cq/workflow/content/console.html page with all available workflows. You should find workflow that you are interested in.
In you case it is possibly http://localhost:4502/cf#/etc/workflow/models/request_for_activation.html
On this page you can workflow config which contains several steps. Open for editing Request for activation step, switch to tab Arguments and then you can change Name patterns field. It should be regex pattern e.g. .*approver.* for all groups which contains approver in name.
As a variant you can custom workflow or step. In this case you need to figure out by you self how to configure it but usually it is something similar.