Use hand-written change detection for PR/push job trimming

[huonw]

This replaces the use of https://github.com/tj-actions/changed-files with a much simpler hand-written version:

1. determine the commit to compare the PR to
   1. for a push, this is the immediate parent (i.e. HEAD^)
   2. for a pull request, this is the HEAD of the base branch
2. do the comparison using git diff --name-only $comparison_sha HEAD

This is basically what the action does, except it needs to handle a lot more edge cases/functionality that don't matter to pants: categorising the changes in detail (e.g. which files are specifically added vs. modified vs. renamed etc.), submodules, and various other forms of customisation. Pants just cares which files have any changes at all, which is much simpler.

Handling PRs is a bit subtle, but the 'simple' implementation (just diff Actions' HEAD vs base branch HEAD in isolation) is correct, without needing to deal with commit ranges or finding a merge base, I think:

1. GHA runs on the merge of base branch HEAD and PR HEAD by default: this is why actions don't run if there's merge conflicts
2. This merge commit is the default checked-out commit/aka the GHA HEAD
3. Thus, the GHA HEAD includes the base branch HEAD and any changes there. Diffing the base branch HEAD and GHA HEAD will identify only the changes from the PR that were merged in.

For instance, this PR branches off af8004a from last week, which is 30 commits older than the current main HEAD a267fef. Here's the results of various git diff --name-only $sha1 $sha2 | pants run build-support/bin/classify_changed_files.py calls:

description	sha1	sha2	changes
branch point vs. main	af8004a	a267fef	ci_config docs other release rust
PR vs. main	a267fef	3f04618	ci_config docs other release rust
PR vs. branch point	af8004a	3f04618	ci_config other
CI: PR merge vs. main	a267fef	(transient on CI)	ci_config other

This approach ensures we're diffing the actual changes that would get merged (if nothing else merged, cf. a merge queue), meaning the contents of the eventual squash-and-merge commit, which can be slightly different to what's shown in the PR UI. It also means we don't need to worry about PRs getting too far from main for change detection to work, because it's literally diffing commits and their file trees in isolation, rather than needing to traverse far into history.

This PR tests the PR logic, and I've tested the push logic on my fork.

[thejcannon]

Just for my own understanding, this is all a bit of a workaround, right?

Ideally "the cache" would just make doc only changes go pretty quickly. That's what we see our build at $work. The challenge is getting the cache to be warm/hot enough.

[huonw]

Potentially? I'm just changing implementation details and aren't across the historical context. Relevant changes from the git history:

• the addition of this classification script: A general mechanism for classifying CI changes #17218
• the removal of the old skip-rust etc. mechanism: Streamline CI #17224
• the addition of the original concept of "docs only" A better solution for skipping CI steps for docs-only changes. #16053 Skip CI checks on docs-only PRs. #16041

I think relying on remote caching isn't feasible, in the short term:

• pants' bootstrapping makes it special, with the Rust code built outside of normal pants (Use Pants to build our rust code #18688 would help a lot), and just general self-referential-ness (the discussion on Use Pants to build our rust code #18688 about using released version of pants to build pants is relevant)
• Remote caching in public repos seems like it's a bit awkward, e.g. PRs would need access to auth secrets and public access risks things like a cache poisoning attack (https://pantsbuild.slack.com/archives/C0D7TNJHL/p1682519628658449?thread_ts=1682478913.537359&cid=C0D7TNJHL). Some options that could improve this, off the top of my head:
  • read-only remote cache for PRs
  • some other sort of trust layer?
  • caching to the GHA cache directly (Proof of concept: support remote caching to Github Actions cache #17840... eventually)

[benjyw]

Just for my own understanding, this is all a bit of a workaround, right?

Ideally "the cache" would just make doc only changes go pretty quickly. That's what we see our build at $work. The challenge is getting the cache to be warm/hot enough.

Yes, in an ideal world the cache (or relying on --changed-since, which perhaps we should do?) would be sufficient.

But this is just replacing like with like, to fix the issue you pointed out a few days ago.

[benjyw]

And yeah, this is primarily to not build rust or wheels when we don't need to.

[thejcannon]

Yeah, I'm using this as an opportunity to educate myself. Certainly not meant as a challenge or blocker 😄

[stuhood]

(Looks like you have reviewers, but just stopping by to say: thank you for working on the CI infrastructure!)