New version of Quay linked tool, but not auto-build

It’s been a while since I’ve needed to make any changes to our published CWL and we now build the docker images via CircleCI and push to Quay (due to the long period with no support for docker login on Quay). I don’t know if this is impacting this but here is what I am seeing.

When I attempt to select the new tag/release (3.0.0) the “files” tab indicates:

A Dockerfile associated with this Docker container could not be found.

Same for descriptor and test files.


I took a look at version 3.0.0 and it looks like all the files are there. Did you mean version 3.3.0?


Apologies, yes I was meaning 3.3.0.


As an update, we believe that the situation has arose due to

we now build the docker images via CircleCI and push to Quay (due to the long period with no support for docker login on Quay)

To elaborate, the tool started life as a fully automated tool where we grab information on corresponding github versions from the trigger for a particular build. (More info at Tools — Dockstore documentation ) But now that the Docker image is being pushed into by Circle, we no longer have that build information to key off of to figure out which GitHub version is relevant.

We have a few ways forward:

  1. We have someone looking into how “partially-automated” works and whether it makes sense in this situation (and why it did not activate)
  2. If the tool is a part of a workflow, it might be simpler to share that workflow via our GitHub apps support Dockstore GitHub App — Dockstore documentation
  3. We’ve been working on backporting GitHub Apps support for tools from workflows for cases where the Docker image is really independent from GitHub (think tools that are using a BioContainers Docker image and no Dockerfile is available locally) , but this would be a medium term solution (i.e. not a week or two solution)

Apologies that there is no simple solution and we’ll let you know what we find out

Just letting you know that (1) the “partially automated” mode doesn’t seem like it would apply. It currently only seems to let one skip over Docker images but not to switch over to images completely built somewhere else.

Not the best news, but let us know if you’re interested in pursuing (2) or if we should let you know when (3) is ready for testing.

Hi, I think (3) is the only solution that will really work. We’ve tended to only add tools rather than workflows.