feat(stage): add independent tag for independency

[ecrupper]

Part of the effort for go-vela/community#546

Adding a independent tag at the stage level. When this is set to true, that stage will continue to run regardless of the status of the other stages. It will, however, still fail if one of its own steps fails (rulesets depending). The functionality of that will be in a separate PR in go-vela/worker.

Below is a sample pipeline:

version: '1'
stages:
  quick-stage-1:
    steps:
      - name: execute fast
        image: alpine:latest
        commands:
          - echo "executing"
          - exit 1
      - name: do not execute
        image: alpine:latest
        commands:
          - echo "should not see"
  slow-stage-1:
    independent: true
    steps:
      - name: execute slow
        ruleset:
          event: push
        image: alpine:latest
        commands:
          - sleep 5
          - echo "executing"
      - name: status success only
        image: alpine:latest
        ruleset:
          status: success
        commands:
          - echo "executing"
      - name: do not skip this step
        image: alpine:latest
        commands:
          - echo "success"
  slow-stage-fail:
    independent: true
    steps:
      - name: execute slow 2
        image: alpine:latest
        commands:
          - sleep 5
          - echo "executing"
      - name: execute fast
        image: alpine:latest
        commands:
          - echo "executing"
      - name: fail this step but continue
        ruleset:
          continue: true
        image: alpine:latest
        commands:
          - exit 1
      - name: fail this step
        image: alpine:latest
        commands:
          - exit 1
      - name: skip this step
        image: alpine:latest
        commands:
          - echo "not skipped"

The names of the stages and steps in the above pipeline give a good idea as to how this pipeline should execute using the independent tag. In summary, the default behavior remains unchanged, while the addition of independent to a specific stage will have that stage operate independently but still giving way to any ruleset specified in the steps.

I would love to hear any feedback, design suggestions, or overall concerns!

[codecov]

Codecov Report

Merging #247 (ec7dea8) into main (9661c89) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #247   +/-   ##
=======================================
  Coverage   96.93%   96.93%           
=======================================
  Files          57       57           
  Lines        6301     6306    +5     
=======================================
+ Hits         6108     6113    +5     
  Misses        143      143           
  Partials       50       50           

Impacted Files	Coverage Δ
pipeline/ruleset.go	100.00% <ø> (ø)
pipeline/stage.go	100.00% <ø> (ø)
pipeline/container.go	86.02% <100.00%> (+0.06%)	⬆️
yaml/stage.go	100.00% <100.00%> (ø)

[cognifloyd]

I'm undecided on using continue as a stage key. But, I've left my questions (so far), and noted some debug prints that need to be removed.

[wass3r]

regarding naming

TL;DR - continue works for me.

i don't mind continue and conceptually it's similar to continue in rulesets. one alternative naming is continue-on-error used in GitHub Actions, which is pretty explicit, but then i'd almost feel like we'd have to adopt that in rulesets as well, maybe 🤔

regarding design

this granular per-stage control is good, but i wonder if we should have a higher level fail-fast-like option that exists in some other CIs. it's often true by default afaik, which would be applicable to us as well in its current state. if set to false, it's the equivalent of setting continue: true on all stages per your proposal here. it would be a stages-only setting, i think, so i'm not sure where this higher level spot would be - metadata? how often would people choose that over setting it individually? might be good question for our users :) regardless, this PR could be a stepping-stone towards that maybe.

@kneal @jbrockopp curious about your thoughts as well, since you worked a bunch on the design?

[kneal]

I think the design is fine personally. I'm not sure how many options there are, we don't have a ton of explicit type keys like continue-on-error. So, just sticking with continue: true is fine by me because it does have some symmetry with the ruleset. Overall, I think there are other implementation options we could have picked but this is probably the lowest hanging fruit.

To be honest, when I saw the story I wasn't a big fan of it because it felt like a smallish bandaid to larger features that don't/should probably exist but I get the purpose of the functionality.

So, all-in-all the implementation here seems fine to me.

[42shadow42]

I'm undecided on using continue as a stage key. But, I've left my questions (so far), and noted some debug prints that need to be removed.

I feel like independent may be a better name, but mostly I just care that the feature exists.

[cognifloyd]

Ooh. I like independent better than continue. That feels more declarative.