@dairiki so eventually, with this in, it should be possible for somebody with the right amount of access to set up a branch protection ruleset, making All tests passed a required check. This in turn will make it possible for the project to enable fun features like auto-merge or merge queues. I think it would be useful to file a number of issues post-merge describing tasks to be performed by the people with better accesses, separately.

@dairiki so eventually, with this in, it should be possible for somebody with the right amount of access to set up a branch protection ruleset, making All tests passed a required check. This in turn will make it possible for the project to enable fun features like auto-merge or merge queues. I think it would be useful to file a number of issues post-merge describing tasks to be performed by the people with better accesses, separately.

I don't have much familiarity with auto-merge or merge queues. They do sound potentially useful.
At the same time, this is not a large project (in terms of the number of active contributors and maintainers) we seem to be getting along okay without them.

For the past two years, the bulk of the work — both in terms of maintenance and new features — on Lektor has been done by two people: @yagebu, who among other things has done a great job keeping the JS frontend healthy, and myself.
I don't have sufficient permissions to access the GitHub project settings. (I'm not sure about @yagebu.) This makes me hesitant to play with any features that require access to the project settings.
We've been blocked before by issues requiring updates to GitHub (and PyPI) settings. These have required emails and significant turnaround time to resolve.

Anyhow, I'm hesitant to move forward with this. If a maintainer who does have access to project settings is interested in shepherding this, that would be a different case.

@dairiki it is safe to merge as is. It is still a nice restructuring. W/o the repo settings updates, the workflow remains the same. However, adding jobs that depend on "everything important is green" is easier this way. All those other things I mentioned are possible improvements of the configuration on top, nothing more.

@dairiki perhaps, #1207 would be less controversial?

However, adding jobs that depend on "everything important is green" is easier this way.

But we only have one job that depends on "all green". If I understand correctly, this doesn't buy us much until we add more of those.
And it has the downside of introducing one more third-party action into our workflow (which comes with security implications — however slim they are, in this case).

@dairiki perhaps, #1207 would be less controversial?

Yes, I'm fine with the renaming.

That's fair. Perhaps its current value is encoding what's considered required in PRs (on the summary workflow run page, in the job graph), as code.

@dairiki on the point of more jobs, I could bring-in something provenance-related from my other workflows (like SLSA, GH-native attestations and regular Sigstore) if that's desired. Until somebody with access configures Trusted Publishing, the PyPI ones won't be available.