make version bump easier for plugin maintainers
rajatjindal opened this issue · 20 comments
This issue is to continue discussion on using krew-plugin-release (or alternate) for auto-bumping the version in krew-index on a new release.
the original discussion can be found here: #267
so options that we have considered to far are:
- move krew-plugin-release ownership to krew team
- implement a bot user `krew-plugin-release-bot', which listens for events and submit PR's on behalf of user. (but fork of krew-index is done/owned by the bot, so enduser do not have to give fork/commit permissions to the github action)
- May be a webservice owned/managed by krew team that listens for release events (using github events), and auto-bump the version in krew-index.
more suggestions/alternates are welcome.
- move krew-plugin-release ownership to krew team
Is the concern here that the owner of this repo potentially can extradite your GitHub token?
- Implement a bot user `krew-plugin-release-bot', which listens for events and submit PR's on behalf of user. (but fork of krew-index is done/owned by the bot, so enduser do not have to give fork/commit permissions to the github action)
- May be a webservice owned/managed by krew team that listens for release events (using github events), and auto-bump the version in krew-index.
Instead we've been thinking of this:
- Make a daily cronjob that visits GitHub repo of every plugin. It picks up the highest stable release (i.e. no
-alpha,-beta,-***suffix). Then if it's a version bump, it modifies the manifest, validates it locally, and makes a PR (which can be auto-merged by the existing bot I have).
What do you think of this?
The concern Chris had was if owner of krew-plugin-release turns out to be malicious, the token is quite powerful to cause damage. (which is a valid concern in my opinion).
that works too
if we have a place to host a webservice, it might be easier and more efficient to do it based on a push notification.
So let's call "daily scanning of source repos for new stable releases" option 1.
Option 2: Write a public webhook that receives "tag" events from plugin repositories (plugin author must configure). When a valid event is received, the webhook would find the which plugin(s) are associated with that repo, and use a simple string replacement to prepare a patch. The patch then is sent as a PR to this repo by a "bot account" on GitHub (only to be auto-approved and merged without human intervention).
I just copy my previous comment:
There is a general purpose tool for that, which is pretty extensible : https://github.com/renovatebot/renovate/
I would suggest to try to extend it. I do not know in details how it work, but generally there are two parts to write :
provider - some source of artifacts and versions
detector - part which scans for file patterns (like plugin files) and is able to extract version used here
Having those two, renovate compares the version and proposes a PR to update once newer version is found. It is mature tool and used across many companies and os projects
@grzesuav the fact that it's written in JS/TS is going to be a productivity blocker. I don't know if we (as Krew/k8s maintainer ecosystem) can maintain something like this. For me personally, it'll be an uphill battle.
If you have any expertise with it, we'd love to have you present it at a SIG meeting or something like that. I've scanned their docs and it's unclear to me where the "provider" and the "detector" lives and how they're authored.
@ahmetb the idea is that you do not need - you just add renovate bot access to your repository and configure it. I can make an issue report there to assess how difficult would be to add support to krew specific plugin files.
@grzesuav if you can follow up on that, that would be great.
There's a bit of hesitation to give additional bots access in repositories, if it can operate on OSS repos through PRs that would be much better.
In addition, we've heard from plugin developers that they don't want to give additional bots/apps access (to make a krew PR when there's a new tag etc).
Asked on their issue tracker : renovatebot/renovate#4769
@ahmetb usual flow is that you give renovate bot developer access to repository (example : https://gitlab.com/grzesuav/kubectl-mtail/-/project_members) and then it watches for version updates and propose a PR : https://gitlab.com/grzesuav/kubectl-mtail/merge_requests/20/
Yeah I don’t think that’s going to work well for us each repo owner needs to install it. Instead we can scrape all repos and daily/hourly create PRs automatically to bump.
Thanks for investigating though. Really appreciate it.
@ahmetb but the repo owner do not need to install it. It would be needed only in this repository. I shown you my example, when I use it to bump version of docker images used in my gitlab-ci. The renovate scans various places (dockerhub, maven repo, npm repo) detects new version and proposes a upgrade.
Ahha, sorry I got confused heavily by GitLab's UI.
This sounds doable, though it would be really good if it required no access at all so we could directly enable it. It seems like I'd have to get permission from SIG CLI to install this to our org. Do you know for their GitHub integration it's a read-only permission or RW?
it seems write permissions are needed, but they mention https://github.com/apps/forking-renovate which need only read permissions
Thanks. I'm nearly sure write permissions won't fly in this org. That's why Forking Renovate sounds promising. If it's ready for use, and you have some familiarity with JS, it's worth prototyping. I can't personally write JS beyond jquery. :)
Another concern would be that the project is backed by a commercial entity, so a solution that we write ourselves here has a chance of outliving the tool.
Similarly, I suspect Krew will have "custom needs", such as waiting for a while before auto-updating to a new release (because maybe the manifest owner needs to make a change with the new version). Every time we have a case we'll end up customizing the Renovate code for Krew (in the upstream?).
/cc @corneliusweig
-
I not JS programmer either, but I believe with help of someone more familiar with renovate I can give a try, no promises though. Anyway I think approach in generalized form (not focusing on krew yamls, jut making it customizable) is a nice feature and probably will be useful also for others.
-
I believe that then someone else will fork the project. It is really good and widely used, with no real alternative I am aware of.
-
Renovate is easily customizable, via ,
renovate.json(https://gitlab.com/grzesuav/kubectl-mtail/blob/master/renovate.json) and have a lot of config options - I believe most of useful ones were implemented or have been requested. Would be best to evaluate special needs and cross check with documentation if they are present.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
I think krew-release-bot has already shown its usefulness. It is already documented as a good way to update plugin manifests in our contribution guidelines. So it's time to close this issue.
Issues about release-bot should be opened here https://github.com/rajatjindal/krew-release-bot.
/close
@corneliusweig: Closing this issue.
In response to this:
I think
krew-release-bothas already shown its usefulness. It is already documented as a good way to update plugin manifests in our contribution guidelines. So it's time to close this issue.Issues about release-bot should be opened here https://github.com/rajatjindal/krew-release-bot.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.