1c/E2E-TESTME finding+fix: inject bridge_drone_token as Drone bot MACHINE TOKEN (DRONE_USER_CREATE token:)
All checks were successful
continuous-integration/drone/push Build is passing

Clean-room finding caught by the e2e: DRONE_USER_CREATE had no token: => a fresh-DB rebuild's Drone
auto-generates a random bot token, so the committed (sops) bridge_drone_token gets 401 and the bridge
can't trigger builds. The original cc-ci only matched because its token was captured out-of-band. Now
the bot's machine token == bridge_drone_token deterministically on every rebuild. (Evolves the toplevel
again; re-establish byte-identical on cc-ci after the e2e + Adversary re-verifies C1.)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-27 19:27:00 +01:00
parent ee585ef6b4
commit c8bbd35f2a

View File

@ -39,7 +39,12 @@ let
}
set_env LETS_ENCRYPT_ENV ""
set_env EXTRA_DOMAINS ""
set_env DRONE_USER_CREATE "username:autonomic-bot,admin:true"
# Inject the bridge's Drone token as the bot's MACHINE TOKEN so it is reproducible on a fresh
# Drone DB. Without `token:`, Drone auto-generates a random token that the committed (sops)
# bridge_drone_token can't match on a clean-room rebuild the bridge gets 401 and can't trigger
# builds (the original only matched because its token was captured out-of-band post-hoc). Caught
# by the E2E-TESTME acceptance test. With `token:`, every rebuild's bot carries the sops token.
set_env DRONE_USER_CREATE "username:autonomic-bot,admin:true,token:$(cat /run/secrets/bridge_drone_token)"
set_env GITEA_DOMAIN "git.autonomic.zone"
set_env GITEA_CLIENT_ID "${giteaClientId}"
set_env RPC_SECRET_VERSION "v1"