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

Mark workflow run as neutral or success when skipping #227

Closed
riker09 opened this issue Jul 5, 2021 · 8 comments
Closed

Mark workflow run as neutral or success when skipping #227

riker09 opened this issue Jul 5, 2021 · 8 comments

Comments

@riker09
Copy link

riker09 commented Jul 5, 2021

I want to run a workflow on pull_request trigger when a certain label is assigned to the PR. I use this action to check and the workflow is cancelled when the label is not present, so this action right here works as intended.

However, the workflow run is marked as failed in my GitHub UI, when in reality it should not have run at all. Is there a way to achive this behaviour? Judging from the discussion at actions/runner#2347 this is something that only the GitHub team could solve.

I've read in a blog post from the official GitHub Actions Blog that GitHub will skip any push or pull_request events that have [skip ci] in their commit messages. But what I really want is the other way around.

@riker09
Copy link
Author

riker09 commented Jul 5, 2021

To answer my own question:

on:
  pull_request:

jobs:
  prepare:
    runs-on: ubuntu-20.04
    continue-on-error: true
    outputs:
      sha7: ${{ steps.prepare.outputs.sha7 }}
    steps:
    - id: check-label
      uses: agilepathway/label-checker@v1.0.90
      continue-on-error: true
      with:
        one_of: cicd
        repo_token: ${{ secrets.GITHUB_TOKEN }}

    - if: steps.check-label.outcome == 'success'
      run: |
        echo "::set-output name=sha7::${GITHUB_SHA:0:7}"

  build:
    if: needs.prepare.outputs.sha7
    runs-on: ubuntu-20.04
    needs: prepare

    steps:
      - uses: actions/checkout@v2

    # ...

this marks the PR check as success, though. But this is better than failure in my opinion. Gotta love them little green checkmarks. 😃

@riker09
Copy link
Author

riker09 commented Jul 6, 2021

Well, I should have tested it more extensively first. This does not work when the PR is assigned the cicd label. All tests are being run, this is the resulting log:

[...]
2021-07-06T06:29:08.0452411Z with:
2021-07-06T06:29:08.0452792Z   any_of: cicd
2021-07-06T06:29:08.0454423Z   repo_token: ***
2021-07-06T06:29:08.0454865Z ##[endgroup]
2021-07-06T06:29:08.0502532Z ##[command]/usr/bin/docker run --name ***REDACTED*** --label 8a33c1 --workdir /github/workspace --rm -e INPUT_ANY_OF -e INPUT_REPO_TOKEN -e INPUT_ONE_OF -e INPUT_NONE_OF -e INPUT_ALL_OF -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/***REDACTED***":"/github/workspace" ***REDACTED***
2021-07-06T06:29:08.4962745Z Checking GitHub labels ...
2021-07-06T06:29:08.6978831Z Label check successful: required none of , and found 0.
2021-07-06T06:29:08.6979653Z Label check successful: required any of cicd, and found 1: cicd
2021-07-06T06:29:08.6985999Z Error: Label check failed: required 1 of , but found 0.
2021-07-06T06:29:08.6986667Z Label check failed: required all of , but found 0.

From the looks of it I would say that even though I only passed one option (one_of) the other three tests are also evaluated with empty values. This looks like a bug to me and I would gladly help, but I don't know any Go.

@johnboyes
Copy link
Contributor

Hi @riker09, sorry for delay in replying, I need to tweak my GitHub notifications 😧
I'll take a look at this and get back to you shortly.

@johnboyes
Copy link
Contributor

Hey @riker09, was this issue also fixed by actions/toolkit#230 (which was the fix for actions/toolkit#228)? Thanks v much

@riker09
Copy link
Author

riker09 commented Aug 6, 2021

Hey @riker09, was this issue also fixed by actions/toolkit#230 (which was the fix for actions/toolkit#228)? Thanks v much

Well, yes, in a certain way. The error I originally encountered in this issue here was fixed. However, what I actually would like to achieve, is automatically skip all remaining jobs/steps without marking the workflow as failed. From my understanding of GitHub Actions this cannot be done easily. The only solution is to check the outcome of this action later in the workflow file.

When GitHub decides to have other step/action results besided failure and success I might have a way to make things go my way. In the meantime, I'm going to close this issue as the original question has been answered with a workaround.

@riker09 riker09 closed this as completed Aug 6, 2021
@pro100svitlo
Copy link

pro100svitlo commented Oct 20, 2022

I was also looking for this feature.
The proposed workaround is a workaround, but it would be really nice to have something like an optional enum param for action, where default is failure

  exit_type: [failure, cancel]

In this way, the user of the action can control the way the workflow will end: failure (reg) or canceled(gray).
Would be really nice to have 🙏🏼

@pro100svitlo
Copy link

@johnboyes is there any chance this feature can be added?

@johnboyes
Copy link
Contributor

Hi @pro100svitlo, thanks for suggesting this - I'll take a look into it when I have time over the next week or two and get back to you. One thing I'm keen to establish if this is something which GitHub themselves intend to provide at some stage (and if so, when).

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

No branches or pull requests

3 participants