Forgejo 'latest' is not a reliable release version

[adrinux]

At this point Forgejo are maintaining two releases, a stable version v1.21.2-1 and an old-stable v1.20.6-1, the code in this role to check the Codeberg API:

https://codeberg.org/api/v1/repos/forgejo/forgejo/releases?limit=1

Fetches whatever was released latest and the v1.20.6-1 release came after v1.21.2-1

In my case I had GITEA_VERSION set to 'latest' and ansible_role_gitea installed v1.20.6-1 on my existing v1.21.1-0 instance -- Forgejo refused to migrate the newer version of the database and the instance wouldn't restart.

The workaround/fix is simple, just specify the released version in GITEA_VERSION instead of 'latest' and rerun the role.

Earl Warren's replies to my comment imply that there isn't really a better way to get the correct 'latest' except something hairy like looping over the latest releases.

I'm not sure what the fix is. Possibly just a documentation change to recommend setting a release version of Forgejo instead of leaving GITEA_VERSION at its default of 'latest'?

[DO1JLR]

Well, yes, we could add more logic to the detection what the latest release is by increasing the limit and comparing the tag_name or something like that... But as you mentioned, it is not that smooth.

Maybe we could add some more state handling and if the new forgjo release has a lower version than the newer one, it won't run or something like that...

I am not sure if I find the time to try any of the ideas this year.
But I am happy to review a pull-request that will implement something like that or improves the README.

[r-pufky]

Just to add a comment (I'm the one that originally authored 'latest'):

The idea behind the 'latest' tag is that it would always deploy the latest stable version of the software without needing to update roles/repositories for every version that came out, especially when release frequency was much higher. It was also a simpler time -- the role applied to one piece of software with a well-defined semantic versioning, which made 'latest' easy -- not to the multiple-repository w/ two versions of 'stable' for one, and semantic for the other.

My suggestion would be that 'latest' applies to the latest 'stable' version of forgejo, or the latest 'stable' version of gitea; and explicitly state that. This retains the original behavior and applies a similar expectation for forgejo. If you need more control, then you have the option to explicitly state versioning.

TBH, with the hard fork of forgejo, it no longer makes sense to support forgejo in this role as the divergence will only become greater over time.

[adrinux]

Hi @r-pufky to address your final comment, as per #147 DO1LJR already forked to a forgejo role. I started working on a fork/branch with the aim of a PR but got busy before I could test my changes, will get back to it eventually...

As for Forgejo, Codeberg still doesn't allow tagging them differently so which ever is released last will match 'Latest'. You might get a 7.0.x LTS release or a 10.0.x release with 'Latest'.

It might be that we need to parse https://forgejo.org/releases/ somehow instead. Or check current version and somehow compare that to 'Latest'. Either way that's an issue for https://github.com/roles-ansible/ansible_role_forgejo now.