Refactor into a base image.

[Alexhuszagh]

[Alexhuszagh]

This still needs to fix deployment and CI: we need to make sure the base image is always built first, and that it is staged for our other image build. It also needs to then be deployed as ghcr.io/cross-rs/base:$tag. The other solution would be to use templates: we run a script which would configure every image, which would avoid deploying another image. But I'm not sure I like that solution.

[Alexhuszagh]

This will probably fail, but I'm wondering to see how the CI orders things so we can use the proper base image. bors try --target x86_64-unknown-linux-gnu

[bors[bot]]

try

Build failed:

• conclusion

[Alexhuszagh]

As expected, this is failing because ghcr.io/cross-rs/ubuntu:main doesn't exist. https://github.com/cross-rs/cross/actions/runs/3159167477/jobs/5142204364#step:10:95

#3 [internal] load metadata for ghcr.io/cross-rs/ubuntu:main
#3 ERROR: failed to authorize: failed to fetch anonymous token: unexpected status: 403 Forbidden
------
 > [internal] load metadata for ghcr.io/cross-rs/ubuntu:main:
------
Dockerfile.x86_64-unknown-linux-gnu:1
--------------------
   1 | >>> FROM ghcr.io/cross-rs/ubuntu:main
   2 |     ARG DEBIAN_FRONTEND=noninteractive
   3 |     
--------------------
ERROR: failed to solve: failed to fetch anonymous token: unexpected status: 403 Forbidden

We either need to do this incrementally (IE, deploy once then have our builds rely on that, in which case our builds would be out-of-sync with the base images, which would be bad), or need to build and stage the image from the build-base (which I'd need to figure out how to do in CI).

The first option would be bad because if we upgrade our base to say, Ubuntu 22.04, then our first build would use 20.04, not 22.04 since it would use ubuntu:main from the previous build. Any subsequent builds would work after the first merge, but this would be a bad design.

I'm guessing one solution is to save to a tarball and then load from there? I'll look into doing this.

[Emilgardis]

I feel like there should be a GH action already made for saving an image to artifacts and then loading it

[Alexhuszagh]

Will still fail, just testing saving to tarball. bors try --target x86_64-unknown-linux-gnu

[bors[bot]]

try

Build succeeded:

• conclusion

[Alexhuszagh]

bors try --target x86_64-unknown-linux-gnu

[Alexhuszagh]

bors try --target x86_64-unknown-linux-gnu

[bors[bot]]

try

Build succeeded:

• conclusion

[Alexhuszagh]

bors try --target x86_64-unknown-linux-gnu --target x86_64-unknown-linux-gnu.centos --target wasm32-unknown-emscripten

[bors[bot]]

try

Build failed:

• conclusion

[Alexhuszagh]

bors try --target x86_64-unknown-linux-gnu --target x86_64-unknown-linux-gnu.centos --target wasm32-unknown-emscripten

[bors[bot]]

try

Build failed:

• conclusion

[Alexhuszagh]

bors try --target x86_64-unknown-linux-gnu

[bors[bot]]

try

Build failed:

• conclusion

[Alexhuszagh]

bors try --target x86_64-unknown-linux-gnu

[bors[bot]]

try

Build failed:

• conclusion

[Alexhuszagh]

bors try --target x86_64-unknown-linux-gnu pain

[bors[bot]]

try

Build failed:

• conclusion

[Alexhuszagh]

why is download-artifact producing a directory? what? bors try --target x86_64-unknown-linux-gnu

[bors[bot]]

try

Build failed:

• conclusion

[Alexhuszagh]

pain bors try --target x86_64-unknown-linux-gnu

[bors[bot]]

try

Build failed:

• conclusion

[Alexhuszagh]

It seems that the path is the directory for downloading artifacts, not the file name... This should be fixable.

$ ls -la base.tar
drwxr-xr-x  2 runner docker       4096 Oct  4 19:30 .
drwxr-xr-x 15 runner docker       4096 Oct  4 19:30 ..
-rw-r--r--  1 runner docker 1001731072 Oct  4 19:30 base-main-ubuntu.tar

[Alexhuszagh]

bors try --target x86_64-unknown-linux-gnu

[Alexhuszagh]

bors try- bors try --target x86_64-unknown-linux-gnu

[bors[bot]]

try

Build failed:

• conclusion

[Alexhuszagh]

bors try --target x86_64-unknown-linux-gnu

[Alexhuszagh]

bors try- bors try --target x86_64-unknown-linux-gnu