Skip to content

ci(workflows): make the VM retry chains actually run after a boot flake - #3937

Open
metux wants to merge 1 commit into
masterfrom
wt/dfly-retry-fix
Open

metux wants to merge 1 commit into
masterfrom
wt/dfly-retry-fix

Conversation

@metux

@metux metux commented Oct 13, 2026

Copy link
Copy Markdown
Contributor

Problem

Die VM-Retry-Ketten (dragonflybsd, freebsd, netbsd) feuern nie, weil die
Retry-if:-Bedingungen auf der impliziten success()-Statusfunktion beruhen:

- name: run in X VM (attempt 1)
  id: x-1
  continue-on-error: true
  ...
- name: run in X VM (attempt 2)
  if: steps.x-1.outcome == 'failure'     # erbt implizit success()

Nach einem continue-on-error-Fehlschlag von Attempt 1 ist success() false → alle
späteren Steps (Stale-VM-Cleanup und Attempts 2/3) werden stillschweigend übersprungen.

Beobachtet auf xserver-build-dragonflybsd: Die VM bootet transient nicht hoch
(ssh: Could not resolve hostname dragonflybsd), der eine Versuch ist rot, und die Lane
erholt sich nie, weil die Retry-Kette nie ausgelöst wird.

Fix

Die Retry-if:-Bedingungen mit !cancelled() präfixieren — das ist true bei jedem
nicht-abgebrochenen Lauf, unabhängig vom früheren continue-on-error-Fehlschlag. Damit wird
ein transienter VM-Boot-/Image-Flake bis zu 3× wiederholt.

Angewendet auf die identischen Ketten von dragonflybsd, freebsd und netbsd (jeweils
Cleanup vor Retry + 3 Versuche). Ein erklärender Kommentar bei der DragonFly-Kette
dokumentiert die success()-Falle.

Kein Verhaltens-Change am Build selbst — nur die Retry-Auslösung.

The retry `if:` conditions (steps.<x>-1.outcome == 'failure') rely on the
implicit success() status function. After attempt 1 fails with
continue-on-error, success() is false, so every later step — the stale-VM
cleanup and attempts 2/3 — is silently skipped. Observed on
xserver-build-dragonflybsd: the VM fails to boot ("ssh: Could not resolve
hostname dragonflybsd"), the single attempt is red, and the lane never
recovers because the retry chain never fires.

Prefix the retry conditions with !cancelled() (true whenever the workflow
isn't cancelled, regardless of the earlier continue-on-error failure) so a
transient VM boot/image flake is retried up to 3x. Applied to the identical
dragonflybsd, freebsd and netbsd retry chains.

Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
@metux
metux force-pushed the wt/dfly-retry-fix branch from ac339fc to e46b1ce Compare October 19, 2026 11:07
@metux
metux force-pushed the master branch 5 times, most recently from eae2c21 to 483a172 Compare October 30, 2026 11:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant