Automatic upgrades broken?

[acolomb (André Colomb)]

Hi, I noticed that one Synology NAS where I just installed the community’s Syncthing package again fails to get an automatic upgrade although it should.

The installed version is v1.1.0, Linux (AArch64). However, I don’t think it is a client issue.

The upgrade server URL currently just lists all v1.2.1 release candidates if I read it correctly. That would match the log output on my device:

2019-08-02 11:16:05 skipping pre-release v1.2.1-rc.1
2019-08-02 11:16:05 skipping pre-release v1.2.1-rc.2
2019-08-02 11:16:05 skipping pre-release v1.2.1-rc.3
2019-08-02 11:16:05 skipping pre-release v1.2.1-rc.4
2019-08-02 11:16:05 skipping pre-release v1.2.1-rc.5

Could someone check what’s going on at the upgrade server please?

[calmh (Jakob Borg)]

The upgrade server only offers the last five releases. Generally that includes the last couple of stable and an RC or two. Right now we have an unusual amount of RCs out so all of those five are RCs. That situation will change on Tuesday.

I noticed the issue and we should be able to offer more historical releases, or filter it to just the last RC in a series. But as it is, it’s just a straight dump of the GitHub API response. We would need to massage the data a bit to improve the situation.

[acolomb (André Colomb)]

Indeed the listing API seems quite limited

I’d hoped there was at least a parameter to filter out pre-releases (or show them exclusively). That way it could be solved with just two queries, max. 5 rc’s and 5 stables.

Seeing the upgrade logic is kind of smart about doing latest minor upgrades before attempting a new major version for example, it might lead to inconsistent results if the (visible) release history changes over time.

[acolomb (André Colomb)]

Actually, the GitHub API does return 29 results on the first page… So who does the limiting?

Just setting the GitHub URL directly in Advanced Settings helped as a workaround.

[calmh (Jakob Borg)]

We do, and as mentioned we could do that smarter. We can remove a number of fields from the GitHub response and include more releases. The default response you’re looking at is > 1.5 MiB in size. We serve the response ~10 times/s. Oh, and with gzip compression which helps, but still. Smaller is better.

Ideally we’d only serve the latest in each series (latest major-1, latest RC).

[uok]

see https://github.com/syncthing/syncthing/issues/5924