Add semantic releasing pipeline #1

New issue

Closed

opened 2026-07-22 00:41:06 +02:00 by ben · 1 comment

ben commented

2026-07-22 00:41:06 +02:00

Owner

Add a semantic releasing action, with changelog, version, triggered android build, forgejo release, commit tag and in-build version number.

cloudbot commented

2026-07-22 10:14:48 +02:00

Collaborator

Implementation plan

Using the runners now live in forgejo-runners (semantic-release on node:20-slim, android-builder on cimg/android:2024.01). Two decoupled workflows, chained by a git tag rather than a direct job dependency, so the version-bump commit doesn't need to fight CI-skip semantics.

1. Versioning source of truth

app/build.gradle.kts currently hardcodes versionCode = 1 / versionName = "1.0". Move these into a small properties file so semantic-release never has to parse Kotlin DSL:

version.properties (new, repo root)

versionName=1.0.0
versionCode=1000000

app/build.gradle.kts — read it in defaultConfig:

val versionProps = java.util.Properties().apply {
    load(rootProject.file("version.properties").inputStream())
}

defaultConfig {
    versionCode = versionProps.getProperty("versionCode").toInt()
    versionName = versionProps.getProperty("versionName")
    ...
}

versionCode must be a monotonically increasing integer, so it's derived from semver rather than copied as a string:

versionCode = major * 1_000_000 + minor * 1_000 + patch

(valid while minor/patch stay under 1000 — fine for this app's scale; revisit if that ever changes).

2. semantic-release config

package.json (new, repo root)

{
  "name": "frameify-release-tooling",
  "private": true,
  "devDependencies": {
    "semantic-release": "^24",
    "@semantic-release/changelog": "^6",
    "@semantic-release/exec": "^6",
    "@semantic-release/git": "^10",
    "@semantic-release/gitea": "^8"
  }
}

.releaserc.json

{
  "branches": ["main"],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    ["@semantic-release/exec", {
      "prepareCmd": "node scripts/bump-version.js ${nextRelease.version}"
    }],
    ["@semantic-release/git", {
      "assets": ["version.properties", "CHANGELOG.md"],
      "message": "chore(release): ${nextRelease.version} [skip ci]"
    }],
    ["@semantic-release/gitea", {
      "giteaUrl": "https://git.marquezkeenan.family"
    }]
  ]
}

@semantic-release/gitea talks to Forgejo's Gitea-compatible release API — it creates the git tag, the Forgejo release, and attaches the generated changelog as release notes. No GitHub plugin needed.

scripts/bump-version.js — small helper called by the exec plugin's prepareCmd, writes version.properties with the new semver plus the derived integer versionCode (using the formula above), so the bump logic lives in one reviewable place instead of an inline shell one-liner.

3. Workflow: release (`.forgejo/workflows/release.yml`)

name: release
on:
  push:
    branches: [main]

jobs:
  release:
    runs-on: semantic-release
    steps:
      - uses: https://data.forgejo.org/actions/checkout@v4
        with:
          fetch-depth: 0
      - run: npm ci
      - run: npx semantic-release
        env:
          GITEA_TOKEN: ${{ secrets.RELEASE_TOKEN }}

RELEASE_TOKEN is a repo (or org) Actions secret: a Forgejo API token scoped to write:repository on utilities/Frameify, used both to push the version-bump commit and to create the release/tag.

Since @semantic-release/git's commit message ends in [skip ci], and this workflow only triggers on branch pushes, the bump commit re-triggering release.yml is the main loop risk to watch in testing — Forgejo Actions' skip-ci handling should be verified with a --dry-run first (step 6).

4. Workflow: Android build + release asset (`.forgejo/workflows/android-build.yml`)

Triggered by the tag @semantic-release/gitea pushes, not by the release workflow directly — this keeps the two jobs decoupled and avoids needing push: branches and push: tags to interact:

name: android-release-build
on:
  push:
    tags: ['v*.*.*']

jobs:
  build-and-attach:
    runs-on: android-builder
    steps:
      - uses: https://data.forgejo.org/actions/checkout@v4
      - run: ./gradlew assembleRelease
      - name: Attach APK to the Forgejo release
        run: |
          TAG="${GITHUB_REF_NAME}"
          RELEASE_ID=$(curl -sf -H "Authorization: token ${{ secrets.RELEASE_TOKEN }}" \
            "https://git.marquezkeenan.family/api/v1/repos/utilities/Frameify/releases/tags/${TAG}" \
            | jq -r .id)
          APK=$(find app/build/outputs/apk/release -name '*.apk' | head -n1)
          curl -sf -X POST \
            -H "Authorization: token ${{ secrets.RELEASE_TOKEN }}" \
            -F "attachment=@${APK}" \
            "https://git.marquezkeenan.family/api/v1/repos/utilities/Frameify/releases/${RELEASE_ID}/assets"

