Codespaces and dev containers

[ankudinov]

Starting this thread to discuss Codespaces and dev containers build.

1. I'm curious if keyring is required? Tested GH CLI with Codespaces before - it worked well without. Curious if there is any challenge I missed or it can be simplified?
2. What are the warnings?
3. I'd say install all requirements for testing directly in the container without pyenv. Any good reason to have pyenv within a container?

[hellt]

1. I was following the official installation guide, but I suspect that maybe this keyring already installed in msoft provided base images?
2. containerlab reads the ~/.docker/config.json before pulling the images to check if auth data exists. Currently containerlab emits warnings that the file is not available. While it doesn't prevent the lab from booting, it looks ugly. Therefore I added empty files to silence the warnings.
3. pyenv is my preferred choice to manage venvs and python installations, since it is lightweight and easy to setup I package it in the devcontainer image. The devcontainer image is meant to be used to develop containerlab as well, so the test infra is pre-setup here.
   Yes, I could install the venv for clab testing in a postCreate command, that way it would only be used in the containerlab' devcontainer environment (and not in the lab codespaces), but, again, due to the fact this is all super lightweight I decided to roll it all in

[ankudinov]

1. Maybe I missing what is the final target? To connect from your laptop to Codespace it's sufficient to install SSHD feature in the dev container. Which is already part of the devcontainer.json. To install GH CLI inside dev container I'd use this feature:

"features": {
  "ghcr.io/devcontainers/features/github-cli:1": {}
}

So, my guess - we could simplify Dockerfile anyway. That's the beauty of dev container - Microsoft have done most of the work already. =)

2. OK. I guess I have not seen that as we don't pull cEOS-lab images. =/

3. I'd rather create 2 different pre-build dev container images - one for development, one for labs. If they share a lot - create a 3rd base image. You can have multiple tags for different Python versions, etc. IMO, dev container fully replaces venv/pyenv and mixing can cause some challenges and confusion. I've seen people mounting dev container to a repository with venv (not Pyenv though) - it's not good. =) Every single name:tag combination points to a fixed dev environement with a fixed Python / Golang version. Matrix makes this job easy.

Also try to keep devcontainer.json itself very simplistic and base it on a pre-build with all the features, extensions, etc. That reduces the Codespace / dev container build time significantly. Image, tokens, host requirements, postCreate and workspace mount are the only things to be present in an ideal devcontaine.json - the rest comes from pre-build image.

[hellt]

1. the reason I am installing gh is because I am using gh auth token to authenticate with the private registries. It also provides a CLI interface to codespaces, to check which codepsaces are running, stopping/starting others, etc. It also makes it easy to switch to PR branches when checking out pull requests. The best tool ever.

The reason I moved from using the features in the devcontainer config file is because I generate code completions, and features are running after the dockerfile is built.

3. I wanted to have clab-devconatiner:<tag> and clab-devcontainer:<tag>-slim, where the slim version is stripped from Go and Python stuff, to run the labs. But I had not time to do this properly via a matrix, so I did not do this for the initial launch. Welcoming contributions for it.

[ankudinov]

The reason I moved from using the features in the devcontainer config file is because I generate code completions, and features are running after the dockerfile is built.

Maybe pre-build a base container fist and do competitions in a simple dev container based on a pre-build image.