From f474275d67d81799377ecfd3990f72839fb449f3 Mon Sep 17 00:00:00 2001 From: Lorem Dev Date: Tue, 8 Sep 2026 23:40:30 +0200 Subject: [PATCH] ci: take the release pipeline's action majors together download-artifact v7 -> v8 and tauri-action v0.6.2 -> v1.0.0, landed in one commit because they only ever run together and each one's Dependabot pull request went stale the moment the other merged. upload-artifact v6 -> v7 went ahead of them in #54. Neither is exercised by any pull request: release.yml runs on a tag and nothing else. What follows is the compatibility review that stands in for a check, per change. download-artifact v8 has the one real breaking change of the three. A digest mismatch is now an error rather than a warning, and the action no longer unzips a download whose Content-Type says it is not a zip. Both exist to support v7's direct (unzipped) uploads; this pipeline uploads ordinary zipped artifacts and downloads them in the same run, so the second is inert and the first is a straight gain -- a corrupted transfer now fails the release instead of publishing a damaged asset. tauri-action v1.0.0 carries eight breaking changes and none of them reach this workflow: - The step passes `projectPath` and `args`, nothing else. The renamed inputs (assetNamePattern, includeUpdaterJson) and the removed ones (includeRelease, includeDebug, updaterJsonKeepUniversal, project auto-init) are all unused. - No `tagName`, so this is the build-only path and the new "update the name and body of an existing release" behaviour cannot fire. The publish job still owns the release and its CHANGES.md notes. - `.app.tar.gz` and its signature now carry the version. Nothing here reads them: "Stage release assets" collects an explicit extension allowlist (dmg, deb, rpm, AppImage, msi, exe, msix, and the two skillkeeper-cli archives), which never included the updater bundles. - Tauri v1 and unstable v2 support is dropped; this app is on 2.11.5. Two v1 changes do land on this layout, and the workflow already satisfies both. Runner detection now fails loudly when a lockfile is present but its package manager is not installed -- corepack and `pnpm install --frozen-lockfile` both run before this step. And lockfile detection now walks up the tree, so with `projectPath: apps/desktop` and the only pnpm-lock.yaml at the repository root, v1 finds a lockfile where v0.6.2 found none. The worst case there is a redundant install. The real check is a release candidate: RC tags are cut from develop, publish as a pre-release, and releases/latest/download never resolves to a pre-release, so one cannot reach install.sh users. --- .github/workflows/release.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index d87ef14..00dec0f 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -266,7 +266,7 @@ jobs: } >> "$GITHUB_ENV" - name: Build the app (Tauri) - uses: tauri-apps/tauri-action@84b9d35b5fc46c1e45415bdb6144030364f7ebc5 # v0.6.2 + uses: tauri-apps/tauri-action@1deb371b0cd8bd54025b384f1cd735e725c4060f # v1.0.0 env: # macOS signing is injected via $GITHUB_ENV by "Configure Apple code # signing" above, and only when a certificate secret is set. The @@ -503,7 +503,7 @@ jobs: run: node scripts/release-notes.mjs - name: Download all artifacts - uses: actions/download-artifact@v7 + uses: actions/download-artifact@v8 with: path: dist-all