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.
Related
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 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).
I have a build configuration that uses sources from multiple repositories. Thus, changes from all those repos go to the product. But in the process I want to know which specific repos had any changes. I couldn't find anything in the build parameters. Is there any way to get this info in the build process?
Thanks,
Zura
I suspect you've probably already come to your own conclusions on this because it seems to be standard TeamCity functionality you're asking about, but here are my notes based on my brief time using TeamCity for the sake of completeness:
A build configuration can have multiple VCS roots attached to it, and by default will start probing each root for new changes every 60 seconds
Once changes are detected for one or more of the roots, the build configuration will show "Pending(n)" next to it where n is the number of changes it's found.
If you click the triangle next to the Pending message, you see details of who committed the change a comment, and a filecount.
If you click the filecount, it will popup a list of the files, and the name and revision of the VCS root it came from.
When the build is triggered, it will remember all this change detail so you can go back later and query which changes were used in each build execution, including which VCS root and revision they originated from.
So, changes from multiple VCS roots are interleaved with each other and easy to trace. You mention "build parameters" which is also useful, and logged, however it's more about the state in which the build agent itself runs in such as filesystem paths, environment variables or parameters passed specifically into the build configuration.
I have recently been charged with building out our "software infrastructure" and so I am putting together a continuous integration server.
After a build completes would it be considered bad form for the CI system to check in some of the artifacts it creates into a tag so that it can be fetched easily later (or if the build breaks you can more easily recreate the problem.)
For the record we use SVN and BuildMaster (free edition) here.
This is more of a best practices question rather than a how-to question. (It is pretty easy to do with BuildMaster)
Seth
If you believe this approach would be beneficial to you, go ahead and do it. As long as you maintain a clear trace of what source code was used to build each artifact, you'll be fine.
You should keep this artifact repository separated from the source code repository.
It is however a little odd to use a source code repository for this - these are typically used for things that will change, something your artifacts most definitely should not.
Source code repositories are also often used in a context where you want to check out "everything", for example the entire trunk. With artifacts you are typically looking for a specific version, and checking out all of the would only be done if exporting them to some other medium.
There are several artifact repositories specialized for this, for example Artifactory or Apache Archiva, but a properly backed up file server will thought-through access settings might be a simple and good-enough solution.
I would say it's a smell to check in binaries as a tag. Your build artifacts should be associated with a particular build version in your build system, and that build should be associated with a particular checkin. You should be able to recreate the exact source code from that information. If what you're looking for is a one-stop-function to open the precise source-code revision that generated the broken build, I'd suggest that you invest some time into building a Powershell module that will do that for you.
Something with a signature like:
OpenBuild -projectName "some project name" -buildNumber "some build number"
I´ve created a Artifact path in TeamCity like this:
src\MyBuild\bin\Release\* => MyBuild.zip
Now I want to publish this created artifact through a download link:
http://localhost:8080/repository/downloadAll/BUILD_TYPE_ID/BUILD_ID:id?showAll=true
...But where I can get the BUILD_TYPE_ID and the BUILD_ID?
The documentation shows several different ways of getting to artifacts that might be easier.
To help you along though, I believe BUILD_ID is the internal ID of a particular build but unfortunately I don't know how to get it. I do know though that you can substitute ".lastSuccessful" to get the last successful build. BUILD_TYPE_ID is the ID of the project you want artifacts for. You can find it by going to your team city page and clicking on that project. You should see a URL that looks like
http://yourteamcity:8080/viewType.html?buildTypeId=bt1&tab=buildTypeStatusDiv
See the "buildTypeId=bt1"? That bt1 is the BUILD_TYPE_ID (it is likely to be something other than bt1 on your machine).
An example
We use the following URL pattern to get at artifacts.
http://yourteamcity:8080/repository/downloadAll/BUILD_TYPE_ID/BUILD_NUMBER
It still uses the BUILD_TYPE_ID, but it uses BUILD_NUMBER instead of BUILD_ID. BUILD_NUMBER is visible on the TeamCity project page.
So for us an example link to get build number 312.4 would look as follows -
http://yourteamcity:8080/repository/downloadAll/bt1/312.4
Your numbering scheme may be very different.