Reduced number of Dockerfiles

[shimwell]

Description

This PR aims to simplify the CI process from many dockerfiles and scripts to less dockerfiles and scripts, carrying on the good work @bam241 made migrating from Dockerhub and Circle to GitHub Actions.

This is the first part of simplifying the CI, if this PR is successful then the next stage would be to move .sh scripts inside the Docker container

Motivation and Context

Simple is nice

Changes

Multiple Dockerfiles replaced with one

Behavior

Same end point, we should just have an easier system for the CI

[shimwell]

Tests are passing 🎉 and I think this is ready for a review

What do people think is this a reasonable first step for simplifying the dockerfiles.

There is more to be done but I am keen to keep the PR easy to review

[gonuke]

This all looks fine to me semantically/syntactically. However, it appears that the current workflow may (???) duplicate effort. In the original, each Dockerfile is based on a docker image created and pushed at an earlier step, referred to by name. In this case, we always start with the same base image, and it's unclear to me how much is cached within the workflow.

This may be a known issue with plans to resolve as this progresses? Or may be something we should discuss.

Discussion:

• Since it only happens in the process of building CI images - hopefully relatively rare - we don't care? Especially if it gives simplicity for maintenance and developer onboarding.
• We can fix it by careful/clever use of build_args

[gonuke]

Maybe we could temporarily add a master high-level TODO list as a comment in one of these files so that everyone sees the end goal/vision?

[shimwell]

Yep good point, I shall keep an eye on efficiency of the building, looking at the action logs this PR build takes about the same amount of time as previously, ~23mins

For the high level TODO list I was thinking it could be something like this

• combine dockerfiles
• move dockerfile location
• move ARGS and ENV to top of dockerfile
• move .sh scripts into dockerfile
• add code space developer environment
• remove old files include circleci
• update setup-qemu-action to v2

[gonuke]

Oooo... you could make a GitHub project with these steps defined there... 😀 rather than in a single PR or comment in a file.

[gonuke]

As for efficiency, if it is just as fast, I'd like to make sure we understand why so that we don't accidentally break it in the future.

[shimwell]

As for efficiency, if it is just as fast, I'd like to make sure we understand why so that we don't accidentally break it in the future.

The current builds use -f for file and that file has a few docker files below which also needed to be built. If the images are built and in the local docker image collection then they are used, if they are not found then are downloaded.

This build uses --target which also needs the stages below to have previously been built. If they are in the local collection then they are used and if they are not found then they built from scratch. However the images are found in the cache as the building route starts from the base, tagging each build as it goes and works up the stages.

Each docker image build results in a tagged image and if the same dockerfile is built with the same build args values then the previously tagged image will be used. This happens automatically for modern docker installs on your desktop (buildkit required). Enabling Docker Layer Caching on GitHub requires a bit of extra lines in the existing yml scripts using the setup-qemu-action to get docker layer caching working for the current build scripts and this also applies to the proposed layout.

[shimwell]

Oooo... you could make a GitHub project with these steps defined there... grinning rather than in a single PR or comment in a file.

Yes certainly, I have added the tasks to a project here https://github.com/svalinn/DAGMC/projects/6

[gonuke]

As for efficiency, if it is just as fast, I'd like to make sure we understand why so that we don't accidentally break it in the future.

The current builds use -f for file and that file has a few docker files below which also needed to be built. If the images are built and in the local docker image collection then they are used, if they are not found then are downloaded.

This build uses --target which also needs the stages below to have previously been built. If they are in the local collection then they are used and if they are not found then they built from scratch. However the images are found in the cache as the building route starts from the base, tagging each build as it goes and works up the stages.

Each docker image build results in a tagged image and if the same dockerfile is built with the same build args values then the previously tagged image will be used. This happens automatically for modern docker installs on your desktop (buildkit required). Enabling Docker Layer Caching on GitHub requires a bit of extra lines in the existing yml scripts using the setup-qemu-action to get docker layer caching working for the current build scripts and this also applies to the proposed layout.

If I understand correctly, then, it's the setup-qemu-action part that is key, because we push these images with varying tag names and I'm not convinced that relying on fetching them would work. Instead, we have to rely on the cache.

[shimwell]

If I understand correctly, then, it's the setup-qemu-action part that is key, because we push these images with varying tag names and I'm not convinced that relying on fetching them would work. Instead, we have to rely on the cache.

I agree

[bam241]

few comments I didn't had the time to post,

I was doing a review and got interrupted...

Pushing this for future info

[bam241]

I would put 2 line breaks between stages

[bam241]

maybe also add a comment before the FROM to explain what the stage is about

[pshriwise]

Just returned from vacation so I'll keep an eye out for the next PR that continues this work. Thanks for diving into it @shimwell!