mirror of
https://github.com/tinygo-org/tinygo.git
synced 2026-09-13 16:09:30 +00:00
Ron Evans
b81c62704a
* ci: build the compiler image on a prebuilt LLVM image The Docker workflow built LLVM as the first stages of the compiler image. The only thing that prevented a rebuild was the BuildKit registry layer cache. A layer cache is a best-effort optimisation, so CI sometimes built LLVM again although llvm-version.txt did not change. Move the LLVM stages to Dockerfile.llvm and make the compiler image start from that image through an LLVM_IMAGE build argument. The compiler build now holds no LLVM build step, so it cannot build LLVM again. Tag the LLVM image with the LLVM revision and a hash of the files that set the content of the image: llvm-version.txt, Dockerfile.llvm, GNUmakefile, and the files in make/. tools/llvm-image-tag.sh prints the tag, and CI and developers use the same script. The workflow builds and pushes the LLVM image only when the registry does not hold that tag. Remove the object files and the git history from the LLVM image in the same layer as the build. The CI caches already link against that subset, see .github/actions/setup-llvm/action.yml. Delete llvm.yml. It made an image that nothing used, and it needed a push to a special branch. The Docker workflow now does the same work when it is necessary, and the force-llvm input of the manual trigger makes the image again. The LLVM image goes to GHCR only, because only CI uses it. The compiler image continues to go to Docker Hub and GHCR. * ci: remove the LLVM git history in the layer that makes it The removal was in the tinygo-llvm-build stage. This stage is below the layer that makes the shallow clone. A later layer only hides files from a parent layer. Thus the pack files stayed in the published image. * ci: link the LLVM image to the repository The label puts the package in the repository package list, so the package settings are easy to find. BUILDING.md now tells you to build LLVM locally if you are not able to pull the image.