Add a gha build container

[jesse-peters]

This is the same PR as #209, but its a branch of the main repo, not a fork. Theres a theory in discord that its impacting the GITHUB_TOKEN scope.

I took another whack at https://github.com/aurae-runtime/aurae/issues/79 using a few different methods. The time to run is still a bit longer than native GHA jobs, but with a self-hosted runner I think it would be pretty similar.

I'm building the image as the first step in the pipeline, then using that image to run the jobs on downstream. I have introduced cargo-chef to package the dependencies, without needing to compile the code itself.

Using minideb we launch a container that has the rust requirements (but without extras like cargo-chef). This runs the actual make steps, and uses native GHA caching for the rust modules.

I would be happy to setup and own a self-hosted runner and https://github.com/aurae-runtime/aurae/issues/78. I'm happy to chat about that in discord too (kuxaku) :)

Most of the build layers should cache across branches too (using buildkits native GHA cache), so the first time it runs should be the longest.

Biggest Risks:

I got the caching wrong and the pipeline doesn't have correct dependencies someplace along the test/build process
The build times are longer, impacting developer feedback times

Out of scope:

I did not apply the docker image to the deploy step yet.

I kept the original two GHA jobs in the pipeline for reference. If/when this gets merged they can be ran alongside for a bit to ensure its working, or deleted in a second PR.

[jesse-peters]

There are 2 areas for speed improvements here I see - both are a bit outside of my rust expertise though.

1. The container resets the rust toolchain. I think this should have been cached already, so not sure why its re-downloading the toolchain again.

• here

2. Im not actually sure the packages are being cached properly from the cargo-chef step. You can see the same package being compiled in the docker image, then again on a make command. Here is the proc-macro2 dep being compiled in both places. I suspect this is not the behavior we want, but I don't know rust well enough to be sure.

• docker build step
• make docs step

[jesse-peters]

Would it be alright if we made the aurae-builder package publicly read accessible?

[krisnova]

Can you help me understand what exactly changes with this PR? I know we are putting our binary in a container which is great (I think?) but I am not really sure what we are doing here and why? What exactly is the motivation for this? More importantly... should we document the motivation/expectation?

What happens if somebody "breaks the build" but their code works fine locally? Are we certain that the commands we are running in a container are the same commands that developers will be developing with locally?

[krisnova]

This will just build a container with auraed installed in it right? Does it run auraed as a pid 1 in the container?

[jesse-peters]

The goal with this container is to provide a place for Github Actions to run tests. There were two open issues that this will address and help with: #78 and #79. In Discord I had a conversation with @future-highway where they mentioned the need for tests to be run inside a container as well.

This is not a container to ship auraed in, but I would be happy to create a shippable one next.

Instead of running the tests inside of the default Ubuntu environment provided by Github, we're using our custom container to run the tests inside. Currently it only adds an additional job in GHA on branches, since we are not removing the existing tests that are functioning until a later PR (and we have determined this one is working as expected).

If we make this build image public, developers can pull it down or (build it locally)and run tests on the same platform as Github Actions will be. I believe this will lead to a development environment more closely resembling the CI system.

I could add a README to the docker folder explaining what this image is. I expect to see a few different docker containers in that folder over time, so some documentation there might be helpful.

[krisnova]

This makes much more sense and seems like a great addition! Docs would be helpful!

Maybe something on the contributions page like a "ci and pipeline" expectations or something.

[krisnova]

I am going to merge and we can add docs in the next PR

[jesse-peters]

The dockerfile has changed so this latest run might take a a few minutes (the rebuild is triggered off any change in the dockerfile or the cargo.lock file.