Add Gitea and update Node.js

[publicarray]

Motivation: Adds Gitea, not much more to say about it.
Linked issues: fixes #1522, fixes #4749, fixes #4256 and closes #2533, closes #2101

Checklist

• Build rule all-supported completed successfully
• Package upgrade completed successfully
• New installation of package completed successfully
• create wiki entry (still to-do) - probably no longer necessary
  • - recommend to set up a shared folder for storing repositories (the wizard does this for you)

[hgy59]

superb!
two small issues

• make DSM 6 compatible (SYNOPKG_PKGHOME is not defined)
• add wizard to provide a shared folder for the repositories (we don't want repositories unter var to avoid to backup/restore those on package update).

[publicarray]

Thanks :) Good points.
While testing I manually created a share and updated the paths during the install. I agree it's best to do it by default.

Thanks, I forgot about the PKGHOME

[efussi]

Gitea just released v1.15.9 -- what about using this version from the get-go?

[efussi]

Testing this locally, I noticed in the build output that main.Version is empty:

Running go generate...                                                                                             
generating bindata for options                                                                                     
generating bindata for public                                                                                      
generating bindata for templates                                                                                   
CGO_CFLAGS="-g -O2 -DSQLITE_MAX_VARIABLE_NUMBER=32766" go build -mod=vendor -v  -tags 'bindata sqlite sqlite_unlock_notify' -ldflags '-s -w  -X "main.MakeVersion=GNU Make 4.2.1" -X "main.Version=" -X "main.Tags=bindata sqlite sqlite_unlock_notify"' -o gitea

This can be set by adding

ENV += GITEA_VERSION=$(PKG_VERS)

after https://github.com/publicarray/spksrc/blob/216f353cf10305185b05c91fe28b948006c8d6d8/cross/gitea/Makefile#L26.
See also https://github.com/go-gitea/gitea/blob/ffaebb1a849f78dd7ba5def69237f3b44ae13bbf/Makefile#L91.

[hgy59]

The version I see in the web ui is
Powered by Gitea Version: sonarr+3.0.5.1144-237-g216f353c

I have no idea why sonarr is written here.

[efussi]

The version I see in the web ui is Powered by Gitea Version: sonarr+3.0.5.1144-237-g216f353c

I have no idea why sonarr is written here.

Interesting observation. I see Powered by Gitea Version: 1.15.8 with the package I built myself before I came across this PR. Maybe the empty main.Version is more visible than I thought.

[efussi]

When I was building a Gitea spk myself, I noticed that Gitea releases contain a source package with prebuilt frontend files which allowed me to avoid the native/nodejs dependency:

PKG_DIST_NAME = $(PKG_NAME)-src-$(PKG_VERS).$(PKG_EXT)
PKG_DIST_SITE = https://github.com/go-gitea/$(PKG_NAME)/releases/download/v$(PKG_VERS)
: 
DEPENDS = native/go
: 
EXTRACT_PATH = $(WORK_DIR)/$(PKG_DIR)

Is this a viable approach? Or is there some advantage in rebuilding the frontend files as well?

[publicarray]

Is this a viable approach? Or is there some advantage in rebuilding the frontend files as well?

Building it doesn't take too long (NodeJS only needs to be installed once) and it verified with the digest file. To do the same I would split the frontend to a new cross package. (gitea-web) similar how Jellyfin is done. Generally I prefer building to downloading binaries.

[publicarray]

Oh, you mean the gitea-src-1.15.9.tar.gz vs /tags/v1.15.9.zip? Yea, not a bad idea.

Edit: there is a file size difference of 4mb on the finished build 🤔

[publicarray]

@efussi and @hgy59 Thanks for your feedback 😄

[efussi]

Nice work, @publicarray!
Three more minor comments for your consideration:

• Using gitea-src-1.15.9.tar.gz appears to remove the need to explicitly set GITEA_VERSION=$(PKG_VERS).
• Target build checks whether the frontend files are already there and if so, skips building them. So changing $(MAKE) build to $(MAKE) backend isn't strictly necessary.
• What about using $(RUN) $(MAKE) build instead of cd $(GO_SRC_DIR) && env $(ENV) $(MAKE) build?

[efussi]

When trying to install gitea_armv7-7.0_1.15.9-1.spk from https://nightly.link/SynoCommunity/spksrc/actions/runs/1639773942, I got the following error:

Please install the following package(s) before installing this package:
- Git Server

even though I have the Synology provided "Git Server" installed on my NAS. When I removed the https://packages.synocommunity.com/ package source, the missing package changed from Git Server to git.
Gitea works fine when I remove

SPK_DEPENDS = "git"

from spk/gitea/Makefile.

[publicarray]

Nice work, @publicarray! Three more minor comments for your consideration:

Thanks 😃

* Using `gitea-src-1.15.9.tar.gz` appears to remove the need to explicitly set `GITEA_VERSION=$(PKG_VERS)`.

I'm keeping it just in case. There is no downside in keeping it defined.

* Target `build` checks whether the frontend files are already there and if so, skips building them. So changing `$(MAKE) build` to `$(MAKE) backend` isn't strictly necessary.

Build will fail since it can't find node

* What about using `$(RUN) $(MAKE) build` instead of `cd $(GO_SRC_DIR) && env $(ENV) $(MAKE) build`?

Thanks

When I removed the https://packages.synocommunity.com/ package source, the missing package changed from Git Server to git

Generally our version ships a more up-to-date git version. But I can switch to using system Git.

[hgy59]

Can gitea run with synocommunity Git package git - or does it require the synology Git Server package Git?

The synology package does not only provide git cli but also runs a git server with dropbear and sshd.

We have to choose one of the following approaches

