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

Implement neutral exit status on bin/filter #13

Open
swinton opened this Issue Nov 15, 2018 · 15 comments

Comments

Projects
None yet
7 participants
@swinton
Copy link
Contributor

swinton commented Nov 15, 2018

GitHub Actions can now have neutral status, to gracefully exit a workflow early.

We should update the bin/filter Action to take advantage of this functionality, triggering a neutral state by exiting with status code 78.

@NiklasMerz

This comment has been minimized.

Copy link

NiklasMerz commented Dec 21, 2018

Looks like 0ac6d44 already fixed this. But I am trying to find out why my actions after the filter get the status cancelled. Is this by design?

@JoshuaToenyes

This comment has been minimized.

Copy link

JoshuaToenyes commented Dec 27, 2018

@NiklasMerz I'm seeing the same thing...

From the docs:

The associated check run shows a neutral status, and the overall check suite will have a status of success as long as there were no failed or cancelled actions.

But I'm seeing that follow-on actions are cancelled, which would make the suite fail... which doesn't make sense to me. Seems that follow on actions should also have a neutral status, since they weren't ever started. Which leads me to ask the same question, by design? Anyone from GitHub have insight on this?

@JoshuaToenyes

This comment has been minimized.

Copy link

JoshuaToenyes commented Dec 29, 2018

Until we have a long-term resolution on this from GitHub, I've simply pulled-in some of GitHub's filter action login into my critical action.

pattern="refs/heads/${BRANCH_FILTER:-*}"
filter "$pattern"
ret=$?

if [ $ret -ne 0 ]; then
  exit $ret
fi

Relevant code in my entrypoint.sh

The above is simply using a copy of GitHub's ref filter shell script, which I've renamed filter, then I'm using an environment variable $BRANCH_FILTER to filter on the branch.

Ultimately, I'm not sure if a "canceled" action should cause the whole suite to be marked with a red "X" in GitHub's UI... it's not very helpful in my use case. I'd rather see them marked as neutral.

In my case, I'm simply filtering on the branch to prevent publishing artifacts on non-master branches in a single action.

@johnnyreilly

This comment has been minimized.

Copy link

johnnyreilly commented Jan 5, 2019

I'm experiencing this problem too:

It looks like filtering makes subsequent actions in GitHub show as cancelled because the filter item has failed. That seems... Not quite right? Eg:

"Action publish' cancelled because action check for new tag' failed"

TypeStrong/ts-loader#893

@NiklasMerz

This comment has been minimized.

Copy link

NiklasMerz commented Jan 5, 2019

I contacted the github support about that and they forwared the request to the engineering team.

This forum thread deals about that, too.

johnnyreilly added a commit to TypeStrong/ts-loader that referenced this issue Jan 8, 2019

johnnyreilly added a commit to TypeStrong/ts-loader that referenced this issue Jan 8, 2019

release event not available so use push event and filter (#893)
* release event not available so use push event and filter

* use @master in place of @1.0.0

* check for a new tag last

* Try using docker://zenika/alpine-chrome:with-node

Need chrome to run tests

* Can use yarn

* Just run execution tests

* Use node 10 docker image and run all tests

* Comment tests until they are dockerised

* Run execution tests again

* Don't install pnpm globally

* Use npx to run pnpm

* Run Chrome no sandbox

* More --no-sandbox

* create own dockerfile with node / chrome headless

* common karma.conf.js using ChromeHeadless --no-sandbox

* no sandbox on command line

* use alpine-chrome:with-node docker image

* back to the version that works

* drop node 6 from travis

* try using node:10-slim

* start building and running in docker

* use full node image instead of slim for comparison tests

* set GITHUB_WORKSPACE = "/github/workspace/ts-loader"

* close to being able to run comparison tests in docker container

* left a stray

* tests pass in docker

* can comparison tests pass in a GitHub Action?

* comparison tests will not pass in github action

* add docker:build step to package.json

* Exclude npm publishing until actions/bin#13 is fixed

* Update main.workflow
@johnnyreilly

This comment has been minimized.

Copy link

johnnyreilly commented Jan 8, 2019

Would anyone be able to comment on if / when this is likely to be looked at please? For now I've commented out the part of my workflow that depends upon filtering, hoping to introduce it when this issue is remedied.

I've been tempted to give @JoshuaToenyes workaround a shot but ultimately I'd rather use the official workflow.

There's no particular urgency; obviously GitHub Actions are in beta. But it would be cool to know if there's a desire to look at this at some point.

@nicolo-ribaudo nicolo-ribaudo referenced this issue Jan 8, 2019

Open

💡 GitHub Actions ideas #79

0 of 3 tasks complete

mthenw added a commit to mthenw/frontail that referenced this issue Jan 9, 2019

@NiklasMerz

This comment has been minimized.

Copy link

NiklasMerz commented Jan 15, 2019

You could check out my "workaround"? When I build my workflow like that the status gets set to neutral.
Just use filters in resolving actions?

https://github.community/t5/GitHub-API-Development-and/Cancelled-Github-actions-fails-PR-checks/m-p/17464/highlight/true#M639

@johnnyreilly

This comment has been minimized.

Copy link

johnnyreilly commented Jan 15, 2019

That's interesting @NiklasMerz - thanks for sharing! DId you hear back from @mcolyer as to whether this is how it's supposed to be used?

@mcolyer

This comment has been minimized.

Copy link

mcolyer commented Jan 16, 2019

@johnnyreilly thanks for the ping. I'm trying to reproduce what others are alluding to here. Given this workflow (and a push in a branch that isn't labeled with test):

