e07c8412f0a7342e9a21164983ccaabe38963439
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.
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 totrueto 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:
- On each push to the default branch, generates a changelog using git-cliff
- Creates or updates a
next-releasebranch with the updated CHANGELOG.md and .version file - Opens or updates a PR titled "chore(release): prepare for vX.Y.Z"
- When the .version file exists (after merging the release PR), creates a Gitea release with the changelog
Description
Languages
Markdown
100%