publish.yml's nightly run rebuilds and overwrites the latest tag automatically whenever a new
Godot stable drops. That's fine for routine version bumps, but this map's base-image change (off barichello/godot-ci, onto debian:bookworm-slim with a hand-rolled Godot/Blender/mingw-w64
install) is more invasive than a routine bump — a subtle breakage wouldn't surface until Project4x's next release run pulls latest and fails or misbehaves.
Does the nightly rollout need a dry-run/canary step (e.g. hold latest back for N successful
builds, or require a manual approval the first time) before this specific change goes live, or is
the validation done in Merge, publish, and validate the debian-slim image end-to-end
(#9) sufficient on its own?
## Question
`publish.yml`'s nightly run rebuilds and overwrites the `latest` tag automatically whenever a new
Godot stable drops. That's fine for routine version bumps, but this map's base-image change (off
`barichello/godot-ci`, onto `debian:bookworm-slim` with a hand-rolled Godot/Blender/mingw-w64
install) is more invasive than a routine bump — a subtle breakage wouldn't surface until
`Project4x`'s next release run pulls `latest` and fails or misbehaves.
Does the nightly rollout need a dry-run/canary step (e.g. hold `latest` back for N successful
builds, or require a manual approval the first time) before this specific change goes live, or is
the validation done in [Merge, publish, and validate the debian-slim image end-to-end
(#9)](https://git.arthurerlich.de/haylan/godot-ci/issues/9) sufficient on its own?
Part of [Smaller/faster godot-ci image (map)](https://git.arthurerlich.de/haylan/godot-ci/issues/2).
No canary/dry-run needed. This is a low-traffic internal repo with one consumer (Project4x); if ticket #9's end-to-end validation (real Linux export, real Windows export, real .blend import) passes, ship it on the next nightly like any other version bump — no extra rollout machinery.
## Answer
No canary/dry-run needed. This is a low-traffic internal repo with one consumer (Project4x); if [ticket #9](https://git.arthurerlich.de/haylan/godot-ci/issues/9)'s end-to-end validation (real Linux export, real Windows export, real .blend import) passes, ship it on the next nightly like any other version bump — no extra rollout machinery.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Question
publish.yml's nightly run rebuilds and overwrites thelatesttag automatically whenever a newGodot stable drops. That's fine for routine version bumps, but this map's base-image change (off
barichello/godot-ci, ontodebian:bookworm-slimwith a hand-rolled Godot/Blender/mingw-w64install) is more invasive than a routine bump — a subtle breakage wouldn't surface until
Project4x's next release run pullslatestand fails or misbehaves.Does the nightly rollout need a dry-run/canary step (e.g. hold
latestback for N successfulbuilds, or require a manual approval the first time) before this specific change goes live, or is
the validation done in Merge, publish, and validate the debian-slim image end-to-end
(#9) sufficient on its own?
Part of Smaller/faster godot-ci image (map).
Answer
No canary/dry-run needed. This is a low-traffic internal repo with one consumer (Project4x); if ticket #9's end-to-end validation (real Linux export, real Windows export, real .blend import) passes, ship it on the next nightly like any other version bump — no extra rollout machinery.