CI: allow workflow tasks to be skipped if not relevant for the changes - #7864
CI: allow workflow tasks to be skipped if not relevant for the changes#7864ninsbl wants to merge 2 commits into
Conversation
|
Please note that all workflows still run here, because changes to a workflow-file allways trigger it to run (always included). |
echoix
left a comment
There was a problem hiding this comment.
I'm scared that this will more than double our waiting times, especially when the queue is long. Imagine if we wait for 3 hours to start a job, and after 3 hours, what we get is a 10 second run that allows to queue the real workflow, that will now wait another 3 hours or so: it's at the back of the line.
It would be favoriting jobs from other repos in OSGeo org.
THanks for your feedback. Would a possible solution be to move the check in detect-relevant-changes.yml as tasks into the other workflows so they start, all execute the same but brief check and can skip heavy tasks if not needed? |
|
Look if instead of a reusable workflow (that is a job by itself), if it could be like an action. The pr is already using an action though. |
CI workflows have to run for all PRs because of branch protection. Sometimes, that consumes unnecessary much CI time.
Since we can not skip entire workflows, this PR adds a new filter-job, that checks if relevant files for the workflow got changed by a PR/commit. It is then used to skip the following job(s) within a workflow. That way, heavy CI jobs (like pytests) can be skipped if they do not add any value (e.g. if only docker files are changed) but the workfow itself still reports success.
This should save some valuable CI time and allow simple pure documentation changes to be merged faster.
When reviewing, please be extra critical with the list of files that causes workflow jobs to be skipped. Also, I am not 100% sure how this will affect CI runs that start after a PR is merged...
Written with the help of AI.