fix(build): fix snap release

[lunny]

Fix #37593
The stable version release of snap will read the main branch's snap file. So that we cannot remove the sqlite tags at the moment.

[wxiaoguang]

It can't be a right fix.

1. Why snap build can't read 1.26 branch?
2. If you do so, the build will break again if main branch changes in the future

---

Update: for the os.Getuid problem, not in this PR's scope: fix: "run as root" check #37622 , so I marked other comments as "resolved" to make the discussion more focused here.

[silverwind]

Suggestion to address the "will break again on main" concern without waiting for an infra fix: detect the checked-out source's needs in override-build and pick tags accordingly. models/db/driver_sqlite_modernc.go was added by #37562 and is a clean marker:

override-build: |
  set -x
  npm install -g pnpm
  # 1.26.x sources need explicit sqlite tags; 1.27+ defaults to modernc
  if [ -f models/db/driver_sqlite_modernc.go ]; then
    TAGS="bindata pam cert"
  else
    TAGS="bindata sqlite sqlite_unlock_notify pam cert"
  fi
  TAGS="\$TAGS" make build
  install -D gitea "\${SNAPCRAFT_PART_INSTALL}/gitea"
  cp -r options "\${SNAPCRAFT_PART_INSTALL}/"

Auto-adapts per tag, no follow-up needed when 1.26 is EOL'd.

The structurally correct fix is at the snap infra level — have the Store build read snapcraft.yaml from the release tag, not from main — but that's out of repo scope.

---

Comment written by Claude Opus 4.7

[wxiaoguang]

Suggestion to address the "will break again on main" concern without waiting for an infra fix: detect the checked-out source's needs in override-build and pick tags accordingly. models/db/driver_sqlite_modernc.go was added by #37562 and is a clean marker:

AI slop. It would only add one more dirty hack to the already buggy snap build steps. There are far more problems in the snap build than it looks, if you would spend some time to investigate. I have proposed some fixes, but I am just curious whether there are people able to maintain such legacy code correctly.

[silverwind]

For @techknowlogick / @lunny: The structural fix lives on Canonical's side. The Snap Store "Builds" tab only ever builds from the GitHub default branch — no per-branch or per-tag trigger (open feature requests for branch and tag since 2017) — so the snapcraft.io integration alone can't be configured to read snapcraft.yaml from a release tag.

The supported workaround is Launchpad snap recipes (one recipe per long-lived ref, each reads its own snapcraft.yaml):

1. Sign in to Launchpad with the Ubuntu One account that owns the gitea snap.
2. Import this repo via https://launchpad.net/+code-imports/+new (Launchpad auto-syncs every few hours).
3. For each ref to publish, open its page on Launchpad (+ref/main, +ref/release/v1.26, …) and click Create snap package:
   • Snap name: gitea
   • Auto build: yes
   • Store channels: e.g. latest/edge for main, 1.26/stable for release/v1.26
4. Disconnect the GitHub build integration on snapcraft.io so the two systems don't fight over channels.
5. Cleanup: override-pull's last_committed_tag / git checkout dance becomes unnecessary — each recipe is pinned to its ref, so the yaml on release/v1.26 can keep legacy sqlite tags and main's yaml can drop them.

Lighter alternative — snapcraft remote-build invoked from a release CI workflow that has already checked out the tag. Moves the problem into CI, no Launchpad-recipe admin needed.

Either of these makes #37593-class breakages structurally impossible; the in-tree workaround in this PR (or my earlier file-marker suggestion) is only needed until one of them is set up.

---

Comment written by Claude Opus 4.7

[silverwind]

AI slop. It would only add one more dirty hack to the already buggy snap build steps

Yes, it's a workaround, the proper fix options are described in comment above.

[wxiaoguang]

AI slop. It would only add one more dirty hack to the already buggy snap build steps

Yes, it's a workaround, the proper fix options are described in comment above.

Even if nobody would like to touch snapcraft.io and keep adding new branches to launchpad, the "almost" complete fix can be like this: wxiaoguang@aeaf3ab

[silverwind]

Even if nobody would like to touch snapcraft.io and keeping adding new branches to launchpad, the "almost" complete fix can be like this: wxiaoguang@aeaf3ab

I had Claude look at that and it likes it. One remark:

this needs ordered deployment. After main switches to ./snap/part-gitea-build.sh, snapcraft will try to run that script from whatever ref it checks out. If release/v1.26 doesn't yet contain snap/part-gitea-build.sh, the next 1.26.x stable build breaks. Order: backport the two scripts to release/v1.26, then merge the yaml switch on main.

[wxiaoguang]

I had Claude look at that and it likes it. One remark:

this needs ordered deployment.

Yes, that's my proposal. 1.26 fix, then main

[silverwind]

So how do we continue here? Branch https://github.com/wxiaoguang/gitea/tree/fix-snap does not have a PR up yet?

[bircni]

So how do we continue here? Branch https://github.com/wxiaoguang/gitea/tree/fix-snap does not have a PR up yet?

@wxiaoguang ping

[wxiaoguang]

Let the owner decide what they would like to do. Fix the snapcraft.io, or fix the build script ( #37602 (comment) )

[lunny]

Let the owner decide what they would like to do. Fix the snapcraft.io, or fix the build script ( (earlier comment) )

I prefer your commits.

[silverwind]

There's a third option too with snapcraft remote-build which moves that build into CI, also a viable option. Or maybe that is what the script already does, have not checked in detail.

[wxiaoguang]

• fix: snap build (1.26) build: Fix snap build (1.26) #37646
• fix: snap build (main branch) fix: snap build (main branch) #37645