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.

Sign up for GitHub

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

Jump to bottom

Command to early-exit the job and set check conclusion #662

Closed
ylemkimon opened this issue Aug 16, 2020 · 56 comments
Closed

Command to early-exit the job and set check conclusion #662

ylemkimon opened this issue Aug 16, 2020 · 56 comments
Labels
actions-feature enhancement New feature or request

Comments

@ylemkimon
Copy link

ylemkimon commented Aug 16, 2020 •
edited
Loading

Describe the enhancement
Currently to skip the rest of steps during a job, an if condition has to be added to all of steps or steps have to be moved to another job.

It'd be nice to have a command to early-exit (premature, prematurely, graceful, gracefully) (end, finish, terminate, termination, stop, halt, skip, cancel, discontinue, fail) the job during a step without failing the job:

::exit::

It'd be also nice to set the conclusion of early-exited job:

::exit::failure

(equivalent to exit 1)
or

::exit::neutral

(equivalent to exit 78 in Actions v1)
and other check conclusions.

This would help save build time for both GitHub and customers.

Additional information

Related StackOverflow and GitHub Community posts:

Related issues:

Other CIs:
@ylemkimon ylemkimon added the enhancement New feature or request label Aug 16, 2020
@a-tokyo
Copy link

a-tokyo commented Sep 24, 2020

This is really useful and is quite needed!

@mosteo mosteo mentioned this issue Oct 1, 2020
Merged
@Nukesor Nukesor mentioned this issue Oct 4, 2020
Closed
@remorses
Copy link

remorses commented Oct 9, 2020

This is useful to not repeat the same if statement many times, you can instead do an early exit

@webbertakken webbertakken mentioned this issue Oct 20, 2020
Merged
3 tasks
@billyvg billyvg mentioned this issue Oct 21, 2020
Merged
@mirestrepo mirestrepo mentioned this issue Oct 27, 2020
Open
@onedr0p onedr0p mentioned this issue Dec 18, 2020
Closed
@Croydon Croydon mentioned this issue Jan 1, 2021
Closed
@derberg derberg mentioned this issue Jan 12, 2021
Merged
@ockham ockham mentioned this issue Feb 3, 2021
Closed
@ashleywang1 ashleywang1 mentioned this issue Feb 8, 2021
Closed
@christian-kreuzberger-dtx
Copy link

This would be a great addition. Right now I have a pre-condition that I can only check in a bash-script, and I'm exiting with exit 1 for a purpose. However, in my PR it shows up as a failure :(

image

@bartlettroscoe
Copy link

I can't believe GHA does not support this. I guess you need to just implement and entire job as one big step run by your own driver script and then you can put whatever logic you want in that script to terminate early and with a zero exist (and a nice informational message). Is that the only current workaround for this?

GHA seems to be a new unique declarative language with somewhat limited functionality.

