-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Epic: Support devcontainer.json
#7721
Comments
This would be a welcome addition, we currently make heavy use of the docker-compose based vscode devcontainer feature. And had to adjust our setups significantly to ensure we don't have duplication between lokal devcontainer and gitpod setups. This wasn't straight forward as in gitpod docker-compose needs to be called separately from starting the development container where in vscode the devcontainer is part of the docker compose file. We are happy to provide some insights how we have ensured that we are sharing the same compose file across vscode and gitpod. What we could not circumvent is having seperate Dockerfiles for the devcontainers as vscode and gitpod use different base images. To reduce duplication we have extracted the setup steps into scripts that are copied into and executed during image creation of the devcontainer. That said I think there is room for tooling that does this for you. Note: |
@svenefftinge Would this be an |
Just to pile on, one benefit of the As a new user to Gitpod, I don't expect I'll want to jump whole-hog into coding online. I expect my default will still be just coding on my personal machine inside a devcontainer. I like the option of being able to use Gitpod when on someone else's computer though (such as a work computer) which happens somewhat often (it also seems nice for my open source projects). Because of this, having one standard config that works the same across environments is definitely a feature I appreciate. Edit (2/5/22): |
Our company has been using If we could use those with Gitpod, migration would be trivial. Also, as @jorroll mentioned, the fact that Maybe it's because I'm still learning, but I've found the process of trying stuff in |
I need this badly 🙏🏻 after seeing the today's GH universe 😄 |
+1 on this, my projects are tied to .devcontainer format |
Another +1, it would make the transition to Gitpod way easier |
Heck, even if I still had to specify in .gitpod.yml which .devcontainer.json to use. I don't mind reminding myself whose product I'm using. Be nice if there was some open governed group maintaining standards like these for devtools... |
See #6922 |
Nice that you guys already scheduled it, I`m introducing devcontainers into our team's culture, but its still a task to set them up and make sure they work stable. |
As a new user, it completely shocked me that gitpod opens VSCode but does not use VSCode devcontainer configuration. It took me a lot of googling until I found this issue, and then I was like "What??" This may be a showstopper, if pointing gitpod.yml to .devcontainer/Dockerfile doesn't work. (edit: it did) |
Exactly as per @jessitron jessitron. Impressed at first, but felt let down next, after realising that nothing in the .devcontainer folder of the project wasn't taken into account. It probably is best not to have too many files format to do the same thing, and I'm afraid devcontainer will become a de facto standard instead of the .gitpod.yml, so might as well focus on that. |
Hey there! Just wanted to mention that we're in the process of opening up the dev container spec to be like the VS Code LSP. We plan to house the spec at https://github.com/microsoft/dev-container-spec and are looking into the release of a reference implementation. We're still early in the process, but we're happy to collaborate on the spec even before all of this is done - there's already a few things we plan to do like providing ways for services and other tools to add their own metadata into the format you'll see mentioned in this repository (and we'll also be moving the two VS Code specific properties we have under a tool specific property to follow suit). I'm sure that aspect would be useful to GitPod among other things. |
devcontainer.json
devcontainer.json
We have now made some small progress towards this. During a Gitpod hackathon we've created this branch. There's a lot of clean-up required. We commented out useful code during our hack which needs to be restored. Overall, we feel that we would like to continue with this piece of work as we could be very close to shipping an initial working solution. The current approach consists in modifying the Also, we discussed with @filiptronicek that we could have the converter utility abstracted out from the code of the server, so that it could also be used independently (e.g. using |
I agree with this, it's quite a painstaking process to test |
This is definitely on our radar, we have captured it in #7671. It's something that I personally cannot wait to start working on; because the value that brings is huge. |
It would also be useful to store |
Hi all 👋! I wanted to provide some updates on the dev container specification. We recently released the reference implementation as an open source CLI, in addition to an initial version of the spec. We now have a As @Chuxel mentioned, we also introduced a The CLI and spec are both in active development, so they'll continue to evolve, especially with external feedback. We'd love any feedback or questions you may have, and we're more than happy to collaborate on things that'd make this a better fit for you. Thanks! |
Just here to be another squeaky wheel -- I'm doing devex for my team, and we have a good mix of VS Code and JetBrains developers. It would be really sweet to have a first-class way to share a containerized development environment between both, and it seems like there's potential in the developing devcontainer spec to encode what both tools would need. The hard thing about using e.g. a shared Dockerfile is that the devcontainer CLI actually generates a Dockerfile when the image is built. It does this, as far as I understand it, to support features, so that support for e.g. languages can be shared in a modular way. So if I make a |
quite honestly i do think it would be smart to deprecate the i feel like |
Please support this feature. The spec is open source and already building in room to support other platforms. I don't want to maintain multiple standards and risk having inconsistent environments because one spec lacks features. After all, isn't consistency the whole point of doing dev containers? |
With Codespaces now having free hours and devcontainer features it's probably time to take devcontainer spec seriously. |
Yes - I already see many projects where things are just maintained parallelly to support Gitpod and Codespaces/VS Code. Very often those environments become different. So it's even more annoying. Now Docker team is trying to introduce their own way to open projects locally. To be honest - this idea is great and it's a good alternative to Gitpod/Codespaces if you want to open project locally: |
True. With the traction CodeSpace is gaining, not supporting devcontainer would not be a wise move for GitPod... I still prefer GitPod, because I'm more GitLab than GitHub, but I don't think I will continue to manager gitpod and devcontainer in all my projects for long. |
Can't emphasize this enough: Devs come to GitPod already familiar with developing in containers, and having heard your marketing that GitPod lets you do that in the cloud. Then they open their repo and the first thing they find out is that you've ignored their development container definition. (Wait, wasn't containerized dev...the whole...wait, what?) This is truly a very significant negative experience that makes those potential new users feel like you've betrayed your explicitly advertised raison d'etre before they've typed a single line of code. This should be on your "must fix and how did we let this happen in the first place" list. Between now and when it's fixed, you could at least add a notification when a user opens a repo with a .devcontainer folder that GitPod is ignoring, and say, "Hey, we just noticed you have a VS Code .devcontainer folder. We don't support that yet, but until we do, check out these docs to help you convert your container definition to our format..." That would tell those users that their expectation is both reasonable and on your roadmap, and give you a greater chance of keeping them on your platform while they wait. Right now they just go, "Well, that sucks" and leave. The 10-15 people who posted comments up above about their experience are the small subset from that larger group who chose to kindly give you their feedback before going back to whatever dev env they used before. |
Can't second this enough. Not supporting devcontainer definitions just makes it impossible for me to move out of GitHub's codespaces. |
🆙 x 💯
🆙 x 💯
🆙 x 💯 |
Thank you all for the comments, context and information ! 👋 A note on updates to this issue For avoidance of doubt: This is currently the most upvoted issue in our issue tracker (we are very aware!). Infrequent updates to this issue is not a signal that it is "ignored" by Gitpod. Your additional context + comments are useful. GitHub issues do not reflect internal discussions, investigations, or conversations etc. What type of support are you after? From the comments I can summarise the following broad reasons for the demand in devcontainer support. Until we have further updates here, a signal of the areas most important to you would be very useful to us: 👀 - Migrating projects to Gitpod (Gitpod for a project that already uses devcontainer) Any other use cases not covered above? If your use case is not adequately covered in these areas, please comment below. The more information you can provide us, e.g. your specific use case, a link to a repo or replication, or concrete examples of what you're trying to achieve, the better. This helps us to identify what "type" of devcontainer support would be most useful for you. Again, thank you for your patience, hopefully we have more updates for you soon 🙏 For those looking for faster For those who commented about iteration speed on |
You make a good point, we should document current approaches of what you can do today (and also in future) to help manage a devcontainer and gitpod.yml setup (link below). Many good ideas have been shared here. A good point to remind is that one of our guiding principles is to "integrate, don't dictate" [1], and we honour this wherever we can. |
Multiple devcontainer configurations for the same repository. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I don't think this issue should be closed. |
@loujaybee
Is there anything to update here? Is there somewhere else we can follow the progress/discussions? |
Hi all, any update here? I am leading the virtual env. work for public demos at my employer and we want to standardise on Gitpod but I will not do so until Gitpod supports devcontainer. |
Hey all, I’m thrilled to share that we’ll be launching support for the devcontainer.json configuration format later this year, along with some additional surprises. 🙂 |
Given VS Code's and GitHub's dominance in the developer world, VS Code's devcontainer.json format is going to become a quasi-standard eventually. Supporting it will allow us to lower the entry barrier for teams who already use it so they can easily spin up their dev environments in Gitpod and experience the speed (startup time, prebuilds) and efficiency (lower cost) of our product.
The text was updated successfully, but these errors were encountered: