Change a pipeline label using the API

[mdaliejaz]

Description

As a Go API client

• I want to be able to change the label of a pipeline using the API
• So that I can update the label of a pipeline as part of a step in my builds

[djleeds]

I'd love to see this feature! I'm working on a project where I'd like to use semantic versioning for the base version numbers (e.g., 1.4.3) maintained in a maven pom.xml file, but have Go append the ${COUNT} number to that. The resulting label would be something like 1.4.3-178.

As it is today, you have to edit the value in the Label Template field in Go -- for example, updating it from 1.4.3-${COUNT} to 1.5.0-${COUNT}. This can be a problem because of timing -- if Go picks up my new commit before I had a chance to edit the label field, the version number for that build would be incorrect -- for example, it'd be 1.4.3-179 instead of 1.5.0-179.

[zabil]

This should be a part of modifying a pipeline resource once an endpoint for pipeline is introduced using #1100

[rprieto]

I would love this feature as well. In our case, each build generates its own build number (e.g. module semver, git tag, ...). For now our Go pipeline shows 67, while the artefact is actually called email-service-1.4.2-35.

Being able to change it from the build itself would be great, especially if it's a one-line integration piece (i.e no complex API calls, maybe even just creating a VERSION artefact with the build number inside).

[rprieto]

Hi, is there any news on this front? Where's the best place to look to see if this particular API endpoint has been merged? (http://api.go.cd/current/ show "pipeline" endpoints, but nothing about updating the build number yet)

[jyotisingh]

@rprieto You can subscribe to #1417 which is about building the pipeline-config API.

[zabil]

Implemented as a part of #1417

[arvindsv]

I don't really think #1417 solves this. That change pipeline label template. This issue talked about changing the pipeline label (of an existing or new pipeline). Right?

[rprieto]

I think you're right. For me this issue was really about a build being able to update the "build label", so that instead of just showing 1, 2, 3... a pipeline can display anything the team finds valuable, e.g.

• 1_ab83c90f, 2_e639bf7c... (commit sha)
• 1_2.0.0, 2_2.0.0, 3_2.0.1 (release number as defined in package.json)

The API in #1417 seems to be about updating pipeline definitions, not this.

It would be very nice if we didn't even have to call the API for that, for example

• if a build has an artifact called BUILD_LABEL the contents gets appended to the build number
• or the way TeamCity does it, parsing the build logs to find a specific line like #go build_label=foobar

[testusergo]

There is some relevant conversation here, here and here.

[arvindsv]

Sorry, that (previous comment) was me. I was trying out something as a different user.

[darrenr]

Is this item going to get re-opened as the config changes in 15.3 have not address this?

[arvindsv]

@darrenr: Yes, reopening this.

[manifest]

Hi @arvindsv ! Is there any news on this issue?

[ckaushik]

@arvindsv: I would also like to have our pipeline labels reflect the pom versions, as suggested by @rprieto and @djleeds

This github issue seems to be about updating the label template using an API. So is there another ticket tracking this feature request? I know there was some discussion about introducing an option of plugins for this, but I couldn't find anything related to it on github

[arvindsv]

@ckaushik: This is the issue for changing the pipeline label (not just the template). Though there has been work on other APIs, this one hasn't been picked up yet. The plugin issue you're thinking about it probably https://github.com/gocd/gocd/issues/1784.

When this is picked up, someone will need to verify what happens when two pipeline runs end up having the same label (which is what the current mechanism tries to prevent).

[ckaushik]

Thanks @arvindsv. My understanding was pipeline labels are only for readability and it is not used in vsm as an identifier. So I think it is okay to have same label across different pipeline runs. For example if I trigger an older build of an app, say 1.3.4, the pipeline label can be shown as 1.3.4 again.

Please correct me if I am wrong

[henriquegemignani]

The current system does not prevent different runs with the same label. You can set the label template to be ${Material}, making the label the same as the material's label. If you run this pipeline twice, both runs will use the same label.

