Allow to filter /api/invocations by job_id

[scholtalbers]

What did you do?

• add an additional filter to /api/invocations to filter this endpoint by a dataset id

Why did you make this change?

This will allow one to retrieve the workflow invocation and subsequently the workflow (through the workflow id) that produced the given dataset.
Without this, I could only see to retrieve the responsible workflow through /datasets/<id> -> creating_job -> /jobs/<id/ -> __workflow_invocation_uuid__ -> filter invocations/ -> (..)

Alternatively, I wanted to add the workflow_id to the dataset show endpoint, but due to the additional queries/joins this might be too heavy.
In addition, I'm happy for alternative solutions to the problem "dataset_id => workflow_id".

How to test the changes?

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. run a workflow
  2. use the resulting dataset id to filter -> /api/invocations?dataset_id=

License

• I agree to license these contributions under Galaxy's current license.
• I agree to allow the Galaxy committers to license these and all my past contributions to the core galaxy codebase under the MIT license. If this condition is an issue, uncheck and just let us know why with an e-mail to galaxy-committers@lists.galaxyproject.org.

[mvdbeek]

This only works for simple workflow outputs (so not for any random dataset produced by a workflow). It also doesn't work for collection. I think filtering by job is the correct way to do this.

[scholtalbers]

ok, which is currently not yet possible right? So I could update this change from dataset_id to job_id?

[mvdbeek]

Yes, I think that would be fine. There's a 1 to 1 relationship between job and invocation, so maybe this would be more appropriate in

galaxy/lib/galaxy/webapps/galaxy/api/workflows.py

Line 934 in 61fcd51

def show_invocation(self, trans: GalaxyWebTransaction, invocation_id, **kwd):

?

[scholtalbers]

hmm, but then we need to make the invocation_id optional? Otherwise, one needs to know the invocation_id upfront..

However, the invocation_id and potentially the workflow_id could also be returned on the show job endpoint, then there is no need for a filter.

[simonbray]

I think this is quite similar to the API changes in #11244?

[scholtalbers]

@simonbray its similar indeed. Except that on the /invocations the workflow id is returned. Whereas on the changes from #11244 jobs/<uuid>/?view=workflow only the invocation id is returned. Possibly the ?view=workflow could be updated to return this information as well.