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
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:
@ -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"
|
||||
|
||||
Reference in New Issue
Block a user