Feature Request: Custom the build label

[ericmm]

Hi,

Is it possible to custom the build labels triggered by different branches? e.g. if the build '1.11' is from 'master', then custom the build label to '1.11-master', if the build '1.12' is from 'branch1', then custom the build label to '1.12-branch1'

Thanks.

[ashwanthkumar]

Probable duplicate of #87

While this feature is not easy to implement because GoCD doesn't have support for it, I would really like to understand what's the use-case for this feature? When looking at the Pipeline history page it wouldn't serve much information because each build can be for a different branch (and sometimes they would be stripped because branch names are too long). Instead we emit the branch info as an environment variable in the tasks of the PR plugin, and we can easily push that to a notification system like Slack or send out an Email for visibility.

[ericmm]

Thanks for the reply, the use-case for this feature is we can easily identify from the build label if it's a candidate release build or not. In go configuration, it supports something like labeltemplate="15.1.${COUNT}-${git[:7]}", which appends first 7 git hashcode to a build label, but this is what I am looking for.

Let's say we have two branches, one called 'production' and other one is 'master', if we don't use this plugin, we'll have two pipelines, one for master and one for production, and they can have different label templates, say master is starting from 1.xxx, and production is from 2.xxx. If we use this plugin, all changes committed will be triggered into one pipeline, let's say the template is 3.xxx, if I am given a build label '3.123', I don't know if it's a production branch build or master branch build unless I dive into the output details.

hope this clarifies.

[ashwanthkumar]

@ericmm The original intended purpose of these plugins is to build feature branches or pull requests, both of which are short-lived. These plugins should not be used to build multiple long live branches.

Going by your example, you might want to take master branch artifacts through a series of pipelines and production branch artifacts differently. By having a single pipeline to build both, you loose all the features GoCD gives you in terms of artifact propagation (and VSM).