Better way to organize docker images for testing.

[ekpyron]

We need to:

• decide how to distribute permissions to update the docker images
• consider if and how to switch to source based images, if that helps
• if nothing else works, re-evaluate how much speed-up we gain by using the docker images for the tests anyways in contrast to switching back to stock docker images, updating them and caching, which would ensure better maintainability and updateability.

[ekpyron]

Rationale: the PR updating the clang Dockerfile was merged a day ago and we're still waiting for an updated image, causing test failures on all PRs. And updating the docker images for testing has to be easy and fast and should be done regularly anyways, since we will otherwise likely lock ourselves into testing against outdated dependencies.

[ekpyron]

@axic on gitter:

Setting version in the dockerfile: https://github.com/ethereum/aleth/blob/master/scripts/docker/cpp-build-env.dockerfile#L5 Using versioned images: https://github.com/ewasm/hera/blob/master/circle.yml#L201

Doing things like that for our docker images might alleviate the pain in updates a lot already, because we can first push the docker updates, while keeping the tests intact and only update to the new docker image later.

[ekpyron]

Also: problems with the docker images now happened twice within the same day, resp. for the most part of two days now, so we really need to take care that this works better IMHO :-)...

[ekpyron]

We should look into https://docs.docker.com/docker-hub/builds/advanced/ That way we can setup autobuilds triggered by git commits with a custom versioned docker tag, for which we could fetch the version from the LABEL in the Dockerfile using introspection. Then we could enable autobuilds on all branches, resulting in the following:

We can just create PRs that bump the version in a Dockerfile and simultanously bump the version in the CI config. That will autotrigger the build and push of a new versioned docker image without affecting other PRs and CI runs. Once the automatically built docker image is (automatically) pushed, the tests in the PR can be retriggered and the whole thing merged, once the tests pass.

Without any local builds, version issues or the requirement of distributing dockerhub push permissions.

There are several slight variations of this we can consider (e.g. using docker's autotesting to validate that the docker images can run the build and tests before pushing), but generally I would say such a fully automated setup is feasible and very much worth setting up.

And with such an automation setup I'd actually very much agree that the docker solution is in fact superior to CI caching. Even though we'll probably still need the latter for osx anyways.

[ekpyron]

Another option to consider: I just played around with github actions and github packages in https://github.com/ekpyron/test

It turns out that we could also define a github action to be triggered on every pull request that modifies a docker file, which builds the docker file and publishes it to the "github package repository" associated with our repo. And that acts as a fully fledged docker registry, so we can then have CircleCI pull the docker image from there instead of from docker hub...

[ekpyron]

Related issue: https://github.com/ethereum/solidity/issues/7685

[github-actions[bot]]

Hi everyone! This issue has been closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.