Pipeline step types proposal #81
Conversation
amfred
requested review from
aglover,
agrimmer,
ahpook,
bobcatfish,
fdegir,
MarckK,
ravilach,
tracymiranda and
zxiiro
as code owners
docs/vocabulary.md
Outdated
| Each type of Pipeline Step will generally have several implementations that are tool specific. For example, Source will have implementations for various Source Code Management (SCM) tools. Publish will have implementations for each type of repository, and so on. | ||
|
|
||
| #### Setup | ||
| * Semantics: Provision build resources, set up the build workspace. |
There was a problem hiding this comment.
Is the Setup stage specifically for preparing for builds?
Could it also be used to prepare for tests?
If not, consider naming it "Build Setup".
There was a problem hiding this comment.
i had a similar comment on PR #76 (comment) since similar setup steps are required for other stages.
There was a problem hiding this comment.
Let's put "Build Setup" and "Test Setup" as two different examples of setup steps. If you're running one pipeline that builds and tests you might only need one setup step, or you might want a "daily test pipeline" that only setups up its test environment and runs tests, without a build. I took "build" out of the description of this one.
There was a problem hiding this comment.
I'll put this in a separate PR just because the merge conflicts are getting fun.
There was a problem hiding this comment.
Actually, nix that last comment; I had already taken "build" out of the name.
docs/vocabulary.md
Outdated
| Each type of Pipeline Step will generally have several implementations that are tool specific. For example, Source will have implementations for various Source Code Management (SCM) tools. Publish will have implementations for each type of repository, and so on. | ||
|
|
||
| #### Setup | ||
| * Semantics: Provision build resources, set up the build workspace. |
There was a problem hiding this comment.
i had a similar comment on PR #76 (comment) since similar setup steps are required for other stages.
|
As part of #83, we've been wondering how the notion of "quality gates" relates between this and #76. A quality gate, in my mind, ensures that the things that come after it are in some way safer than before it went through the quality gate. Like, if we think of a load test quality gate.. the artifact is lower risk after this, because we know it can handle some set amount of load (else it would fail the gate). So the question is.. Is "quality gate" a step? Or can steps be quality gates? Or is there something that sits between step & stage called quality gates and a quality gate is just made up of steps? Not sure if this is the right place to have this conversation, but you've done a ton of smart thinking about this @amfred and thought it would be relevant to this proposal. |
|
@justinabrahms I think you're right; quality gates are often implemented as steps in a pipeline. In fact, ideally we want most of our quality gates automated, and pipelines are a great way to do that. So we might as well use consistent terminology! Quality gates might be manual, but then we don't talk about them as much in the pipeline context. From a pipeline perspective, manual steps could manifest as opening an issue or a request. Or they might happen entirely apart from the pipeline, in a paper process. |
|
Similar to #76, could we merge this if there is no major concern? |
Co-authored-by: Justin Abrahms <[email protected]>
amfred
requested review from
OliverNocon,
afrittoli,
thedevelopnik and
rakhbari
as code owners
Co-authored-by: Mattias Linnér <[email protected]>
These are inspired by https://github.com/open-toolchain/tekton-catalog and https://ploigos.github.io/ploigos-docs/#_everything_workflow in particular, but I believe the terminology here is generally accepted. I used the term "build step" because it's the most commonly used term for this level of pipeline implementation, from the overview above.
I recommend putting this section just after the Stages, but this section can also stand alone.
#77