2 Commits

Include renames

Author	SHA1	Message	Date
lyuksovannyy	965fb5a284	Read the release token from RELEASE_TOKEN ... The publish step set GITEA_TOKEN from the org-level API_TOKEN secret, but the Actions runner injects its own GITEA_TOKEN into every step and that value overrides a step-level env: entry of the same name. The org secret was silently ignored and the job failed. Pass the secret as RELEASE_TOKEN instead, which the runner does not reserve, and read that name in release.py. --token-env makes the source configurable, so the runner-provided GITEA_TOKEN can still be used deliberately by passing --token-env GITEA_TOKEN.	2026-09-13 00:10:07 +02:00
lyuksovannyy	cfa6dd9e1e	Add release workflow publishing builds to Gitea ... Build, verify and publish dist/<id>.plugin to the Releases tab on every push to main. Nothing is plugin-specific: the id and version are read from plugin.json, so the workflow keeps working once this template is renamed into a real plugin. The version in plugin.json decides what happens: a new version creates tag v<version> and a new release, while an unchanged version rebuilds the existing release and replaces its attachment. The tag is never moved, so it keeps pointing at the commit that first introduced that version, but the release notes are refreshed to name the commit the build came from. The upload is gated on verify_bundle.py, so a bundle that fails offline verification is never published. dist/ stays gitignored and the artifact is always built by CI rather than committed.	2026-09-13 00:04:32 +02:00