Changing the target of VCS labelling

Answered

Created September 01, 2020 13:11

The following describes our current setup. It is a bit special and probably not ideal, so feel free to suggest another way of achieving the same results:

Build A builds several branches and publishes resulting artifacts (typically jar files and some reports). It uses a `VCS Root 1`
Build B can reuse builds from build A and the associated artifacts to produce a new artifact (an exe file). It also uses `VCS Root 1` and gets the build script from the `develop` branch (no matter which branch originated the built the artifacts).

Build B accepts an optional parameter, tagName, when building, which it will use when naming the resulting exe file. If none is supplied it will use the a commit sha and build number supplied from Build A to name the resulting artifact, typically `a57d88_b437.exe`. If the tag is supplied it will name the artifact `{tagName}.exe`. It will also try to tag the commit and push the tag to Github. It's this latter part that does not work, as all authentication with the remote is handled by TC, so my script is unable to reuse the Connection specified in TeamCity.

I was wondering if I could somehow use VCS Labelling to do the tagging for me, but I know it's not a great fit, as VCS Labelling works on the sources of a build, not the "parent" build's sources. That means if I give the tagname to VCS Labelling, it will label the checked out branch in Build B (`development`) and not the build in A that originated the build in B.

3 comments

Fedor Rumyantsev

Created September 04, 2020 15:16

Hello!

There are two solutions I could think of:
1) as you know the revision of build A when build B is started, you could introduce a dummy build C which only function would be to label the sources (via VCS Labeling feature). For example, you may set up an additional build step in B which will make a custom REST API request like below:

[POST] /app/rest/buildQueue

<build>
  <buildType id="Build_A_Configuration_ID"/>
   <lastChanges>
    <change id="modificationId"/>
  </lastChanges>
</build>

The modificationId, in turn, may also be resolved via REST API through the below call (using commit SHA from build A):

[GET] /app/rest/changes/version:5aa4d61ff0e3da5e7b4d31edbdc1941bbdbce6c3/id

2) alternatively, you may call GitHub REST API directly (https://docs.github.com/en/rest/reference/git#tags) - please mind that would probably require token for an account capable of tagging sources on the VCS side to be stored somewhere, e.g. in password-typed parameter.

Please let me know if either of the above works for you.

Carl-Erik Kopseng

Created September 08, 2020 00:05

Hi, Fedor! Thanks for the nice ideas. I am not sure I totally follow on the first suggestion, though, as the REST calls does not lead to anything being built for config C. I have been trying it out in various ways for the last hour without getting much further. I cobbled together a small shell script that gets a change id like this:

curl -s 'https://teamcity.server/app/rest/builds/12086' \
-H 'Accept: application/json' \
-H 'Cookie: TCSESSIONID=foobarB78E8D23473188BB887kwanza' \
| jq .lastChanges.change[0].id 
# returns the change id --> 26739

I then plugged that into your request, substituting "modifactionId" for 26739 and the correct id for the build type id.

This triggers a change in build configuration A. Which is not that surprising, but hardly what I want :-) We wanted to trigger a build for the dummy build configuration C. The problem is that if I replace the `buildType[id]` with the id for config C it says

Responding with error, status code: 400 (Bad Request).

Details: jetbrains.buildServer.server.rest.errors.BadRequestException: Cannot trigger build, if the 
changes are specified, they should be visible on the build configuration Change Log under the requested branch.
Original error: Revisions are not found for build configuration Dummy Build Config C {id=Dummy_Build_C, internal id=bt36}

Invalid request. Please check the request URL and data are correct.

So, in order to trigger a build for a specific change, that change needs to already have been built by that build configuration, if I understand this right. And that does not seem that useful to me ...

We want to

use the commit sha (known from build a), $SHA
use a given label (known from build b), $LABEL
use these two to trigger a build in C that will end up labelling commit $SHA with $LABEL

Fedor Rumyantsev

Created September 08, 2020 21:08

Hello Carl-Erik,

I have just double-checked the logic locally and got the above request working. One major thing that I should have described in more detail is that the revision that you try to execute (the one in lastChanges node) has to be known to TeamCity. It is not necessary that there is a build on the revision, but it should appear on the Change Log tab of the configuration view in order for this logic to work.

With this in mind, could you please let me know if:
a) configuration C uses the same VCS root as A/B configurations?
b) if configuration C ever had any builds? (so that new changes have a "base" to be compared against)

Per my test, I have made a commit to VCS on a fresh configuration with no builds and have tried to execute it; it did fail because revision was not found. After that, I have started build manually and done three more commits, awaited until Change Log tab contained the corresponding changes, then ran commit 2 (out of 4 total) via above request - the revision was properly handled. The test has been executed on 2020.1.3, but the logic should apply for at least a couple of years.

On a separate notice, there is a feature request to allow more control over the build revisions: https://youtrack.jetbrains.com/issue/TW-5610; please feel free to vote/comment if you find it interesting.

Please sign in to leave a comment.