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.
Related
I am struggling a bit with the concept of azure pipelines and am looking for hints on how to solve the issue:
We have one Build definition that produces a binary artifact "Generator" in indeterminate intervals.
We have another build definition that should run every night, pull some source code from a repo, obtain the "Generator" artifact from the other build definition, execute it on the source and produce a new artifact.
The problem I have is, how can I get the latest build from the other build definition?
Here is a screenshot of my problem:
While I can select the proper build definition, the Build has to be an actual build. I cannot add "latest" here (tried and failed) but I don't really want to pin the build number.
Imagine the "Generator" to be something that gets updated once in a while and adds new features etc. The separate build definition at hand, which is not related to the build definition producing the "Generator" just wants to use the "latest" generator and to generate something from its own repository that can be published as an artifact afterwards.
I am pretty sure I am missing something and would be glad to get some hints. (Setting Current build instead of Specific build) actually does not allow me to select the project and build definition that is different from the current one.
Get latest artifact from Build Defintion X and use it to produce a new artifact
It seems the task Download Build Artifacts you are using is not the latest version, like 0.131.1. When I add this task (My version is 0.148.1), there is an option Build version to download that I could select the latest version:
So, try to remove it and add it again, check if you have that option.
Check this ticket for some more detail about this issue.
Besides, if you could not get the latest version, you can try to use the Fetch Build Artifacts task instead.
Ticket here.
Hope this helps.
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.
Is there any other way to put a value next to build name except 'teamcity.build.branch'?
I need to specify a metadata next to each build that might be dynamic or might be result from a previous build configuration part of the build chain using TC SNAPSHOT dependencies.
Is that possible?
According to the TeamCity 9.x documentation, there's no other way to add a "label to each build" except via the teamcity.build.branch parameter.
For Git & Mercurial, TeamCity provides additional parameters with the names of VCS branches known at the moment of build start via teamcity.build.vcs.branch.<VCS root ID>.
If you just want to add a human-friendly description, you could try teamcity.build.triggeredBy and teamcity.build.triggeredBy.username.
I see you've already asked this question on the JetBrains forums and been directed to a feature request on JetBrain's YouTrack. Oleg Gerovich mentions using the "triggered by" column there.
It might be possible to create a plugin to do what you want.
Now remember, you're only asking if it's possible in your question. Feel free to update your question. ;)
My Hudson projects don't seem to properly aggregate downstream test results and I'm wondering if I've missed a configuration step somewhere. I have two projects, Foo and Foo-Tests, both of which are freestyle jobs.
On project Foo I have the following configuration:
Checked "Aggregate downstream test results".
Checked "Automatically aggregate all downstream tests" under the previous option.
Checked "Build other projects" and specified "Foo-Tests" to build.
On project Foo-Tests I have the following configuration:
Checked "Publish JUnit test result report" and specified my JUnit report XML files.
When Foo builds, it builds successfully and correctly triggers a Foo-Tests build. The Foo-Tests build is successful and publishes the JUnit reports correctly. However, when I look for the aggregated test results in Foo, there's a "Latest Test Result (no tests)" link for the build which sends me to a 404.
Here's what I've tried that doesn't solve the problem:
Tell Foo to "Publish JUnit test result report" with no parameters (there are no tests in project Foo, just Foo-Tests). This caused an error since there were no test files for it to process within the project.
Tell Foo-Tests to "Fingerprint all published artifacts" with no parameters (I was wondering if Hudson treated JUnit reports as artifacts behind the scenes). This caused an error since I hadn't explicitly defined any artifacts to publish.
I'm using Hudson 1.266.
Edit:
I should note that I've found two questions on the Hudson Users mailing list that have no answers and would possibly help solve this:
Question 1 (Nabble)
Question 2 (Nabble)
We're using Hudson ver. 1.324 and had similar trouble. Although you mention that you tried enabling fingerprinting and it didn't work for you, it did for us. We followed the instructions found here:
http://shotgunsandpenguins.blogspot.com/2009/07/how-to-aggregate-downstream-test.html
I was able to replicate your problem with Hudson 1.266. This a Hudson error, which was fixed in a later build (prior to 1.287), so either upgrade Hudson or use this two-click workaround: from the Project page, go first to Latest Build and then Aggregated Test Results.
The problem is that the Project page for Foo is only showing the Latest Test Results link, which has a URL like http://localhost:8080/hudson-1.266/job/Foo/lastBuild/testReport/. Since Foo has no tests of its own, this link has no JUnit XML file to reference and returns the error you mentioned. This was fixed somewhere between 1.266 and 1.287 by redirecting from latestBuild/testReport/ back up to latestBuild/ when there are no tests. The alternative for you in 1.266 is to, instead of clicking on Latest Test Results in the Project page, scroll down a bit and click on Latest Build under Permalinks. This will take you to the latestBuild/ URL, and from there you can click on Aggregated Test Result, which has a URL like http://localhost:8080/hudson-1.266/job/Foo/lastBuild/aggregatedTestReport/. On this page, all your test results from downstream projects will be available under the Drill Down section.
Unfortunately, there is still a problem with the Drill Down links, even in 1.287. From Foo, when you drill down to Foo-Tests as outlined above, you will be taken to a malformed URL, which looks like http://localhost:8080/hudson-1.287job/Foo-Tests/. You'll have to manually modify that URL to insert a / between the hudson context and the job path following it so that it looks like http://localhost:8080/hudson-1.287/job/Foo-Tests/. Then you will be able to actually see the downstream test results.
I haven't had a chance to look through the Hudson source to find the error, but there's already an issue open for this. Its issue 1574, and its been open for almost a year.
On a side note, I really love Hudson for CI, but their interface isn't as smooth as it could be. I look forward to their rework of the UI in ExtJS. Maybe thats what they're spending all their time on.
I fixed the missing '/' issue in Hudson 1.288
The key to using the aggregate downstream tests results is to run fingerprinting on both jobs. In this case, that would be 'Foo' and 'Foo-tests'
Hudson matches up the build with the downstream tests by finding files with identical fingerprints. So this means your fingerprints have to match. Kind of like a crime scene.
the two projects, Foo and Foo-Test, have to know they're on the same stream, so it takes fingerprints (and therefore archiving) of a common file.
i had to pick a file that didn't change between the running of Foo and Foo-Test, and still changed between times they are both run. for me that was an unrelated, temporary .jar generated by Foo in the custom/common workspace for my versions of Foo and Foo-Test.
i.e., i had to let both Foo and Foo-Test fingerprint the same file.
after that, at least with hudson 1.330, things work - aggregated links, drilldown, etc.