3 Commits

Include renames

Author	SHA1	Message	Date
lyuksovannyy	1ef4e61334	Fall back to the runner token when the org secret is absent ... pluginBase failed with "RELEASE_TOKEN is not set" while chatSummaries published fine, from the same organisation secret. An organisation secret is only exposed to a repository that has Actions enabled, so it can be empty in one repo and present in another. Try RELEASE_TOKEN first, then the runner-provided GITEA_TOKEN, which can publish releases in its own repository, and report which one was used. When none is set, name every variable that was tried and point at the repository Actions setting rather than failing with a bare message. The publish step also reports whether the organisation secret arrived, printing only its length, so the fallback is visible in the job log.	2026-09-13 00:20:58 +02:00
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