Filtering paths & skipping concurrent runs can lead to problems

[bjchambers]

1. Push commit 1: Run two jobs. 1-push because of the push and 1-pr because of the pull request.
2. Concurrent jobs skips 1-pr because it is concurrent and newer than 1-push.
3. Cancel 1-push (see it's going to fail, etc.)
4. Push commit 2 that touches ignored files.

What I'd expect: No successful, non-skipped run has occurred, so we need to run things.

What happens: Both jobs run on commit 2, but both decide that since (a) the only change is ignorable and (b) the most recent run (1-pr succeeded -- by skipping everything) there is nothing to do.

It seems like perhaps instead of "skip if there are no changed files since a successful run" it should be "skip if there are no changed files since a non-skipped successful run".

Is this a known issue / existing work arounds?

[paescuj]

Could you please share your config?

[bjchambers]

Created a repro repository.

The workflow is setup to use skip jobs. It ignores changes to README.md but always fail to run tests (false).

https://github.com/bjchambers/skip-actions-repro/blob/main/.github/workflows/workflow.yml

I made a PR that first added a file. This behaves as follows:

• Push action failed: https://github.com/bjchambers/skip-actions-repro/actions/runs/3904203587
• Concurrently, the PR action succedeed (it was skipped because the push action was running): https://github.com/bjchambers/skip-actions-repro/actions/runs/3904204596

I then added a commit that changed README.md. This shows all checks as having passed!

• Push action succeeded, because it only changes README.md and all files were already in an action run. https://github.com/bjchambers/skip-actions-repro/actions/runs/3904209440/jobs/6669676073.

• PR action succeeded. https://github.com/bjchambers/skip-actions-repro/actions/runs/3904209861/jobs/6669676367

[paescuj]

Thanks! 👍 I'll have a look at this.

[fkirc]

Thank you for providing the reproducing repo! I recognize that there are multiple problems with “concurrent skipping“, which is why I made the decision to disable concurrent skipping by default. I made this decision many months ago because there have been several concurrency-issues, some of them are safety-critical.

In fact, I would consider concurrent skipping as an experimental feature. For me, it is an open research question whether we could change the behaviour of concurrent skipping in a way that is useful for the general public. Perhaps we might implement a new skipping-mode, similar to “same_content_newer“?