#gocd

Is it possible to get the label of a grandparent (parent of the upstream pipeline) pipeline?

Anyone know if it's possible to get the label of a grandparent (parent of the upstream pipeline) pipeline? Like $upstream but the one above that...

Hi! I discovered gocd today, and I'm pretty much looking forward to give it a try. I was wondering if "elastic agents" is a thing now, or the Release 15.3 proposal page is correct and it hasn't been developed yet

tlauder: if you know the name of the pipeline, you can use the API to pull properties

tlauder: you may want to set a property on the stage in question so that it can be read by any stage

tedbot: I want to customize the label of a downstream pipeline with a grandparent label so I don't think I can use the API for that

oh you mean within the app? yeah, I haven't seen any way to do that

I hear they accept pull requests :)

:)

It's common practice to set the parent's label to that of the grandparent's and then the child's label to that of the parent.

That way, all labels are the same (and propagate downstream).

You can see it done on https://build.go.cd (Username: view, Password: password).

You can see that all labels are the same here as well: https://build.go.cd/go/pipelines/value_stream_m...

Makes it easy to follow a build's progress across pipelines too.

Yeah, normally I would do that but in this case this pipeline can't be fully CD so the downstream pipeline is pulling in part of the same material it's parent is. In this case it's pulling chef cookbook from it's parent but a package artifact is shared by both

So with that type of setup, if I use $(upstream_cookbook}-${package_artifact} in the parent and ${upstream_pipeline}-${package_artifact} in the child, I end up with $(upstream_cookbook}-${package_artifact}-${package_artifact} in the end

This would all go away if I could just use a CD workflow for this package :(

Why not just use ${upstream_pipeline}, instead of ${upstream_pipeline}-${package_artifact}?

Because the child pipeline depends on part of upstream and depends on 1 material shared with upstream, so the cookbook code flows from upstream -> downstream but the application code flows directly to upstream and directly to downstream.

It's a workaround for wanting to do CD for the cookbook code but not being able to do CD for the application code itself