Gitea Snap update issue

[JensTheCoder]

Gitea Snap works without any frictions until it comes to an upgrade. "git push …", and others commands, throw errors.

The reason: This symbolic link is ignored:

/snap/gitea/current

here in these hooks:

/var/snap/gitea/common/data/gitea-repositories/organization/repo/hooks/*

Or, to put into other words: When triggered, a hook calls

/snap/gitea/1234/gitea

and "1234" does no longer exists after an upgrade.

Work-around:

ln -s /snap/gitea/current 1234

[6543]

@JensTheCoder which gitea version do you refer to?

[JensTheCoder]

1.14.3
It's the lastest version with Snap.

[techknowlogick]

What version did you upgrade from, and which was the first version you installed with snap?

[JensTheCoder]

$ journalctl -u snap* > log.txt

Installation date: Apr 22, 2021 (latest)

Your tag history:

https://github.com/go-gitea/gitea/tags

Means, the initial installed version is 1.14.1

Upgrade path:

1. 1.14.1
2. 1.14.2
3. 1.14.3

[CSitterlee]

Same problem for me. Installed v1.14.3 with snap and got the same hooks-path-problem after automatic updates. Now I'm on v1.14.5. The workaround in the first post only works for existing repos. Hooks in new repos always use paths with the current snap-revision-number.

/etc/systemd/system/snap.gitea.web.service is using /var/snap/gitea/5508 as WorkingDirectory (5508 is my current snap-revision for gitea). Maybe the problem is here?

[OleHusgaard]

I ran into this problem today after installing Gitea on a fresh Ubuntu 20.04 installation last month. I use the normal Ubuntu install and updates, as opposed to installing Gitea manually.

On Aug 19, after the initial installation, revision 5542 of the Gitea snap was being used.
On Aug 22, after an update, revision 5570 of the Gitea snap was being used.
On Sep 03, after an update, revision 5595 of the Gitea snap was being used.

Yesterday, on Sep 22, I again updated my Ubuntu system. This meant that revision 5629 of the Gitea snap was being used. And after this update I got the problem when pushing "remote: ./hooks/pre-receive.d/gitea: line 2: /snap/gitea/5570/gitea: No such file or directory".

In /snap/gitea/ I now have folders for the last two revisions 5595 and 5629 and a symlink from "current" to the last revision, so it looks like the last two revisions are saved when upgrading.

This does not look to me like a problem with Gitea as such, but rather a problem with the snap integration.

The suggested workaround solved my problem.

[OleHusgaard]

I have had a look at the code, and the problem seems to be with initializing the repositories. Here setting.AppPath is used for the repository hooks. On my system when I start Gitea, I see "routers/init.go:77:GlobalInit() [I] AppPath: /snap/gitea/5629/gitea". But unfortunately this path includes the revision of the Gitea snap, so the hooks of new repositories will break when that snap revision is no longer installed.

The only solution I see (probably because I know very little about snap) is a bit of an ugly hack: In modules/setting/setting.go, in function getAppPath(), we check if the returned value matches "/snap/gitea/$NUMBER/gitea", and in this case instead return "/snap/gitea/current/gitea". This should work, as there is a symlink from the latest snap revision to current.

This will only work for repositories created after this issue has been fixed. But a good workaround for older repositories has already been proposed here.

[JensTheCoder]

@techknowlogick how to remove the feedback tag?

[techknowlogick]

@OleHusgaard an easier way may just be to override the apppath via LDFLAGS when snap builds the gitea binary. here is where the binary is built https://github.com/go-gitea/gitea/blob/main/snap/snapcraft.yaml#L70

[OleHusgaard]

Thank you @techknowlogick. However, I do not understand how the apppath can be changed or overridden by using the linker flags. Could you please explain, if you think that would be a better way to fix this issue?

After having learned a bit more about snap I am finally able to build and deploy a gitea snap with modified code, so I am able to fix this issue and test the fix.

[techknowlogick]

@OleHusgaard in the makefile it adds a few things to the LDFLAGS env var, however it appends rather than overrides, so if the additional config is added via LDFLAGS in the yaml right before where the make command is run.

More info on ldflags can be found here: https://docs.gitea.io/en-us/install-from-source/#changing-default-paths

[techknowlogick]

If you'd like to attempt this yourself, but need some guidance feel free to ping me on discord and I'd be happy to help.

[OleHusgaard]

@techknowlogick That is a nifty golang feature, and it would have made the fix slightly easier. I have created pull request #17157

[wxiaoguang]

Fixed by

• Sync gitea app path for git hooks and authorized keys when starting #17335

in 1.16