Cache crates.io index for CI

[wildwestrom]

I decided personally it was a good idea to cache the crates.io index.

Do you think it's a good idea to do this for the template?

• A disadvantage is that the index (which is about 300MB) is now stored on Github's servers.
• An advantage is now the action doesn't have to fetch the entire crates.io index every time, which takes too long for my impatient self.

Example:

            - uses: actions/cache@v3
              with:
                path: |
                    ~/.cargo/registry/index/
                key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock')

[fspoettel]

Hey @wildwestrom, yes I'd accept a PR for that, thank you! 🙌

The limits for caches are fair and caches get deleted eventually if stale, so I don't see a reason not to include this in the template:

GitHub will remove any cache entries that have not been accessed in over 7 days. There is no limit on the number of caches you can store, but the total size of all caches in a repository is limited to 10 GB.

[wildwestrom]

Ok cool.
Now I also think it would be better to use the same environment for the check and test steps. Should I open a separate issue?

[fspoettel]

I think I'd prefer jobs to stay separate. Correct me if I'm wrong - Github runs job in parallel anyway so if all use the same cache, there shouldn't be a big difference in completion time from the user's perspective. It does consume a bit more VM time, but it's easier to see which part of the CI failed with parallel jobs. No strong opinion here though.

Looking at it a bit more closely, I'm wondering if we even need the check job if we run test anyway? Test does catch compiler errors as well. Maybe we can remove the job altogether?

[wildwestrom]

No we don't. I was wondering why you put it in. test compiles the program anyway, so it has to go through a check as well.

[fspoettel]

Cool, thanks for confirming! Let's remove it then. 👍