Check that PRs' CHANGELOG.md changes don't modify already-released content in CI

[ErichDonGubler]

We've had recurring issues with PRs' CHANGELOG.md entries going stale, particularly when PRs are filed close to a regular release date. This PR tries to make this by creating a CI check that fails when a PR modifies the changelog and it detects changes outside the ## Unreleased section header.

This is an MVP that is not yet suitable as a required check, because there is no escape hatch for cases where we do want to change released changelog content. The intent is to enable this once some follow-up to add such an escape hatch has achieved consensus and is implemented.

[ErichDonGubler]

Recent violators of the check I'm adding here that I had to fix in #8407:

• Add support for transient textures on Vulkan and Metal #8247
• Make include_spirv! actually work statically #8250

[ErichDonGubler]

Sigh, this check is running into issues with GitHub's default checkout action machinery wanting to be as shallow as possible. The "easy" fix here is not to use shallow repository checkouts. We'll want follow-up to see if there's a way to only check out what's necessary, but that's sort of a catch-22 unless we use the GitHub API (which I'd strongly prefer to avoid, so folks can run things locally offline).

[ErichDonGubler]

I have several PRs demonstrating that core logic works here:

• Failure case(s)
  • DO NOT MERGE: CHANGELOG check: example of something in a releasd section, right after the section begins · gfx-rs/wgpu@8b4659a
• Success case(s)
  • DO NOT MERGE: CHANGELOG check: example of something before the Unreleased section, which should be fine · gfx-rs/wgpu@803f225
  • DO NOT MERGE: CHANGELOG check: example of something in Unreleased, middle common case · gfx-rs/wgpu@da89cfb
  • DO NOT MERGE: CHANGELOG check: example of something in Unreleased, end common case · gfx-rs/wgpu@60ec196
  • DO NOT MERGE: CHANGELOG check: example of something in Unreleased, start common case · gfx-rs/wgpu@bdd96a0

These are present in the check's unit tests in xtask, so I'm not worried about regressions in the future. 😁

There are some questions that are still open for this, but none are blocking until we make this check required:

• What escape hatch should we use when we need this, i.e., our typos database is updated, and we correct an old CHANGELOG entry, and we want the PR to land? It's pretty easy to use a label, i.e., changelog: released entry changed, to control this. I suggest we do that.

  We don't need to resolve this right now, because it's only important if we make this a required check. I don't see that as necessary for a first iteration.

• What fancy GitHub integration do we want? I can see several things that look interesting:

  • Step summary
  • Warning/error messages on end file contents of the PR

[ErichDonGubler]

Bikeshedding for the file's name welcome!

[ErichDonGubler]

Bikeshedding for the job's name welcome!

[ErichDonGubler]

From today's maintainers' meeting notes:

• #8351 Check that PRs' CHANGELOG.md changes don't modify already-released content in CI (By Erich Gubler; Unassigned)
  • EG: This is coming, and it won’t immediately annoy people in CI, but the intent is to add another required check.
  • Consensus: All: Let’s land, as a required check.

[ErichDonGubler]

@cwfitzgerald: I feel like I've satisfied your feedback. Was there anything else holding back your approval?

[cwfitzgerald]

Just bandwidth, will re-review in a min.

[cwfitzgerald]

By a minute I mean 8 hours.