Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should we deal with gitea updates in the future? #51

Open
DO1JLR opened this issue Jun 25, 2020 · 21 comments
Open

How should we deal with gitea updates in the future? #51

DO1JLR opened this issue Jun 25, 2020 · 21 comments

Comments

@DO1JLR
Copy link
Contributor

DO1JLR commented Jun 25, 2020

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?

@thomas-maurice
Copy link
Owner

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

@thomas-maurice
Copy link
Owner

@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.

@sapk
Copy link

sapk commented Jul 6, 2020

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.

@DO1JLR
Copy link
Contributor Author

DO1JLR commented Jul 6, 2020

I like the idea from @sapk

@sapk
Copy link

sapk commented Jul 7, 2020

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

@thomas-maurice
Copy link
Owner

@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
Copy link
Owner

Should I just mention @giteaio on twitter and ask them for advice ?

@techknowlogick
Copy link

@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.

@thomas-maurice
Copy link
Owner

Well then that would be truely awesome!

@thomas-maurice
Copy link
Owner

The idea here is not to inadvertently break people's setups

@techknowlogick
Copy link

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.

@thomas-maurice
Copy link
Owner

That would be brilliant mate <3

@techknowlogick
Copy link

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

@thomas-maurice
Copy link
Owner

Thanks !

Also if you want this shit to become part of the official gitea project just hit me up

@thomas-maurice
Copy link
Owner

@techknowlogick is the ticket public btw ? so I can track it :)

@JensTimmerman
Copy link
Contributor

+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?

@JensTimmerman
Copy link
Contributor

JensTimmerman commented Dec 2, 2020

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...

@stefanux
Copy link

+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 ).

@DO1JLR
Copy link
Contributor Author

DO1JLR commented Jul 19, 2021

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:


If someone feels motivated to do so, this can of course still be incorporated here.

@JensTimmerman
Copy link
Contributor

JensTimmerman commented Sep 22, 2021

@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...

@DO1JLR
Copy link
Contributor Author

DO1JLR commented Sep 22, 2021

@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_name is 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants