People are still on the older snap names, so a release that publishes only wekan leaves them on a stale package. Two things stood in the way, both in the snap-variants job.

It gated EVERYTHING on WEKAN_REPO_TOKEN being able to push to wekan/<variant>. Building and publishing a snap needs SNAP_AUTH and nothing else; keeping the variant GitHub repositories in step with wekan/wekan is a separate, optional thing. Because the two were tied together, a token without push rights meant no variant snaps at all — which is why v10.48 and v10.49 published none. The guard answers two questions now: one decides the build and the publish, the other decides only whether the repository is updated, and every “cannot push” warning ends with “The snap is still built and published”.

The variant tree is also no longer taken from a clone of the variant repository: it is copied from the release tag the job checked out, with the snap name and title written into BOTH snapcraft.yaml and snapcraft-core26.yaml — renaming only the first left the core26 file saying name: wekan. So the snap is built from what was just released, whatever state the variant repository is in.

Both variants build on amd64 and arm64 now, the two native runners the default snap uses, and publish to stable, candidate, beta and edge like the default snap: base: core24 with grade: stable, which is what those channels accept. A last check before the upload refuses a build whose file name does not start with the variant’s snap name — publishing a wekan_*.snap from there would overwrite the default snap in the store.

SNAP_AUTH has to carry the ACL for all three names, which is one snapcraft export-login --snaps wekan,wekan-ondra,wekan-gantt-gpl.

snapcraft.yaml is what the variant job builds; snapcraft-core26.yaml is the same snap on the next base. The sync step renamed only the first, so the core26 file in wekan-ondra and wekan-gantt-gpl kept saying name: wekan — and a core26 build from either repository would have published itself as the DEFAULT WeKan snap. Both files are renamed now, and a guard pins it.

It also ignores /wekan-ondra/ and /wekan-gantt-gpl/, which is where those two repositories are cloned when they are synced by hand from this working copy.

wekanteam/wekan-gantt-gpl and wekanteam/wekan-ondra are the same WeKan as wekanteam/wekan — the variant repositories are identical to wekan/wekan apart from the snap name — so nothing is rebuilt: a new workflow, “Publish variant Docker image (manual)”, points the variant tag at the multi-arch manifest the release already built and verified. Same digests, all five architectures, seconds instead of a half-hour emulated build, and no way for the variant image to claim a release it was not built from. releases/docker-publish-variant.sh does the same thing from a terminal.

It is workflow_dispatch only, on purpose: the release publishes wekanteam/wekan every time, and the variant images are published when the maintainer decides to. The credential is checked and logged in with before anything is pushed, and both the source manifest and the pushed tag are asked which architectures they carry.

v10.50 built the amd64 snap, uploaded it, and died on

Publishing snap "wekan_10.50_amd64.snap"...
Unsquashing snap file 'wekan_10.50_amd64.snap'.
Credentials could not be parsed. Expected valid Ubuntu One credentials.

and the job then printed “SNAP_AUTH did not work: the Snap Store refused the upload”. The store refused nothing — snapcraft could not READ the secret. The commonest way that happens is storing what snapcraft export-login PRINTED instead of the file it WROTE.

The secrets check now rejects what is unambiguously not a credential — under 100 characters, or carrying snapcraft’s own “Exported login” banner — in one line at the TOP of the job instead of after a full build on every architecture. The message after a failed upload no longer claims to know which failure it was: it names both, and how to tell them apart from the snapcraft line above it (“could not be parsed” is an unreadable secret, 401/403 is a valid one without the ACL for that snap name). And every re-export command in the workflow now names all three snaps, since one release publishes wekan, wekan-ondra and wekan-gantt-gpl.

releases/ holds about ninety scripts and FOUR of them were reachable from a menu — the test run, the database conformance run, run-everything and the CHANGELOG hash repair. Everything else existed only for whoever remembered the file name: the bundle builds per architecture, the whole snap flow, the Transifex scripts, the Sandstorm packaging, the tag and release helpers, the Docker image publishing, the VM helpers.

They are one list now, in eight groups — Release, Snap, Bundles, Docker images, Sandstorm, Translations, Git and repo, Server and VM. Pick a group, pick a script; one that needs a version, a language code, a branch or a file is ASKED for it and gets it passed through. build.bat offers the same entries in the same order through Git Bash, and says so by name when bash is not on PATH.

Nine scripts are deliberately absent, each with its reason recorded in the guard: the four the Tests and Setup menus already run, the helper the others source, the three that run inside the built snap, bundle or Docker image, and the superseded ones.

releases/ufw-enable.sh was one line — sudo ufw enable — and so were eleven others. Nothing called them except the menus, so they are the command itself now, in the same menu entries. Checked one at a time before deleting: docker-build-deps.sh looked like the same kind of thing and is still here, because releases/docker-build.sh runs it. The ten that are systemd, ufw, snap or multipass are Linux-only and build.bat does not offer them, because Windows cannot do them at all.

And both scripts run any entry without the menu, which is what makes them usable from a script or a cron entry:

./build.sh --list                     every name, with what it does
./build.sh release-snap 10.50
./build.sh push-translation ja
./build.sh ufw-enable                 what releases/ufw-enable.sh used to do

The name is the file name without its extension, or — for the twelve commands — the name of the wrapper file it replaced, so anything anybody had in a script keeps working. An unknown name says so and exits 2. Guards keep the two menus offering the same entries in the same order, and pin that every example in the help text is a real command name.

The header of snapcraft.yaml still described an older policy — “the workflow publishes it to the candidate + beta + edge channels; the stable channel is published MANUALLY later” — which has not been true for a while: every snap job publishes stable, candidate, beta and edge.

Both snapcraft headers now say the actual reason for the base. core24 is a released base, so the snap can be grade: stable and the stable and candidate channels accept it. core26 is still experimental: build-base: devel forces grade: devel, and a devel-grade snap is refused by stable and candidate, so it could only reach beta and edge. That is why the release builds core24 and keeps the core26 file for testing only. A guard pins all of it, including that snapcraft-core26.yaml is only ever renamed by the variant sync, never built.