Yes. The use case would be as follows:
- 2020: I install a Gitea 1.14.1 instance
- 2022: I did not upgrade my Gitea instance
- I try to upgrade to 1.16.5 and run into problems
- I dump the database and create a tar with the data directory of Gitea
- I upload the tar to hostea
- I rent a Gitea instance on hostea
- The hostea migration tool applies migrations & tests from 1.14.1 to 1.16.5
- I self-host hostea and do the same
Yes. Whenever a Gitea instance is published scripts will be written within hostea that will:
- Skip the release if it is tainted for some reason
- Automate what the release notes recommend to do manually
- Apply upgrades in sequence (1.16.1 then 1.16.2 etc.) rather than jumping to the latest directly
- Run sanity checks
Such tooling and upgrade automation is made possible because hostea is opinionated on how Gitea is installed and assumptions can be made. For instance it will use SQLite, run from the docker distribution on a GNU/Linux distribution etc. This restricts the range of possible upgrade failures.
Ideally the tooling is 100% implemented in Gitea itself. It is more likely that it is first implemented in hostea, proposed and discussed upstream for a while and then exists in Gitea. It is also quite possible that some aspects of the tooling are rejected because they are too specific and there is no clear way to make it generic enough to enter the Gitea project.
Both. There is something similar for Discourse. Some major upgrades require access to the machine, in both cases. But the vast majority of upgrades can be controlled from the web interface.
When a monitoring (such as Icinga) is in place, there exist plugins that do exactly this using various sources. And Gitea does this too: you can see in the gitea.hostea.org admin panel a notification that an upgrade to 1.16.5 is available.