exteraGramPlugins/chatSummaries
2
0 Fork 0
generated from exteraGramPlugins/pluginBase
Code Issues Pull Requests Actions Packages Projects Releases 5 Wiki Activity

Publish a build on every push to main
Publish plugin / publish (push) Successful in 4s
Details

Browse Source 
Trigger the release workflow on pushes to main, not just on v* tags, so
every push leaves a downloadable .plugin attached to the current version.

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.

Hand-pushed v* tags and manual runs are unaffected and still use the tag
verbatim.
This commit is contained in:
lyuksovannyy committed 2026-09-12 23:57:43 +02:00
1 parent 196da742de
commit aec9f9376f
3 files changed
+56 -21
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

README.md
+16 -12
View File
@@ -100,21 +100,25 @@ standard `ANDROID_SERIAL` env var for device selection.
## Publishing a release
`.gitea/workflows/release.yml` builds, verifies and publishes the `.plugin` to the repo's
Releases tab. `dist/` is gitignored, so the artifact is always built by CI rather than
committed.
Releases tab on every push to `main`. `dist/` is gitignored, so the artifact is always built
by CI rather than committed.
```bash
# tag a version and push it -> release named after the tag
git tag v1.0.1 && git push origin v1.0.1
```
The `version` field in `plugin.json` is the single source of truth:
The workflow also accepts a manual run (Actions → Publish plugin → Run workflow), which
derives the tag from `version` in `plugin.json`. Either way it runs `--check`, builds with
`--release`, and gates the upload on `verify_bundle.py`, so a bundle that fails verification
is never published.
| Push to `main` with… | Result |
| --- | --- |
| a new `version` | creates tag `v<version>` and a new release |
| the same `version` | rebuilds the existing release, replacing its attachment |
Re-running against an existing tag reuses that release and replaces the attachment instead of
piling up duplicates.
So every push leaves a downloadable build attached to the current version, and bumping
`version` is what cuts a new release. Pushing a `v*` tag by hand still works and uses that
tag verbatim, as does a manual run (Actions → Publish plugin → Run workflow).
Every path runs `--check`, builds with `--release`, and gates the upload on
`verify_bundle.py`, so a bundle that fails verification is never published. A rebuild
replaces the attachment rather than piling up duplicates, and refreshes the release notes to
name the commit it came from. The tag itself is never moved: it keeps pointing at the commit
that first introduced that version.
Authentication uses `secrets.API_TOKEN`, an organisation-level Actions secret holding a user
token with the `write:repository` scope (which covers releases). Set it once under