-
Notifications
You must be signed in to change notification settings - Fork 213
Local devcontainers (take 2) #575
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
Conversation
✅ Deploy Preview for nextflow-training ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
0762f9b
to
8da3a67
Compare
@pinin4fjords where do we stand on this? |
Co-authored-by: Maxime U Garcia <maxime.garcia@seqera.io>
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.
Minor comment, but I followed the guide, and managed to run a different nextflow version in my local devcontainers compared to my own local install.
This is some serious magic
Co-authored-by: Maxime U Garcia <maxime.garcia@seqera.io>
Applying maxime's little suggestions dismissed his approval, but this is tested and ready to go. |
Re-pitching #539 in light of recent changes. I'll pull updates to docs etc from there once people are happy with the approach.
Local devcontainers usage means making the host file paths valid within the container to appease docker-outside-docker. This is really just a case of:
/workspaces/training
valid and consistent with materials, and add some options to move new terminal starting dirs to the symlink.I'm not sure if this will all work without a local build, so
I also had to pin the java version ('latest' didn't work for me).