I'm having some trouble preventing a Scheduled Build from being automatically kicked off after the same build has been trigger manually and no changes are present.
Problem: The Build is scheduled to go out at 3am everyday but only if any changes have been made (the Settings option ‘Build even if nothing has changed since the previous build’ is Unchecked). The problem is that if you trigger a manual build and no changes are made afterwards, the Scheduled Build is still going to get triggered even if there are no changes. Please follow the scenario bellow for an example:
Scenario:
Scheduled build gets kicked off today at 3am - assembly version changes to 1.0.0.1
On the same day, several changes are checked-in before noon.
The same Build is kicked off manually at 1pm - assembly version changes to 1.0.0.2
No more check-ins are made after the manual build from 1pm
The next day at 3am the Scheduled build gets triggered which it shouldn't have (assembly version changes to 1.0.0.3) since there were no check-ins since 1pm (triggered manually).
It seems like the 1pm build is not even being considered and accounted for.
It looks like TFS is taking in count check-ins since the last “Scheduled Build” rather than “the last completed Build” (same build definition) which in this case was the manually triggered one.
So my question is: “Is there any way we can prevent TFS from triggering Scheduled build if there were no check-ins after a manual build has been kicked off?”
Currently, it looks like TFS does not have that option anywhere in the Build Definition
Thank you in advance
In order to do this you would need to write your own scheduler that checked the previous manual build for you. You could write a TfsJob for this or even as a a scheduled powershell that runs at the allotted time...
I ran into this issue today as well.
It seems this is currently "by design".
Someone else posted a suggestion to "fix" this here:
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/5702884--build-even-if-nothing-has-changed-since-the-previ
Related
I'm a pretty new DevOps engineer, and i mostly deal with CI processes.
I'm wondering if it makes sense to define both nightly build And build on each push.
Seemingly, it doesn't make sense, since if the code is built after each push, why do you need to build at midnight, it was already built when you pushed it to the repository.
Am i right?
IMHO you are right - it does not make sense to have a fixed time schedule if at the same time you have a push trigger.
A reason why you still want to have a nightly build (or other fixed schedules) could be if you cannot run a full test with every build.
For example you could decide that you only do minimum tests (or smoketests) with every push triggered build, but once per day (e.g. night) you do a full test run.
As far as I know, the advantage of midnight build is that tasks with long running/deployment time can be run at midnight.
After these tasks run at midnight, you can directly view the results the next day.
In this case, you can set the condition for a specific task to control whether it runs at midnight. You could use $(Build.Reason) to judge it.
On the other hand , we recommend that you can set a specific time schedule trigger.
CI triggers cause a pipeline to run whenever you push an update to the specified branches or you push specified tags. The build is only triggered when the code changes.
Changes in the pipeline itself and the operating environment will not trigger the build.
But they can sometimes determine whether the project can run successfully.
In this case, the schedule trigger can run the build at a specific time to ensure that the project is executable.
I will share what we do and maybe help you:
We have three build tiers, one to cover a case like the Push example you pointed, other with a set of PowerShell tests, and a Scheduled one with full set of tests that takes around 5 hours.
As you can picture each case have their one scenario based on time a number of tests.
When I check-in a file, the TFS CI trigger waits very little and starts the build. The problem is that I may have 10-30 files to check-in, and I would like the TFS to wait at least 5 minutes after my last file checked in before it starts a new CI build. In Cruise-Control I had a "modificationDelaySeconds" property where I could set the minimum amount of seconds to wait after the last check-in. How do I do this in TFS (2012)?
The closest alternative in TFS is to define Rolling Builds (also known as Batched-CI-builds).
Change the build trigger from Continuous Integration to Rolling Builds. This way, the build waits till the last build has finished; you can also configure that you do not want to build more often than every 5 minutes.
We've got a Jenkins setup where we do incremental builds on SCM change, validate and then if this works do a full build (from scratch). This basically works but we waste time doing full builds during the day that we don't normally use.
I know we could trigger full builds every night, but many of our branches won't change for a few days - and then we might get a rush of changes. Thus building every branch every night is wasteful too.
What I really want is some mechanism where we only do the full builds once (say at night) if there has been an SCM change and the incremental build and validate worked - there is no point auto-triggering full builds where the incremental build and validate failed. Actually just "the incremental build and validate worked" should suffice - as these normally just run on SCM change.
Any suggestions? Is there some Jenkins extension that would help with this?
To achieve what you've asked for you can create a new job that is the same as your existing one, but have it only poll the SCM once a day, for a nightly build.
Set the schedule to something like this: H H(0-5) * * *.
In your original job, remove the post-build triggering of a full build.
That will give you pretty much what you've asked for, except the nightly build will do an incremental build and then a full build if the incremental one succeeded, rather than just checking the result of the last incremental build.
BUT...
What is the cost of the 'waste' you are trying to avoid? How much does running a full build every night actually cost you? And wouldn't you be better off finding out when the full build is broken as soon as possible, i.e. during the day when it was broken rather than only the following morning?
Environment: TFS 2010
I met a strange issue on the TFS 2010.
I create a rolling build, and set it should be triggered no more often than every 30 minutes.
Usually, it works fine. I can find the build was triggered several times one day.
Then there is a long vacation and after I came back, the rolling build was not triggered in the last two days.
There is nothing changed for the build definition and TFS server.
It is very strange.
Does anyone know the reason or have the same situation?
BTW, I have a little question for rolling builds. That is, Rolling builds work when there are accumulate check-ins until the prior build finishes. If 1:00 AM, a rolling build was triggered, it will finish at 1:20. At 1:10 some new code was checked in, an other build such as nightly build was triggered before 1:20. Question: Is the rolling build triggered at 1:30?
The whole point of rolling builds is so they don't build up in a queue, basically it means if anyone checks in while a build is happening it won't trigger a build.
If you set a time, eg 30 minutes, it won't ever build within 30 minutes of a previous build.
For the next build to happen you need to check in again outside of those conditions (eg 30 minutes later)
I checked in some code and my build was added to the build queue. I can't go home until the build passes.
There is nobody in front of me, but it's been well over half an hour since my checkin and my build hasn't started (plus it's a half an hour to build the 49 large projects against the build environment). I've been at work since morning and just want to go home before midnight (it's past 8:30 already). My checkin's just sitting their in queue, not being fired off.
How do I force the build to start in an empty build machine if there is nobody in front of me in queue and nothing else going on?
edit: This is what I get for breaking my own rule of never checking in after 3pm unless it's a mandate.
Open the Team Explorer pane and navigate to your team project. Expand the 'Builds' node and find the build definition that you need to build. You should then be able to right-click it an choose 'Queue new build..'. (This does require a separate permission, and you may not have that permission).
This will then bring up the confirmation dialog where you can specify the shelveset to build (if its a gated build).
If the Builds screen shows that there are queued builds, and none running - it could be that there are no available Build Agents or they are marked offline. See Manage Your Build System for more information about how to check the status of your build agents.