TST: Skip CI in Action - #11168

I suppose the CI / ${{ matrix.name }} (pull_request) builds are because you use dependencies between builds to not run them if the ci-skip one fails.
It's also a bit annoying to have to run a docker for this, with the time it takes. But I'm not ready to learn typescript right now to avoid this ;), and couldn't find third party actions that do it better, so I guess it's fine for now.

I was about to add https://github.com/pllim/actions-cancel-workflows here too (tested at kali-maa#42) but now I am not sure with your comment about Docker being slow. Should I just use the third-party Action (https://github.com/styfle/cancel-workflow-action)? For that third-party one, I couldn't vet the code because its dist/index.js has over 6000 LOC, but I see other repos using it, including Apache and Google (though those repos might just be some employee pet projects or something, as they don't look high profile). 🤷

Well, it's just that needing a docker build which takes ~1min just to check some string in a commit message seems a bit overkill, but I don't have a better solution for now ...
For the "skip workflow" one, the source for https://github.com/pllim/actions-cancel-workflows in typescript is ~80 lines and relatively easy to understand (https://github.com/styfle/cancel-workflow-action/blob/main/src/index.ts), and I guess runs much faster than in a docker. If we can avoid multiple builds with docker taking minutes before the actual test builds, it seems better, or maybe we can combine all our custom actions in a unique docker build that would skip ci, kill running workflows, etc ?

I was talking about this file, which I think index.ts calls: https://github.com/styfle/cancel-workflow-action/blob/main/dist/index.js

Speed wise, there are two possible solutions but none of them pretty:

• Like you said, combine everything into one giant custom action -- This will really complicate the logic, especially if you want to customize pieces of them in the future. Also might render it unusable for anything else other than core lib (e.g., smaller package might not want all the bells and whistles).
• Move the custom actions into core lib as scripts (can exclude them from manifest and so on) and have the CI run them as steps instead of individual jobs. This way, I don't think you need Docker as theoretically it would just use the Python you installed in the previous step. This would definitely only make them usable only in core lib.

FWIW, it seems to work at https://github.com/pllim/playpen/runs/1566774010?check_suite_focus=true but I'll have to wait till Actions un-blacklist me here to find out for sure.

Also, I have it pull the Docker image now instead of creating from scratch, so the "build" part went down from over a minute to 18s. Maybe it is more bearable this way?

"[ci skip]" found in "fix yaml [ci skip]", cancelling this workflow
Cancelled WorkflowRun(url=..., id=426714081)

Let's defer the cancel duplicate runs to another PR. One thing at a time.

No, something is still not right. It tried to cancel but it didn't work. Maybe it is grabbing the token from my fork, which does not have the power to cancel jobs here upstream? If that is the case, we cannot know if the cancelling will work until this is merged. 🤷

https://github.com/astropy/astropy/pull/11168/checks?check_run_id=1566876617

"[skip ci]" found in "tst: skip ci in action [skip ci]", cancelling this workflow
Cancelled WorkflowRun(url=..., id=426750801)

Cancelling does not work at kali-maa#43 . I need to understand this inconsistency.

I think I have convinced myself that when a PR is opened from a fork, the canceling does not work. So, I think I have to go back to failing this outright.

I was talking about this file, which I think index.ts calls: https://github.com/styfle/cancel-workflow-action/blob/main/dist/index.js

The javascript file is generated from the typescript one ;)

Also, I have it pull the Docker image now instead of creating from scratch, so the "build" part went down from over a minute to 18s. Maybe it is more bearable this way?

Yes, seems much better 👍

I rewrote it in TypeScript. Now it takes 3s to run. I still think we should implement the cancel duplicate workflows one as a separate PR. I am quite done with this one until I hear back via reviews. Thanks!

UPDATE: I was testing the Action that Simon talked about and it worked well and though might as well add it here.

UPDATE 2: I pinned the third-party action to its release hash, just in case.

Thanks to brilliant idea from @eslavich over at spacetelescope/jwst#5591 , I updated the Action to not fail, so now you get your nice green check mark and also cancelled jobs.

Yay for keeping at it! It sounds very nice now, and also extensible. Will you make the javascript part of the PR? In any case, do change the message actually shown ("Failure means CI is skipped on purpose").

I meant whatever is in "pllim/action-skip-ci@main" and the other one!

I fixed the bug upstream in the action.

whatever is in "pllim/action-skip-ci@main" and the other one

Ah, I thought I linked them above. But here they are again. This time, I'll link to the actual TypeScript where the implementation is.

• https://github.com/pllim/action-skip-ci/blob/main/src/main.ts
• https://github.com/styfle/cancel-workflow-action/blob/ce177499ccf9fd2aded3b0426c97e5434c2e8a73/src/index.ts (note that I pin this one to the hash of its 0.6.0 release, so we don't need to vet the code again every time a change is pushed there)

So this PR seems ready right ? It looks great and I think we should start to use it and see how it goes.

Yeah, I have been using it myself. If we move the code to some org, I'll batch PR to update all affected packages.

Hurray! 🎆

I immediately used in #11222 where @saimn had asked for a small change to the changelog entry. Saved the world ~10x6minx100W ~0.1 kWhr.