Is there an option to keep track of dependency versions and/or auto-updating them? #1108

Andre601 commented 2023年07月21日 20:08:43 +02:00

Not gonna lie. I'm a lazy person, but I also can't keep track of every dependency I use in my projects all the time, which is why I usually use dependabot on GitHub.

Logically, Codeberg does not have this bot (or to my knowledge any similar kind), so I was wondering if there is still some way to automatically keep track of dependencies and their versions and to, at the very least, receive notifications about available updates...

Not gonna lie. I'm a lazy person, but I also can't keep track of every dependency I use in my projects all the time, which is why I usually use dependabot on GitHub. Logically, Codeberg does not have this bot (or to my knowledge any similar kind), so I was wondering if there is still some way to automatically keep track of dependencies and their versions and to, at the very least, receive notifications about available updates...

Gusted commented 2023年07月21日 21:27:44 +02:00

There's Renovabot, Codeberg currently doesn't provide this yet. You would need to self-host it, if you would like to use it.

There's [Renovabot](https://docs.renovatebot.com/), Codeberg [currently doesn't provide this](https://codeberg.org/Codeberg-Infrastructure/configuration-as-code/issues/12) yet. You would need to self-host it, if you would like to use it.

Andre601 commented 2023年07月21日 21:35:21 +02:00

There's Renovabot, Codeberg currently doesn't provide this yet. You would need to self-host it, if you would like to use it.

I did have negative experiences with the bot... or more accurately with the users behind it, so it left a bad taste in my mouth...

Tho, I'll wait and and hope for the Codeberg account one to become available eventually and just manually update for now...

> There's [Renovabot](https://docs.renovatebot.com/), Codeberg [currently doesn't provide this](https://codeberg.org/Codeberg-Infrastructure/configuration-as-code/issues/12) yet. You would need to self-host it, if you would like to use it. I did have negative experiences with the bot... or more accurately with the users behind it, so it left a bad taste in my mouth... Tho, I'll wait and and hope for the Codeberg account one to become available eventually and just manually update for now...

pat-s commented 2024年01月19日 00:40:20 +01:00

@6543 RE: your comment Codeberg-Infrastructure/configuration-as-code#12 (comment)

Users could add the bot to their org or repo and give them the required access to create issues and PRs. The bot will automatically scrape all repos it has access to.

Caveat: User must be aware that the bot will have access to the repos and hence also the people which administrate the bot, i.e. have access to the account. Also, users cannot change the frequency of the runs or which renovate version is used.

Possible downside/challenge for CB: many repos will be onboarded, and the bot will take quite some time to process all at some point (even with caching enabled). Users usually don't clean up or opt out if the repo is not used anymore or contains only issues. Hence, at some point, a lot of repo checks will be done for no reason (in every run).

@6543 RE: your comment https://codeberg.org/Codeberg-Infrastructure/configuration-as-code/issues/12#issuecomment-1514515 Users could add the bot to their org or repo and give them the required access to create issues and PRs. The bot will automatically scrape all repos it has access to. Caveat: User must be aware that the bot will have access to the repos and hence also the people which administrate the bot, i.e. have access to the account. Also, users cannot change the frequency of the runs or which renovate version is used. Possible downside/challenge for CB: many repos will be onboarded, and the bot will take quite some time to process all at some point (even with caching enabled). Users usually don't clean up or opt out if the repo is not used anymore or contains only issues. Hence, at some point, a lot of repo checks will be done for no reason (in every run).

Andre601 commented 2024年01月19日 01:29:27 +01:00

Maybe one way could be to have the user create a woodpecker file that would run the renovate task, using a dedicated user account provided by CB...
That would eliminate the need for having to either use your own account (Risky) or make a dedicated account (Also kinda risky and wastes resources on CB) while not having CB handle it all by themself I would say.

Downsides are that you somehow would need to expose access tokens for the user account in question, similar to how GitHub with their GitHub token in Actions works... This would be a can of worms to deal with...
Also, one single account could face the issue of rate limits if it would gather dependency data from GitHub and alike.
Finally, maybe some concurrency problems? Like if two ci runs start close to each other...

So... yeah... probs not a good solution either.

It would already be a good thing if

A) the "adding user" experience was better. Right now you add a user and it's added... No confirmation, auth, whatever.
Tho, this is an upstream issue

B) there were actual bot/application accounts (Labeled as such) that could be added to a repo using oauth. Bonus points if it would have similar customization in terms of repo access like GitHub does (i.e. define repos the app has access to).
Having a automated user account just feels wrong.

Those are my two cents on all this.

*Maybe* one way could be to have the user create a woodpecker file that would run the renovate task, using a dedicated user account provided by CB... That would eliminate the need for having to either use your own account (Risky) or make a dedicated account (Also kinda risky and wastes resources on CB) while not having CB handle it all by themself I would say. Downsides are that you somehow would need to expose access tokens for the user account in question, similar to how GitHub with their GitHub token in Actions works... This would be a can of worms to deal with... Also, one single account could face the issue of rate limits if it would gather dependency data from GitHub and alike. Finally, maybe some concurrency problems? Like if two ci runs start close to each other... So... yeah... probs not a good solution either. It would already be a good thing if A) the "adding user" experience was better. Right now you add a user and it's added... No confirmation, auth, whatever. Tho, this is an [upstream issue](https://github.com/go-gitea/gitea/issues/27342) B) there were actual bot/application accounts (Labeled as such) that could be added to a repo using oauth. Bonus points if it would have similar customization in terms of repo access like GitHub does (i.e. define repos the app has access to). Having a automated user account just feels wrong. Those are my two cents on all this.

Luensche commented 2024年01月22日 12:32:19 +01:00

@6543 RE: your comment Codeberg-Infrastructure/configuration-as-code#12 (comment)
Possible downside/challenge for CB: many repos will be onboarded, and the bot will take quite some time to process all at some point (even with caching enabled). Users usually don't clean up or opt out if the repo is not used anymore or contains only issues. Hence, at some point, a lot of repo checks will be done for no reason (in every run).

Perhaps there could also be an option in private repos that resets itself every 180 days if it is not actively extended?

> @6543 RE: your comment https://codeberg.org/Codeberg-Infrastructure/configuration-as-code/issues/12#issuecomment-1514515 > Possible downside/challenge for CB: many repos will be onboarded, and the bot will take quite some time to process all at some point (even with caching enabled). Users usually don't clean up or opt out if the repo is not used anymore or contains only issues. Hence, at some point, a lot of repo checks will be done for no reason (in every run). > Perhaps there could also be an option in private repos that resets itself every 180 days if it is not actively extended?