@bartlettroscoe bartlettroscoe mentioned this issue Mar 27, 2021
Open
@peterbe peterbe mentioned this issue Apr 2, 2021
Closed
@jneira jneira mentioned this issue Apr 2, 2021
Merged
@daved daved mentioned this issue Apr 6, 2021
Open
@loriab loriab mentioned this issue Apr 19, 2021
Merged
2 tasks
@ADKaster ADKaster mentioned this issue May 21, 2021
Merged
@ismay ismay mentioned this issue Jun 9, 2021
Open
aaron-prindle added a commit to aaron-prindle/skaffold that referenced this issue Jun 17, 2021
@aaron-prindle
add gh actions
d780396 
    Fixes GoogleContainerTools#6032, add code to not run Github Actions on docs-only changes. This PR:
    - Updates linux and osx github actions to check if the PR only changes docs/* files and if so, pass the test w/o running the full test suite

    Github actions does not have support for exiting the job from a step easily. See:
    - https://stackoverflow.com/questions/60589373/how-to-force-to-exit-in-github-actions-step
    - actions/runner#662
    The approach here uses an env var and checks this env var in all subsequent steps, this way no single command fails and tests are skipped as desired.  The downside is that all subsequent steps need to have this check but there is no better solution at the moment from my investigation

  I considered directly using the the 'conclusion' value github actions provides, eg:
  - "if: steps.s1.conclusion == 'failure'"
  but I believe that if a step fails then the test fails which is not what we want.

   There shouldn't be any side effects w/ this approach, all steps have a conditional on the docs-only check and should work correctly as before in the non-docs file are updated case

    N/A.  Future work generally might include a tag that also skips testing but is not directly related
aaron-prindle added a commit to aaron-prindle/skaffold that referenced this issue Jun 17, 2021
@aaron-prindle
add gh actions early success if change is docs only
83025f5 
    Fixes GoogleContainerTools#6032, add code to not run Github Actions on docs-only changes. This PR:
    - Updates linux and osx github actions to check if the PR only changes docs/* files and if so, pass the test w/o running the full test suite

    Github actions does not have support for exiting the job from a step easily. See:
    - https://stackoverflow.com/questions/60589373/how-to-force-to-exit-in-github-actions-step
    - actions/runner#662
    The approach here uses an env var and checks this env var in all subsequent steps, this way no single command fails and tests are skipped as desired.  The downside is that all subsequent steps need to have this check but there is no better solution at the moment from my investigation

  I considered directly using the the 'conclusion' value github actions provides, eg:
  - "if: steps.s1.conclusion == 'failure'"
  but I believe that if a step fails then the test fails which is not what we want.

   There shouldn't be any side effects w/ this approach, all steps have a conditional on the docs-only check and should work correctly as before in the non-docs file are updated case

    N/A.  Future work generally might include a tag that also skips testing but is not directly related
aaron-prindle added a commit to aaron-prindle/skaffold that referenced this issue Jun 17, 2021
@aaron-prindle
add gh actions early success if change is docs only
5806628 
    Fixes GoogleContainerTools#6032, add code to not run Github Actions on docs-only changes. This PR:
    - Updates linux and osx github actions to check if the PR only changes docs/* files and if so, pass the test w/o running the full test suite

    Github actions does not have support for exiting the job from a step easily. See:
    - https://stackoverflow.com/questions/60589373/how-to-force-to-exit-in-github-actions-step
    - actions/runner#662
    The approach here uses an env var and checks this env var in all subsequent steps, this way no single command fails and tests are skipped as desired.  The downside is that all subsequent steps need to have this check but there is no better solution at the moment from my investigation

  I considered directly using the the 'conclusion' value github actions provides, eg:
  - "if: steps.s1.conclusion == 'failure'"
  but I believe that if a step fails then the test fails which is not what we want.

   There shouldn't be any side effects w/ this approach, all steps have a conditional on the docs-only check and should work correctly as before in the non-docs file are updated case

    N/A.  Future work generally might include a tag that also skips testing but is not directly related
aaron-prindle added a commit to aaron-prindle/skaffold that referenced this issue Jun 17, 2021
@aaron-prindle
add gh actions early success if change is docs only
bd97977 
    Fixes GoogleContainerTools#6032, add code to not run Github Actions on docs-only changes. This PR:
    - Updates linux and osx github actions to check if the PR only changes docs/* files and if so, pass the test w/o running the full test suite

    Github actions does not have support for exiting the job from a step easily. See:
    - https://stackoverflow.com/questions/60589373/how-to-force-to-exit-in-github-actions-step
    - actions/runner#662
    The approach here uses an env var and checks this env var in all subsequent steps, this way no single command fails and tests are skipped as desired.  The downside is that all subsequent steps need to have this check but there is no better solution at the moment from my investigation

  I considered directly using the the 'conclusion' value github actions provides, eg:
  - "if: steps.s1.conclusion == 'failure'"
  but I believe that if a step fails then the test fails which is not what we want.

   There shouldn't be any side effects w/ this approach, all steps have a conditional on the docs-only check and should work correctly as before in the non-docs file are updated case

    N/A.  Future work generally might include a tag that also skips testing but is not directly related
aaron-prindle added a commit to aaron-prindle/skaffold that referenced this issue Jun 17, 2021
@aaron-prindle
add gh actions early success if change is docs only
e97594c 
    Fixes GoogleContainerTools#6032, add code to not run Github Actions on docs-only changes. This PR:
    - Updates linux and osx github actions to check if the PR only changes docs/* files and if so, pass the test w/o running the full test suite

    Github actions does not have support for exiting the job from a step easily. See:
    - https://stackoverflow.com/questions/60589373/how-to-force-to-exit-in-github-actions-step
    - actions/runner#662
    The approach here uses an env var and checks this env var in all subsequent steps, this way no single command fails and tests are skipped as desired.  The downside is that all subsequent steps need to have this check but there is no better solution at the moment from my investigation

  I considered directly using the the 'conclusion' value github actions provides, eg:
  - "if: steps.s1.conclusion == 'failure'"
  but I believe that if a step fails then the test fails which is not what we want.

   There shouldn't be any side effects w/ this approach, all steps have a conditional on the docs-only check and should work correctly as before in the non-docs file are updated case

    N/A.  Future work generally might include a tag that also skips testing but is not directly related
aaron-prindle added a commit to aaron-prindle/skaffold that referenced this issue Jun 17, 2021
@aaron-prindle
add gh actions early success if change is docs only
cf2d53a 
    Fixes GoogleContainerTools#6032, add code to not run Github Actions on docs-only changes. This PR:
    - Updates linux and osx github actions to check if the PR only changes docs/* files and if so, pass the test w/o running the full test suite

    Github actions does not have support for exiting the job from a step easily. See:
    - https://stackoverflow.com/questions/60589373/how-to-force-to-exit-in-github-actions-step
    - actions/runner#662
    The approach here uses an env var and checks this env var in all subsequent steps, this way no single command fails and tests are skipped as desired.  The downside is that all subsequent steps need to have this check but there is no better solution at the moment from my investigation

  I considered directly using the the 'conclusion' value github actions provides, eg:
  - "if: steps.s1.conclusion == 'failure'"
  but I believe that if a step fails then the test fails which is not what we want.

   There shouldn't be any side effects w/ this approach, all steps have a conditional on the docs-only check and should work correctly as before in the non-docs file are updated case

    N/A.  Future work generally might include a tag that also skips testing but is not directly related
aaron-prindle added a commit to aaron-prindle/skaffold that referenced this issue Jun 17, 2021
@aaron-prindle
add gh actions early success if change is docs only
aca692d 
    Fixes GoogleContainerTools#6032, add code to not run Github Actions on docs-only changes. This PR:
    - Updates linux and osx github actions to check if the PR only changes docs/* files and if so, pass the test w/o running the full test suite

    Github actions does not have support for exiting the job from a step easily. See:
    - https://stackoverflow.com/questions/60589373/how-to-force-to-exit-in-github-actions-step
    - actions/runner#662
    The approach here uses an env var and checks this env var in all subsequent steps, this way no single command fails and tests are skipped as desired.  The downside is that all subsequent steps need to have this check but there is no better solution at the moment from my investigation

  I considered directly using the the 'conclusion' value github actions provides, eg:
  - "if: steps.s1.conclusion == 'failure'"
  but I believe that if a step fails then the test fails which is not what we want.

   There shouldn't be any side effects w/ this approach, all steps have a conditional on the docs-only check and should work correctly as before in the non-docs file are updated case

    N/A.  Future work generally might include a tag that also skips testing but is not directly related
aaron-prindle added a commit to aaron-prindle/skaffold that referenced this issue Jun 17, 2021
@aaron-prindle
add gh actions early success if change is docs only
79c24a4 
    Fixes GoogleContainerTools#6032, add code to not run Github Actions on docs-only changes. This PR:
    - Updates linux and osx github actions to check if the PR only changes docs/* files and if so, pass the test w/o running the full test suite

    Github actions does not have support for exiting the job from a step easily. See:
    - https://stackoverflow.com/questions/60589373/how-to-force-to-exit-in-github-actions-step
    - actions/runner#662
    The approach here uses an env var and checks this env var in all subsequent steps, this way no single command fails and tests are skipped as desired.  The downside is that all subsequent steps need to have this check but there is no better solution at the moment from my investigation

  I considered directly using the the 'conclusion' value github actions provides, eg:
  - "if: steps.s1.conclusion == 'failure'"
  but I believe that if a step fails then the test fails which is not what we want.

   There shouldn't be any side effects w/ this approach, all steps have a conditional on the docs-only check and should work correctly as before in the non-docs file are updated case

    N/A.  Future work generally might include a tag that also skips testing but is not directly related
@louwers louwers mentioned this issue Feb 25, 2024
Merged
@likebreath likebreath mentioned this issue Feb 28, 2024
Merged
@ljharb
Copy link

ljharb commented Mar 16, 2024

@joshmgross since you directed people here in actions/github-script#147 (comment), is there any chance this could be reopened, or that https://github.com/orgs/community/discussions/82744 could be updated?

@nicolasbrugneaux nicolasbrugneaux mentioned this issue Mar 25, 2024
Merged
@coderabbitai coderabbitai bot mentioned this issue Mar 27, 2024
Merged
@silverqx
Copy link

Has anything changed about this? I'm searching for how to successfully exit the workflow in the middle to skip the rest of the steps. Is it possible?

@nsalfos
Copy link

nsalfos commented Apr 17, 2024 •
edited
Loading

Has anything changed about this? I'm searching for how to successfully exit the workflow in the middle to skip the rest of the steps. Is it possible?

i dont think anything changed in GHA iteself... i might be wrong tho...
there is a way but is not pretty... you have to put a conditional for each step after the one you want to skip.
like:

- name: I dont want anything to run after this
  id: boss-step
  run: |
    echo "skipnext=true" >> $GITHUB_OUTPUT

- name: Some next step
  if : ( steps.boss-step.outputs.skipnext  != 'true' ) 
  run: |
    echo "will only run if skipnext is not true"
  
- name: Some other step
  if : ( steps.boss-step.outputs.skipnext  != 'true' ) 
  run: |
    echo "will only run if skipnext is not true"

and so on... for how many steps you have after your condition

@silverqx
Copy link

Ok, thx for reply, I have 27 steps to skip so this isn't a solution for my workflow. I will have to create a new workflow for this case.

@ArkadiuszMichalski
Copy link

I experienced the same problem myself. I am unable to terminate entire workflow as success without adding conditions in subsequent steps, which significantly obfuscates the entire code.

Closing this issue after a few years is not serious, considering how many people expect it.

@dirkf
Copy link

dirkf commented Apr 26, 2024

"For avoidance of doubt", he's surely saying that GH is not treating the issue seriously, rather than that closing the issue is not serious for the people who want the issue resolved.

infinisil added a commit to tweag/nixpkgs that referenced this issue Apr 26, 2024
@infinisil
workflows/check-by-name: Skip instead of canceling on conflicts
f5f3bf7 
This avoids sending emails when there's merge conflicts.
The check will appear to be green,
but it doesn't matter since the PR can't be merged anyways.

Unfortunately there's no better way to do this right now: actions/runner#662
@infinisil infinisil mentioned this issue Apr 26, 2024
Merged
@burhanyasar
Copy link

It might not fit all scenarios but in our similar too many if else case, it was possible to split the single pipeline to tag a new version on push and other pipelines would just run on a new tag, instead of checking an if statement.

@coilysiren coilysiren mentioned this issue May 13, 2024
Closed
infinisil added a commit to NixOS/nixpkgs that referenced this issue May 14, 2024
@infinisil
workflows/check-by-name: Skip instead of canceling on conflicts
6fc3ccd 
This avoids sending emails when there's merge conflicts.
The check will appear to be green,
but it doesn't matter since the PR can't be merged anyways.

Unfortunately there's no better way to do this right now: actions/runner#662
malt3 pushed a commit to malt3/nixpkgs that referenced this issue May 15, 2024
@infinisil @malt3
workflows/check-by-name: Skip instead of canceling on conflicts
ef45109 
This avoids sending emails when there's merge conflicts.
The check will appear to be green,
but it doesn't matter since the PR can't be merged anyways.

Unfortunately there's no better way to do this right now: actions/runner#662
@kachick kachick mentioned this issue Jul 23, 2024
Merged
@sheck sheck mentioned this issue Sep 19, 2024
Merged
@emilshr-sigtech
Copy link

Bumping this up as this is a very common use-case that the community is demanding.

toofar added a commit to qutebrowser/qutebrowser that referenced this issue Oct 19, 2024
@toofar
wip: patch pyqtwebengine to test new Qt features ahead of PyQt release
4caf211 
TODO:
- this requires some extra stuff in the container: pacman -Sy --noconfirm make pyqt-builder sip
- skip tests if no patch applied: actions/runner#662
- extensible patch selection, eg patches in a dir and auto select the
  ones to apply based on detected versions
toofar added a commit to qutebrowser/qutebrowser that referenced this issue Oct 19, 2024
@toofar
wip: patch pyqtwebengine to test new Qt features ahead of PyQt release
4846243 
TODO:
- this requires some extra stuff in the container: pacman -Sy --noconfirm make pyqt-builder sip
- skip tests if no patch applied: actions/runner#662
- extensible patch selection, eg patches in a dir and auto select the
  ones to apply based on detected versions
toofar added a commit to qutebrowser/qutebrowser that referenced this issue Oct 19, 2024
@toofar
wip: patch pyqtwebengine to test new Qt features ahead of PyQt release
31e2c19 
TODO:
- this requires some extra stuff in the container: pacman -Sy --noconfirm make pyqt-builder sip
- skip tests if no patch applied: actions/runner#662
- extensible patch selection, eg patches in a dir and auto select the
  ones to apply based on detected versions
@distante
Copy link

4 years on the making... :(

@silverqx
Copy link

They aren't making it 4 years. I think they don't do it because it doesn't fit nicely into the current code as it would need custom logic, something like an edge case, some coders don't like this and prefer the default behavior. Also, I think it would need to patch things all around to make this real.

toofar added a commit to qutebrowser/qutebrowser that referenced this issue Oct 26, 2024
@toofar
wip: patch pyqtwebengine to test new Qt features ahead of PyQt release
bfe2540 
TODO:
- this requires some extra stuff in the container: pacman -Sy --noconfirm make pyqt-builder sip
- skip tests if no patch applied: actions/runner#662
- extensible patch selection, eg patches in a dir and auto select the
  ones to apply based on detected versions
toofar added a commit to qutebrowser/qutebrowser that referenced this issue Oct 26, 2024
@toofar
wip: patch pyqtwebengine to test new Qt features ahead of PyQt release
7b3d443 
TODO:
- this requires some extra stuff in the container: pacman -Sy --noconfirm make pyqt-builder sip
- skip tests if no patch applied: actions/runner#662
- extensible patch selection, eg patches in a dir and auto select the
  ones to apply based on detected versions
toofar added a commit to toofar/qutebrowser that referenced this issue Oct 27, 2024
@toofar
wip: patch pyqtwebengine to test new Qt features ahead of PyQt release
f2bf475 
TODO:
- this requires some extra stuff in the container: pacman -Sy --noconfirm make pyqt-builder sip
- skip tests if no patch applied: actions/runner#662
- extensible patch selection, eg patches in a dir and auto select the
  ones to apply based on detected versions
@immanuelazn immanuelazn mentioned this issue Oct 29, 2024
Merged
@asendra asendra mentioned this issue Oct 29, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
actions-feature enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests