Skip to content

Restructure Docker build process #389

@straight-shoota

Description

@straight-shoota

While looking into adding support for aarch64 docker images, I noticed a couple of issues with the current docker build process.

  • dist_docker builds the images, then stores them in a gzipped tarball in order to persist them in the workspace.
  • The entire build step currently takes about 4 minutes. 90 seconds of that are spent for exporting the images to disk. It might be more efficient to just push the images to the registry and pull them again when necessary.
  • The images are used by follow-up steps:
    • dist_docs: Loads the ubuntu-build image and uses it to build the API docs (the regular image should actually suffice)
    • test_dist_linux_on_docker: Loads the ubuntu-build image and uses it to run the entire test suite.
    • publish_docker: Loads all images and publishes them to docker hub
  • test_dist_linux_on_docker itself seems very heavy (30 minutes) for little gain. A simple smoke test to make sure Crystal works should be good enough. Running the entire test suite is unlikely to fail. It could be considered an integration test for the compiler build itself (just packaged in docker). But even then it's quite a lot. Also, we're only doing this on a single platform.
  • publish_docker depends on test_dist_linux_on_docker in releases, but not nightly releases. This inconsistency seems odd.

With support for aarch64 docker images, we'll be doubling the current number of docker images and their sizes.

Here's what I'd like to do in order to simplify the entire process:

  1. Remove test_dist_linux_on_docker. We can replace it with a simple smoke test (build hello world) directly in the dockerfile.
  2. Publish docker images directly to the registry instead of persisting them to the workflow. dist_docs can pull the single image it needs.
  3. Simplify the Makefile. It seems too be way more complex than it needs to be. With 2. we should end up running only single docker build command with a couple of parameters.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions