Skip to content

consumer-verify

consumer-verify #7

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: "43 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).
asset_prefix: busbar-hashicorp-vault
plugin_name: busbar-hashicorp-vault
plugin_alias: vault
plugin_kind: secret
# EMPTY, and correct: this repo publishes exactly one kind of artifact, a signed
# busbar-*.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