Skip to content
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

enhance(ruleset): add stage status rule for independent stages #1215

Closed
wants to merge 3 commits into from

Conversation

ecrupper
Copy link
Contributor

@ecrupper ecrupper commented Oct 25, 2024

Ref: go-vela/community#910

Example pipeline:

version: "1"

stages:
  failing:
    steps:
      - name: fail
        image: alpine:latest
        commands:
          - exit 1

      - name: run on failure
        image: alpine
        ruleset:
          status: failure
        commands:
          - echo fail

  indy:
    independent: true
    steps:
      - name: wait
        image: alpine:latest
        commands:
          - sleep 3

      - name: should not run
        image: alpine:latest
        ruleset:
          stage_status: failure
        commands:
          - echo "why am I running"

Before:
Screenshot 2024-10-25 at 10 06 57 AM

After:
Screenshot 2024-10-25 at 10 06 38 AM

@ecrupper ecrupper requested a review from a team as a code owner October 25, 2024 15:00
Copy link

codecov bot commented Oct 25, 2024

Codecov Report

Attention: Patch coverage is 84.84848% with 5 lines in your changes missing coverage. Please review.

Project coverage is 56.87%. Comparing base (f463fc9) to head (6d7b268).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
compiler/types/pipeline/ruleset.go 28.57% 4 Missing and 1 partial ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1215      +/-   ##
==========================================
- Coverage   56.87%   56.87%   -0.01%     
==========================================
  Files         599      599              
  Lines       32856    32866      +10     
==========================================
+ Hits        18687    18692       +5     
- Misses      13535    13539       +4     
- Partials      634      635       +1     
Files with missing lines Coverage Δ
compiler/types/yaml/ruleset.go 100.00% <100.00%> (ø)
compiler/types/pipeline/ruleset.go 74.32% <28.57%> (-2.44%) ⬇️

@wass3rw3rk
Copy link
Member

wass3rw3rk commented Oct 28, 2024

i don't know if it's just me, but it seems counter intuitive to have status: failure that will run the step on build failure and then stage_status: failure which will not run the step. were there other options you were experimenting with?

@ecrupper
Copy link
Contributor Author

i don't know if it's just me, but it seems counter intuitive to have status: failure that will run the step on build failure and then stage_status: failure which will not run the step. were there other options you were experimenting with?

Sure. The other option I had was keeping status the same but having independent stages only acknowledge that rule when the failure is from its own stage. I'm a little confused on why the hang up on stage_status. The most clear example of this being useful is a notification plugin: "Stage A failed". This is currently impossible to set up accurately

@wass3rw3rk
Copy link
Member

wass3rw3rk commented Oct 29, 2024

to be clear, i'm not against the functionality. little hang up on the terminology and potential confusion with what we already have in place.

status implies build status, so stage_status seems fine to differentiate, though it's unclear if that means any stage's status, the current stage's status, a dependent stage's status, since there is a one to many relationship.

the other part is that a step with status: failure runs that step when there's a build failure, whereas a step within a stage with stage_status: failure does not run that step when there's a stage failure(?).

the independent stage is inverting the logic/meaning. at this time, i don't have a better alternative though 🤔

@ecrupper
Copy link
Contributor Author

ecrupper commented Nov 4, 2024

I am going to close this PR in favor of pursuing a purely worker repo solution:

An independent stage should only use the status rule for its own stage's status. The point of an independent stage is to be independent from the rest of the build, so having a status rule that checks the overall build status doesn't make any sense. If that's a requirement, then the stage is no longer independent.

@ecrupper ecrupper closed this Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants