I've been using the automatic links between commits and WI in TFS by writing #id in the commit message.
However, it stopped working for the entire collection, not only for a single project.
All the projects have checked the "Automatically create links for work items mentioned in a commit comment."
I´m really lost and I don´t know how to fix it.
Thank you very much for your ideas and support.
You need to check if the work item exists and you have the permission to view this work item (you can see it on your project portal) when you tried to link it to a commit.
When you make a commit on your local repo. You need to push your commit to the tfs server.
This option Automatically create links for work items mentioned in a commit comment. is set on repository level. You can check if the this option is checked for the repositories.
If above are all good, you can try unchecking the option Automatically create links for work items mentioned in a commit comment and save, then check this option and save again.
Related
I noticed that work items can be linked to a build. But I don't see a way to automatically link the work items to the build.
On pull requests, we require pull requests to be associated with a work item. When the pull request is complete, the work item is updated with a link to the commits.
If I look at a branches commit history in TFS, there is a build column. I assume that the build column would contain the build that the commit is in, but it is always blank.
We want to be able to look at a build and see what work items are contained in the build.
Is there a way to do this?
The “Automatic linking of a build with associated work items” feature was released in TFS 2017 Update 2. You could enable this feature by toggling the setting under Options in your build definition:
In this way, each successful build associated with the work item automatically appears in the development section of the work item form.
More information you can refer to the blog below:
https://blogs.msdn.microsoft.com/devops/2017/08/25/automatic-linking-work-items-to-builds/
In TFS, when I link a work item in a PR, the PR gets approved, merged and the a CI deployment is performed, then I bet TFS should be able to see that the linked workitem(s) have been deployed production. I shouldn't have to look into master or develop branch to see if the code I am looking for is in place.
So, when looking at that particular work item (in epic, on board, wherever) I should be able to see some kind of deployment status.
Is that an out-of-the-box feature or does that require a plugin?
Actually the "deployment status" can be checked with the linked Pull Request and commit.
Once the PR gets approved, merged and the CI deployment is performed, the code changes will be checked in. Normally we can check if the code changes are really there by navigating to the specific merged branch.
Actually, when you looking at that particular work item, you can check the linked PR and commit to know the deployment status.
When you link a work item in a PR which is not approved and
completed, then you can see that there is only a Pull
Request with the ID under the All Links tap in the work item.
Once the PR is approved and completed, you can see that there is a
commit linked to the work item.
So, when you see a corresponding Commit linked there, that means the changes are deployed. You can also double click the linked PR and commit to open them to see the change details.
I have created an application, and I want to commit it to GitHub as as soon as I implement a new option. What I have noticed is that when I use the commit option under source control in Xcode,
some commits appear in the GitHub website, while others don't, following is a clarification
The following figure shows the commits that appear in Xcode and the next one shows the commits appearing in the GitHub website. As you can notice "Added the Login with Facebook button" commit is missing, and any commit that I try to do after this one does not appear. What is the problem?
EDIT: What I have noticed is that I have two working copies of the same project. I doubt that I have created both, where the first copy has the remote GitHub link specified to it, while the other does not. I have tried to add the GitHub link to the second, but it creates more confusion than ever.
A while ago, I accidentally checked in some unfinished unittest files I had changed and added in solution A together with some files that contained an actual bugfix for project B.
For some unknown reason I never noticed the checkin was going to include files from another solution so the checkin was done, after which other team members added more checkins to both solutions.
My question now is two-fold;
How can I undo the part of the checkin that hit solution A without affecting B at all
Is there a way to prevent mistakes like this from ever being possible to happen within Visual Studio (Enterprise 2015), make it impossible to checkin files not part of the currently opened solution somehow?
I think the easiest solution would be to use the ROLLBACK command, if you have installed the TFS power tools (TFPT) you should be able to do it within visual studio.
In your current branch, get the latest version from server then view history and find your changeset. Then right click and select "Rollback entire change set".
This will rollback the changes in your local workspace and checkout the file. (If there are conflicting changes you will have to resolve conflicts.)
Now when you are ready to check-in, exclude/undo the files which you don't want to rollback.
Commit/checkin the files which you want to rollback.
I haven't seen a better way of doing this, and think that this is much better than individually rolling back each file in the change set.
Now to answer your second question: check this ANSWER which I wrote a while back. I am copying it here for convenience.
As far as I tested, this default setting is controlled by the following registry entry. If the value of this registry entry is set as 1, then it should change the default behavior to filter by "Solution Changes".
"HKCU\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl"
Name: FilterPendingChanges
REG_DWORD
Value: 1 = Show Solution Changes
Value: 0 = Show All
I'm a developer and I've made some changes to a solution, which I have saved off to a shelveset. Another developer unshelves my changes and builds the solution on a server. Is there a way for the second developer to check in my shelveset? I know he/she can check in the individual files comprising the shelveset. However, I was thinking of a "checkin" command that took the name of a shelveset as a parameter, or if there was another way to check in those changes as a unit, with the shelveset name.
The other developer can open a Visual Studio Command Prompt and use the following command:
tf checkin /shelveset:shelvesetname;shelvesetowner
See Checkin Command on MSDN for more details.
I don't think check-in via TFS Command Line directly is a better way, it maybe conflict with the latest code on TFS.
I think the better way to check in shelveset if there are some another changes in you code, but you don't check in it, is create a new WorkSpace in your local computer
Then map the latest code to the new workspace, then unshelve(download) the shelveset, resolve the conflict if necessary, then check in the code
For those having issues with the error:"Items cannot be specified with the /shelveset option.", try putting the user name in parenthesis as follows:
tf checkin /shelveset:shelvesetname;"shelvesetowner"
An easy way to do this is to define a new workspace and have the developer unshelve to that workspace. Then, all of the pending changes for that workspace correspond to the shelfset, and they can check in everything in the workspace.
The second developer can go to Team Explorer -> Builds and right click on the Build definition you are working with.
Select “Queue New Build…”
In the combobox “What do you want to build?”, select “Latest sources with shelveset”.
If you go to the button “…” you can select any shelveset from anyone.
Then check the box “Check in changes after successful build”.
A build runs with that shelveset, the shelveset is checked in when the build passes.