Rename the reusable workflows to release.yml and update-release.yml,
add UPX compression for release binaries, and sync the standalone
update-release workflow with the active release pipeline fixes.
Update README, AGENTS, compliance notes, and changelog references to
match the new workflow names and usage patterns.
Use JSON parsing for release id extraction in publish action instead of
regex matching, preventing wrong id selection from nested fields.
Add a pre-upload release endpoint check to fail early with explicit
release URL diagnostics when the resolved id/path is invalid.
Teacup can wrap workflow outputs as %touch docker-compose.yml(string=...), which produced an
invalid releases/{id}/assets URL and a 404 in Upload release binaries.
Unwrap and validate release-id before building the API path.
Normalize %touch docker-compose.yml(string=...) wrapped token values in publish composite before
API calls. This prevents malformed Authorization headers under teacup.
Also only print 'Release Published' summary when the publish step succeeds,
and print a failure summary otherwise.
Replaces the workflow_call to do-release with directly inlined release
and validate jobs. All steps now appear flat in the Actions UI with full
individual step visibility instead of being collapsed under a setup job.
Tag resolution in the release job is simplified: the tag always comes
from needs.prepare.outputs.tag, removing the detect-tag guessing needed
for standalone dispatch.
do-release.yml is unchanged and remains available for manual dispatch.
Tag push events never fire on this Gitea 1.25.x instance (confirmed
across 159 workflow run history). The workflow_call path is reliable and
has worked consistently. Remove the temporary if-false guard.
Stop using GITHUB_TOKEN/GITEA_TOKEN fallbacks in prepare/do-release/publish mutation paths. Require explicit PAT wiring via secrets.RELEASE_PAT for commit/push/tag and release update operations so downstream workflows trigger reliably.
Handle Teacup workflow_call input forwarding gaps by using needs.prepare.outputs.tag as a fallback and normalizing %touch docker-compose.yml(string=...) wrappers before selecting the release tag.
When prepare-release tags HEAD with a new release version, do-release should
immediately detect that tag rather than finding the latest tag chronologically.
Changes:
- Modified detect-tag step to check if HEAD is exactly at a tag first
- Falls back to latest tag only if HEAD is not tagged
- Fixes issue where v1.0.2 was detected instead of v1.1.0 at HEAD
This ensures correct version detection in prepare-release → do-release workflow chain.
- Update prepare-release to call do-release via workflow_call after tag creation.
- Update README examples and release-flow docs to reflect direct invocation
instead of relying only on tag-push triggers.
- Remove token and cache-token from public action inputs
- Always use github.token internally for downloads/push
- Read fixed cache token from VOCIFERATE_CACHE_TOKEN env
- Add explicit 'Resolve cache token' step before prepare/tag in
prepare-release workflow and pass it via env
Add a new optional cache-token input to both published actions.
- Default cache key token is now action_repository + release_tag.
- Cache key uses this token plus runner architecture.
- prepare-release workflow passes github.sha as a fixed token.
This prevents cross-repository cache collisions when consumers pull
vociferate binaries produced by this repository.
Add two focused subdirectory composite actions:
- prepare/action.yml: downloads the vociferate binary, runs it to update
changelog and release-version, then commits, tags, and pushes — replacing
the boilerplate git steps consumers previously had to write inline.
- publish/action.yml: extracts the matching changelog section and creates or
updates the Gitea/GitHub release. Outputs release-id, tag, and version so
consumers can upload their own assets after it runs.
Simplify the vociferate workflows to use ./prepare and ./publish directly,
validating both actions in the self-release pipeline.
Update README to show the clean two-action usage pattern.
- Remove publish steps (release creation, binary build/upload) from the
Prepare Release workflow; it now stops after committing and pushing the
tag.
- Add Do Release workflow triggered on v*.*.* tag pushes; reads release
notes from the tagged changelog section, creates or updates the release,
builds linux/amd64 and linux/arm64 binaries, uploads assets, then
smoke-tests both binaries in a follow-on validate job.
- Remove the standalone Action Validation workflow; binary validation now
runs as a second job in Do Release after the release job succeeds, using
the exact tag and version just published.
- Update README to document the two-workflow release model and add split
prepare/publish usage examples for both the composite action and the
reusable workflows.
- Update changelog unreleased section to reflect the new pipeline split
and corrected artifact scope (linux/amd64 and linux/arm64 only).
