-
Notifications
You must be signed in to change notification settings - Fork 1
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
chore: integrate development docker stack with vscode #22
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great my bro
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your additions! I've left a few suggestions. So I think we are moving towards a monorepo approach where we do bind VSCode to the devcontainer? 👍 I will open an issue for this, it would be great if we use issues systematically so that we leave a written trace for future reference (if possible, I think we should enforce that branches follow the <issue-number>-<description>
naming pattern as well).
We may also want to remove the remains of the devcontainer bindings (namely the devcontainer.json
files).
Edit: the issue is up at #23
Co-authored-by: Alexandre Chau <[email protected]>
Co-authored-by: Alexandre Chau <[email protected]>
Co-authored-by: Alexandre Chau <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🍔 thank you for your work. Should we cleanup the devcontainer files that we will not use anymore?
.vscode/tasks.json
Outdated
"presentation": { | ||
"reveal": "always", | ||
"panel": "new" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know if the "start" task is automatically stopped (sigint'd?) when VS code is closed? I think it's best if we ensure that the containers do not continue running in the background. If that is not the case, I'm not sure what we should do since there's nothing equivalent to e.g. folderClose
(see microsoft/vscode#65986). Let me know @Thechi2000, thanks! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not seem to be possible, but it seems that reopening the folder does not launch more containers; the existing one are reattached into the task. I think we should leave it that way, since there is not much we could do
Should we cleanup the devcontainer
We can remove the unused devcontainer.json
files, but the .devcontainer
folders are still useful to store the Dockerfile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thank you. Though I guess since we don't use the -d
flag on docker compose up
anymore, when the VSCode process dies then the command may stop the stack through SIGINT
? No problem anyway, we'll see how well it behaves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 📦 thank you!
Some settings that will help development on VS Code
Closes #23