I’d like to get the complete set of workflows (even if just the ids and time started/stopped) across all workflows and branches in a project.
The insights API doesn’t seem to cut it here, because I need to know:
The names of all workflows that have run in the last 90 days. Workflows get renamed periodically, or even just appear and disappear as people test things out. This is hard to find
The names of all branches that have triggered builds in the last 90 days. Branches come and go frequently. This is hard to find
The pipelines API gets closer but involves a lot of work. I’d have to go through each page of pipelines from the last 90 days, then use that to look up each pipeline’s workflows and sort by stopped_at. Unfortunately, this is definitely hundreds and possibly thousands of pipelines to sort through.
I could also go through the pipeline-> workflow process and use it to query the recent workflows API so I only have to store the branch x workflow_name pair, which would result in nicer output but many more API calls.
What’s my most efficient option for getting workflow runs sorted by either creation or stopping time?
You’re right - this isn’t easy right now. You could also utilize the builds endpoint, but you’d still have to do some custom script for dates and the exact data you want (and it would likely result in multiple API calls that could increase quickly)
Is there something specific you’re after? We’ve had a couple folks ask about this kind of data, but I’m wondering what the use case is.
We’re looking to track test failures and performance changes over time in a large, multi-package repository. As I mentioned, there is a constant stream of changes to the CI configuration, so searching just by workflow name isn’t an option, and searching by branch doesn’t work very well since workflows on master are different from workflows pre-merge (which is where we want to gather metrics).
The data we’re currently looking at is the failure rate of a workflow over the last 15/30/90 days (across all branches), and how the runtime changed in those rolling windows. We’d like to be able to run the same analysis on jobs.
As mentioned, the insights API gets us workflows back in the order that makes sense, but we’d have to know all workflow and branch names. The pipeline API gets us the info without said restrictions, but provides no guarantees about whether the first pages contain the most recently execute workflows.
The builds endpoint probably won’t work for us since we have such a large repo with many contributors, and the build limit would force us to poll for new data nearly constantly.
Currently I’m polling pipeline pages and checking the updated_at field as a proxy for “have new workflows run on this workflow”. Once I find n consecutive pipeline pages with no updates, I just assume nothing has been rerun and stopped polling. It’s not foolproof and the n looks like it might have to be large, but it’s not too slow
If you aren’t tied to the API exclusively, I think a lot of this will be answered by the new Insights UI (coming in early Fall). Buildtrakr could also be really useful for you.
If you have feature requests specifically around the API, you should definitely post them at ideas.circle.com (this has been newly updated so the turnaround is much faster).
Just realized I hadn’t responded earlier. Thanks for the pointers! I took a look and at the moment haven’t made any changes, but it’s good to know that there are existing options out there. I put some comments in your insights post that’s really just an extension of some other things I’ve talked about on here before, but the UI itself looks really nice even if the functionality hasn’t been expanded from the base insights API.
Happy to mark this as solved, as I think you’ve given me all I need to think about alternative solutions