Publish dockerfile

[ddalcino]

This separates .devcontainer/Dockerfile into dependent and dependee Dockerfiles. One Dockerfile will be built and published in the Github Container Repository during a CI workflow. The Dockerfile that remains in the .devcontainer folder will depend on this published container.

This will:

• Speed up build times for users using VSCode, because the only thing Docker really needs to do is pull the prebuilt container
• Provide a prebuilt base container that can be easily extended
• Prevent build errors like this one: publish docker image  gui_starter_template#210 (comment)

Fix cpp-best-practices/gui_starter_template#210

Uses two commits from #8

[codecov-commenter]

Codecov Report

Merging #30 (dc14794) into main (f37c1ab) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #30   +/-   ##
=======================================
  Coverage   77.77%   77.77%           
=======================================
  Files           3        3           
  Lines          36       36           
  Branches       19       19           
=======================================
  Hits           28       28           
  Misses          7        7           
  Partials        1        1           

Flag	Coverage Δ
Linux	37.03% <ø> (ø)
Windows	80.00% <ø> (ø)
macOS	38.46% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f37c1ab...dc14794. Read the comment docs.

[ddalcino]

To make this work, some settings will need to be changed.

This process is partially described in https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry.

• We need to add a repository secret called PAT, with the value of a new personal access token with permissions to read, write, and delete packages in GHCR. Repository secrets are under 'Settings > Secrets > Actions > New repository secret'.
• After the container builds correctly, it will be pushed to GHCR, but it will be privately accessible. From the organization profile menu, you can associate the cpp package with the cpp_boilerplate_project repository and change access permissions to 'public'. It's not very straightforward, I had to follow this guide to figure out how to do it.

After these settings are changed, cpp_boilerplate_project will be linked to the packages that this workflow generates. You can see what that would look like here, on my personal fork of cpp_boilerplate_project: https://github.com/ddalcino/cpp_boilerplate_project/pkgs/container/cpp.

[ddalcino]

I think we should have multiple base containers for every combination of the provided variables that devcontainer can inherit from and we support. (e.g. ghcr.io/cpp_best_practices/cpp:focal:11:13, ghcr.io/cpp_best_practices/cpp:bionic:11:13 etc..) So that the FROM call should look like FROM ghcr.io/cpp_best_practices/cpp:${VARIANT}:${GCC_VER}:${LLVM_VER}:0.1.0

I am planning on doing something like this, but I'm not sure about the names. I want to follow established naming/versioning conventions, but I'm not certain what they are. Is a : character common between bits of versioning info? I was thinking of something more like FROM ghcr.io/cpp_best_practices/cpp-${VARIANT}-gcc${GCC_VER}-llvm${LLVM_VER}:0.1.0, and adding aliases for some tags, like cpp:latest, for the latest versions of everything.

Oh, and thanks for the feedback! It's very useful.

[ddalcino]

Giving descriptive prefixes is even better! But what happens with the optional variables like ${USE_CLANG} and with the ${USE_ROOT} I added in my branch?

I haven't looked at it yet, but the state of USE_ROOT sounds like a very useful thing to add to the container tag.

I think that the ${USE_CLANG} is not needed any more since we use presets, and we pass the desired compiler through CMake.

I think it definitely makes sense to remove USE_CLANG from the parent docker/Dockerfile. It might be worthwhile to add an example docker/example.dockerfile that extends the parent file, and adds USE_CLANG back in. I will leave that change for another PR though.

Another idea I had is to support within devcontainers all containers that the CI supports. So that I can easily reproduce in my machine the ci builds no matter what my native OS is.

Have you looked into Github self-hosted runners? It sounds like that's what you are describing. I'm not too certain though; I have never used them.

The only real way for the Docker container to truly mirror the GH workflow CI environment would be to run this Docker container in CI. We can get close to the CI environments by removing most of the Docker container and replacing it with setup-cpp, the same tool we use to install most of our packages in CI, but there would always be differences. There are a few things that our container can do that setup-cpp cannot, for instance, install include-what-you-use. Personally, I like the fact that we are maintaining a container that installs tools in a completely different way than setup-cpp: if something goes wrong with one of them, we can easily fall back on the other.

[ddalcino]

This check is insufficient. What we need here is to check that:

1. we are on the main branch
2. there isn't already an existing container in our package repository that has the same tag, that a push would mistakenly overwrite. We don't want to overwrite an existing cpp-gcc11-llvm-13:0.1.1 when we have forgotten to bump the version to 0.1.2; there may not be a way to get the original back.

If both these conditions are true, it should be safe to push a new version of the container.

I'm not so experienced with GH workflow syntax, and I'm not clear on how to make this check work. Honestly, I'm not even sure if ${{ github.ref == 'refs/heads/main' }} does what it looks like it does.