-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: set_pipeline
step
#31
Conversation
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
@vito Please consider to support pipeline self set. For example, for the I see you have create issue #4254 to track implementation of |
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
031-set-pipeline-step/proposal.md
Outdated
Pros: | ||
|
||
* Fairly straightforward semantics which seem to support a natural follow-up | ||
question after learning about the `set_pipeline` step. | ||
* Keyword use has precedent in `version: every`/`version: latest`/`inputs: all`. | ||
|
||
Cons: | ||
|
||
* Supporting both self-updating pipelines and projects could cause confusion | ||
and fragmentation; it doesn't seem wise to have two competing approaches to | ||
the same goal. | ||
* Given that `self` isn't *critical* (it's easy to work around through | ||
templating, i.e. `set_pipeline: ((name))`), is it worth the | ||
risk/maintenance? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have multiple teams and 100s of pipelines coming from multiple git repos. We are addressing fly sp
workflow for all changes to pipelines ymls with pipeline_resource and/or a custom built resource with fly binaries listening on these pipelines files/folders.
Even though we do not have strong preference for using either pipeline name or self
as set_pipeline values( Good that we support both :) ), we are really excited for the set_pipeline plan. We also go through lot of compliance/audit related activities periodically and pipeline config changes being tracked in the same git repo as the pipeline definitions will help a lot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a relatively small set of pipelines, so both ways are ok for us. Honestly, I like the self
build in reference it is clean, straightforward, and easy to deal with.
This is a follow-up change of PR#4708 to add "set-pipeline: self". The RFC is concourse/rfcs#31. Signed-off-by: Chao Li <chaol@vmware.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Weird error...
changing the file path to |
Works so far, although I would like to see the team name to be able to be changed. Right now I have four teams which all have their own auto-setting pipeline, which I would like to merge into one. |
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Err, that guidance aside... The old pipeline resource accepted globs in its I thought I'd flag it in case this is an unintentional reduction in functionality. |
@DanielJonesEB Interesting, definitely not intended. Good call! That worked previously because the resource itself performed glob expansion against its local filesystem. For the @osis Ack, hmm, that's a silly bug, but funnily enough kind of related to the above problem too. 🤔 🤔 🤔 I wonder if we need some sort of pseudo-filesystem abstraction. @TheDevMinerTV That's a tricky one. Configuring within the team is somewhat easy because we can assume someone set the configuring pipeline within that team and therefore they have authority to set other pipelines. But once you go cross-team, that same assumption is no longer valid - only if you're the I think this touches on a larger goal of full-stack automation, which might involve things like a |
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Sounds fair 😄 |
Coming from concourse/concourse-pipeline-resource#10, is set_pipeline step gonna support destroy or there will be a destroy_pipeline step in the roadmap? |
@xtremerui I don't think we'll need destroying with the advent of pipeline archiving, where you can just remove the step from you config. |
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
|
||
For example, the step should only ever configure one pipeline at a time - it should not support the `pipelines:` functionality for configuring a bunch at once. | ||
|
||
Similarly, the step should not support fully dynamic configuration (`pipelines_file:`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi !
I'd like to to know which part of 'concourse-pipeline-resource' dynamic configuration do you plan to implement ? It could be great to have all "keys" (var_files
, team
, config_file
, vars
, unpaused
and exposed
) except as you said pipelines
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far, vars
and var_files
are implemented, config_file
is the same as file:
, unpaused
is just forced as true
, team
is experimentally supported (collecting feedback here: concourse/concourse#5731), and exposed
has just been proposed (https://github.com/concourse/rfcs/discussions/75).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for answering!
I should have miss something about dynamic configuration of set_pipeline
. For me, dynamic config was like file
for task (https://concourse-ci.org/config-basics.html#schema.file-path), or https://github.com/concourse/concourse-pipeline-resource#dynamic for a single pipeline. So, is it possible to generate set_pipeline
config using previously executed task, for instance to select var_files to apply ?
Is it planned to implement a get_pipeline step in the future, to do what the concourse-pipeline-resource was doing as "in"? |
@gid0 There are no plans for this at the moment. If you've got a use case for this, feel free to open a new discussion! |
Rendered
Please comment on individual lines, not at the top-level.