Suggestion to add a Jenkinsfile pipeline declarative "sample" showing how this would integrate into a Jenkins CI/CD environment?

[hpe-ykoehler]

No description provided.

[stuartleeks]

Hi @hpe-ykoehler - at its core, this project is a wrapper around devcontainers/cli and all the interactions with dev containers (building/running) are performed via the CLI. So while this project only has support for GitHub actions/Azure DevOps pipelines, the devcontainer CLI can be installed in other environments and used to build and run dev containers there. I'm not familiar with Jenkins, but if it offers a similar capability for building custom tasks then this project may be a useful reference if you are interested in building that.

Hope that helps!

[hpe-ykoehler]

Hi,

The issue I have right now about Jenkins support would likely also apply to github or azure. The lifecycle is what I am most concern about. When a devcontainer up is called, more than one image or container can be created, some features may create stuff, etc.

When changes occur, left over images can stay on the machine eating disk space.

I also do not see any devcontainer down or way to destroy previous devcontainer docker containters, if changes occur to the Dockerfile associated with the devcontainer I see the additional image created but again no cleanup.

CI/CD aspect needs to be normally operated over time without much maintenance, so I am curious how the lifecycle works from devcontainer point of view (since it is mentioned on the website that devcontainer is also to be used with CI/CD, and how those extra docker images and containers are expected to be managed.

I didn't see or understand those aspects in the context of Github. while I understand that Github and Azure are microsoft and Microsoft is driving this, Jenkins is very well integrated everywhere and a leading opensource project in that area, so I would recommend this project to be integrated with it. For example, Jenkins support running an agent with a Dockerfile, it would be interesting to get Jenkins agent also support a devcontainer as part of the agent.

[stuartleeks]

I also do not see any devcontainer down or way to destroy previous devcontainer docker containters, if changes occur to the Dockerfile associated with the devcontainer I see the additional image created but again no cleanup.

You are correct that this project doesn't implement any cleanup. With the hosted runners for GitHub actions/Azure DevOps pipelines we get to pass that problem on to the hosted agent platform :-) If you are using self-hosted agents, you could run a separate periodic task to clear out old containers/images (or run that task in each pipeline execution).

If you use the devcontainer CLI directly, the up command returns details on the container that is started which could be captured and used for cleanup.

In terms of devcontainer down, there is an issue tracking that on the CLI repo: devcontainers/cli#386

[hpe-ykoehler]

I can implement a pipeline in jenkins to use docker-in-docker (instead of docker-from-docker) so that when the agent goes down associated stuff does with it, but I was expecting the devcontainer website to talk about those things because even for a developer that is a problem as well.

It is unlikely that developers will understand that they need to manage their docker environment (containers and images) to clean stuff behind, unless they are docker-aware/trained.

So somehow documentation should point towards some other documentation on how to do proper docker clean up, or provide a way to help developer do so (which in turn will likely also be usable by CI/CD as well)

[stuartleeks]

I have added #207 to track the suggestion of adding documentation on the cleanup aspect - thanks!

[alexanderilyin]

If you love Bash as much as I do:

#207 (comment)

[hpe-ykoehler]

@alexanderilyin thanks for sharing, I had something similar for local development but not as clean.

I still do not like this approach for CI/CD because the "stage" at the CI/CD level includes the devcontainer build aspect, which to me is more of a pre-build aspect (is not directly related to the project being build)

we also use docker-compose so we have to basically do docker-compose down instead of docker rm.