-
Notifications
You must be signed in to change notification settings - Fork 192
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
Add Gitpod environment to nf-core tools #1384
Conversation
Let's add this functionality to the pipeline template too here. Would it need to be any different? As mentioned on Slack my main concern is re-building images unecessarily. I don't know how all of this works on the back-end but be great if we can re-use these images as much as possible, especially since they will now potentially be used across all nf-core pipelines too after we have added it to the template. |
We should build it differently then if we want to propagate this to the other repos.
And then put the Dockerfile somewhere in this repo, and use a GH action to publish it to ghcr.io on modification. Where is a good folder to put the Dockerfile? Also if not ghcr.io, then where? This means image is built when the Dockerfile is updated here, and then the other repo's just pull the image ready to work. |
I would be tempted to put it in
We have an nf-core Dockerhub account we can push to but I guess we would only want an Actions to update the image on the tools repo to keep things centralised (as opposed to having an Actions to update the container in the pipeline repos too). Another consideration is how we perform the tagging and how important that is overall i.e. do we always just pull the |
Why put it in a hidden folder? While it's unlikely to need lots of updating, I think it's better not to "hide" it.
Ya, exactly. Keep it centralised. But the built image needs to be hosted somewhere. Are there still costs to using Dockerhub?
I would say always pull the latest. There's really no need to pull an older environment that I could think of. |
Kept the original |
I created a test pipeline from this PR (using my docker-hub image for now). Everything seems to work as intended 🤩 (initial start up time was the normal 30-60 sec). You can play around with it if you want: https://github.com/mashehu/nf-core_test (I included also the nf-core extensions (except for liveshare, because that functionality is already included on gitpod) |
Co-authored-by: Matthias Hörtenhuber <mashehu@users.noreply.github.com>
Anyone know how to test the GH actions workflow? |
Co-authored-by: Matthias Hörtenhuber <mashehu@users.noreply.github.com>
You could try to have it run in your repo by removing the if-clause (and adding the dockerhub secrets). |
Can someone who has permissions build and upload the image to the nf core dockerhub? |
Why do you need it preloaded? It will be pushed with this PR, no? |
True. |
Co-authored-by: Matthias Hörtenhuber <mashehu@users.noreply.github.com>
They are part of the github org secrets for nf-core. |
command: |
NFCORE_BUILD_PATH=$HOME/nf-core_build
pip install --upgrade -r requirements-dev.txt -e . -t $NFCORE_BUILD_PATH
PATH="$NFCORE_BUILD_PATH:$PATH" That should allow one to develop with the current nf-core build. |
Co-authored-by: Matthias Hörtenhuber <mashehu@users.noreply.github.com>
OK. Next attempt. My prebuild is now using a cached version of the Docker image so |
hmm, I don't think this works. |
Sorry, I guess I wasn't clear enough with my previous message. The current docker image used for the Gitpod environment is the cached one, so it doesn't have One way to test locally is to do what Gitpod is doing in the background. Build the Docker image, clone the tools repo into workspace, and then do the |
Local test instructions: # locally build docker image
docker build -f nf_core/gitpod/gitpod.Dockerfile -t gitpod:test .
docker run -it --rm gitpod:test bash
# Inside docker image
cd /workspace/
sudo git clone https://github.com/nf-core/tools.git
sudo chown -R gitpod:gitpod .
cd tools/
python -m pip install --upgrade -r requirements-dev.txt -e .
nf-core
vim nf_core/__main__.py
nf-core |
Yes, I tested it also now locally and it works great! Awesome! |
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.
Tested also the template and everything works as expected. 🚀
Thanks for all the testing! |
We would save around 1.5 GB by squashing the image, but the gh action can't do that at the moment (it is an experimental feature), but would be great to get the size still down somehow. Something for a feature release 🙂 |
Well the image doesn't need a lot of what's in there and could likely be made a whole lot lighter, but for now I'm not going to mess too much with it. It shouldn't really be a problem as I see it so far. |
Well, a smaller image means shorter start up time, plus lower resource consumption. Both things are nice to have. 🙂 |
@drpatelh Anything else that needs to be done here before merging? |
Sorry, missed this. This is amaaaazing! Thanks guys :) |
Adds a gitpod environment with
Singularity might be possible through the docker image: https://github.com/kaczmarj/singularity-in-docker
My fork has prebuilds enabled.
Check if it meets your needs @drpatelh . We can then enable prebuilds on the nf-core repo.
I've not added extensions, but check the extensions tab if there's something you think might be useful.