On a project following the basic workflow described here, we had the following scenario:
- At some point of time, release tag 'v126.96.36.199' was placed on 'qa' branch and that version went into production
- Later, while development continued on the 'master' and 'qa' branches, a fix was needed for the previous release, so we've created a branch 'release1.1.200' from the last release tag, commited the fixes into it, and placed a new tag 'v188.8.131.52' on the last commit of the release branch - pushing both the commits and the tags to the origin.
- On the CCNET automated build, when getting the code using the Git source control plugin, we specified 'release1.1.200' as the branch to use, and expected to get '184.108.40.206' as the CcNetLabel
But instead of that, we kept getting a '220.127.116.11' label ¿?
By following the CCNET server log, we've found out that the sequence in which the Git source control plugin works is:
- repository is cloned or updated
- labeller is invoked
- branch specified in CCNET configuration is checked out (!)
So when the labeller tries to get the last tag by invoking git describe, it receives something like 18.104.22.168-xxx where xxx specify the commits present after that tag.
Once the problem was clear, the solution was to add to the labeller configuration an (optional) element specifying a branch to ckeckout, and to do so within the labeler before issuing git describe.
As a final touch, we've also upgraded the labeller to support dynamic parameters, so the name of the release branch could be specified dynamically when launching the build. The updated labeller is available at its Gitub project .