Is there a possibility to trigger some job only if one of couple of others job was build by SCM trigger?
For example:
1. Projects A, B, C are build by SCM trigger.
2. Project D will be build only if A or B or C was build. It should build only once even if all of the upstream project were build (A, B and C).
For job 'D', under Advanced project options, add quiet period (how long, experiment what works well). Also make build parametrized, and add parameter for SCM version. When triggering the build from other builds, use parametrized trigger plugin and give SCM version as parameter.
The idea here is, that when there are two identical builds queued, Jenkins will combine them, and build D just once.
This assumes version control support of Jenkins actually sets environment variable indicating the version (in A, B and C jobs), I'm not 100% sure of this.
If you get it to work otherwise, but you get multiple builds, experiment with "allow concurrent builds" checkbox in build D, I think it had some effect on this, one way or another.
Related
Within our company we use TeamCity for both automatically triggered build configurations, that are triggered quite regularly, and also manual not-as-often build configurations.
Examples of automatic builds are: up-to-date light builds, tests, etc. These are usually triggered because new code/data is available.
Currently, there is big chained process for a release of our product on all platforms. This is done manually by running the last composing build config, and it will do all the build configurations it needs to. None of them are ever automatically triggered, and all are unique to the release build chain.
My questions are, as the amount of agents we have available is quite limited, is it possible that the release process has priority in a way that it would:
Pop any automatic builds and add them again to the queue (just cancelling would be fine, but less desirable) as long as the release chain is ongoing?
Delay any automatic trigger build until the release build chain is finished?
I would understand that there is no existing solution for this, as the only thing I'm using for now is the priority classes. And even though it does work nicely for deciding what stuff on the queue to execute first, it doesn't affect any ongoing build process.
Do you know a great solution for that, or have an idea on how I could tackle this myself by implementing something using, for example, the REST API?
TeamCity have custom build queue priorities feature. You can configure your release process build configurations to have higher priority, so they will run before any non-prioritized build, and there no need to remove/readd builds from/into queue.
we have some depending builds, and i want to start them all after all... (talking of RTC/Jazz build definition, which are used in RTC/Jazz source control - we use the build-engine from RTC/Jazz)
build framework
build server [depends on 1.]
build (start) unit test server [depends on 2.]
build client [depends on 1.]
build (start) unit test client [depends on 4.]
build (generate) allover report [depends on 1.-5.]
build (publish) if all was ok... [depends on 6. if ok]
is there a way to add a sequence into different build definitions? the builds are performed on two different build engines which are even on different build server. right now i have to copy the results and publish all manually...
one important note: these are the nightly builds, where all work of the day is brought together... they are triggered via the 'schedule option' in each build definition. but think what happens when one build is not yet ready and the other already starts? (this already has happened and i want to avoid it furthermore)...
what is the proper way to handle this? (maybe i was using the search option wrong but no results in google and Stackoverflow)
The build scheduler management in RTC isn't as complete as a TeamCity or Jenkins (actually, RTC4+ allows to delegate that job scheduling feature to Jenkins)
But if you want to introduce a sequence between builds definitions, you can look at post-build delivery, introduced in "How to keep your streams flowing smoothly in Rational Team Concert 3.0.1".
The idea is, if a build succeeds, to trigger a deliver to another stream (post-build deliver step).
If that other stream is monitored by another job, that job would only starts if the previous one succeeds: sequence achieved.
This seems simpler than adding pre/post-build extensions points.
Note that post-build steps currently don't get run when a build is invoked by the Team Concert Plugin for Jenkins. See WI 277270.
You can place a post request to jour jazz server after each successful build like:
localhost:/jazz/service/com.ibm.team.build.internal.common.ITeamBuildRequestService
<request>
<method>requestBuild2</method>
<interface>com.ibm.team.build.internal.common.ITeamBuildRequestService</interface>
<parameters xsi:type="com.ibm.team.repository.common.services:ComplexDataArg">
<type>COMPLEX</type>
<value xsi:type="build:BuildRequestParams">
<allowDuplicateRequests>true</allowDuplicateRequests>
<personalBuild>false</personalBuild>
<buildDefinition itemId="YOUR_BUILD_DEFINITION_NAME" />
</value>
</parameters>
</request>
I have one requirement of one build definition should invoke the other build definition.
Based on the result of the first one, the second one should get triggered.
Is there any option?
Following the article "
How to keep your streams flowing smoothly in Rational Team Concert 3.0.1", you could set up the post-build deliver step in order to deliver to another stream, monitor by another build.
If the first build goes well, it delivers to the second stream, which is monitored by a build workspace associated to a second build, which will start then.
Note that only a RTC 4.0.6+ (February 2014) allows to fine-tuned the conditions for which a post-build deliver will be triggered.
I have one start job A which uses conditional build step to run a few downstream jobs (B1, B2, B3, ...). I also use join plugin to join those jobs and then start another job C as a join post-build project to build. The reason I use post-build option is I need to pass parameters through all these jobs. However if one of the downstream jobs (B1 or B2 or ...) fails, the job C still runs though I never check "trigger even if some of downstream projects are unstable". Anyone knows the reason? And how to solve the problem? Thanks for shedding some lights on it.
After a few tests I found that join plugin seems not working well with conditional build step plugin, so I removed join plugin and instead checked "block until the triggered projects finish builds" option for each conditional step, then put the join project at the end as a normal triggered job. It works.
My setup up is such that TeamCity kicks off a build on successfuil building of another project.
This works well, but now I need to constrain it such that the above only happens in a certain window during the day.
i.e. Kick off a build of Y on successful build of project X, but only between the hours of 9 and 5.
From what I can tell, I can't AND or OR two Build Triggers in order to achieve this. Does anyone know of a way around this?
Many thanks
Another solution could be to add the first-step in build Y which will return success-code in specified interval; and next step will be executed only in this case;
To address Justin's comment: my understanding is that you want project Y builds skipped outside of the specified time window.
I can offer the following solution:
Create an auxiliary build Z:
Build Steps. One build step: command line runner, the script checks current time and returns error level = 0 if the time is between 9 and 5, and a different error level otherwise.
Build Failure Conditions. Have it fail if build process exit code is not zero.
Build Triggering. Triggered by a successful build X.
Modify build Y to be triggered by a successful build Z rather than X.
This will do the trick.
However, you'll have to spend a build configuration for Z, which may be an issue if you're using the Professional Edition of TeamCity, with its limit of 20 build configurations. You could also do without creating build Z, by adding the same build step into Y, but I don't know if it's going to meet your needs. The downside is that it will cause project Y to have a number of builds failed only because it was not the right time for them. Still, you'll save CPU resources by avoiding the remaining steps of build Y (if resource saving is what you're trying to achieve).