‼ There’s new information in this issue. Please read the updates at the bottom of the article.‼
We use our own TFS server and were using TFS 2013 Update 2 up until last Tuesday. We have several build definitions for my current project, and most of them are scheduled at a specific time, because we have specific times for automatic deployment. Up until Tuesday, everything seemed to work well and the Builds ran at the specified time (both before and after Daylight Saving Time applied).
And then I installed Update 4… 🙂
After installing Update 4, our scheduled builds ran an hour early. Of course I checked both the time on the server and the time the build was scheduled for: these were fine. I looked at the Update 4 documentation, but couldn’t find anything related. I did see however the build server report its time setting as UTC +01:00, and the build definition stating UTC +02:00.
Next up was searching the web, which pointed me to an article on connect.microsoft.com: Scheduled build launched 1 hour earlier. As a comment on this article, which is from July last year, Microsoft employee Mario mentions the issue is fixed in the (at that time) RC of the Summer Update. He also mentions:
Once you install that Update on the server please recreate/re add the build definition and the database will now respect the right times.
Visual Studio 2013 Update 3 & 4
Since we were using Update 2, I looked at the documentation of both Update 3 and Update 4. And if you go to the New technology improvements in Visual Studio 2013 Update 3 chapter and look at the Fixed issues paragraph you find this for Team Foundation Server:
Scheduled builds may run an hour early after daylight saving time.
This led me to believe the update Mario was talking about July last year was part of Update 3. Which might be the cause of our issues.
The solution – Quick & Dirty
To get our builds to run at the scheduled times, we used a real obvious and Quick & Dirty solution: we shifted the scheduled times of the builds an hour, so they run at the time we expect them to run, not the time they are scheduled to run (??!?!?).
There are some downsides to this solution, like the builds not running at their scheduled time, but an hour early. That’s not logical. So you should document / communicate it well. Another downside is I expect the build won’t run at the right time after Daylight Saving Time.
The REAL solution
I created a new build definition that was scheduled at a specific time. And it ran at the specified time. Since Update 3 solves this issue, I expect it to run at the same time after Daylight Saving Time.
So the only REAL solution is to re-create your build definitions.
I think (but am not sure) the following scenarios apply:
|Build definition created in||Build definition running in||Result|
|Update 2||Update 2||Works fine (?)|
|Update 3 / 4||Update 3 / 4||Works fine|
|Update 2||Update 3 / 4||Trouble in paradise|
For details about the updates, have a look at the Description of Visual Studio 2013 Update 3 and Description of Visual Studio 2013 Update 4.
You can find the Connect article over at Scheduled build launched 1 hour earlier.
UPDATE April 9 2015 16:15
It seems like it’s enough to edit (something small in) the build definition and save it to TFS again. The builds for which we shifted the time now build at the shifted time.
I’ve set the time for the scheduled builds to their original value and hope I can add a second update here tomorrow saying all is well…
UPDATE April 10 2015 09:45
Just to confirm, like Bryan MacFarlane states below: changing something small and saving your build definition is enough to fix this issue. So the impact is minor. 😀