workflow "Verify ps" {
  resolves = ["ps1"]
  on = "pull_request"
}

action "filter" {
  uses = "actions/bin/filter@master"
  runs = "filter label test"
}

action "ps1" {
  needs = "filter"
  uses = "mcolyer-test/actions-test@master"
}

I see this:

image

Given the above, it looks like it's working as expected - ps1 is marked as neutral and not cancelled. @NiklasMerz, @JoshuaToenyes or @johnnyreilly what am I missing?

@johnnyreilly

This comment has been minimized.

Copy link

johnnyreilly commented Jan 17, 2019

It doesn't look like what I and others have experienced.

You can take a look at my own experience here: TypeStrong/ts-loader#893

Hopefully you can see from the last 2 commits and runs in azure pipelines what happened when I tried.

If it helps I'd be happy to try and reproduce it again on a fresh pr to make your life easier?

@balassit

This comment has been minimized.

Copy link

balassit commented Jan 17, 2019

Similar issue for me. I want to skip the docker login and deploy when the branch is not master, but all of my actions are marked as neutral. The Build action should be completed because it not dependent of the filter

workflow "Docker Deploy" {
  resolves = [
    "Deploy to Docker"
  ]
  on = "push"
}

action "filter-to-branch-master" {
  uses = "actions/bin/filter@master"
  args = "branch master"
}

action "Build" {
  uses = "actions/docker/cli@76ff57a6c3d817840574a98950b0c7bc4e8a13a8"
  runs = "docker build -t balassit/my-angular-project:prod ."
}

action "Docker Login" {
  uses = "actions/docker/login@76ff57a6c3d817840574a98950b0c7bc4e8a13a8"
  needs = ["filter-to-branch-master"]
  secrets = ["DOCKER_USERNAME", "DOCKER_PASSWORD"]
}

action "Deploy to Docker" {
  uses = "actions/docker/cli@76ff57a6c3d817840574a98950b0c7bc4e8a13a8"
  needs = ["Docker Login", "Build"]
  runs = "docker push balassit/my-angular-project:prod"
}

Github action

@nicolo-ribaudo

This comment has been minimized.

Copy link

nicolo-ribaudo commented Jan 17, 2019

@balassit It doesn't seem totally unreasonable: since the Deploy to Docker action is stopped, all it's children can stopped. Does it work if you also add Build in Docker Deploy's resolves?

@balassit

This comment has been minimized.

Copy link

balassit commented Jan 17, 2019

@nicolo-ribaudo assuming you meant adding Build and Docker Login like this:

workflow "Docker Deploy" {
  resolves = [
    "Deploy to Docker",
    "Build",
    "Docker Login"
  ]
  on = "push"
}

I get the same result. Looking at the Build log, it says

SKIPPED Build 07:45:46Z

Action 'Build' skipped because action `filter-to-branch-master' failed

@mcolyer

This comment has been minimized.

Copy link

mcolyer commented Jan 18, 2019

Similar issue for me. I want to skip the docker login and deploy when the branch is not master, but all of my actions are marked as neutral. The Build action should be completed because it not dependent of the filter

Ahh so I think I know what's going on here now. So this is a known issue that we're working to correct. If you have multiple branches in your workflow, currently as soon as one of has an action that stops all of the branches stop. In the example above, we want the build action to execute regardless of the result of the filter-to-branch-master action and are working on a fix.

@johnnyreilly

This comment has been minimized.

Copy link

johnnyreilly commented Jan 18, 2019

@mcolyer it sounds like there's 2 issues being discussed in this thread as the ts-loader case has only a single branch. Did you get what you needed from the link:
TypeStrong/ts-loader#893 ?

I'm happy to raise a new PR to illustrate the filter issue around subsequent steps after a neutral being marked as failed if that's not clear enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment