chore: Reduce devcontainer size

[jheidbrink]

Summary

Reduces the devcontainer size from 6 GB to 4 GB.

The Dockerfile meant to remove several downloaded source folders, but those commands assumed a WORKDIR of /. With the WORKDIR set to /usr/local, those rm command had no effect. This was undetected due to rm being called with the -f option. This PR fixes the paths, and also uses the --interactive=never flag instead of the -f flag, so that regressions are detected by failing rm commands.

This PR also removes /root/.cache/go-build folders.

This PR partly removes llvm-10, thus does a small part of #14279.

Test Plan

In the magma folder:

docker build -f .devcontainer/Dockerfile .
# look up the image id
docker run -it --mount type=bind,src=$MAGMA_ROOT,dst=/workspaces/magma <container_image_id> /bin/bash
# inside the container:
bazel build //...

[github-actions]

Thanks for opening a PR! 💯

A couple initial guidelines

• All commits must be signed off. This is enforced by DCO check.
• All PR titles must follow the semantic commits format. This is enforced by Semantic PR.

Howto

• Reviews. The "Reviewers" listed for this PR are the Magma maintainers who will shepherd it.
• Checks. All required CI checks must pass before merge.
• Merge. Once approved and passing CI checks, use the ready2merge label to indicate the maintainers can merge your PR.

More info

Please take a moment to read through the Magma project's

• Contributing Conventions for norms around contributed code

If this is your first Magma PR, also consider reading

• Developer Onboarding for onboarding as a new Magma developer
• Development Workflow for guidance on your first pull request
• CI Checks for points of contact for failing or flaky CI checks
• GitHub-to-Slack mappings for Magma maintainers for guidance on how to contact maintainers on Slack

[github-actions]

dp-workflow

0 tests   0 ✔️  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit c040376.

[jheidbrink]

lldb means lldb-10. Given that all the other packages here depend on llvm-11 and this one on llvm-10, I assumed without testing that we can use lldb-11 here.

[jheidbrink]

In contrast to -f, --interactive=never fails when the directory doesn't exist, so that we detect when this command isn't doing what we expect.

[Neudrino]

Would one want to create an alias for it, if it is used multiple times throughout the script?

[jheidbrink]

I would say it's simple enough that it's ok to repeat it. Repeating it is slightly easier to read as you don't have to look up the alias.

[jheidbrink]

This solution has the disadvantage that we have to count how many directories we descended. I discussed with @nstng to use pushd/popd, or running the cd in a subshell so that the parent shell never changes directories. We figured that this version is the most widely understood one and thus kept it despite the disadvantage of having to count.

[Neudrino]

How about introducing a variable for the workdir? I.e.

ARG basedir=/usr/local
cd where/ever/you/want
...
cd ${basedir}

This would avoid the counting and be pretty safe to always return to the desired directory.
Similar to https://docs.docker.com/engine/reference/builder/#workdir.

[jheidbrink]

I would prefer the current solution as it is a bit less stateful as it doesn't care what the working directory is set to.

[Neudrino]

Another thought: How about the "poor mans pushd/popd": cd -? Might that be a valid option?

[jheidbrink]

That wouldn't work for prometheus-cpp below, as that uses multiple cd commands. I'm inclined to not put more thought into this, but accept it as good enough.

[Neudrino]

The Dockerfile meant to remove several downloaded source folders, but those commands assumed a WORKDIR of /.

I wonder if the workdir is set correctly for all parts? Form the code it looks more as if the workdir should only be set to /usr/local for the Go installation but be reset to the original (/) afterwards?

[Neudrino]

Rebuild the container locally from branch. Builds and starts fine. ✔️

[jheidbrink]

The Dockerfile meant to remove several downloaded source folders, but those commands assumed a WORKDIR of /.

I wonder if the workdir is set correctly for all parts? Form the code it looks more as if the workdir should only be set to /usr/local for the Go installation but be reset to the original (/) afterwards?

Hm, I think steps in a dockerfile should avoid relying on a specific WORKDIR (including /), and if they do they should have an explicit WORKDIR declaration close by.