Minor tweaks on #208

.github/assets/release-body.md

@@ -29,7 +29,7 @@ Install both files from the same release. Mixing an Interlinearizer zip with a d
 the application is the usual cause of a blank Interlinearizer window.
 
 Step-by-step instructions, first steps once it is open, and troubleshooting are in
-[INSTALL.md](https://github.com/sillsdev/interlinearizer-extension/blob/main/INSTALL.md).
+[INSTALL.md](https://github.com/sillsdev/interlinearizer-extension/blob/v<version>/INSTALL.md).
 
 Please report problems at
 [github.com/sillsdev/interlinearizer-extension/issues](https://github.com/sillsdev/interlinearizer-extension/issues).

.github/workflows/publish.yml

@@ -117,9 +117,16 @@ jobs:
             echo 'Release body has no `interlinearizer_<version>.zip` placeholder to fill.'
             exit 1
           fi
+          if ! grep -q '/blob/v<version>/' .github/assets/release-body.md; then
+            echo 'Release body has no `/blob/v<version>/` placeholder to fill; its doc links would not be pinned to this release.'
+            exit 1
+          fi
           # Substitute into a copy outside the repo: `release-body.md` is tracked, and the
-          # `Bump repo versions` step below fails on a dirty working tree.
-          sed "s|interlinearizer_<version>\.zip|interlinearizer_${VERSION}.zip|g" \
+          # `Bump repo versions` step below fails on a dirty working tree. `bodyFile` below is
+          # therefore absolute where `artifacts` is not.
+          # Pinning the INSTALL.md link to this tag keeps old releases on the docs they shipped with.
+          sed -e "s|interlinearizer_<version>\.zip|interlinearizer_${VERSION}.zip|g" \
+            -e "s|/blob/v<version>/|/blob/v${VERSION}/|g" \
             .github/assets/release-body.md > "${RUNNER_TEMP}/release-body.md"
           if [ -n "${STUDIO_VERSION}" ]; then
             if ! grep -q '<Studio version>' "${RUNNER_TEMP}/release-body.md"; then

.github/workflows/verify-release.yml

@@ -28,6 +28,7 @@ jobs:
         env:
           BODY: ${{ github.event.release.body }}
           ASSET_NAMES: ${{ toJSON(github.event.release.assets.*.name) }}
+          RELEASE_TAG: ${{ github.event.release.tag_name }}
         run: |
           failed=0
 
@@ -43,11 +44,23 @@ jobs:
             failed=1
           fi
 
-          # Held in a variable rather than piped into `grep`: under `pipefail`, `grep -q` exiting on
-          # its first match can leave `jq` killed by SIGPIPE, failing the pipeline on a match.
+          # Requiring the tag catches a body copied from a previous release, whose docs link
+          # resolves and looks right while serving another version's instructions.
+          if ! grep -qF "/blob/${RELEASE_TAG}/INSTALL.md" <<< "${BODY}"; then
+            echo "::error::The release body's INSTALL.md link must point at /blob/${RELEASE_TAG}/INSTALL.md so these instructions stay with this release."
+            failed=1
+          fi
+
+          # Match the exact Studio zip file name the install steps give.
+          # `|| true` else a no-match `grep` would abort the step under `set -e`.
+          studio_zip="$(grep -oE 'Paratext\.10\.Studio\.Setup\.[^[:space:]`]+-Windows\.zip' <<< "${BODY}" | sed -n '1p' || true)"
+          # Held in a variable, not piped: `grep -q` quitting early would SIGPIPE `jq` under `pipefail`.
           names="$(jq -r '.[]' <<< "${ASSET_NAMES}")"
-          if ! grep -qE '^Paratext\.10\.Studio\.Setup\..+-Windows\.zip$' <<< "${names}"; then
-            echo '::error::No `Paratext.10.Studio.Setup.<version>-Windows.zip` asset is attached. The install steps tell testers to download one, and the workflow that builds the release does not attach it.'
+          if [ -z "${studio_zip}" ]; then
+            echo '::error::The release body names no Studio zip for testers to download in step 1.'
+            failed=1
+          elif ! grep -qxF "${studio_zip}" <<< "${names}"; then
+            echo "::error::The Studio zip the release body names is not attached: ${studio_zip}"
             echo "Attached assets:"
             echo "${names}"
             failed=1

INSTALL.md

@@ -20,7 +20,7 @@ elsewhere — and it is the build that release is meant to be used with.
    [Interlinearizer releases page](https://github.com/sillsdev/interlinearizer-extension/releases)
    and find the newest release.
 2. From its **Assets** list, download
-   `Paratext.10.Studio.Setup.<version>-Windows.zip` (around 240 MB).
+   `Paratext.10.Studio.Setup.<Studio version>-Windows.zip` (around 240 MB).
 3. Extract the zip and run the `Paratext 10 Studio Setup` installer inside it.
 
 Start Paratext 10 Studio once to confirm it runs, then close it again. That first run creates the

README.md

@@ -219,7 +219,7 @@ These steps will walk you through releasing a version on GitHub and bumping the
 2. Manually dispatch the Publish workflow in GitHub Actions targeting the branch you want to release from. This workflow creates a new pre-release for the version you intend to release and creates a new `bump-versions-<next_version>` branch to bump the version after the release so future changes apply to a new in-progress version instead of to the already released version. This workflow has the following inputs:
 
 - `version`: Enter the version you intend to publish (e.g. 0.2.0). This is simply for verification to make sure you release the code that you intend to release. It is compared to the version in the code, and the workflow will fail if they do not match.
-- `studioVersion`: Enter the version of the Paratext 10 Studio build you are going to attach to this release (e.g. 0.5.0). The workflow substitutes it into the release body's install steps, so it has to be the version of the zip you actually attach in step 3. Leave blank if you don't know it yet, and the body keeps a `<Studio version>` placeholder for you to edit on the draft.
+- `studioVersion`: Enter the version of the Paratext 10 Studio build you are going to attach to this release (e.g. 0.5.0). The workflow substitutes it into the release body's install steps, so it has to be the version of the zip you actually attach. Leave blank if you don't know it yet, and the body keeps a `<Studio version>` placeholder for you to edit on the draft.
 - `newVersionAfterPublishing`: Enter the version you want to bump to after releasing (e.g. 0.3.0-alpha.0). Future changes will apply to this new version instead of to the version that was already released. Leave blank if you don't want to bump.
 - `bumpRef`: Enter the Git ref you want to create the bump versions branch from, e.g. `main`. Leave blank if you want to use the branch selected for the workflow run. For example, if you release from a stable branch named `release-prep`, you may want to bump the version on `main` so future development work happens on the new version, then you can rebase `release-prep` onto `main` when you are ready to start preparing the next stable release.
 
@@ -233,8 +233,9 @@ These steps will walk you through releasing a version on GitHub and bumping the
   ```bash
   npm run package
   # Create a new pre-release in GitHub on tag `v<version>`
-  # Copy `.github/assets/release-body.md` into the release body, filling in its version
-  #   placeholders by hand — nothing substitutes them on this path
+  # Copy `.github/assets/release-body.md` into the release body and fill in its placeholders by
+  #   hand — the extension zip name, the INSTALL.md link tag, and `<Studio version>`; nothing
+  #   substitutes them on this path
   # Press the "Generate release notes" button in the release creation page to generate a changelog
   # Attach contents of `release` folder to the release
   ```
@@ -256,9 +257,9 @@ These steps will walk you through releasing a version on GitHub and bumping the
 
     </details>
 
-3. Attach the Paratext 10 Studio build to the new draft release. The workflow attaches only the extension zip, so the application build has to be uploaded by hand — attach `Paratext.10.Studio.Setup.<version>-Windows.zip`. If you left `studioVersion` blank in step 2, also replace `<Studio version>` in the release body's install steps with the version of the zip you attached; the extension zip's own version is always substituted by the workflow. The workflow run's job summary records the exact `paranext-core` revision the extension was built against, which is the revision the Studio build should come from.
+3. Attach the Paratext 10 Studio build to the new draft release. The workflow attaches only the extension zip, so the application build has to be uploaded by hand — attach `Paratext.10.Studio.Setup.<Studio version>-Windows.zip`. Studio builds are published on the [`paratext-10-studio` releases page](https://github.com/paranext/paratext-10-studio/releases), a private repo — that link 404s unless your GitHub account has been granted access. If you left `studioVersion` blank in step 2, also replace `<Studio version>` in the release body's install steps with the version of the zip you attached; the extension zip's own version is always substituted by the workflow. The body has to name the zip you actually attached. The workflow run's job summary records the exact `paranext-core` revision the extension was built against, which is the revision the Studio build should come from.
 
-4. Install both zips and confirm the Interlinearizer tab renders, then adjust the draft release's body and other metadata as desired and publish the release. Until it is published it stays a draft, which is visible only to people with write access to this repo — publishing is what makes the zips downloadable by testers. Publishing also runs the Verify Release workflow, which fails if the body still has an unfilled `<Studio version>` or `interlinearizer_<version>.zip` placeholder, or if no Studio zip is attached; all of these are fixable on the published release, and editing it runs the check again.
+4. Install both zips and confirm the Interlinearizer tab renders, then adjust the draft release's body and other metadata as desired and publish the release. Until it is published it stays a draft, which is visible only to people with write access to this repo — publishing is what makes the zips downloadable by testers. Publishing also runs the Verify Release workflow, which fails if the body still has an unfilled `<Studio version>` or `interlinearizer_<version>.zip` placeholder, if its INSTALL.md link does not point at this release's tag, or if the Studio zip the body names is not among the attached assets; all of these are fixable on the published release, and editing it runs the check again.
 
 5. Open a PR and merge the newly created `bump-versions-<next_version>` branch.
 

cspell.json

@@ -49,6 +49,7 @@
     "paranext",
     "paratext",
     "pdpf",
+    "pipefail",
     "plusplus",
     "punct",
     "rebaseline",
@@ -62,6 +63,7 @@
     "scriptio",
     "scrollers",
     "shadcn",
+    "SIGPIPE",
     "sillsdev",
     "struc",
     "Stylesheet",