We have had two stories moved from "In Progress" to "Done" status by Azure Boards automatically. From what I can tell we don't have any rules set for it and can't seem to find out why the system is automatically moving stories. Any suggestions or help would be appreciated, I am afraid we are going to miss items that actually need to be worked.
If the story on the Azure DevOps board is linked to some code branch or pull request in the code repository, changes to the repository can update the status of the story. For example, if you link the story to some Pull Request* (as stated by #Daniel Mann), and then you complete that Pull Request, the story will automatically be moved to "Done" state.
You can check the Development and Related Work sections of the story (usually on the right) to see if it has some link to the code.
Related
I am trying to automate my project boards. I would like an action to trigger when someone opens a Pull Request and links it to a issue on the board, then the issue would be moved to "In Review".
I imagine once I trigger by a pull_request, this information would be seen on the given environment variables. But I dumped all of them and I could not find any reference to the issue I am linking and would like to move on the project board.
Can someone give me some light on what I could do to achieve this result?
First you can reference an issue in your commit message described in the documentation. Then you can set up built-in automations for the project board. If you then push something to your repository and create a merge request, the issue should be automatically linked and moved to the column "In Review".
I'm using Azure DevOps for both planning and coding,
Now when PR with attached issue (task)is merged, task is set to "Closed" automatically (I use project template based on Agile)
Is there a way to change it, e.g. I'd like my custom status "Ready for deploy" to be set instead of "Closed"?
This is currently controlled by the PR Compeltion Settings:
Unfortunately, the (feature) you're looking for is not presently supported, you can't handle the work item state when you check "Complete linked work item after merging"
Here is a related UserVoice in Microsoft Developer Community site: Customize Work Item State after PR is closed.
You can vote up and add your comment there. This User Voice is already Under Review.
As workaround you could try to use Service Hook to get the PR event and change the work item state to what you want.
I have a git repo in Azure DevOps Repos, I also have a test User Story set up.
I cloned the master branch and opened it in VSCode and then on commit I used the extension to select my User Story automatically which added #ID to the commit message and then pushed the change back to the master branch.
When I then look at my User Story in DevOps there is no linked check-in.
Am I missing some kind of linkage, my VSCode is connected to my DevOps and it was able to list the User Story in VSCode when I used the add work items option no problem so not sure what the issue is. Assuming this isn't a one way thing where I have to create a branch from the user story and link it at that point?
Automatic link of commit to User Story not working with #ID
Please check if the repository option Submit mention link is enabled:
Go to Project Settings->Repositories:
This option will allow you to automatically create links for work items mentioned in a commit comment.
Hope this helps.
For some reason (that I have yet to figure out) this setting was not on in about half our repositories).
I have enabled this now for all repositories (one-by-one as there is no general setting for this, unless somebody knows how).
Also is there an option to generate the links for existing commits that where done before enabling this setting?
I have been tasked with figuring out to solve this issue. I am working on a project that uses TFVC in Azure Devops and when a check-in is made the system adds that comment to the discussion thread on the work item. What setting can I change to turn that off?
UPDATED:
I created a test TFVC project in a separate DevOps account that I had with no extensions installed. Checked in changes, a link was added to the Development sections as expected but just like described above it was also added to the discussion, see screenshot. So this appears to be default behavior so how do we turn it off?
As far as I know, you cannot turn this feature off once you have linked the checkin with the work item.
Does TFVC in Azure DevOps automatically write the check-in comment to
the discussion for a work item?
For this issue, the answer is no. The comment added in Check in will be used as the title of the changeset(TFVC) and will not be automatically written to the discussion of the work item.
Changesets will be linked to the Development field of the work item to drive development.
Does TFVC in Azure DevOps automatically write the check-in comment to the discussion for a work item?
Obviously not.
Automatically write check-in comments to the discussion of work items is not applicable to all users, so MS does not add it as the default behavior.
And as test, I could not found this issue on my side, and you could also to check this issue on the other organization or new organization.
As a bold guess, your organization may have one extension installed and these behaviors are performed by this extension, like Work Item Autosave. But I could not sure it, you need to check your extensions one by one, Organization Settings->Extensions.
If you find that extension, you can disable or change the settings to disable this feature.
Hope this helps.
Once the PR is approved I want to automatically advance the state of the linked work item, but I don't want it to be marked as "complete". Instead I'd like the work item state to be "ready for testing" (still in progress).
For now, work item state can only be changed as complete when merging a PR.
And there has an user voice Customize Work Item State after PR is closed which suggests this feature, you can vote and follow up.
The work around for now is changing the linked work item(s) through CI build (after completing the PR). Detail work flow as follow:
Add a CI build to trigger automatically after the target branch has new commit(s). And add a PowerShell task to update the linked work items state by REST API.
When PR is completed, CI build will be triggered automcally. And the linked work items state will be updated.
You can try to use
Add a rule to a work item type
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/custom-rules?view=azure-devops
Create service hook and cosume it later using azure function or logic app https://learn.microsoft.com/en-us/azure/devops/service-hooks/overview?view=azure-devops