Reset reusable channel publish to the last known-good release flow from b83c0f5 and keep build_platform_artifacts gating for source-only dispatch compatibility.
When release and target_commitish are already valid, treat temporary git ref 404 responses as a warning so release jobs continue instead of failing on API propagation lag.
Let createRelease own tag creation with target_commitish and remove preflight tag-ref waits to reduce tag visibility races that lead to untagged release behavior.
Use GitHub REST create/update via actions/github-script with target_commitish and release id from API responses to avoid tag lookup races in the gh CLI path.
Create and update releases through explicit API payloads, include target_commitish, and verify tag binding through release id to avoid transient tag-endpoint inconsistencies.
Use gh release create --verify-tag and remove target_commitish from release payload
now that tags are created upfront. This avoids server-side untagged release fallback
while preserving deterministic tag-to-release publication.
Stop depending on tag lookup right after publish. Resolve release by tag with a
name fallback, then patch/create by id using the same payload and force a final
id-based patch to heal untagged placeholders before downstream upload steps.
Replace github-script release creation with gh release create/edit plus explicit
release-id resolution and patching. This avoids inconsistent REST createRelease
untagged behavior and keeps publication pinned to app-v tags.
* fix(release): rebind untagged draft releases to expected app-v tag
After create/update, fetch release by id and force tag_name/target_commitish when
GitHub returns an unexpected tag (including untagged placeholders). This self-heals
release metadata before downstream upload steps consume release_id.
* fix(release): remove tauri-action release publishing side effects
Build macOS/Windows bundles with tauri CLI and upload artifacts explicitly via
gh release upload to the expected app-v tag. This prevents tauri-action from
creating untagged releases while keeping release assets deterministic.
* fix(release): wait for tag ref visibility before release API calls
Before create/update release, poll GitHub REST git.getRef(tags/app-v...) until the
new tag is visible. This avoids release API timing gaps where tag exists in git
but release endpoints still return inconsistent not-found/untagged behavior.
After create/update, fetch release by id and force tag_name/target_commitish when
GitHub returns an unexpected tag (including untagged placeholders). This self-heals
release metadata before downstream upload steps consume release_id.
* fix(release): create missing app-v tag before release verification
Ensure reusable publish creates and pushes the expected app-v tag when absent,
then validates it points to source_ref. This prevents release records with tag_name
but no git refs/tags object, which previously broke Source code archives.
* fix(release): pin tauri publish to tagged release metadata
Pass tagName/releaseName/releaseDraft/prerelease to tauri-action in addition to
releaseId, so asset upload fallback remains bound to the expected app-v release
instead of creating untagged releases.
* chore(ci): align workflow action versions for release flow
Update github-script usage to v9 across release-related workflows and keep
the current tauri-action release binding changes in the same branch for testing.
* fix(release): harden tagged release resolution for source-only promote
Canonicalize release_id via getReleaseByTag after create/update and fail fast on
invalid tag/commit inputs to avoid untagged release binding. Also propagate
source-only marker through promote push events so push-triggered channel runs
skip platform artifacts and verify-nix consistently.
* fix(release): avoid tag lookup hard-fail during release creation
Remove immediate getReleaseByTag canonicalization after create/update because
GitHub can return 404 for tag-based release lookup while the release id is valid.
Keep release_id flow and downstream release-id validation to prevent regressions.
* fix(release): create missing app-v tag before release verification
Ensure reusable publish creates and pushes the expected app-v tag when absent,
then validates it points to source_ref. This prevents release records with tag_name
but no git refs/tags object, which previously broke Source code archives.
* fix(release): pin tauri publish to tagged release metadata
Pass tagName/releaseName/releaseDraft/prerelease to tauri-action in addition to
releaseId, so asset upload fallback remains bound to the expected app-v release
instead of creating untagged releases.
* chore(ci): align workflow action versions for release flow
Update github-script usage to v9 across release-related workflows and keep
the current tauri-action release binding changes in the same branch for testing.
* fix(release): harden tagged release resolution for source-only promote
Canonicalize release_id via getReleaseByTag after create/update and fail fast on
invalid tag/commit inputs to avoid untagged release binding. Also propagate
source-only marker through promote push events so push-triggered channel runs
skip platform artifacts and verify-nix consistently.
* fix(release): create missing app-v tag before release verification
Ensure reusable publish creates and pushes the expected app-v tag when absent,
then validates it points to source_ref. This prevents release records with tag_name
but no git refs/tags object, which previously broke Source code archives.
* fix(release): pin tauri publish to tagged release metadata
Pass tagName/releaseName/releaseDraft/prerelease to tauri-action in addition to
releaseId, so asset upload fallback remains bound to the expected app-v release
instead of creating untagged releases.
* chore(ci): align workflow action versions for release flow
Update github-script usage to v9 across release-related workflows and keep
the current tauri-action release binding changes in the same branch for testing.
* fix(release): create missing app-v tag before release verification
Ensure reusable publish creates and pushes the expected app-v tag when absent,
then validates it points to source_ref. This prevents release records with tag_name
but no git refs/tags object, which previously broke Source code archives.
* fix(release): pin tauri publish to tagged release metadata
Pass tagName/releaseName/releaseDraft/prerelease to tauri-action in addition to
releaseId, so asset upload fallback remains bound to the expected app-v release
instead of creating untagged releases.
Ensure reusable publish creates and pushes the expected app-v tag when absent,
then validates it points to source_ref. This prevents release records with tag_name
but no git refs/tags object, which previously broke Source code archives.
GitHub ref APIs can briefly return 404 right after create/update release.
Retry getRef(tags/...) before failing binding verification to avoid false
negatives that interrupt next/release channel publishing.
* fix(release): prevent untagged fallback from tauri publish
Set explicit github-script output for release_id and validate it before build jobs.
This prevents tauri-action from creating untagged releases when release id wiring
breaks and keeps assets attached to the intended app-v tag release.
* fix(release): add source-only promote mode and harden release binding
Add a source_only dispatch option to promote workflows and propagate it into
channel publish so maintainers can skip platform builds and verify-nix when needed.
Also validate release/tag/commit binding to prevent untagged fallback and ensure
source archives stay aligned with the intended app-v tag.
When an existing app-v tag points to a different commit than source_ref,
re-point it to the checked out source commit and continue publishing.
This preserves Source code archive correctness without blocking artifact release.
Ensure GitHub release tags are created from the checked out channel ref and fail
early if an existing tag points to a different commit. This keeps Source code
archives aligned with built artifacts and prevents mixed-release snapshots.
* ci(release): sync Cargo/tauri versions after npm version on promote
Keep bundle artifact names aligned with package.json by updating
src-tauri/Cargo.toml and tauri.conf.json when promoting channel branches.
Made-with: Cursor
* ci(release): sync Cargo/tauri in post-release dev bump PR
Run the same package.json→Tauri sync after bumping main to the next -dev
version so local builds match auto-generated PR contents.
workflow_dispatch previously used github.ref_name for source_ref, so
running Next Channel from branch `next` loaded stale reusable workflows
and could recreate the invalid `app-v` tag. Pin source_ref to the
channel branch; document running manual workflows from `main` for
latest publish YAML.
An empty VERSION produced the invalid GitHub tag "app-v" and broke
update-manifest downloads (release tag mismatch).
Validate semver prefix, write package version via heredoc to GITHUB_OUTPUT,
and refuse to compute tag app-v.
Made-with: Cursor
GitHub does not fire push workflows for commits pushed with the default
actions token. Chain Next/Release channel workflows from the matching
promote workflow_run on success.
Made-with: Cursor
* ci(release): gate promote-main on explicit main checks
Add an always-on ci-main workflow that produces a stable check name, and validate that check via check runs (not branch protection APIs). Wire promote-main-to-next to require ci-main / ci-ok and document the required check in the release SOP.
* ci(release): accept ci-ok or UI-style name in main promote gate
GitHub check run names for normal workflows are often the job name only;
keep optional match for the UI-style workflow/job label. Drop unused
statuses:read permission.
Made-with: Cursor
Exclude check runs and status contexts from the current workflow run in the validation fallback path so the promote gate does not fail on its own in-progress job when branch protection contexts are unavailable.
Fix the main-branch promotion gate to evaluate required status contexts from branch protection instead of all check runs, preventing self-blocking while the validator job is still in progress.
* ci(release): split channel pipelines and automate version transitions
Introduce dedicated next/release orchestration workflows backed by a reusable publish pipeline with RC/final package version updates and post-release main dev bump PRs. Add a strict release process SOP with RC freeze, hotfix override, and mandatory backport rules.
* ci(release): gate main-to-next promotion on green CI
Add a dedicated workflow that validates main branch checks/statuses and block the promote-main-to-next flow unless main is green. Update the release SOP to reflect the enforced pre-promotion validation.
* ci(release): fix channel promotion edge cases and policy gaps
Switch channel promotions to reset-based snapshots with force-with-lease pushes, stop auto-merging channel nix-refresh PRs, and guard main dev bump against version downgrades. Add RC changelog fallback, require AUR release updates in SOP, and extend npmDepsHash sync to main/next/release pushes.
* docs(release): clarify backport and nix refresh survivability rules
Require RC fix backports to reach main before the next main-to-next promotion, and document that channel-local nix refresh PRs are advisory unless equivalent changes are merged into main.
Add a GitHub Actions workflow that recomputes prefetch-npm-deps from
package-lock.json and updates nix/upstream-sources.json so Nix builds stay
aligned without manual hash edits.
Reverts #271, #292, #293, #294, #295, #296.
The flatpak CI pipeline itself works end-to-end, but the installed bundle
surfaced three separate manifest issues during smoke-test on Wayland+NVIDIA:
1. GDK_BACKEND is not set, so without an X11 display in the sandbox GTK
aborts with "Failed to initialize GTK".
2. libayatana-appindicator3 is not bundled in the GNOME 47 runtime, so
libappindicator-sys panics the main thread.
3. The release binary is compiled via \`cargo build --release\` rather than
\`cargo tauri build\`, so the \`custom-protocol\` feature is off and
Tauri falls back to devUrl — the window opens but shows
"Could not connect to localhost".
Rolling back so main stays on 1.43.0. A follow-up on the original PR
tracks the fixes needed before re-attempting.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The flatpak-github-actions container runs as root, but the actions/checkout
workspace is owned by the runner user. Without a global safe.directory entry
git aborts later steps (notably gh release upload, which probes git
internally) with "fatal: detected dubious ownership".
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The \`app-v*\` tag referenced by the manifest only becomes a real git ref
when the Draft release is published, so the previous \`git ls-remote\`
lookup during CI always returned empty and flatpak-builder failed with
"unknown revision app-v<version>". Use \`github.ref_name\` and
\`github.sha\` directly — both exist when the workflow fires.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds full Flatpak support for Psysonic including:
- Flatpak manifest (org.gnome.Platform 47 + rust-stable + node20)
with proper finish-args for MPRIS, Discord RPC, PulseAudio, Wayland/X11
- AppStream metainfo XML and .desktop entry
- In-app updater disabled at build time via VITE_PSYSONIC_FLATPAK=1
- CI job \`build-flatpak\` in release.yml: generates cargo/npm offline
sources, patches manifest with release tag/commit, builds bundle via
flatpak/flatpak-github-actions@v6, uploads .flatpak to GitHub release
- Release docs updated in CLAUDE.md (Flatpak bump and Flathub mirror flow)
GitHub rejects \`gh pr merge --auto\` when the PR has no required
status checks and no required reviews — the error is "Pull request
is in clean status (enablePullRequestAutoMerge)". Our ruleset
requires neither, so auto-merge has nothing to wait for. Switch
to a direct merge instead. If we ever add required checks, --auto
can come back.
Validated against the v1.43.0 test release: PR #226 was created
by the workflow but the auto-merge call failed; merging it
manually with the same flags minus --auto succeeded immediately.
Co-authored-by: Psychotoxical <dev@psysonic.app>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After enabling branch protection rulesets on main, the existing
direct push from the verify-nix job (`git push origin HEAD:main`)
is rejected. Push the refresh commit to a per-release branch
(`chore/nix-lock-refresh-v<VERSION>`) instead, open a PR, and
enable auto-merge so the change lands as soon as repo conditions
allow (0 required reviews + 0 required status checks → instant).
Adds `pull-requests: write` to job permissions so GITHUB_TOKEN can
create + merge the PR.
Co-authored-by: Psychotoxical <dev@psysonic.app>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
cachix-action installs a post-build-hook via NIX_USER_CONF_FILES, but
the Determinate Nix daemon reads system nix.conf and never fires the
hook — only two early prep paths ever reached the cache, never the
actual psysonic output. Add an explicit closure push after the build;
Cachix dedupes, so redundancy is cheap.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The macOS updater pipeline is stable now, so restore full-platform
builds + the Nix cache refresh on every release. These were disabled
temporarily during v1.34.14–v1.34.23 iteration to cut turnaround time.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
tauri-action always re-packs Psysonic.app into .app.tar.gz after tauri
CLI finishes (regardless of includeUpdaterJson), so the .sig that tauri
CLI produces never matches the final tarball — and the sig tauri-action
was supposed to produce silently goes missing ("Signature not found for
the updater JSON. Skipping upload...").
Rather than fight the repack, sign the repacked tarball ourselves in a
follow-up step using `tauri signer sign` against the same private key
(from TAURI_SIGNING_PRIVATE_KEY), then upload the fresh .sig. tauri-
action still handles the DMG + .app.tar.gz upload; we only add the .sig.
Also removes an unused `std::rc::Rc` import in the vendored cpal patch.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Root cause: tauri-action runs a second "Packaging" pass after tauri CLI
finishes, which rewrites src-tauri/target/<target>/release/bundle/macos/
Psysonic.app.tar.gz with different bytes. The .sig produced by tauri CLI
no longer matches the new hash, so tauri-action silently deletes it —
leaving the directory with only .app and .app.tar.gz (no .sig for our
manifest generator to consume).
Fix: pass `includeUpdaterJson: false` to tauri-action so it skips the
repack + updater JSON upload entirely, then copy both the .app.tar.gz
and .app.tar.gz.sig produced by tauri CLI into the workspace root with
the expected asset names and `gh release upload` them.
Also disables build-linux and the Windows matrix entry during testing
to cut iteration time roughly in half.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Replace the glob find for the .sig file with an explicit target-based
path ($matrix → src-tauri/target/<target>-apple-darwin/release/bundle/
macos/Psysonic.app.tar.gz.sig) and dump directory listings so we can
see what tauri-action actually leaves behind if the path is wrong
- Skip verify-nix while we iterate fast on signing + updater (its auto-
commits of flake.lock / npmDepsHash cause rebase friction on every
release)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
tauri-action on macOS cross-target builds produces the .app.tar.gz.sig
locally but silently skips its upload ("Signature not found for the
updater JSON. Skipping upload..."), which caused generate-manifest to
abort on v1.34.15 because the .sig asset was absent.
New step after tauri-action locates the .sig under src-tauri/target/*/
release/bundle/macos/ and uploads it as Psysonic_aarch64.app.tar.gz.sig
or Psysonic_x64.app.tar.gz.sig — the exact filenames generate-update-
manifest.js expects.
Also bumps version to 1.34.16.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- tauri-plugin-updater wired into lib.rs with pubkey + GitHub Releases
endpoint in tauri.conf.json; updater:default capability granted
- AppUpdater.tsx: on macOS, the download button now invokes the updater
plugin (check + downloadAndInstall) which downloads the signed
.app.tar.gz, verifies the minisign signature against the bundled
pubkey, replaces /Applications/Psysonic.app, and relaunches. Windows
and Linux keep the existing "download DMG/EXE/AppImage via reqwest
then point to the folder" flow
- CI: pass TAURI_SIGNING_PRIVATE_KEY + _PASSWORD to tauri-action so the
.sig files are produced alongside the update bundles
- New generate-manifest job (after build-macos-windows) runs
scripts/generate-update-manifest.js which downloads the .sig files
from the release, assembles latest.json for darwin-aarch64 and
darwin-x86_64, and uploads it back as a release asset
Windows will be added to latest.json once the Certum cert is active.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Wire up Developer ID Application certificate + App Store Connect API Key
to tauri-action on the macOS runner. Decodes the base64-encoded .p8 into
a file before the build, exports APPLE_API_KEY_PATH via $GITHUB_ENV, and
forwards the remaining credentials through the env block. Windows runner
receives the vars but tauri ignores them off-platform.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Wires cachix/cachix-action@v15 into the verify-nix job. The action
watches the nix store for the duration of the workflow and uploads
new paths to the `psysonic` cache on cachix.org automatically.
Using Cachix-managed signing (no signing key on our side) — Cachix
signs server-side with the cache's built-in keypair. End users will
pick up the public key automatically via `cachix use psysonic`, so
no manual nix.conf configuration is required.
Consequence: after the next `v*` release, `nix profile install
github:Psychotoxical/psysonic` pulls a prebuilt binary from Cachix
instead of recompiling Rust + npm deps locally.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Supersedes PR #203's out-of-tree upstream-src layout now that the Nix
build lives in the canonical repo. The flake treats `self` as the
source of truth — nothing in flake.nix or psysonic.nix needs a manual
version bump per release.
flake.nix
- `inputs.upstream-src` dropped; `src = self` throughout
- Dev shell retains the full WebKitGTK / GStreamer / AppIndicator
closure needed for tauri:dev on NixOS (Linux x86_64 + aarch64)
nix/psysonic.nix
- Version read from package.json (upstreamMeta.version removed)
- `srcClean` filter excludes node_modules / dist / target / .git /
result / .flatpak-builder
- `cargoDeps = rustPlatform.importCargoLock` with empty
`outputHashes` — sufficient for our local `[patch.crates-io]`
path overrides (cpal-0.15.3, symphonia-format-isomp4)
- Wraps the installed binary with LD_LIBRARY_PATH + GST_PLUGIN_PATH
+ GIO_EXTRA_MODULES + GDK_BACKEND=x11 + WebKit disable flags
nix/upstream-sources.json
- Reduced to `{ npmDepsHash }`. Placeholder for the initial commit;
the verify-nix job rewrites it on every release from the actual
`prefetch-npm-deps` output.
.github/workflows/release.yml
- New `verify-nix` job gated on `create-release` (same as the
Tauri builds). Checks out `main`, installs Nix, recomputes
`npmDepsHash`, refreshes `flake.lock`, runs
`nix build .#psysonic --no-link` as the sanity check, then
commits lock + hash updates back to `main` when they changed.
- The old standalone `upstream-release-nix.yml` is intentionally
not ported; its scheduled re-poll of the upstream release is
redundant now that the source lives here.
Tarball publishing and Cachix upload remain explicitly out of scope —
those ship in a follow-up workflow tied to the cache setup.
cucadmuh
Frank Stellmacher
kilyabin
Frank Stellmacher
Psychotoxical