document set_pipeline step
#281
Conversation
implemented in concourse/concourse#4708 Signed-off-by: Zoe Tian <ztian@pivotal.io> Co-authored-by: Jamie Klassen <cklassen@pivotal.io>
lit/docs/jobs/steps/set_pipeline.lit
Outdated
|
|
||
|
|
||
| \define-attribute{set_pipeline: string}{ | ||
| \italic{Required.} A freeform name for the action of configuring the pipeline. |
There was a problem hiding this comment.
This field is actually the name of the pipeline; there is no separate 'name' field.
lit/docs/jobs/steps/set_pipeline.lit
Outdated
| - get: booklit | ||
| trigger: true | ||
| - set_pipeline: set-booklit-pipeline | ||
| name: booklit |
There was a problem hiding this comment.
This should just be set_pipeline: booklit.
lit/docs/jobs/steps/set_pipeline.lit
Outdated
| \example{Self-reconfiguring pipeline}{ | ||
| This is a reasonable way to get Concourse to mimic the default behaviour of | ||
| some other CI systems, where the automation configuration is automatically | ||
| read from a source code repository and updated on every commit. |
There was a problem hiding this comment.
I don't think we want to focus on this aspect of the set_pipeline step just yet. For now, I think its sole purpose should be to configure other pipelines, as opposed to self-updating pipelines.
Self-updating pipelines are a little misleading; you can have a set_pipeline step at the start, and use passed constraints to gate job execution on the pipeline being reconfigured, but what's misleading is that the new configuration actually applies to all jobs at once. There may be downstream jobs waiting to run, but with an older version of the repo with a task config that's no longer compatible with the pipeline config (because a get step was added/removed, for example).
This is solved in the future with the introduction of Projects (concourse/rfcs#32), which makes the distinction between CI config vs. product code more explicit - keeping CI config always in sync, and representing product code as a separate resource to which passed constraints can be applied without resulting in desync'd task configs. I have somewhat rambling thoughts on this here: https://github.com/vito/rfcs/blob/projects/032-projects/proposal.md#exposing-only-the-config-directory
Until then I think we should set expectations for set_pipeline as a replacement for the concourse-pipelines resource type which just makes it easier to automate configuration of your other pipelines. The "race condition" I mentioned still exists, of course, but in this form it at least is more obvious that the problem isn't addressed, and it's merely running fly set-pipeline for you.
There was a problem hiding this comment.
...However it's probably worth documenting these nuances and painting a picture of the future we're striving for, since people might try to use it in this way regardless. This kind of content can probably appear in the main documentation page. I can work on that if you like!
and change 'self-reconfiguring' example to simpler 'one pipeline reconfiguring another'. Signed-off-by: Zoe Tian <ztian@pivotal.io> Co-authored-by: Jamie Klassen <cklassen@pivotal.io>
implemented in concourse/concourse#4708