Use renovate for automatic dependency updates #14044

New Issue

GiteaMirror · 2025-11-02T11:01:09-06:00

GiteaMirror commented

2025-11-02 11:01:09 -06:00

Originally created by @TheFox0x7 on GitHub (Jan 25, 2025).

Feature Description

Filing this as follow up to my question on discord. It's not for gitea but for this repository.

At the very least I think it might help track dependencies and when they get version updates which are of some interest - at the cost of the noise in PRs.

Screenshots

No response

Originally created by @TheFox0x7 on GitHub (Jan 25, 2025). ### Feature Description Filing this as follow up to my question on discord. It's not for gitea but for this repository. At the very least I think it might help track dependencies and when they get version updates which are of some interest - at the cost of the noise in PRs. ### Screenshots _No response_

GiteaMirror added the proposal/accepted type/proposal labels 2025-11-02 11:01:09 -06:00

GiteaMirror commented

2025-11-02 11:01:10 -06:00

@wxiaoguang commented on GitHub (Jan 25, 2025):

at the cost of the noise in PRs.

Yup, that's the problem ..... too noisy and there will be a lot of "dependency-only commits".

I think most current maintainers prefer to keep current "manually update dependency" at the moment.

@wxiaoguang commented on GitHub (Jan 25, 2025): > at the cost of the noise in PRs. Yup, that's the problem ..... too noisy and there will be a lot of "dependency-only commits". I think most current maintainers prefer to keep current "manually update dependency" at the moment.

GiteaMirror commented

2025-11-02 11:01:10 -06:00

@wxiaoguang commented on GitHub (Jan 25, 2025):

Some more backgrounds: there are so many dependencies, so it's really difficult to figure out every change in them.

For example: Rocky Linux 9 (Fedora 34) cannot recognize the signature added by Gitea #33296

Even if we could have something like "renovate" to propose dependency updates one by one, without full understanding of every line of changed code, it's impossible to know that there is a breaking change in ProtonMail/go-crypto and it really affects the RPM sign in Gitea. So I think "updating all dependencies together regularly" is not bad at the moment. At least, we could trust the 3rd packages should be stable.

@wxiaoguang commented on GitHub (Jan 25, 2025): Some more backgrounds: there are so many dependencies, so it's really difficult to figure out every change in them. For example: Rocky Linux 9 (Fedora 34) cannot recognize the signature added by Gitea #33296 Even if we could have something like "renovate" to propose dependency updates one by one, without full understanding of every line of changed code, it's impossible to know that there is a breaking change in `ProtonMail/go-crypto` and it really affects the RPM sign in Gitea. So I think "updating all dependencies together regularly" is not bad at the moment. At least, we could trust the 3rd packages should be stable.

GiteaMirror commented

2025-11-02 11:01:10 -06:00

@lunny commented on GitHub (Jan 25, 2025):

A low-frequency pull request schedule could be considered, such as allowing one PR every two weeks.

@lunny commented on GitHub (Jan 25, 2025): A low-frequency pull request schedule could be considered, such as allowing one PR every two weeks.

GiteaMirror commented

2025-11-02 11:01:10 -06:00

@silverwind commented on GitHub (Jan 26, 2025):

I prefer to test dependency updates manually. Especially in the frontend, there are almost no functionality tests, necessiating manual testing.
Many dependency updates require changes in the code (eslint plugins adding new rules for example), the bot would not do them, creating extra work.
It needs a way to pin certain dependencies, currently done here for JS: https://github.com/go-gitea/gitea/blob/main/updates.config.js

I feel like introducing a updater tool would introduce a bad culture of blindly merging these PRs, especially if they come too frequent. I'd say at minimum we want one PR every 2-4 weeks.

@silverwind commented on GitHub (Jan 26, 2025): 1. I prefer to test dependency updates manually. Especially in the frontend, there are almost no functionality tests, necessiating manual testing. 2. Many dependency updates require changes in the code (eslint plugins adding new rules for example), the bot would not do them, creating extra work. 3. It needs a way to pin certain dependencies, currently done here for JS: https://github.com/go-gitea/gitea/blob/main/updates.config.js I feel like introducing a updater tool would introduce a bad culture of blindly merging these PRs, especially if they come too frequent. I'd say at minimum we want one PR every 2-4 weeks.

GiteaMirror commented

2025-11-02 11:01:10 -06:00

@silverwind commented on GitHub (Jan 27, 2025):

So as a start, I suggest configuring a bot that raises PRs to update the golang dependencies in go.mod/go.sum every 2 weeks. These are sufficiently tested, so it should be pretty safe.

@silverwind commented on GitHub (Jan 27, 2025): So as a start, I suggest configuring a bot that raises PRs to update the golang dependencies in `go.mod`/`go.sum` every 2 weeks. These are sufficiently tested, so it should be pretty safe.

GiteaMirror commented

2025-11-02 11:01:11 -06:00

@silverwind commented on GitHub (Sep 19, 2025):

After https://github.com/go-gitea/gitea/pull/35515, we can potentially use such a bot. Keep note there is also https://github.com/go-gitea/gitea/pull/35223, I don't know which one is better.

@silverwind commented on GitHub (Sep 19, 2025): After https://github.com/go-gitea/gitea/pull/35515, we can potentially use such a bot. Keep note there is also https://github.com/go-gitea/gitea/pull/35223, I don't know which one is better.

GiteaMirror commented

2025-11-02 11:01:11 -06:00

@silverwind commented on GitHub (Oct 14, 2025):

https://github.com/go-gitea/gitea/pull/35659 will resolve the license issue and move it completely to build time, so we are free to use a update bot without having to worry about generated assets.

@silverwind commented on GitHub (Oct 14, 2025): https://github.com/go-gitea/gitea/pull/35659 will resolve the license issue and move it completely to build time, so we are free to use a update bot without having to worry about generated assets.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14044