1. depend on synocommunity git package (as before)
2. depend on synology git server (as currently)
3. avoid any dependency and validate in preinstallation wheter git cli is available
4. avoid any dependency and include cross/git in spk/gitea

my favorite is 1.)

Remarks

3.) lacks the dependency, so one can break gitea by uninstalling git, without any warning. (probably the dependency can be added to the INFO file at installation time to fix this)

When we keep 2.) or use 3.) we probably get conflicts with user and repository management between gitea and git server

We should drop the synocommunity git-server package as it is outdated, never run on DSM 6+ and is overhauled by synology Git Server and gitea.

[publicarray]

Thanks yea I'm also for option 1.

[hgy59]

@publicarray If you remove the old git-server, you can remove rsc:share/gitweb/ from cross/git/PLIST.

This line was removed in 17bbc09 but is needed by git-server so I added it again in 0aacd11.
While removing git-server the line rsc:share/gitweb/ can finally be removed from cross/git/PLIST.

[hgy59]

@publicarray I propose to move the update of curl and openssl to a dedicated branch as those trigger the CI for a whole bunch of packages...

[Libbum]

Can anyone confirm that they can ssh into this with the synology ssh daemon? I'm capable of doing ssh me@domain, but cannot get ssh gitea@domain to function (Permission denied (publickey) error). I've ran the "Update the '.ssh/authorized_keys' file with Gitea SSH keys." action and can confirm that file looks the way it should.

One thing I can see that could be a complication is the synology user is sc-gitea, thus the .ssh directory is not owned by gitea.

[publicarray]

@Libbum I made a mistake with the .ssh directory in DSM7 it's in the wrong location (cp -r /var/packages/gitea/var/.ssh /var/packages/gitea/home/) but even modifying login shell in /etc/passwd for the sc-gitea user is not enough to make it work.

I'm stuck on this:

git clone sc-gitea@<NAS IP>:publicarray/test.git
Cloning into 'test'...
Gitea: Internal error
Gitea: Internal error
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

[Libbum]

OK, Thanks for the tip @publicarray. I'll take a look on my system tomorrow and report back if I can dig anything up.

[wkobiela]

@publicarray I have a question - I have installed Gitea on DSM6 using this script https://github.com/flipswitchingmonkey/gitea-spk
and it is up and running. What should I do to switch to your community package? Should I fully uninstall previous Gitea package and use some kind of backup?

[publicarray]

Hi @Wuszek because they use different ports you can run them side by side to verify everything works before uninstalling the older version. You are right that a backup and restore is the best way. This package here forces you to use a shared folder for the repositories, I don't know where they would be for the older package though. By just copying the repositories Gitea also allows you to adopt them from the admin setting page.

[hgy59]

another condition for side by side installation is satisfied too: the package names differ
gitea - synocommunity
Gitea - the other spk

[wkobiela]

IM STILL ON DSM6

Actually, after instalation of community packaga, it somehow "broke" first instance. I mean, it was "working" but only showing "Error 500" site. So, the best solution is to make backup/dump of old Gitea instance, uninstall it, install new and copy backup files/ configuration files. New gitea can use old app sql database, so no need to touch that.

First, to do a dump we need to setup gitea user with ssh access.

cd /etc 
vi group
administration -> add gitea

cd /etc 
vi passwd
/var/packages/Gitea/target --> /var/packages/Gitea/target/gitea
/sbin/nologin target --> /bin/sh

su - gitea

To make a dump, we need to use gitea user, so ssh on nas and:

sudo -i
su - gitea
cd /usr/local/gitea/gitea/ 
./gitea dump -c /usr/local/gitea/gitea/custom/conf/app.ini

Move dump somewhere safe. Install new community gitea package, setup sql access, no need to setup more. Start and stop package. Copy date folder from dump to new location, copy repos to new location (new location will be written in new conf.ini file), and then fill up conf.ini file with old settings, but remember about new paths. Start new package. It should work and behave just like old one.

Cheers

//// For new community app, how to add user sc-gitea and make dump?

/// new  community app - enabling user sc-gitea in ssh
sudo -i
cd /etc 
vi group
administration -> add sc-gitea


cd /etc 
vi passwd
find line /var/packages/Gitea/target 
/sbin/nologin target --> /bin/sh

su - sc-gitea

Make a dump:

sudo -i
su - sc-gitea
cd /usr/local/gitea/bin
./gitea dump -c /var/packages/gitea/var/conf.ini

[Libbum]

@publicarray, I've managed to get ssh working on my DSM7 system so we can identify what I'm doing differently to your setup.

• cp -r /var/packages/gitea/var/.ssh /var/packages/gitea/home/

ls -l /var/packages/gitea/home/.ssh/authorized_keys
-rw------- 1 sc-gitea synocommunity 536 Jan  9 17:36 /var/packages/gitea/home/.ssh/authorized_keys

.ssh has the same user:group, with chmod 700, authorized_keys is 600.

• in /etc/group, sc-gitea to be added to ssh-user
• in /etc/passwd, change sc-gitea to ::/var/packages/gitea/home:/bin/sh <- I think we could just change this to /var/packages/gitea/var/ to avoid the cp above perhaps?

That's essentially everything I think.

[AlexFullmoon]

So, if I may ask — which port should I set in initial configuration? Synology's buildin sshd?

After a bit of digging around the problem seems to be that sshd looks into (nonexisting) /var/packages/gitea/target/.ssh/authorized_keys while gitea writes into /var/packages/gitea/var/.ssh/authorized_keys (I'm probably stating the obvious, sorry)

[publicarray]

@Libbum
I tried again but where did ssh-user come from? I don't have such a group

in /etc/group, sc-gitea to be added to ssh-user