Add Docker caching

[maxslarsson]

Fixes #31

[maxslarsson]

• Rename Bazel module to ground_software #33
• Build for both linux/amd64 and linux/arm64 #30
• Add Docker caching #29 👈
• Dockerize Fill Station Binary #24
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @maxslarsson and the rest of your teammates on Graphite

[ZachGarcia42]

:)

[ZachGarcia42]

Fix merge conflicts please

[ZachGarcia42]

Are we able to just rerun the workflow to see a speed increase from caching?

@ZachGarcia42 reviewed this PR from Slack with Graphite

[maxslarsson]

Yea we can, but I don't think it'll have a massive speed increase unfortunately because of how Docker works. Basically it treats each line in the Dockerfile as a layer, so whenever the inputs for one line changes, it has to rebuild every line below. So whenever we change any code, it invalidates the COPY . . line, which means we have to rerun each line below which includes the bazel build line. That means I don't think it will get cached. Ideally, we'd be able to build the dependencies for our program on a seperate line before the COPY . ., so that that gets cached and the COPY . . is put after.

Do you know if there is a Bazel command to download and build the dependencies only?

[ZachGarcia42]

I don't think that's too feasible unfortunately. 13 minutes isn't terrible. If that's slower than we want, we can create a second docker file for the workflow and move back to uploading/downloading an artifact from the bazel tests. I think this is cleaner than copying some of the repo, doing a build step, copying the rest, and then building the actual target

[maxslarsson]

Yea for sure, I think 13 minutes is fast enough for our purposes, at least for now. If not, we can go back in history and get your artifact solution again.

I think most of the time we test the code locally, and the Docker build is just to get onto the RPi

[ZachGarcia42]

Thanks for this improvement!