Add API endpoint to fetch a history's workflow invocations.

[jmchilton]

Refactor toward managers to allow unified serialization of invocations and such. Add test case.

In service of #5142 I suppose, builds on #6559 (cherry-picked into dev).

Next up... I want to add a jobs_summary API that matches collections (https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/webapps/galaxy/api/history_contents.py#L183) - this should allow effective summary of job states for fully scheduled workflows. One can then imagine a progress bar for whats steps are scheduled and below it a progress bar for what job states are - this second one built on this new API I'm planning and that could probably completely reuse the collection summary code on the client.

[bgruening]

Thanks this is great! Displaying all this information to the user at the end will be a big improvement.

[dannon]

@jmchilton My only question is about getting all of a user's active invocations. Would we want another endpoint, additional query parameters here, or multiple requests for all histories?

(I ask, because this is a feature I started working on at the hackathon and then had this exact issue with -- displaying all active invocations on the workflows landing page)

[jmchilton]

I can add /api/invocations to sort of mirror /api/jobs - should be pretty trivial. Would that be enough?

[dannon]

@jmchilton Yeah, that's what I was getting at. You think the second endpoint is better than having /api/invocations defaulting to all invocations, filtering with a history_id parameter or other query params? (like workflow id, etc)

[jmchilton]

You know me - I'd just add both 😄. But I'm totally fine dropping the /api/histories view of this and just adding the /api/invocations with history_id parameter. I'll rework this, thanks for the feedback @dannon.

[dannon]

@jmchilton Thanks! I think it'll be a little more flexible in the long run, and I'm excited to use it to finish off this active invocations view!

[jmchilton]

I think the changes are good for review - /api/invocations is now good to go. It can take a history_id, workflow_id, or neither.

[dannon]

@jmchilton Thanks! Checking it out.