Make the release pipeline able to release

[thorstenalpers]

Three commits, each one a thing that stopped a release run after it had already done the expensive work. Started as the signing-password check and grew as each run got one step further.

1 · Find out whether the key can sign before building anything with it

The check from #3 only proves a key is present. Two runs failed at the bundler, six minutes in, for two different reasons:

said	meant
Missing comment in secret key	no key at all
Wrong password for that key	key set, password not

Signing a throwaway file right after npm ci settles both halves in a second. The signature is public and the key is read from the environment, not the command line, so nothing reaches a log.

2 · Let a manual run be a rehearsal instead of a failure

The next run got all the way to the last step: ⚠️ GitHub Releases requires a tag. A release belongs to a tag; started by hand there is none.

A run without a publish decision now attaches the installer, its signature and latest.json to itself and says plainly that it published nothing — which is what the manual runs were being used for anyway.

3 · Release when the version changes, not when someone remembers to tag

This is the part you asked for. Bumping the number is the whole ceremony:

npm version patch

Merge that, and the push to main builds, signs, creates the tag at that commit and publishes. A push whose version is already released stops in under a minute on a Linux runner, before anything is compiled — so ordinary merges cost almost nothing and never fail.

It also fixes something an automatic release would have turned into a lie: the version was written in four places and read from a fifth that was a string literal in two views. package.json holds it, tauri.conf.json points at it, and the interface reads it through __APP_VERSION__. Verified by bumping to 0.2.7, rebuilding, and watching the Info page follow.

🤖 Generated with Claude Code

[thorstenalpers]

Extended with the last failure from the same run: ⚠️ GitHub Releases requires a tag.

A release belongs to a tag; started by hand there is none, so the publish step refused — after the build, the signing and everything else had already succeeded. The third consecutive time this pipeline spent six minutes to report something it could have known at the start.

A run without a tag is now a rehearsal: it builds, signs and checks, attaches the installer, its signature and latest.json to the run as an artifact, and says plainly that it published nothing. latest.json takes its version from the tag when there is one and from tauri.conf.json when there is not — the old line would have written main into it.