Support caching bevy_lint in its Github Action

[BD103]

This PR adds support for caching the compiled bevy_lint and bevy_lint_driver binaries in the Github Action. This can significantly speed up the time it takes to install the linter in CI.

Usage

Check out the rendered documentation! The biggest notes are:

• Caching is opt-in
• You can make caches only be saved on the main branch to reduce quota usage
  • This is what we do for our build caches in CI already

You can also check whether there was a cache hit, but that's mostly useful for internal testing.

Performance

The CI run for aa51a8e show the performance benefits. The "Cache miss" jobs are when the linter is built from scratch, while the "Cache hit" jobs are when the linter is downloaded from the cache. The times are summarized below:

OS	Build from Scratch	From Cache
Ubuntu	67s - 68s	26s
Windows	131s - 175s	63s
MacOS	63s - 76s	28s

Essentially, caching doubles the speed at which bevy_lint can be installed. This is awesome!

Testing

I overhauled our linter-action.yml CI check to test caching. It now tests:

• When caching is disabled (what we had originally)
• A cache miss with save-cache-if: 'false'
• A cache miss with save-cache-if: 'true'
• A cache hit

Because these tests depend on the global CI cache, I restricted the concurrency of this workflow so only one instance of it can run at a time. This may result in slower CI times when several PRs are merged at the same time or several PRs modify bevy_lint/action.yml, but in practice I don't think that will be an issue.

[BD103]

While unrelated, this lets us test linter-action.yml in CI on PRs when linter-action.yml is modified.

[BD103]

I chose not to run this for all of the other cache jobs in order to speed up the workflow runtime. Instead, the other jobs just run bevy_lint --version.

Let me know if you think I should change this!

[BD103]

This is what the workflow diagram looks like now:

It's important that the cache-related jobs run sequentially because they depend on the cache existing or not in order to succeed.

[BD103]

Note that this is a string and not a boolean. Action inputs are converted to strings, making these two steps equivalent:

- uses: TheBevyFlock/bevy_cli/bevy_lint@main
  with:
    cache: true

- uses: TheBevyFlock/bevy_cli/bevy_lint@main
  with:
    cache: 'true'

This is important when checking if the input is true or false, as non-empty strings are truthy:

if: ${{ true }} # true
if: ${{ 'true' }} # true
if: ${{ false }} # false
if: ${{ '' }} # false
if: ${{ 'false' }} # true! :O

This is why I do a lot of ${{ inputs.cache == 'true' }} instead of just ${{ inputs.cache }}.

[BD103]

While I would much rather this be 'true' or 'false' for if the cache was hit, actions/cache uses 'true' and ''. I'd rather follow precedence here than make things confusing and different.

[BD103]

This key makes it so caches for different operating systems and linter versions won't be shared. For example, Windows and MacOS will have separate caches, and bevy_lint v0.3.0 and bevy_lint main will have separate caches.

[TimJentzsch]

Very cool, and nicely documented and tested :)

[TimJentzsch]

I'm curious, if the speedup is so big, why don't we enable caching by default?
I would expect most users wanting to have it enabled.

[TimJentzsch]

In the long term (and in a separate PR) we should define some sort of shortcut or component to indicate version compatibility in the book, something like "since v0.3.0".

This would also be useful for the CLI!