search

KratosMultiphysics / Kratos

Kratos Multiphysics (A.K.A Kratos) is a framework for building parallel multi-disciplinary simulation software. Modularity, extensibility and HPC are the main objectives. Kratos has BSD license and is written in C++ with extensive Python interface.
https://kratosmultiphysics.github.io/Kratos/
Other
1.02k stars 244 forks source link

[Question] Run only specific jobs in the CI? #10332

Open matekelemen opened 2 years ago

matekelemen commented 2 years ago

I'm wondering whether it's possible to restructure our jobs in the CI such that I can control which jobs get executed in what order. In particular, it'd be fantastic if I could only run windows first, to make sure my PR works on windows, and only continue with the rest of the jobs if windows succeeds. Any ideas @roigcarlo ?

This would benefit us all, as I'd hog up less resources in the CI if I have a hunch which job my PR might break.

To clarify, merging a PR would still require all necessary jobs to pass; this would only influence what order the jobs are run in (the default could remain "all at once").

philbucher commented 2 years ago

it is technically possible to have dependencies among jobs, but I am not in favor of it as it leads to even more holding up of CI jobs

Instead we could add a custom workflow that can be triggered manually with the branch name and specific configuration

roigcarlo commented 2 years ago

Tend to agree with @philbucher. In order to do that we would need to specify dependencies among executions (like windows-core -> windows_full -> whatever). If you are interested, there are specific keywords in place by default to control the execution of ALL workflows (see github doc).

I sometimes use these when I know the commit I make will fail, they even work if placed in the hidden section of the commit. Other than that I see it difficult.

matekelemen commented 2 years ago

If you are interested, there are specific keywords in place by default to control the execution of ALL workflows

That's very handy (though not for this problem).

Manually triggered jobs could work. How about adding some of them (inactive by default, not required for merging a PR) with notoriously whimsy behaviour (windows, CentOS, unity)?