Forgejo has no first-party "upload release asset" action, so this uses the REST API directly with curl/jq (both present in cimg/android).

5. Signing — explicitly deferred

assembleRelease currently has minification disabled and no signing config, so this produces an unsigned release APK. Deliberately out of scope for this issue: wiring a keystore via secrets is a separate concern with its own security review (keystore storage, signing-secret rotation). Tracked as a natural follow-up issue rather than folded in here.

6. Rollout steps

Add RELEASE_TOKEN as a repo Actions secret (Settings → Actions → Secrets).
Land version.properties, the build.gradle.kts change, package.json, .releaserc.json, scripts/bump-version.js on a feature branch.
Sanity-check locally: npx semantic-release --dry-run against that branch to confirm the version bump and changelog generation resolve correctly before wiring the workflow.
Add .forgejo/workflows/release.yml, merge to main, confirm a conventional-commit-worthy change triggers a real release + tag.
Add .forgejo/workflows/android-build.yml, confirm the resulting tag push builds and attaches the APK to the release created in step 4.
Watch the first couple of releases for the [skip ci] re-trigger risk noted in §3; add an explicit if: !contains(...) guard on the release job if Forgejo Actions doesn't honor it natively.

Deviations from the original ask (kept within "requirements survive")

Changelog + versioning + tagging + release creation: as requested, via semantic-release + @semantic-release/gitea.
Triggered Android build: as requested, via tag-push chaining instead of a direct workflow dependency — simpler to reason about and avoids Forgejo Actions' more limited workflow_run-equivalent support.
In-build version number updates: as requested, via version.properties read into build.gradle.kts, with versionCode derived deterministically from semver rather than hand-maintained.
APK signing: not in the original ask's explicit list, and intentionally left out here — flagged above as a follow-up rather than silently scoped in.

