My workspace is not reconciling after a gated check-in. I don't see an error. My files are checked in, but still showing under pending changes.
Doing a compare with latest shows no differences.
If I bypass the gated check-in, it reconciles as expected.
Clicking 'Reconcile
Workspace' on the build menu shows a dialog that says 'No changes to
reconcile'.
Restarting Visual Studio does not reconcile.
Our team just received new computers and everyone is having this problem. This did require us to install the latest version of Visual Studio 2019 (16.8.4). I'm not sure if it's a problem with the latest Visual studio, or the new computer.
Any advice on how to resolve this?
The Gated check-in is used to protect against breaking changes via building the changes for validation before committing the changes to TFS. The changes actually get being committed to your TFS server only when the Gated Check-in Build is success and all configured tests are passed. Otherwise, the changes will be kept in Pending Changes.
You can reference to the following articles to try checking in Pending Changes using Gated Check-in:
Check In Pending Changes that Are Controlled by a Gated Check-in Build
Gated check-ins
Related
I created a build definition using the TFS 2013 build process template "TfvcTemplate.12.xaml". I'm using the default retention policy, which is to keep the latest 10 builds. However, nothing gets deleted in my drop location and in my TFS history. Builds just keep on accumulating. Could anyone give me pointers on how to troubleshoot this?
Tks
Policies configuration
Build history
We used to get notification from the tray of our windows machine for a finished build while using the xaml build definitions, it also had an option to reconcile workspace. The same functionality is not available for the vNext builds.
The BuildNotification App is available with VS 2015, but it seems that the reconcile workspace is not available with the vNext build. Is there some other app that can give a notification and do the reconcile operation?
We just moved to new builds (vNext) and are missing this feature as well.
Currently, we can do this manually via IDE (VS 2015):
Team Explorer -> Builds
Right click on latest build with you changes -> "Reconcile Workspace..."
The BuildNotificationApp is still a part of the VS 2015 and can be found here: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\BuildNotificationApp.exe. However, this app only applied to XAML build.
For now, to workaround the missing feature, you can use a free build status tool Catlight . It also shows status of vNext builds in tray area.
As for reconcile workspace, there is no this build-in feature for vNext build. However, you can manually use tf reconcile command for your workspace. Such as below screenshot:
Update:
If you just want a simple app or vs extension to achieve it, there is no these things for now. You may have to customize your own extension to implement it.
Update2:
I have created a feature request in uservoice:
Reconcile Workspace for vNext Build
https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/15979690-reconcile-workspace-for-vnext-build
You can use AnyStatus to monitor both vNext and XAML builds.
AnyStatus comes with a feature called Triggers which lets you run a program or a batch script in response to status changes. Using Triggers you can configure it to run "tf.exe reconcile" when the build status changes from Running to OK.
Disclaimer: I am the author of Any Status.
Here is the simplified version of our gated check-in flow for a successful check-in:
Apply shelveset (build agent)
Build (build agent)
Revert Shelveset from Workspace (build agent)
Check in gated changes (CheckInGatedChanges activity on the controller)
Get the Changeset resulted from checking in the gated changes. (build agent)
This flow is very problematic. Indeed, suppose user A commits (submits to the gate) 100 source files affecting all the projects in the solution and then user B commits just 1 source file affecting just one project. How big would be the gated check-in build for the user B on the build agent?
The answer is that user B is going to "suffer" the same build as the user A.
The root cause: we undo the shelveset before checking in the gated changes and then get them again, this time in the form of a changeset. This bumps up the timestamps of the source files, making them newer then the binaries produced a moment ago from the same files.
That is a problem.
How do I solve it?
EDIT
Here what happens if I do not revert the shelveset, but get the respective changeset right away:
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt
Directory: D:\tfs\DFGatedCheckInTest2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 10/24/2014 10:36 AM 12 1.txt
PS D:\tfs\DFGatedCheckInTest2> tf get /version:C105656
D:\TFS\DFGatedCheckInTest2:
Conflict 1.txt - Unable to perform the get operation because you have a conflicting edit
Automatically resolved conflict: edit: D:\TFS\DFGatedCheckInTest2\1.txt as TakeTheirs
Undoing edit: 1.txt
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt
Directory: D:\tfs\DFGatedCheckInTest2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-ar-- 10/24/2014 11:42 AM 12 1.txt
PS D:\tfs\DFGatedCheckInTest2>
Notice the timestamp of the file. It was bumped up. We achieved nothing.
The reason why tf get /version:C12345 updates the time stamp is due to that being the default behavior for it in 2010. This was changed in 2012 and made configurable.
In Visual Studio 2012/TFS 2012 a feature was added that controls the file timestamp on get, read from Brian Harry's post from way back then:
Restore file modification time
When TFS gets files on to your local disk, it always sets the file modification time to the date/time that the get operation happened. There are some work practices where this is problematic. Some practices use the date stamp on the file for incremental deployment or other kinds of change management. SourceSafe had 3 options for setting the time stamp on files:
The time the file is gotten (this was the default and works very well in concert with make and other similar build dependency trackers).
The modification time that the file had when it was last edited before checkin.
The date/time that the file was checked in.
TFS 2010 and before only supported option #1. In TFS 11, we have added support for option #3. It can be set on a workspace by workspace basis. We plan to add support for #2 in the future but haven’t gotten there yet.
source
Back to the source of the issue
As you mention in your other question, you're using tf checkin /shelfset /force, which is where your problem lies. As the answer in your other question explains, that checkin goes directly against the server, the workspace on the server is unaffected and as such is left with the pending changes of unshelving that same shelfset.
tf checkin /force is also very dangerous in case anther developer had used by-pass gated build to check in changes. TFS will assume you know what you're doing and will overwrite these changes. So:
Developer 1 checks in filaA.txt
Build server starts gated checkin
Developer 2 checks in fileA.txt and bypasses gated checkin
Build server finishes and uses tf checkin /shelfset /force and thus overwrites the changes from developer 2
Instead, what the normal TFS workflow does, is check in the local changes on the workspace of the build agent. tf checkin $/ /recursive and it deletes the shelfset at the end of the build, in case of a succesful build and checkin.
This tells the build server to check-in the local changes in the workspace, and it will now know that it has the latest version, and won't have to update the time stamp. Next time the build is triggered the build agent will start with a get latest (to ensure that any bypass checkins are also fetched) and it will know these files are already up to date.
So in general your workflow, on the agent, should look like:
If workspace does not exist, create workspace and mappings
If there are any pending changes, undo them tf undo $/ /recursive
Perform tf get /recursive /version:T (get latest)
Unshelve your shelfset to the workspace of the agent
Build the code
Check in the local pending changes (tf checkin $/ /recursive), don't use /force
If all of that's succesful, delete the shelfset
If anything fails:
Undo all pending changes to reconcile the workspace
Leave the shelfset in tact
Fail the build.
That way the local workspace will better reflect what's going on and you won't have to perform a tf get /version:c12345 to mess up your dates.
I'm starting out with continous integration with TFS 2013. I've added a CI build definition, and on each check-in of the code a build is executed. So far, so good. Next I'd like to get some kind of feedback; I can check in a test which fails, for example, and the build-server will fail it but there's not notification in my Visual Studio. How can I get a notification from the build server, straight to the developer who initiates the CI build?
You can set a build alert up in the portal to alert the user that their build's not succeeded (i.e. failed or partially succeeded)
http://yourTfs:8080/tfs/yourCollection/yourProject/_admin/_alerts#
I've been running into problems queuing a build to a TFS Build Server with a specified shelveset. I'm running TFS 2012. I have a visual studio solution with many projects. I'll open the solution, make a change to a few .h header files in a few of the projects, and then make a shelveset for that changeset.
Next, I queue a build to the TFS server. In the build definition, I select the shelveset that I just created. However, when the TFS Build server processes that queued build, it behaves as if it ignored the shelveset. When the compiler processes those projects that have the modified files, the header files in the sources folder do not include the change in the specified shelveset.
Here's the interesting bit. I've watched the files created on the build server as the build is processed. When the sources folders are first created and populated, the changes in the specified shelveset are present. But by the time the build process gets to the relevant project files, the source files have been changed back to the version without the shelveset change.
As far as I can tell, the latest version of the source plus the selected changeset was copied to the build server, but when a build error occurred, the sources were replaced with the latest version only.
Not sure why that happens. When it first occurred it looked as if the sources were changing from 'latest+shelveset' to 'latest' before the build error. Now that I know that's not the case, I'm not going to worry about this any longer.