Closed tyeth closed 1 year ago
Hello @tyeth
The action retries the failed commands or actions. If you add a wretry.action
in some command, then the all matrix jobs will have the step with action. The action skips successful steps and retries only failed.
As I understand, you want to have some kind of orchestrator for matrix of jobs. The wretry.action
cannot orchestrate jobs/steps, it only wraps a command/step.
You can add a step with wretry.action
and check results. For example, create alternative workflow in experimental branch and check the runs.
Thanks for the clarification, and yes you understood me correctly 🙂
I will have to play more, or maybe find a job level compatible GitHub action for retries
Having thought about it I could just set the builds step to retry twice, but that seems gratuitously wasteful in the case of actual failures due to bad code.
I wonder if there is a way to distinguish a failure between a timeout as opposed to a clear build failure (the builds basically say building in the output then never return anything else). I should turn on debug logging and see what's returned.
The wretry.action
can handle the cases where the the command/action returns non zero exit code. It is not safe to provide user defined error handler.
Maybe, you can setup error handler in your step. If it will be a step with command, then you need no wretry.action
, you can retry it from command line.
Hi, there's this action that's basically a build matrix, and I wonder if it is possible to check if one of the jobs has a pass, i.e. the code at least builds on one platform/environment, as the check condition for retrying any failures in the same or other jobs. This is the file: https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/blob/main/.github/workflows/build-clang-doxy.yml There's basically a large chance of one or more spurious failures.