## Implementation plan Using the runners now live in `forgejo-runners` (`semantic-release` on `node:20-slim`, `android-builder` on `cimg/android:2024.01`). Two decoupled workflows, chained by a git tag rather than a direct job dependency, so the version-bump commit doesn't need to fight CI-skip semantics. ### 1. Versioning source of truth `app/build.gradle.kts` currently hardcodes `versionCode = 1` / `versionName = "1.0"`. Move these into a small properties file so semantic-release never has to parse Kotlin DSL: **`version.properties`** (new, repo root) ```properties versionName=1.0.0 versionCode=1000000 ``` **`app/build.gradle.kts`** — read it in `defaultConfig`: ```kotlin val versionProps = java.util.Properties().apply { load(rootProject.file("version.properties").inputStream()) } defaultConfig { versionCode = versionProps.getProperty("versionCode").toInt() versionName = versionProps.getProperty("versionName") ... } ``` `versionCode` must be a monotonically increasing integer, so it's derived from semver rather than copied as a string: ``` versionCode = major * 1_000_000 + minor * 1_000 + patch ``` (valid while minor/patch stay under 1000 — fine for this app's scale; revisit if that ever changes). ### 2. semantic-release config **`package.json`** (new, repo root) ```json { "name": "frameify-release-tooling", "private": true, "devDependencies": { "semantic-release": "^24", "@semantic-release/changelog": "^6", "@semantic-release/exec": "^6", "@semantic-release/git": "^10", "@semantic-release/gitea": "^8" } } ``` **`.releaserc.json`** ```json { "branches": ["main"], "plugins": [ "@semantic-release/commit-analyzer", "@semantic-release/release-notes-generator", "@semantic-release/changelog", ["@semantic-release/exec", { "prepareCmd": "node scripts/bump-version.js ${nextRelease.version}" }], ["@semantic-release/git", { "assets": ["version.properties", "CHANGELOG.md"], "message": "chore(release): ${nextRelease.version} [skip ci]" }], ["@semantic-release/gitea", { "giteaUrl": "https://git.marquezkeenan.family" }] ] } ``` `@semantic-release/gitea` talks to Forgejo's Gitea-compatible release API — it creates the git tag, the Forgejo release, and attaches the generated changelog as release notes. No GitHub plugin needed. **`scripts/bump-version.js`** — small helper called by the exec plugin's `prepareCmd`, writes `version.properties` with the new semver plus the derived integer `versionCode` (using the formula above), so the bump logic lives in one reviewable place instead of an inline shell one-liner. ### 3. Workflow: release (`.forgejo/workflows/release.yml`) ```yaml name: release on: push: branches: [main] jobs: release: runs-on: semantic-release steps: - uses: https://data.forgejo.org/actions/checkout@v4 with: fetch-depth: 0 - run: npm ci - run: npx semantic-release env: GITEA_TOKEN: ${{ secrets.RELEASE_TOKEN }} ``` `RELEASE_TOKEN` is a repo (or org) Actions secret: a Forgejo API token scoped to `write:repository` on `utilities/Frameify`, used both to push the version-bump commit and to create the release/tag. Since `@semantic-release/git`'s commit message ends in `[skip ci]`, and this workflow only triggers on branch pushes, the bump commit re-triggering `release.yml` is the main loop risk to watch in testing — Forgejo Actions' skip-ci handling should be verified with a `--dry-run` first (step 6). ### 4. Workflow: Android build + release asset (`.forgejo/workflows/android-build.yml`) Triggered by the **tag** `@semantic-release/gitea` pushes, not by the release workflow directly — this keeps the two jobs decoupled and avoids needing `push: branches` and `push: tags` to interact: ```yaml name: android-release-build on: push: tags: ['v*.*.*'] jobs: build-and-attach: runs-on: android-builder steps: - uses: https://data.forgejo.org/actions/checkout@v4 - run: ./gradlew assembleRelease - name: Attach APK to the Forgejo release run: | TAG="${GITHUB_REF_NAME}" RELEASE_ID=$(curl -sf -H "Authorization: token ${{ secrets.RELEASE_TOKEN }}" \ "https://git.marquezkeenan.family/api/v1/repos/utilities/Frameify/releases/tags/${TAG}" \ | jq -r .id) APK=$(find app/build/outputs/apk/release -name '*.apk' | head -n1) curl -sf -X POST \ -H "Authorization: token ${{ secrets.RELEASE_TOKEN }}" \ -F "attachment=@${APK}" \ "https://git.marquezkeenan.family/api/v1/repos/utilities/Frameify/releases/${RELEASE_ID}/assets" ``` Forgejo has no first-party "upload release asset" action, so this uses the REST API directly with `curl`/`jq` (both present in `cimg/android`). ### 5. Signing — explicitly deferred `assembleRelease` currently has minification disabled and no signing config, so this produces an **unsigned** release APK. Deliberately out of scope for this issue: wiring a keystore via secrets is a separate concern with its own security review (keystore storage, signing-secret rotation). Tracked as a natural follow-up issue rather than folded in here. ### 6. Rollout steps 1. Add `RELEASE_TOKEN` as a repo Actions secret (Settings → Actions → Secrets). 2. Land `version.properties`, the `build.gradle.kts` change, `package.json`, `.releaserc.json`, `scripts/bump-version.js` on a feature branch. 3. Sanity-check locally: `npx semantic-release --dry-run` against that branch to confirm the version bump and changelog generation resolve correctly before wiring the workflow. 4. Add `.forgejo/workflows/release.yml`, merge to `main`, confirm a conventional-commit-worthy change triggers a real release + tag. 5. Add `.forgejo/workflows/android-build.yml`, confirm the resulting tag push builds and attaches the APK to the release created in step 4. 6. Watch the first couple of releases for the `[skip ci]` re-trigger risk noted in §3; add an explicit `if: !contains(...)` guard on the `release` job if Forgejo Actions doesn't honor it natively. ### Deviations from the original ask (kept within "requirements survive") - **Changelog + versioning + tagging + release creation**: as requested, via semantic-release + `@semantic-release/gitea`. - **Triggered Android build**: as requested, via tag-push chaining instead of a direct workflow dependency — simpler to reason about and avoids Forgejo Actions' more limited `workflow_run`-equivalent support. - **In-build version number updates**: as requested, via `version.properties` read into `build.gradle.kts`, with `versionCode` derived deterministically from semver rather than hand-maintained. - **APK signing**: not in the original ask's explicit list, and intentionally left out here — flagged above as a follow-up rather than silently scoped in.

ben referenced this issue from a commit

2026-07-22 11:55:01 +02:00

Add semantic-release pipeline for versioning, changelog, and Android builds

cloudbot referenced this issue from a pull request that will close it,

2026-07-22 11:55:20 +02:00

Add semantic-release pipeline for versioning, changelog, and Android builds #2

ben closed this issue

2026-07-22 11:56:09 +02:00