Running selected actions using globs

[wjchulme]

It's good to modularise actions as much as possible to facilitate parallelisation and to avoid re-running chunks of code unnecessarily. But this can dramatically increase the number of actions (it also increases the amount of copying, which can be a problem especially when running locally, but that's a separate issue -- see https://github.com/opensafely-core/job-runner/issues/319 and https://github.com/opensafely-core/job-runner/issues/169).

Having lots of actions can be a problem. When viewing the project on the job server, you get a long, flat list of actions. If you want to run a lot of actions at once, you have to click run for each individual action, which can take a little while (> 1 minute) and is also error prone if you're clicking through very quickly. See https://jobs.opensafely.org/datalab/covid-19-vaccine-effectiveness/booster-effectiveness_main/run-jobs/ for an example of a fairly unwieldy set of actions.

Can we add a feature that allows us to run actions that match a supplied glob? Eg in the above study, I could just ask to run *_seqtrialcox_pfizer_*_none to run 16 actions without having to click run for each one. This requires the project structure to be captured in the names of the actions, but this is no bad thing.

An alternative is adding some sort of optional group field to the action, used to structure the run-jobs page on the jobs server, eg with foldable groups of actions, and the option to run the entire group. But I assume that the first option is easier.

[ghickman]

Adding functionality like a group to the action stanzas is a larger task which affects both job-server and job-runner, so probably best discussed in a call at some point to try and capture how it might work.

Adding some of globbing filter/search to the page is definitely something we could do with any of the various JS fuzzy search libraries out there (we're already using List.js on the home page for this).

For the implementor: the only problem I forsee here is how the library of choice handles the underlying DOM elements since the browser still needs to submit a valid form in the context of Django's form handling on the backend.

[sebbacon]

Alternative idea: how about we change the form so it's submitted with a checklist and giving a "select all / select none" option?

On grouping: feels like this would best be done in project.yaml as a new syntax element e.g. action aliases that can map to groups. Might not end up being that much more work that doing globbing on the client side - not because it's easy, but because I bet the client side might be harder than we think!

[ghickman]

@sebbacon – we already have two of those! The action buttons are checkboxes under the hood. We don't have a select all per se, but there's "run all" which has slightly different semantics IIRC.

What would you expect a "select none" button would add to the UX?

[sebbacon]

My hypothesis is that turning them all into checkboxes makes it considerably easier to submit multiple actions than the status quo (i.e. pressing loads of buttons). i.e. it avoids this:

you have to click run for each individual action, which can take a little while (> 1 minute) and is also error prone if you're clicking through very quickly.

The "select none" is just a useful reset pattern for when you realise you've clicked the wrong things and start again.

[wjchulme]

Select all / none would be most useful if you wanted to run >90% of actions at a time. In my case, I tend to want to run around 10-20% of actions (25-50 actions), so it wouldn't be very useful. But definitely a nice to have in other cases.

[sebbacon]

Tickboxes still better than run buttons though? Or not really?

[wjchulme]

You can select / unselect the run buttons. So they are essentially already tickboxes. You submit the selected actions by clicking submit!