Requiring all jobs pass? (with a wildcard or some equivalent)

[di]

First of all, love the idea of this action, thanks for maintaining it.

I was thinking about adopting this for https://github.com/di/pip-api/blob/master/.github/workflows/test.yml which has a somewhat complex (and long) matrix workflow. But based on the example in the readme and discussion in #5, it looks like I need to explicitly list all the jobs by name with needs:, and since the list of jobs is autogenerated, very long and changes frequently, I don't want to do this. Is there any workaround?

Thanks!

[webknjaz]

Hi Dustin!

Thanks for the kind words 🙏

It sounds like you may be confused by what is expected to be listed in the needs: field.

Let's start with that this is a feature of GitHub Actions and is processed by some orchestration code on GitHub's side. And it is initially processed when that orchestrator does not have any idea of which jobs will run, or how many. This is because of the dynamic nature of the workflows. We can even generate a job matrix from a previous job (I'm actually exploring for way over a year this in the context of tox-based projects and have a rather outstanding PoC).
If you look at https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds, it does not explicitly say it but the example reveals that you are supposed to use job IDs in needs. So these are basically the entry keys under the jobs: section of the workflow file.
This is something that is known to the orchestration platform upfront, before it starts any jobs. And this is how it can build a dependency graph.

If you make a job definition use the matrix feature, there's no way to refer to the individual jobs in the matrix — only to the job ID. Yes, the jobs will appear in the UI separately when they are resolved but the platform will be mostly working with a whole matrix under the job definition. And that's what you need to specify in needs.
There's no way to dynamically add a job that doesn't have a hard-coded ID. And if you add a new matrix factor to the tests job, you won't need to make any changes in that needs list.
Note that ID is not the same as the name: field. You can't refer to jobs using name. Job IDs are unique, names are not.

I think I've explained some of the corner cases @ community/community#33579 (comment). Plus, there's https://github.com/marketplace/actions/alls-green#gotchas trying to show how to make individual matrix jobs allowed to fail.

If you want to see live examples, check out the CI setup of attrs, trio, coveragepy, pydantic, pip, setuptools or anything from https://github.com/marketplace/actions/alls-green#does-anybody-actually-use-this really.

If you'll have ideas on how to improve the readme, I'm happy to do that :)

[di]

Ah, thanks for the clarification, it was unclear to me that names could just be the 'named' jobs, and doesn't need to include any 'unnamed' (autogenerated) jobs from a matrix. I created di/pip-api#166 and it worked great. Thanks!