Make optional builds re-runnable on CI

[ryar9534]

Refactors the CI workflows such that the checks for labels ci: ready to be merged and ci: run integrated tests occur within the corresponding Github Actions jobs, which means that these can be re-run if labels are added after an update to the PR branch, for example.

Resolves #3001

[ryar9534]

I think this would do what we want as of now. However, for a PR the job get_current_labels will always fail. This is so that one may change the tags and execute the label-dependent integrated test and CUDA jobs by simply re-running failed jobs. I am not sure if there is a more clever way which avoids this, but at least I think the get_current_labels job should pass on a push to Develop.

[ryar9534]

Randy also had an interesting suggestion to give build_and_test an input so it can query the labels as a first step, then decide to continue to run. This could get rid of these extra jobs which just read labels and also remove this issue that if you remove a label it is not currently detected. Im going to take a look at that.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 53.21%. Comparing base (b92d789) to head (3933839).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #3094   +/-   ##
========================================
  Coverage    53.21%   53.21%           
========================================
  Files          989      989           
  Lines        83604    83604           
========================================
  Hits         44494    44494           
  Misses       39110    39110           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[ryar9534]

Did you perform enough testing?

I think it seems to be working

[TotoGaz]

I think it seems to be working

Champagne 🍾

Can you update the description of the PR with what you've been doing and then we're good to merge I think. @CusiniM Did you find anything related to making some jobs conditional based on manual (or not) triggers? I'm not sure GHA provides a lot of flexibility in that regard.

[CusiniM]

I think it seems to be working

Champagne 🍾

Can you update the description of the PR with what you've been doing and then we're good to merge I think. @CusiniM Did you find anything related to making some jobs conditional based on manual (or not) triggers? I'm not sure GHA provides a lot of flexibility in that regard.

yes, there is something called workflow_dispatch that might do what we want.

https://stackoverflow.com/questions/58877569/how-to-trigger-a-step-manually-with-github-actions

it's unclear to me whether this can only apply to a subset of the jobs and not to the entire workflow.

https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/

[ryar9534]

yes, there is something called workflow_dispatch that might do what we want.

Yeah we already do have that in the workflow,

it's unclear to me whether this can only apply to a subset of the jobs and not to the entire workflow.

but this was also my question. It seems like you'd have to pass in inputs to tell it to only do a subset of the jobs.