I have 2 build definitions setup in TFS (Microsoft Team Foundation Server) 2013. One build runs and deploys every time a change happens in my main branch. The other build is a rolling build, and is triggered at most ever 30 minutes upon changes in my main branch.
In the scenario where the second build hasn't been run in the last 30 minutes at the time of a code commit, both builds get triggered at the same time. I'd like for the first build to be queued first, and the rolling build to be queued second. Right now, the second build goes first, presumably because either the build definition name alphabetically comes first, or the build definition itself was created in the system first.
How is build queue order determined in this scenario, and what can be done to control this order?
Related
I need to schedule a Jenkins task so it runs once per day, but only if certain other tasks succeed at least once that day. That situation makes it similar to this other question, but none of the answers there describe how to deal with the contingencies I have.
My team has a Jenkins process that builds the software. We'll call that the Builder. Builder checks our GitHub repo every 15 minutes and runs if it sees a code change.
We have another task that runs simple tests. This entire test suite can finish in less than 15 minutes. This is the Short-Tests task. Short-Tests run every time Builder passes.
Lastly, we have a set of tests that take hours to run. Let's call these the Long-Tests. We want to run this once per day, but only if Builder and Short-Tests both pass. The Long-Tests start late at night so we can check the results the next morning.
Furthermore, we want to run Long-Tests only on the most recent successful build that day. If the most recent build failed, we want Jenkins to ignore that build and test using a previous build that passed.
If no builds pass that day, there is no need to run Long-Tests at all.
I can schedule Long-Tests for once per night like this, but please tell me how to set up the dependencies.
01 00 * * *
In order to get this behavior you need some kind of persistence to flag successful build and successful short test completion. There are several options available depending on your actual setup such as:
File based flag (writing to file on successful build / test)
Database flag (writing to database on successful build / test)
Git branch manipulation (pushing/merging to specific branch on successful build step, such as example given here: http://andrewtarry.com/jenkins_git_merges/).
Once you have your persistence setup, you can trigger builds either on change or periodically. For example following dependencies can be setup:
Push to Git code branch, triggers Jenkins Build job
For this step you need persistence, say pushing to git: Upon successful completion of build stage, short tests are triggered and, If successful, push to git "latest passing short test" branch is executed using Git Publisher plugin for example. This is to ensure that only last passed short test are going to be scheduled for long nightly tests.
Lastly, long tests are scheduled periodically, handling branch "latest passing short test".
This is just top level overview, since details depend a lot on your actual setup, permissions, git policies, type of Jenkins configuration etc.
Is there a possible to prevent the full jenkins job from running, that is periodically scheduled; if there is no SCM changes since the last build.
For example,
There is a daily night build, to create a build. The completion of this job triggers(upstream project) the automation testing job for that build.
I would like to be able to have two things
Stop the 1st build job, if there is no SCM change since the last job
2nd upstream automation test job runs only if it has not run for 1 week. (after it has been triggered by the 1st Job)
Thanks in advance
The first part is simple, instead of "Build periodically" set to "Poll SCM" with the same schedule. It's exactly what it does: periodically checking for changes and only running the job if there were some.
The second part (triggering another job with a time constraint) is more complicated. One option is "Throttle builds" (to 1 per week) in addition to your usual build triggering scheme. Another one is "Trigger builds remotely (e.g., from scripts)" option and checking whether required conditions are met in some sort of script or service.
For the first
Did you try the poll the SCM every night? If no changes, the Jenkins job wont start.
0 23 * * *
Will run every night at 11 p.m
for the second
use the following plugin : https://wiki.jenkins.io/display/JENKINS/Run+Condition+Plugin
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
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.
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)