|
| 1 | +name: consumer-verify |
| 2 | + |
| 3 | +# Does what this repo PUBLISHED actually work when a user gets it? |
| 4 | +# |
| 5 | +# Every other workflow here reports on itself. ci.yml proves the code builds and its tests pass. |
| 6 | +# release.yml's verify-assets proves the upload step believed it succeeded, asserted from inside the |
| 7 | +# run that did the uploading. None of that is evidence about the artifact a user downloads, and the |
| 8 | +# gap is not theoretical: webrequest-hook v1.0.4 published as a zero-asset phantom, and |
| 9 | +# headroom-hook's published bundle could not boot the gateway because its shipped config used shapes |
| 10 | +# busbar 1.5.3 retired. Both were green everywhere. Nothing anywhere noticed. |
| 11 | +# |
| 12 | +# The logic lives in ONE place for the whole fleet, exactly like plugin-ci.yml, so a fix reaches |
| 13 | +# every plugin at once instead of being copied ten times and drifting nine. |
| 14 | +# |
| 15 | +# WHY BOTH TRIGGERS. release: published catches a broken publish immediately, and it fires whether or |
| 16 | +# not the release workflow itself finished happy - which matters, because a verifier that only runs |
| 17 | +# when everything already worked is not a verifier. The daily schedule catches ROT: an artifact that |
| 18 | +# published fine can stop working later when nothing about it changed (a bundle that no longer boots |
| 19 | +# against a newer engine, an asset deleted by hand, a release un-flagged as latest). A |
| 20 | +# publish-time-only check structurally cannot see that class. |
| 21 | +on: |
| 22 | + release: |
| 23 | + types: [published] |
| 24 | + schedule: |
| 25 | + - cron: "3 10 * * *" |
| 26 | + workflow_dispatch: |
| 27 | + inputs: |
| 28 | + version: |
| 29 | + description: "Version to verify (e.g. 1.0.4). Empty means the newest published release." |
| 30 | + required: false |
| 31 | + type: string |
| 32 | + |
| 33 | +permissions: |
| 34 | + contents: read |
| 35 | + issues: write |
| 36 | + actions: read |
| 37 | + |
| 38 | +jobs: |
| 39 | + consumer: |
| 40 | + # Pinned to an IMMUTABLE ref, never @dev: the verdict must not change because the shared |
| 41 | + # workflow moved. This SHA is the tip of plugin-consumer-verify.yml as of busbar v1.5.4 |
| 42 | + # (the file is not carried by the v1.5.4 tag itself, so the commit SHA is the pin). |
| 43 | + uses: GetBusbar/busbar/.github/workflows/plugin-consumer-verify.yml@ceb7104a4cdb06f3bba20b68c6c1a76fac2215f7 |
| 44 | + with: |
| 45 | + version: ${{ inputs.version || '' }} |
| 46 | + # Read off the PUBLISHED artifact, not guessed from the crate name: the filename prefix and the |
| 47 | + # manifest name genuinely differ across this fleet (the store repos drop the trailing -plugin |
| 48 | + # that the auth repos keep, and store-valkey publishes as busbar-store-redis). |
| 49 | + # THE VALKEY IDENTITY, NOT THE RETIRED REDIS ONE. release.yml packs |
| 50 | + # `--name busbar-store-valkey-plugin --alias valkey` and uploads |
| 51 | + # busbar-store-valkey-<ver>-<target>.tar.gz, which is the stem busbar itself resolves |
| 52 | + # (crates/busbar/src/config/mod.rs STORE_MODULE_VALKEY_ASSET_STEM). These three inputs were |
| 53 | + # still naming the `redis` identity that v1.0.4 retired, so the consumer check was fetching |
| 54 | + # an asset that has not existed since -- a gate aimed at a name nothing publishes cannot |
| 55 | + # report on the artifact users actually get. |
| 56 | + asset_prefix: busbar-store-valkey |
| 57 | + plugin_name: busbar-store-valkey-plugin |
| 58 | + plugin_alias: valkey |
| 59 | + plugin_kind: store |
| 60 | + # EMPTY, and correct: this repo publishes exactly one kind of artifact, a signed |
| 61 | + # busbar-store-*.tar.gz per target (see release.yml's `plugin-dist/*.tar.gz` upload) -- no |
| 62 | + # container bundle anywhere in this repo's workflows. `bundle_image: ""` makes the shared |
| 63 | + # workflow declare the runnable-bundle boot check NOT-APPLICABLE rather than silently skip it. |
| 64 | + bundle_image: "" |
| 65 | + bundle_env: "" |
| 66 | + secrets: inherit |
0 commit comments