Open DeeDeeG opened 1 year ago
By the way, we have found a (rather hacky feeling) workaround for this... A task designed to execute as quickly as possible and mark the overall build as technically "failed", if we would have skipped all its tasks.
We would rather have a way that feels officially supported in Cirrus rather than a hack or workaround, ideally though. Thank you for considering.
silently_mark_skipped_or_no_scheduled_task_builds_as_failed_task:
skip_notifications: true
only_if: $CIRRUS_CRON == "" && $CIRRUS_TAG == ""
container:
image: alpine:latest
cpu: 1
clone_script: |
exit 0
mark_task_as_failed_script: |
exit 1
timeout_in: 6s
Description
It would be really nice, in my opinion, for builds with no tasks, or builds where all tasks are
SKIPPED
, for theCIRRUS_LAST_GREEN_CHANGE
not to be updated or changed by these builds. (That theCIRRUS_LAST_GREEN_CHANGE
would remain the same as before the build with only skipped tasks, or no tasks, had run.)This aids in the ability to filter most build types/build triggers to safeguard credits, and follow-up with a cron rule to actually build the repo every so often.
Context
only_if:
in.cirrus.yml
.skip:
in.cirrus.yml
.For example, our real-world use-case: we are using
only_if:
to skip PR and branch push builds, and instead only build our default branch every few days with cron builds. And we are usingskip:
based on checkingCIRRUS_LAST_GREEN_CHANGE
to skip if the current commit has already been built before. (We could do both viaonly_if:
, but the result seems to be the same, from some quick testing. I didn't test doing all the skipping logic inskip:
, but I expect no difference?) But the cron builds see the skipped branch push builds to our default branch as successful, in terms of the fact that they updateCIRRUS_LAST_GREEN_CHANGE
. So these cron builds are now skipping as well! We have effectively no builds ever, with our current setup.Basically I consider it (subjectively) a bug that
CIRRUS_LAST_GREEN_CHANGE
updates to the commit of these builds which have no tasks scheduled due toonly_if:
, or all tasks skipped due toskip:
.If there is any concern about breaking existing workflows, then perhaps the info should be presented in a new env var? Perhaps called:
CIRRUS_LAST_GREEN_CHANGE_WITH_TASKS
?Anything Else
Similar to previous issue I found, https://github.com/cirruslabs/cirrus-ci-docs/issues/891.
But unlike that issue, I'm referring to situations where the overall build is reporting as
COMPLETED
aka successful, but there were no tasks or all skipped tasks. Whereas I suppose https://github.com/cirruslabs/cirrus-ci-docs/issues/891 was just about if the entire build wasSKIPPED
.