tests and collateral share some behavior implicitly

[jaraco]

In the current GitHub CI definition, the test and collateral jobs share a bit of logic (checkout, setup python, install system dependencies), but it's easy to forget that both of these essentially need the same behavior, especially because diffcov runs the tests. For example, in this run, I added a workaround to test but not to collateral, so the tests failed when run in diffcov.

Gemini has some ideas on how to model this shared behavior.

[jaraco]

Well, that's annoying. When attempting to move the steps into a shared section, it becomes necessary to specify a shell where it was not necessary before. 🤮

  - name: Run
    run: tox

Becomes

  - name: Run
    run: tox
    shell: bash

So even on Windows, I'm having to specify bash. Seems dumb.

[webknjaz]

xref #163 (comment)

[jaraco]

In that comment, you propose an alternative approach, to use reusable-workflows instead of composite actions. The main reason I chose composite actions was to avoid having to create separate files and the other potential limitations of reusable workflows. I read this comparison, and it seemed that composite actions might be better for skeleton projects.

That said, I should probably also examine the possibility of reusable workflows.

[webknjaz]

Honestly, I'm been using composite actions long enough to conclude that I wouldn't replace multiple separate steps in workflows with them. Their output is collapsed into one huge chunk of text. And even if you use workflow commands to group log lines, the output is rather ugly. Even if that composite action calls other actions, it's less clear what's going on.

I think they are good for things that are inherently coupled. Or if you want to have a shareable step that you want to interface with as an action (i.e. paste into your workflow job definitions), while delegating the logic to a Python script.

Reusable workflows, OTOH, surface entire jobs with steps that are always shown as they should. A few years ago, I even invented a modular layout for CPython. I came up with an idea of having “modules” that are in-repo reusable workflows. Those workflows are only allowed to be called, so they only have workflow_call: as their trigger. No other triggers allowed. And then, there are regular workflows where all the triggers are declared + all jobs are tied together, including dependencies between them and alls-green (integrating this action was what required inventing this structure — there was a need to have a check that would work consistently when parts or the CI were being skipped). And one of the features of this concept became the convention of prefixing the reusable workflow names with reusable-. Things you can see @ https://github.com/python/cpython/tree/98fa4a4/.github/workflows derive from that.

As for creating separate files, I'm not sure I understand this point — you either create a file for a composite action or for a reusable workflow. There's no skipping this in either case. And in both cases, you can have that in a share repository. I only have them in-repo because I'm experimenting with things, and it's temporarily more convenient. But soon I should be able to delete those bits that aren't repo-specific entirely.