ansible-role-gitea
ansible-role-gitea copied to clipboard
thomas-maurice
How should we deal with gitea updates in the future?
Gitea has been updated more often lately. And the practice of updating it every time in this role can be done... But it doesn't seem to make that much sense in the long run.
What do you think about extending this ansible role by adding some magic that automatically downloads the newest gitea version? For example by evaluating a curl on https://github.com/go-gitea/gitea/releases/latest...
Of course the variable gitea_version: 1.12.1 should still be valid. But if you write something like gitea_version: latest, a download of the latest version would be nice.
Or what do you think?
That makes sense to approach it this way, that would actually be cooler that manually updating it like we do right now
It would have to be clear in the documentation that using latest will grab whatever version is the latest so you may expect restarts when running.
I am however concerned if we allow the user to both use latest and a fixed version, then sometimes we might end up in a case where a user is using the version X but we added to the templates config options that were introduced after version X so that might create issues
@DO1JLR any opinion about that ?
I am worried that people would pin Gitea versions and end up with completely fucked configs because we will follow the latest release, which might not be good.
I am not sure ansible allows that but maybe we could do one release per Gitea release. That would however tremendously increase the maintenance time.
At this point I have no strong opinions so I am really open to suggestions.
There is a download url for the last version of a minor version. For example, https://dl.gitea.io/gitea/1.12 will be the last 1.12.x release. That way you could easely grab the last non-breaking binary and update less often (around 2 times a year) the link.
Sorry, I made a assomption that it follow the same scheme of docker but dl.gitea.io/gitea/1.12 is the last build from 1.12 branch. It is the last commit and not the last release.
Maybe we could do something on gitea to have the same scheme somewhere on dl.gitea.io as we use for docker release.
- 1 = last 1.x.x
- 1.12 = last 1.12.x
@sapk like have gitea to have a pattern that accomodates us ? xD I mean that sure would be swell but I'm not sure they even know we exist
@thomas-maurice @sapk is a maintainer of Gitea, and I suspect he found this issue from the official Gitea twitter account retweeting your request for help.
The idea here is not to inadvertently break people's setups
Indeed. Like @sapk suggested above, we could probably move to align dl.gitea.io with the way we tag docker images, which isn't a huge change.
Just created a ticket for it, but in the interim to discover new releases dl.gitea.io actually has an API. ex curl -H "Accept: application/json" https://dl.gitea.io/gitea
Thanks !
Also if you want this shit to become part of the official gitea project just hit me up
+1 to this issue, gitea 1.12.4 was released that fixes security issues, one should not be installing 1.12 wich has known security issues. https://github.com/go-gitea/gitea/releases/latest/ will always contain a redirect link to the latest release, but I agree that one might not just want to update to 1.13 if this has breaking changes.
What about trying to download https://github.com/go-gitea/gitea/releases/tag/v1.12.4 https://github.com/go-gitea/gitea/releases/tag/v1.12.5 https://github.com/go-gitea/gitea/releases/tag/v1.12.6 ... until a 'Not Found' is returned and then keeping the latest 1.12 url and using this?
An update: Gitea just released verison 1.13.0 which contains 'breaking' changes in the changelog (my update from 1.12 to 1.13 was without issues, but I have not done extensive testing yet) BUT 1.13.0 contains security fixes that are currently not backported to 1.12 (I believe, I would need to do a detailed check)
So currently the above proposal doesn't work anymore (We should always install latest security updates asap) Unless we get to work with gitea and see if we can help them do security backports...
I'm in favour of using the lastest release every time, using the api...
+1 for "latest" since its the best decision for new installs (also why would a role decide which is the best version for new installs?). For existing instances just override the variable "gitea_version" (i.e. host_vars, see https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable ).
Hey everyone.
I wanted to inform you that the feature of gitea_version: latest is now built in. However ( so far? ) not in this role but in the gitea role:
- at Galaxy: https://galaxy.ansible.com/do1jlr/gitea
- at Github: https://github.com/roles-ansible/ansible_role_gitea.git (since v2.4.0)
If someone feels motivated to do so, this can of course still be incorporated here.
@DO1JLR How exactly is latest implemented? I noticed gitea sometimes releases a 1.14.x update after a 1.15.x; the latest release in github then points to a backport, following this would lead you to downgrade from 1.15 to 1.14...
or they release v1.15.0-rc3 ; I'm all for timely updates, but an rc might be a bit to soon...
@JensTimmerman good point.
The version detection magic is happening there: https://github.com/roles-ansible/ansible_role_gitea/blob/9326cd01f12cc8248d09e8d5a5df79f605dfe451/tasks/set_version.yml#L10-L30
- The ansible is asking the github api for the latest release via this url.
- The data from the
tag_nameis used except the first character (eg.tag_name: "v1.15.3") - The download link is created with the new variable
gitea_dl_url: "https://github.com/go-gitea/gitea/releases/download/v{{ gitea_version_target }}/gitea-{{ gitea_version_target }}-linux-{{ gitea_arch }}"
The decision which version is the latest version is made by github. I would trust github to not only consider the release date but also the release number for this, but unfortunately I don't know it (yet).