consumer-verify #9
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| name: consumer-verify | |
| # Does what this repo PUBLISHED actually work when a user gets it? | |
| # | |
| # Every other workflow here reports on itself. ci.yml proves the code builds and its tests pass. | |
| # release.yml's verify-assets proves the upload step believed it succeeded, asserted from inside the | |
| # run that did the uploading. None of that is evidence about the artifact a user downloads, and the | |
| # gap is not theoretical: webrequest-hook v1.0.4 published as a zero-asset phantom, and | |
| # headroom-hook's published bundle could not boot the gateway because its shipped config used shapes | |
| # busbar 1.5.3 retired. Both were green everywhere. Nothing anywhere noticed. | |
| # | |
| # The logic lives in ONE place for the whole fleet, exactly like plugin-ci.yml, so a fix reaches | |
| # every plugin at once instead of being copied ten times and drifting nine. | |
| # | |
| # WHY BOTH TRIGGERS. release: published catches a broken publish immediately, and it fires whether or | |
| # not the release workflow itself finished happy - which matters, because a verifier that only runs | |
| # when everything already worked is not a verifier. The daily schedule catches ROT: an artifact that | |
| # published fine can stop working later when nothing about it changed (a bundle that no longer boots | |
| # against a newer engine, an asset deleted by hand, a release un-flagged as latest). A | |
| # publish-time-only check structurally cannot see that class. | |
| on: | |
| release: | |
| types: [published] | |
| schedule: | |
| - cron: "3 10 * * *" | |
| workflow_dispatch: | |
| inputs: | |
| version: | |
| description: "Version to verify (e.g. 1.0.4). Empty means the newest published release." | |
| required: false | |
| type: string | |
| permissions: | |
| contents: read | |
| issues: write | |
| actions: read | |
| jobs: | |
| consumer: | |
| # Pinned to an IMMUTABLE ref, never @dev: the verdict must not change because the shared | |
| # workflow moved. This SHA is the tip of plugin-consumer-verify.yml as of busbar v1.5.4 | |
| # (the file is not carried by the v1.5.4 tag itself, so the commit SHA is the pin). | |
| uses: GetBusbar/busbar/.github/workflows/plugin-consumer-verify.yml@ceb7104a4cdb06f3bba20b68c6c1a76fac2215f7 | |
| with: | |
| version: ${{ inputs.version || '' }} | |
| # Read off the PUBLISHED artifact, not guessed from the crate name: the filename prefix and the | |
| # manifest name genuinely differ across this fleet (the store repos drop the trailing -plugin | |
| # that the auth repos keep, and store-valkey publishes as busbar-store-redis). | |
| # THE VALKEY IDENTITY, NOT THE RETIRED REDIS ONE. release.yml packs | |
| # `--name busbar-store-valkey-plugin --alias valkey` and uploads | |
| # busbar-store-valkey-<ver>-<target>.tar.gz, which is the stem busbar itself resolves | |
| # (crates/busbar/src/config/mod.rs STORE_MODULE_VALKEY_ASSET_STEM). These three inputs were | |
| # still naming the `redis` identity that v1.0.4 retired, so the consumer check was fetching | |
| # an asset that has not existed since -- a gate aimed at a name nothing publishes cannot | |
| # report on the artifact users actually get. | |
| asset_prefix: busbar-store-valkey | |
| plugin_name: busbar-store-valkey-plugin | |
| plugin_alias: valkey | |
| plugin_kind: store | |
| # EMPTY, and correct: this repo publishes exactly one kind of artifact, a signed | |
| # busbar-store-*.tar.gz per target (see release.yml's `plugin-dist/*.tar.gz` upload) -- no | |
| # container bundle anywhere in this repo's workflows. `bundle_image: ""` makes the shared | |
| # workflow declare the runnable-bundle boot check NOT-APPLICABLE rather than silently skip it. | |
| bundle_image: "" | |
| bundle_env: "" | |
| secrets: inherit |