I am working with a multi-configuration Jenkins project. The two configuration axes are Win/Linux and 32/64-bit. I would like to build the primary configuration (32-bit Windows) whenever version control changes, but to only build the other configurations once weekly (just to make sure that they stay reasonably up to date).
Is it possible to achieve this schedule without breaking the project up into multiple individual projects?
Unfortunately not through Jenkins directly at this point AFAIK. There is only one time handler per job, and the multi-configuration is a single job, it has a single timer.
There is a hack, but it will be tough, and I'm not sure of the exact script required, but if you can check the day of the week, you could try something like this in your script:
if (day == Sunday |OR| $NODE_NAME == win32), then:
<carry out build steps here>
finish
This way:
If the day is Sunday, all steps will be carried out regardless of Node.
If the node name is win32, the step swill be carried out too.
However, if day is not Sunday and $NODE_NAME is win64 or linux32 or linux64, no steps will be carried out.
Note that $NODE_NAME is a standard Jenkins environment variable. However, this assumes that your build is done through either "Execute Shell" or "Execute Windows Batch"
Is there any reason the others shouldn't build at the same time?
You could create two jobs, one for your primary so it is a free-style job, and the other as a multi-configuration with Win64/Linux and leave that on a separate, weekly timer.
Please consider this:
Why not build ALL available configurations EVERY time?
- after all, that is the whole idea of Continuous Integration...
Can drop the artifacts of those builds after a short period of time,
so they don't clog your disk, but if anything breaks your build - you will know it right away.
Can also set the slaves' queue to run a single job at a time, so the builds don't overload the build-servers.
The other solution requires:
Two "starters" for your build
All slaves to be available
Set Job_A1 as a weekly scheduler that triggers Job_B (the main multi-configuration build process).
Set Job_A2 to run Job_B whenever there are source-code changes.
Set Job_B to know if it was triggered by Job_A1 or Job_A2 (can pass its name as a parameter),
and also set Job_B to ignore calls from Job_A2 ("exit 0"), if the current config. differs from Windows-32bit.
This way, all 4 configurations will run whenever there are source-control changes, but only one will actually build.
Good luck!
Related
We want to introduce new tests that will be driven from TeamCity. The build part itself is reasonably fast but we expect the processes that follow to take a very long time (hours to days). A different machine will produce results and the results will be analysed. And of course we want to see the results at the end in TeamCity.
While we fully expect the long runtimes, we don't want to keep our TC server occupied for hours or days while it's waiting for the final results.
We see several basic options:
estimate the runtime and run a follow-up test at a predetermined time period
keep checking at regular intervals
run another build manually when the initial run is complete
How do you deal with a situation like this? What kind of considerations need to be taken into account? Did you try something like this and did it work (or not)?
Your three listed options sound reasonable but you are missing important features of teamcity that are at your disposal.
An alternative:
Set up a build that will run ONLY the very long process. Lets call it the Long_Build
Have a second build which does the analysis depend on the success of the Long_Build. Lest's call this one the Analysis_Build
Setup an Agent capable of running the Long_Build and Teamcity will run the build only on that agent.
Have your QA build, or main build, or whatever build succeed IFF (if and only if) the Analysis_Build checks out. This build specifically is an information gathering build that will likely check all of your others tests and everything that your QA deployment depends on in order to call a changeset or set of changesets good enough for deployment.
My advice is to never run builds manually. Whatever criteria you would use to run a build manually can be scripted and run automatically. This way you are closer to a continuous integration process where you can guarantee quality.
Also, if you are not already doing it, make sure you label your source control with successful builds. Whether it is your Long_Build, Analysis_Build or QA build you should have a way to obtain successful builds that have passed a series of quality specs.
I'm looking at automating the bamboo release in my team currently it is manually triggered. Releases happen every second Wednesday and a custom variable is set to signify this. If the variable is present an automatic merge to the release branch is triggered.
There are two issues I am running in to
There doesn't seem to be a way to schedule a fortnightly build in bamboo.
I don't see a way set a custom variable with a scheduled build. I just need some sort of flag to say this was the weekly build and not the automated build that happens on check in.
There are a lot of builds so I don't want to make an additional build plan for each plan.
It's possible to create Schedule trigger with cron expression. Try to use expression which executes your build on 1st and 16th day of month
1 1 11 1,16 * ?
There is no way to set variable value for scheduled builds
a) There doesn't seem to be a way to schedule a fortnightly build in bamboo.
You can use cron job expression for scheduling fortnightly builds.
b) I don't see a way set a custom variable with a scheduled build. I just need some sort of flag to say this was the weekly build and not the automated build that happens on check in.
You must be having some admin user which runs automatically triggered
bamboo builds. You can use Bamboo variable
{bamboo.ManualBuildTriggerReason.userName}. If this variable name is
equal to Bamboo admin user name then this build was triggered at
scheduled time. otherwise it was triggered by user/developer.
Is there a way to trigger a teamcity build only after a certain number of check ins. I tried checking build triggering in teamcity but can't find anything where I can specify the number of check in after whcih I want to trigger a build.
I don't think there is a built in solution to this, but there are some things you could do.
Build your own build trigger plugin as described in the documentation
You may be able to simulate what you want by setting a long quiet period in the VCS trigger.
Use a scheduled trigger to run every hour or more and set it to only run the build if changes are detected
Only the first option will trigger on a specific number of checkins, but the other two could reduce the number of builds you do a day.
You can also look into the artifact clean up rules to reduce the number of artifacts kept. Another option is to use pinned builds to pin one build a day (for example) that will not get cleaned up by the artifact clean up process.
I have created many build configurations in Hudson for a single solution (eg. Release, Debug, Test)
When I commit something wrong, I receive 1 build failed e-mail for every build configuration.
I would like to receive a single e-mail.
I think if I could to make one build dependent on the success or failure of another, I could receive less e-mails.
How to do that?
BTW: I use MsBuild, Subversion and NAnt
It sounds like you have multiple jobs (build configurations) for the same set of source code that are configured to always build. You could, as someone else suggested, use build triggers to chain these jobs together. However, if all the jobs run on each commit, I suggest combining the jobs into a single job with multiple steps. That way when one step fails, the entire build will fail, no unnecessary Hudson cycles will be spent, and you will not receive redundant emails. To add steps to a build, click "Add build step" and select "Invoke Ant" (or whatever other action you want it to take).
You can use the build trigger "build after other projects are build" to put projects up- or downstream from one another. Then you typically let the lighter builds go first (like simple compile).
I don't expect this to be useful in my day-to-day workflow, but when initially configuring projects for hudson there are times when I wish I could get it to try all the build steps - not just stop after the first failure.
Again, I am not advocating this for everyday use - just for configuration of the builds. (One of my projects takes about an hour or so and I'd rather not have to iterate through fixing each build step independently - I would like to fix each of them in parallel.
So, is there a way to tell hudson to continue the build steps when one fails?
The best solution right now is to modify each of your build steps to make sure they unconditionally return success, instead of an error code.
There is an open enhancement request to do exactly what you want in HUDSON-4819
This actually can be quite useful in a day to day workflow. We use Zed Builds And Bugs and it has this feature. For each build step, you simply toggle whether you want the build step to fail the build if it fails. By default it is turned on (sensible).
Where this has come in handy are things like optional steps - e.g. copying final binaries to other distribution servers. Sometimes these servers are up and sometimes not. It doesn't really matter if this particular step fails, but when it does fail, I don't want the whole build to fail.