Replies: 1 comment
-
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Why are you starting this discussion?
Product Feedback
What GitHub Actions topic or product is this about?
ARC (Actions Runner Controller)
Discussion Details
We are using GtiHub ARC in a Kubernetes cluster to build and deploy most of our software. Each repository we build defines a development container (devcontainer) that is used for development in VSCode/Cursor/... but this is also used for CI/CD.
Important to note is that each repo typically defines a Dockerfile to build, rather than a ready-made image to run. We typically compose the various layers from pre-built layer images, much like devcontainer features work. (This approach allows us to have Dependabot working on the tooling, for example updating our Node version or the version for our deploy scripts).
We currently do this manually using an in-house GitHub action that more or less does what @devcontainers/cli does, but has some additional context (for example it knows about our in-cluster image cache and so on). For this to work we need to run ARC in "DinD" mode, which means that for each job we need to spin a Docker service with its own storage etc, adding to build times (typically pulls are lightning fast, but unpack takes time). Additionally, DinD has issues with cgroup limits etc.
I think it would be really useful if it was possible to use dev containers in ARC Kubernetes mode (essentially spinning up a pod with the dev container image) and built from the Dockerfile pointed to in the devcontainer.json. We cannot do this ourselves since there is no way for us to execute any code before the pod is started, this is something that GitHub/ARC would have to implement (and no, I don't consider adding a "pre build job" before the compile job a solution, it is a workaround at best).
Would this request make sense? I personally feel that if dev containers were natively supported by ARC (and maybe even on hosted runners) without the overhead of docker-in-docker or pre-build steps, I would never do CI builds any other way. One image to rule them all!
Beta Was this translation helpful? Give feedback.
All reactions