Short answer: not yet, it might work best with automated tools
Long answer: we're working on it starting with workflows (i.e.
class: Workflow) in conjunction with GitHub apps. That's a new feature detailed in https://docs.dockstore.org/en/develop/getting-started/github-apps/github-apps.html that also allows for a much easier way to define multiple workflows in one repo. We also have a feature in the pipe that deals with one of the issues of workflows in a shared repo (tags applies to all tools regardless of whether they changed)
We have not started thinking about GitHub apps with tools (
class: CommandLineTool) yet but it is on our roadmap.
In the meantime, if you register tools as an automated build via quay.io that might be the cleanest method ... but I do see that https://github.com/common-workflow-library/bio-cwl-tools doesn't have Dockerfiles (so that might not work either)
trs://URI for a Dockstore workflow. When I go to the "TRS" line in the workflow summary page, the link is an
cwltoolworks fine with that, it is not a
trs://link as outlined in the specification. I can not figure out what the TRS link should be. It would be nice to have that as the text on the workflow page, instead of the stub that we have now.
#workflow/github.com/kaushik-work/simple-passthrough-cwlit would be helpful to have
trs://dockstore.org/workflow/github.com/kaushik-work/simple-passthrough-cwlor whatever the proper URI is.
trs://dockstore.org/#workflow/github.com/kaushik-work/simple-passthrough-cwlbased on the pattern
I don't seem to be able to find any documentation or settings that allow you to set an account/password to allow pulls from docker hub via a docker login for base images.
Although I've read the suggested mitigation (https://www.openshift.com/blog/mitigate-impact-of-docker-hub-pull-request-limits [openshift.com]) this doesn't appear to address sensible methods to deal with things like "ubuntu:20.04". It would seem incredibly inefficient for each group needing an OS image to replicate this on quay.io under their own repo.
Is quay.io going to provide tooling for this our do we need to move to all images being built by an external CI (pulling from dockerhub with login) and being pushed to quay (via docker login)?
Quay does not have a mechanism to set up pull credentials for images on outside registries. It expects that the image you pull is publicly available. The only way to mitigate this issue is to move your base images to a free and open registry that does not rate limit the number of pulls.
I have created a feature request for our dev team that would allow users to define pull credentials at build time. That way you could add Docker credentials to your build which should make your pull authenticated.
Unfortunately, Ican't tell you when this feture will be implemented, I did create it with high priority as this issue hits many of our customers.
It is important to note however, that a pull is also counted if the client system already has all the image layers present and nothing is actually downloaded. That means that image caching does not reduce the number of pulls counted against the limit.
confirmed, that indeed sucks
I manage the Sanger account at Canonical.
Today we announced that we will be joining the Docker Hub, verified publisher programme
There are no rate limits because of this new partnership.
Specifically in the second link:
Canonical and Docker will collaborate on Docker Official Images and LTS Docker Image Portfolio to bring the best of the two to the community and ecosystem. The entire LTS Docker Image Portfolio will be exempted from per-user rate limits.