I am trying to find a way to assure that the build number for the same components are unique and it seems that the only place that is really appropriate to get next build number it would be the artifact repository (Artifactory in my case).
In case someone wonders why I am not using the build number from the build system, that's because I have components that are build, in parallel, by different build systems and each one of them may be allowed to upload the artefacts.
Obviously I do not want to introduce a new build-number-server dependency I do indent to use the destination to assure that I have a proper (unique) build number.
Using SCM for build numbers is not good because of several things like forks and branches.
Update: It seems that if I try to PUT a the buildInfo.json with the same build number on Artifactory the server returns a 500 error code with a message Could not insert build Build{...}.
It seems that this is not possible at this moment because you can only publish build info once, which means that even if you can figure out which build number should be next, you cannot reserve it till you finish the build.
https://www.jfrog.com/jira/browse/RTFACT-7676 is asking to allow POST in addition to PUT for builds, so we can modify them (publish it as incomplete at the first place, and updating it later when the build process is finished).
Related
I would like to create a build configuration which compares the results of a build, with the build before it.
In the web UI, adding an artifact dependency, the only options that looks like it could do what I want, is "Get artifcacts from: Build with specified build number", but knowing what to put in the build number box is tricky! I can't do maths in there, and even if I can, our VCS is Perforce, and changelists are not always sequential due to e.g. local/shelved changelists.
I imagine this means I need to write a script to access the REST API, so I need to figure out a build locator to get the artifacts I want... but I'm not sure what the dimensions I should specify are. Is there some combination that can give me the build before a given VCS revision number? Or will I have to walk backwards using revision:<REVISION> until I find one that exists? That feels messy!
To get the last finished "normal" build (from default branch, not personal, not canceled) from the same build configuration as your build you can use URL like .../app/rest/builds/buildType:(id:%system.teamcity.buildType.id%)
(from within the build you can authenticate with %system.pin.builds.user.name%:%system.pin.builds.user.password%)
However, if you need to get the previous build regarding changes (e.g. it can be not the last one), it will be more tricky.
We have a VSTS build setup. Currently we have a single repository hosting multiple services. We have a build definition per service, and triggers each only when the current service is touched, by a trigger pattern.
Now the issue is that each build definition hence the single repository makes the GetSource download the whole repo and also we do a clean.
I have been searching to see if there is a solution like the trigger where we can set a pattern, to just get a part of the repository downloadet. This should be to reduce build/download time.
A workaround might be to not make a clean each time or make multiple repositories. At the moment we would like to avoid the latter.
Let me hear if anyone knows of a good solution.
There is no way to specify the files to be downloaded in Get Sources step. Instead, VSTS will download the whole repo.
The workaround is set Clean option as false so that only the modified files and new added files will be updated in Get Sources step.
I do have a project in TeamCity, that has a build configuration for the master release branch. This is compiled, every time a new version of our product is released.
In order to be able to pinpoint the introduction of errors, I do need a big retention time for some artifacts on this build configuration. As some other artifacts are rather big (full cd installation packages), my server's hard drive gets pretty full when simply upping the cleanup interval of this configuration.
Is it possible to configure two different cleanup intervals somehow? I would love to have a big retention time for the really important artifacts, while throwing the big ones away early.
I currently use TeamCity 9.0.3
Let's say for example, that my project has two artifacs:
smallupdatepack.zip (32 mb)
reallybigupdatecd.iso (700 mb)
I would like to configure TeamCity in a way that has the .iso kept for e.g. the last 10 builds, but the .zip is kept for the last 150 builds.
What I do not want, is a solution where all the .zip files are kept forever, while only the .iso files are deleted by an interval, which is all that seemed possible to me by using the build configuration's setting's artifact patterns alone.
You can specify custom cleanup rules for porjects/targets in Build History Clean-up page.
In your case, you can have a aggressive cleanup for all builds and a lenient cleanup for the Project/target for the master build
I have uploaded an example via an image below , if it helps
If you edit any of the settings, you can set individual period for artefacts. You can setup artefacts cleanup per target. However, for the same target you cannot setup different cleanup rules for multiple artefacts.
The answer by #Biswajit_86 looks like it's the only thing available for setting special clean up rules. I looked at it and it seems like the configuration specific settings should override the project settings and give you what you need, but maybe it doesn't work that way. Try it out and see if it works. If not, file a bug/suggestion with JetBrains.
The only other thing I could think of was to create a separate build configuration that only publishes the artifacts that you want to keep longer than your default rule. Give it a snapshot dependency on the configuration that creates the files and check the box to run on the same build agent. That way it doesn't need to rebuild them and can just publish what was already created. Set up a build trigger so that this new configuration runs whenever the other one finishes. Then set the clean up rules for this configuration to the longer retention setting.
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.
We have a lot of tests. I can break these up so that they run on seperate agents after an initial compile build happens, but is there a way I can recombine these results? Having 8 build configurations that all need to be green makes it hard to see if you've got one ubergreen build.
Is there a way in TeamCity to recombine / join builds once we've split them out? TW-9990 might help - allowing ANDs in the dependencies.
We found the answer which certainly works from TeamCity 5:
One compile build,
N test only builds that take compile.zip!** and copy to where the compile output would normally be. (via a template)
Consolidated finish:
Finish Build Trigger: Wait for a successful build in: ...
Snapshot Dependencies: Do not run new build if there is a suitable one
Only use successful builds from suitable ones
This all seems to work nicely and the whole shbang is easily copied for branches etc. Am very happy - this has worked well for us for many months now.
No idea how to do that natively. Here's my first thoughts on how I would try and tackle such a thing though:
Saving test results to files
Publishing the test result files as build artifacts
Creating a 'Merge build'
Adding artifact dependency onto the individual test projects
Writing a custom 'build' script using something like (N)Ant. This would parse the individual test results and publish the results as per the TC KB
Good luck!
Thinking outside the box you could have an overall build which doesn't really do anything (or use one of your test build configs as your 'master'), with snapshot dependencies on each of your split test builds. That way if any of them fail, the 'master' will fail because one the dependent build failed.
TW-9990 looks to be concerned with build triggering rather than dependencies.