ci: release patch changes and list every patch

.github/workflows/upstream-release.yml

@@ -2,6 +2,8 @@ name: Upstream release
 
 # Watches Modrinth for a new Modrinth App release, rebuilds Modrinth Enhanced
 # on top of it, and publishes a release of our own if everything still works.
+# When the patches changed since our last release of that upstream version,
+# it publishes them again as a revision: v1.2.3-2, v1.2.3-3, ...
 #
 # Nothing is published unless the patches applied, the checks passed and all
 # three platforms built, so an upstream change that breaks a patch stops here
@@ -16,10 +18,6 @@ on:
         description: Build this upstream tag instead of the newest one
         type: string
         required: false
-      revision:
-        description: Release the current patches again on the upstream release in upstream.txt, as v1.2.3-2, v1.2.3-3, ...
-        type: boolean
-        default: false
 
 permissions:
   contents: write
@@ -42,41 +40,42 @@ jobs:
       - name: Decide what to release
         id: check
         env:
-          GH_TOKEN: ${{ github.token }}
           REQUESTED: ${{ inputs.upstream-ref }}
-          REVISION: ${{ inputs.revision }}
         run: |
           set -euo pipefail
           current="$(tr -d '[:space:]' < upstream.txt)"
-          if [ "$REVISION" = true ]; then
+          upstream="${REQUESTED:-$(scripts/latest-upstream.sh)}"
-            # A revision rebuilds what we already ship, not whatever is newest.
-            upstream="${REQUESTED:-$current}"
-          else
-            upstream="${REQUESTED:-$(scripts/latest-upstream.sh)}"
-          fi
           echo "upstream=$upstream" >> "$GITHUB_OUTPUT"
           echo "Upstream release: $upstream (we are on $current)"
 
-          if ! gh release view "$upstream" >/dev/null 2>&1; then
+          # Our newest release of it, as "<revision> <tag>". The plain tag is
-            tag="$upstream"
+          # revision 1.
-          elif [ "$REVISION" = true ]; then
+          last="$(
-            # The first release of an upstream version is its plain tag, which
+            git ls-remote --tags --refs origin "$upstream" "$upstream-*" |
-            # counts as revision 1.
+              sed 's#.*refs/tags/##' |
-            last="$(
+              awk -v up="$upstream" '
-              git ls-remote --tags --refs origin "$upstream-*" |
+                $0 == up { print 1, $0; next }
-                sed 's#.*refs/tags/##' |
+                index($0, up "-") == 1 {
-                awk -v prefix="$upstream-" 'index($0, prefix) == 1 {
+                  n = substr($0, length(up) + 2)
-                  n = substr($0, length(prefix) + 1)
+                  if (n ~ /^[0-9]+$/) print n, $0
-                  if (n ~ /^[0-9]+$/) print n
                 }' |
-                sort -n |
+              sort -n |
-                tail -1
+              tail -1
-            )"
+          )"
-            tag="$upstream-$(( ${last:-1} + 1 ))"
+
+          if [ -z "$last" ]; then
+            tag="$upstream"
           else
-            echo "$upstream has already been released; nothing to do."
+            revision="${last%% *}"
-            echo "proceed=false" >> "$GITHUB_OUTPUT"
+            last_tag="${last#* }"
-            exit 0
+            git fetch --no-tags --depth=1 origin "refs/tags/$last_tag:refs/tags/$last_tag"
+            # Only what goes into the build counts, not docs or CI.
+            if git diff --quiet "$last_tag" HEAD -- patches scripts; then
+              echo "$last_tag already ships the current patches; nothing to do."
+              echo "proceed=false" >> "$GITHUB_OUTPUT"
+              exit 0
+            fi
+            tag="$upstream-$((revision + 1))"
           fi
 
           echo "tag=$tag" >> "$GITHUB_OUTPUT"
@@ -127,15 +126,24 @@ jobs:
         run: |
           set -euo pipefail
           ls -la artifacts
+          # Every patch by its subject, so the list never falls behind.
+          patches="$(
+            for patch in patches/0*.patch; do
+              awk '/^Subject: /{
+                s = $0
+                sub(/^Subject: (\[PATCH[^]]*\] )?/, "", s)
+                while ((getline line) > 0 && line ~ /^ /) s = s line
+                print "- " s
+                exit
+              }' "$patch"
+            done
+          )"
           notes="$(cat <<EOF
           Modrinth Enhanced $TAG, built from [Modrinth App $UPSTREAM](https://github.com/modrinth/code/releases/tag/$UPSTREAM).
 
           Same app as upstream, with the patches in \`patches/\` applied:
 
-          - no advertising,
+          $patches
-          - no telemetry, crash reporting or survey embeds,
-          - offline accounts for singleplayer and offline-mode servers,
-          - renamed and re-iconed as Modrinth Enhanced.
 
           It keeps using the same data directory as the official Modrinth App,
           so instances, settings and accounts carry over. Do not run both at
@@ -144,7 +152,10 @@ jobs:
           See the upstream release notes for everything else that changed.
           EOF
           )"
+          # The tag goes on the commit that was built, not on whatever main is
+          # by now, so the next run compares against the patches it shipped.
           gh release create "$TAG" \
+            --target "$(git rev-parse HEAD)" \
             --title "Modrinth Enhanced $TAG" \
             --notes "$notes" \
             artifacts/*

README.md

@@ -204,10 +204,10 @@ scripts/prepare.sh
   published a newer release than `upstream.txt`, it rebases the patches onto it, rebuilds and — only if every
   platform built and every check passed — commits the bump, tags it with the upstream version and
   publishes a release with the installers.
-- **Revisions** of the same upstream release are published by running Upstream release by hand
+- **Revisions** come from the same run: when `patches/` or `scripts/` changed since the last
-  with `revision` ticked. It builds the upstream release in `upstream.txt` again with the current
+  release of that upstream version, it is released again as `v0.21.2-2`, `v0.21.2-3` and so on.
-  patches and publishes it as `v0.21.2-2`, `v0.21.2-3` and so on. The app and installers still
+  The app and installers still carry the upstream version: RPM and the Windows installers do not
-  carry the upstream version: RPM and the Windows installers do not accept a suffix in it.
+  accept a suffix in it.
 
 `scripts/check.sh` is what makes the automation trustworthy. A patch can apply cleanly and still
 stop doing its job if upstream moves the thing it was holding down, so the checks assert the