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).
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.
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.
I'm building a couple of C++ files in xcode that take a lot of memory to compile (+1 GB / file). Because I do this on my dual core laptop, xcode uses 2 threads for building. The two threads will eventually be building the files that take a lot of memory simultaneously so the system suffers memory starvation and the compilation grinds to a near halt.
A sufficient solution for me would be to force Xcode to use only one build thread. Does anybody know a way to change how many build threads Xcode uses?
For those who are interested, the C++ files contain a sizable boost::spirit::qi parser.
The number of threads Xcode is using to perform tasks is controlled by PBXNumberOfParallelBuildSubtasks option. You can change it with the following command: - defaults write com.apple.Xcode <key> <value>. For example:
defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 8
See Xcode User Defaults for more details.
There are also many other ways to speed up a compilation, from precompiled headers to distributed builds. Read Reducing Build Times for more information on this.
Good luck!
With XCode 5, you can use -parallelizeTargets and -jobs NUMBER with xcodebuild. According to xcodebuild --help:
-parallelizeTargets build independent targets in parallel
-jobs NUMBER specify the maximum number of concurrent build operations
For Xcode 4 you must set the IDEBuildOperationMaxNumberOfConcurrentCompileTasks user default, for example:
defaults write com.apple.dt.Xcode IDEBuildOperationMaxNumberOfConcurrentCompileTasks 4
Note the "dt". This won't affect xcodebuild on the command line. To do that, use something like
xcodebuild -IDEBuildOperationMaxNumberOfConcurrentCompileTasks=4 ...
(See http://lists.apple.com/archives/xcode-users/2011/Apr/msg00403.html and http://lists.apple.com/archives/xcode-users/2011/Jul//msg00377.html )
A single build task should never do the same work twice, and certainly not simultaneously! Factor out the massive chunk of common code into a static library so it can be recompiled only when it changes. Set a target dependency in your application on the static library and link in the static library product. Changes to the rest of your application will then no longer require rebuilding the static library, which should speed up build times tremendously.
Try to exhaust all project-level solutions before manipulating Xcode as a whole. It is too easy to cripple Xcode to using only a single thread and forget to change it back when you move on to a new project. The Xcode User Default Reference documents many options that are not exposed via the Preferences interface, including:
PBXNumberOfParallelBuildSubtasks (positive integer)
This allows you to limit Xcode to using only n build threads on every project it compiles.
BuildSystemCacheSizeInMegabytes (positive integer, default 1024)
BuildSystemCacheMinimumRemovalAgeInHours (positive integer, default 24)
Upping the PCH cache size and retention time could help speed up your builds.