I can see how the summary is a nice feature on the action summary page - but the "on PR" view doesn't have any of those affordances.

There's a small effect in the PR widget as well -- the check identifiers become slash-delimited which kinda provides grouping. Not as visual, of course. Still, I wouldn't look at this as the main goal of the PR. Just a nice cosmetic side effect.

And if a build fails, I usually find that I'm navigating directly to the broken build page from the PR page, rather than going through the Actions navigation.

That's right. And the "category" is unfolded in the sidebar when you go to the log page directly.

[..] but to me, it still seems like a lot more complexity without a lot of improvement. If there were details in the workflow that benefitted from having a single point of configuration, it might make more sense - but the structure you've described here essentially turns all that into workflow inputs, so you don't get that benefit either.

I've been exploring how to use reusable workflows most efficiently and concluded that having such separation is a benefit by itself. Currently, this repo has multiple reusable workflows that are slightly different. This spreads many configuration quirks across multiple places. However, if they are all consolidated on the top level, it becomes much easier to merge a lot of those "modules" into something more uniform. So my strategy isn't making the reusable workflows branchy internally with implicit self-config within. It's rather surfacing things to the top level to make the invocation modes clear to the caller.

the attempt to share the workflow between the cpython and release-tools repositories has generated a huge amount of extra complexity which is not present in the resuable workflow files of the other platforms. And because cross-repository workflow references can't contain variable expansions (as discussed in #137186), the release-tools PR will need to hard-code one cpython commit for the workflow, and use it to build a different commit of the same repository. That's a recipe for even more confusion.

I can see your point about the confusion. However, I came to realize that referencing the commit is what makes such reuse reliable in the first place. So I see it as an advantage. But yes, this confusion that made me question needing a separate repository for referencable automation back in that discussion.

I think it's fine in this case, though, because the inputs are pre-computed early and have assigned names.

the amount that's actually shared between the two repositories doesn't justify this. The checkout step is trivial, the build and test step is a very simple command, and the upload-artifacts step doesn't need to be in the cpython repository at all (it currently isn't).

So I'd suggest abandoning the release-tools PR, and reducing this PR only to splitting the Android workflow out into a separate file.

I could do this, I guess. Still, I think it'd be interesting to consider cross-project reusability in the future. Also, I've been thinking that the upload artifacts step would be useful in the upstream CPython repo too as this would allow the PR creators download the artifacts for local inspection and not just see that "something got built in the jobs, w/o a chance to verify it". I can imagine the reusable workflow being useful for third-party projects that would like to build and test against unreleased versions of CPython too.