[arvindsv]

@ckaushik and @henriquegemignani: Correct. As I mentioned, I'd just want to verify that everything will be ok. As you two mentioned, it already happens - so it should be alright in that sense (it shouldn't crash or anything, I mean). But, there is one feature - pipeline comparison, which uses the label and I'm not sure exactly how or why it does that. The code is around here and I would expect it to break if an API allows the label to be changed. So, I mean looking for things like that.

You can also see label being used in some queries such as this and this.

So, if label is used for something important, we might need to consider introducing another piece of information (column) like "displayLabel" or something - as an alternative.

Warning: No one I know is currently working on this. So, it's open to be picked up.

[manifest]

@arvindsv It looks like we can use GO_PIPELINE_COUNTER environment variable to build an unique label dynamically (something like, "${MY_PROJECT_SIMVER}-${GO_PIPELINE_COUNTER}"), this way having the same label isn't an issue as I see it.

[j2ghz]

Any news on this part of the issue?

or the way TeamCity does it, parsing the build logs to find a specific line like #go build_label=foobar

[sautez]

Wanted to follow up on this. Any news? I've been trying to get the label to update and the best I can do is update the label-template via the API. I would consider writing a Plug-in but can't find out if that will help. That is, can I write a plug-in that will trigger on pipeline play button so that I may update the label-template prior to the build process happening and turning yellow and refreashing the label.

The other option I see here is the ability to have an API call that will refresh the label based on the label-template. This is something that is confusing to me now as if I change the label-template now it will not change the displayed label until the next build. Which I do under we are looking at the last run.

In either case, at the end of the day I need a way to alter the label from code that is inside the Pipeline. I have thought about creating another pipeline who's job is it to update the downstream pipeline with the correct label. Seems a bit too ridiculous as that would be it's only job.

thoughts? Progress? Suggestions on where I may go and look to build a solution?

[vaibhavparnalia]

+1 Our first pipeline is triggered remotely and there is no way for us to label or track the version in gocd currently.

[sautez]

I found a way to do it as noted above. I have a pipeline that it's entire job is to build a label. It then updates the downstream pipeline Parameter with that new label and then the build happens and reads the parameter which includes the Version, Build # and GIT MD5 Hash(cut). This is working for us to know what version is being built but it seems like an extra step. We use the API to update the downstream pipeline parameters. We also use GIT API to retrieve other information.

Posting as a possible solution for others.

[GaneshSPatil]

@arvindsv -- With environment variables support for Pipeline Label, can we close this issue?

[arvindsv]

@GaneshSPatil - I think it's not completely the same (@GaneshSPatil is talking about the ability to use environment variables in pipeline label). That happens only when force triggering a pipeline.

[magowant]

As has been discussed in #1784, maybe consider implement something like TeamCity's build messages? That way a build can specify the label itself.

[dlethin]

What about a solution where in a pipeline label you could reference a property from an upstream pipeline-material - something like ${prop.pipeline_dep.job_name.custom_prop}? This would require a similar approach as mentioned above where there is a dedicated pipeline just for generating and setting the downstream label, but it would do this not by modifying the label of the downstream pipeline label, but instead by calling the go-api to set a property on the running job.

Taking this a step further, this could be one implementation of a pluggable extension point for defining custom label resolvers, which could get referenced like ${upstreamProp(pipeline,job,property)} - upstreamProp could be an identifier the plugin registers, and the plugin would have access to the supplied parameters, as well as environment variables in order to perform the specified string interpolation.

[dlethin]

Following up on my previous comment regarding a plugin framework to support custom pipline label resolvers, it sound like issue #1784 is eactly that - Plugin Infrastructure for Pipeline Label Templates

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. If you can still reproduce this error on the master branch using local development environment or on the latest GoCD Release, please reply with all of the information you have about it in order to keep the issue open. Thank you for all your contributions.

[PauloJFCabral]

I would like to add the branch name to the pipeline label. It is possible?