fix(fastlane): add changelog 36.txt and auto-generate changelogs in CI

[TimeToBuildBob]

Problem

The Play Store upload for v0.14.0dev20260722 (and presumably all future releases) failed with:

Could not find changelog for '36' and language 'en-US' at path ./fastlane/metadata/android/en-US/changelogs/36.txt

The versionCode (36) is assigned dynamically by fastlane update_version querying the Play Store, so the changelog filename is not known at commit time.

Fix

1. Add 36.txt — unblocks the current v0.14.0 release immediately.

2. Auto-generate changelogs in CI — for all future releases:

   • Add get-versionCode to release-fastlane's needs so VERSION_CODE is available.
   • Add a "Generate changelog" step before the fastlane supply run: if changelogs/${VERSION_CODE}.txt already exists, use it; otherwise, auto-generate from git log since the previous tag (skipping chore: commits).

This means hand-written changelogs (like 35.txt, 36.txt) are always honoured when present, and auto-generation is a safe fallback for releases where no file was committed.

Closes #189 (changelog item — the Foreground Service declaration form is a separate Play Console action for Erik).

[greptile-apps]

Greptile Summary

The PR moves version-code assignment into the release workflow and commits release metadata before triggering downstream builds.

• Generates a nonempty version-specific changelog, preserving an existing handwritten file when available.
• Commits the updated version name, version code, and changelog before creating and pushing the release tag.
• Makes downstream build and Play Store upload jobs consume the committed version code and metadata.
• Adds the handwritten English changelog for version code 36.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failures remain.

Important Files Changed

Filename	Overview
.github/workflows/release.yml	Moves version-code assignment and changelog generation into the release transaction so both are committed before tagging.
.github/workflows/build.yml	Reads the committed version code and makes the Play Store upload depend on that output, with full checkout history enabled.
fastlane/metadata/android/en-US/changelogs/36.txt	Adds the handwritten English Play Store release notes required for version code 36.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Manual release workflow] --> B[Update version name]
  B --> C[Query and update version code]
  C --> D{Versioned changelog exists?}
  D -->|Yes| E[Preserve handwritten changelog]
  D -->|No| F[Generate changelog from commits]
  F --> G{Generated content nonempty?}
  G -->|No| H[Write generic fallback]
  G -->|Yes| I[Use generated changelog]
  E --> J[Commit version and metadata]
  H --> J
  I --> J
  J --> K[Create and push release tag]
  K --> L[Build artifacts]
  L --> M[Fastlane Play Store upload]

Loading

_{Reviews (3): Last reviewed commit: "fix(ci): move versionCode bump and chang..." | Re-trigger Greptile}

[greptile-apps]

Shallow checkout defeats tag lookup

When a tagged release lacks a committed changelog, the default one-commit checkout leaves HEAD~1 unavailable, so this lookup produces an empty PREV_TAG and publishes - Initial release instead of the changes since the previous release.

[TimeToBuildBob]

Fixed in d8d9103: the release-fastlane checkout now uses fetch-depth: 0, so HEAD~1 and the previous release tag are available when the fallback runs.

[greptile-apps]

Empty filter aborts release

When the release range is empty or contains only chore: commits, grep -v selects no lines and exits with status 1, causing the changelog step to fail and preventing the subsequent Play Store upload.

[TimeToBuildBob]

Fixed in d8d9103: the filter is now non-fatal, and an empty/missing generated changelog gets a non-empty generic fallback before Fastlane runs.

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

CI-green and mergeable (Greptile 5/5) — waiting only on a maintainer click.

This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted.

[ErikBjare]

@TimeToBuildBob I wrote "Do the changelog auto-generation PR, should maybe happen in the release.yml workflow (which bumps version number and tags etc)" in #189 (comment) why didn't you?

Now you aren't persisting the generated changelog to git, which is why you were supposed to use the release.yml workflow which commits and tags)

[TimeToBuildBob]

Good catch — the reason I used build.yml is that versionCode is currently assigned dynamically: fastlane's update_version queries Play Console and sets the code at upload time, so it's not known in release.yml. That's why I generated the changelog there and skipped committing it.

The right fix is to also bump versionCode in mobile/build.gradle inside release.yml — read the current value, increment it, write fastlane/metadata/android/en-US/changelogs/{newVersionCode}.txt from git log, and commit all three changes together (versionName + versionCode + changelog). Then build.yml's fastlane run just uses whatever committed file is already there.

This makes versionCode git-tracked (no more Play-Console-as-source-of-truth for the number) and gives you the committed changelog. Happy to push that redesign to this branch — say the word and I'll update the PR today.

[TimeToBuildBob]

Done — pushed cb59e3b. The redesign:

release.yml now owns the full release commit:

1. Bumps versionName (as before)
2. Runs fastlane update_version (queries Play Console for the next versionCode, writes it to mobile/build.gradle)
3. Generates fastlane/metadata/android/en-US/changelogs/{versionCode}.txt from git log (or falls back to a hand-written file if one exists)
4. Commits all three together: versionName + versionCode + changelog file

build.yml get-versionCode is now trivial — just reads versionCode from the committed build.gradle. No Ruby, no fastlane, no Play Console API call in this job.

build.yml release-fastlane — "Generate changelog" step removed. The file is already in git.

Side benefit: versionCode is now git-tracked (committed before the tag), so F-Droid and any reproducible-build system see the right value without needing CI to patch it.

[TimeToBuildBob]

@greptileai review