Multiple CI Enhancements

[microdev1]

This contains the following CI enhancements:

• Refactor variable naming in ci_changes_per_commit.py:
  • checkrun -> check_run
  • checksuite -> check_suite
• Simplify fetching changed files: use our own recipe.
• Fix for a git bug: fatal: error in object: unshallow which occurs sometimes post running git fetch --shallow-since.
  • See this stackoverflow post.
• Build docs only when //| matches in *.c files.
• Slightly refactor CI. Mostly carried from Refactor espressif CI #7420.

[jepler]

[I've removed myself as a reviewer. I find this stuff difficult to reason about and as a result I end up being unfairly negative about such changes]

[dhalbert]

Thanks for working on this. Should we set this as a draft for now, since you're still tuning it?

I am still interested in using partial clones, either treeless or blobless. They transparently appear to contain the entire commit history but don't fetch everything. Fetches are done on demand, as necessary. I think it may eliminate the depth calculations, and perhaps remove the need to do github API calls, because the info is all local (not sure about that).

Have you looked at https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ and related material? Quoting, emphasis mine:

• git clone --filter=blob:none creates a blobless clone. These clones download all reachable commits and trees while fetching blobs on-demand. These clones are best for developers and build environments that span multiple builds.
• git clone --filter=tree:0 creates a treeless clone. These clones download all reachable commits while fetching trees and blobs on-demand. These clones are best for build environments where the repository will be deleted after a single build, but you still need access to commit history.
• git clone --depth=1 creates a shallow clone. These clones truncate the commit history to reduce the clone size. This creates some unexpected behavior issues, limiting which Git commands are possible. These clones also put undue stress on later fetches, so they are strongly discouraged for developer use. They are helpful for some build environments where the repository will be deleted after a single build.

[microdev1]

Should we set this as a draft for now, since you're still tuning it?

This should be good to merge now.

I am still interested in using partial clones, either treeless or blobless.

The partial-clone functionality is awesome and I'd like to look into it but maybe in a subsequent PR.

[dhalbert]

@microdev1 what did you just change?

[microdev1]

@microdev1 what did you just change?

Nothing! I am experimenting with caching and partial-clone on my fork and accidentally pushed to this branch.

[dhalbert]

OK, let's try this! Thanks!