argoyle e07c8412f0 fix(release): fetch file SHAs from base branch, not next-release
After POST /branches reports 201 and GET /branches/next-release reports
200, the /contents/{path}?ref=next-release endpoint can still 500 or
404 transiently while Gitea finishes indexing the new branch. That
caused fetch_sha to return empty for files that actually existed on
base, so write_file fell back to POST (create) and got HTTP 422
"repository file already exists" five times before giving up.

Query base branch for the blob SHA instead. Base is stable, and Gitea
content writes are content-addressed by blob SHA, so a SHA fetched from
main works for PUT on next-release (next-release was just forked from
main, so the blob is identical). Treat 404 as "file absent" and retry
other non-200 responses up to 5 times.
2026-05-13 13:09:02 +02:00

Shared Workflows

Reusable Gitea Actions workflows for Unbound Software repositories.

Available Workflows

Release.yml

Automated release workflow using git-cliff for changelog generation.

Usage:

name: Release

on:
  push:
    branches: [main]

jobs:
  release:
    uses: unboundsoftware/shared-workflows/.gitea/workflows/Release.yml@main

Inputs:

  • tag_only (boolean, default: false): Set to true to only create tags without full releases

Requirements:

This workflow reads the release token from /runner-secrets/release-token, which is automatically available on Unbound's Gitea runners. No repository secrets need to be configured.

How it works:

  1. On each push to the default branch, generates a changelog using git-cliff
  2. Creates or updates a next-release branch with the updated CHANGELOG.md and .version file
  3. Opens or updates a PR titled "chore(release): prepare for vX.Y.Z"
  4. When the .version file exists (after merging the release PR), creates a Gitea release with the changelog
S
Description
No description provided
Readme 102 KiB
Languages
Markdown 100%