search

kubernetes-sigs / krew-index

Plugin index for https://github.com/kubernetes-sigs/krew. This repo is for plugin maintainers.
https://krew.sigs.k8s.io
Apache License 2.0
632 stars 481 forks source link

consider krew-release-bot webhook for version bumps #374

Closed rajatjindal closed 4 years ago

rajatjindal commented 4 years ago

continuing from discussions in #270 and #371, opening this ticket to identify next steps for krew-release-bot

Questions that needs to be answered are:

I think we need short term answers for now, and we can decide on the long term plan depending on feedback we receive from users.

ahmetb commented 4 years ago

where should the webhook listener run and where should we store the container images for the same.

We have a Google Cloud Platform project that we've been operating for various *.krew.dev endpoints and stats collection etc . We can deploy it to there.

  • what domain should be used for webhook listener. currently it uses subdomain of my personal domain

Maybe we can put something like release-webhook.krew.dev to use for this, fairly easy to do, once deployed to Cloud Run. The krew.dev is currently owned by me, but it should be fairly easy to add other maintainers to it.

  • where should be the code repository for the webhook code

We'd most probably keep this on your personal account for now. It's not a responsibility that we can offload to the SIG CLI at the moment. We have other repos (like krew-index-autoapprove, and download stats collector) that we've been keeping on our personal accounts.

  • We need two secrets (webhook payload validation secret and secret for krew-release-bot for opening PR).

I think we can just use secret to open PR. Validation secret is not so much necessary (am I right?). For that secret it can be just something that we share in a secured document between maintainers of this.

rajatjindal commented 4 years ago

sounds good to me. For docker image, can we setup automated builds? I've done automated builds for docker hub, but not for gcr.io. can you please help with that.

Also I am happy to add you as collaborator there, just in case you need to push something to that repo while I am not available. (please let me know if that is ok).

We should have both the secrets. One thing that was worrying me was what if someone sends a malicious release event? so together with webhook payload validation and verifying homepage == repo of event, i was hoping we can have some security in place here.

ahmetb commented 4 years ago

Yeah don't worry about setting CI/CD up. For now, run it in your account with your plugins. Let's pilot it for a few months and we can take over?

rajatjindal commented 4 years ago

sure. just so that I ensure i understood you correctly. For now we will keep everything (including docker image, cloud-run, webhook) in my account, and later we can decide to move to krew?

ahmetb commented 4 years ago

Yeah. Let's pilot it for a while. I'll add it to some of my plugins, Cornelius can do the same. And we'll refine the developer experience over time, make sure repo has docs, it works properly etc. Hope that's good.

rajatjindal commented 4 years ago

sure. sounds good to me. :)

ahmetb commented 4 years ago

@rajatjindal how’s it going? Did you make any progress? Do you mind writing a small guide for using it? I might start using this soon on a plugin that I am working on.

rajatjindal commented 4 years ago

Hey @ahmetb , this is up and running. Please refer to this PR i opened for a different plugin: https://github.com/robscott/kube-capacity/pull/23

If you run into any issues with this, please let me know.

ahmetb commented 4 years ago

@rajatjindal My understanding is that this should not be a GitHub action ideally. We can just add a simple webhook that captures tag/release events.

Is GitHub Apps a better approach than webhooks? I'm trying this on my new plugin at https://github.com/ahmetb/kubectl-tree now.

ahmetb commented 4 years ago

I'm also trying to compare GitHub Actions vs GitHub Apps. It seems like GitHub Apps aren't going to be around in the long term, possibly.

rajatjindal commented 4 years ago

hey Ahmet,

this is not a github action anymore, and is a github app. My understanding is that thats how you configure webhooks? I am not sure of the alternate way, if you can please point me to that, I can try that out for sure.

personally I think github apps will stay here as they provide more granular control (and not replaced by github actions). but even if they do, we can write an action to just make an http call on release published.

ahmetb commented 4 years ago

Yeah github apps will stay.

But go to repo Settings → Webhooks. There are webhooks for sure. It just involves pasting an URL and choosing which events you want.

I like “Apps” experience but right now it’s too opaque. I can’t see logs, I can’t see progress, but it actually could allow us to change the underlying endpoint and where it’s hosted.

corneliusweig commented 4 years ago

I didn't follow closely, but the latest state is that the automated PR is done via a GH action, right?

@rajatjindal Is your documentation on the bot's homepage still up-to-date? I wonder if it is really still required to grant the bot read access to the repo. I thought this is not necessary when it runs as a GH action.

I think it would be nice to write up a small howto to help adoption of this tool. The best place for now would be in the krew-release-bot repo, I think. When this is in good shape we can think about how to advertise this to other plugin authors.

ahmetb commented 4 years ago

I didn't follow closely, but the latest state is that the automated PR is done via a GH action, right?

more like:

GH action --> container running on GH ---HTTP---> Cloud Run endpoint --> GH API to create a PR on behalf of krew-release-bot

rajatjindal commented 4 years ago

do you think this is useful? - https://github.com/rajatjindal/krew-release-bot#using-github-actions

rajatjindal commented 4 years ago

I've removed webhook from main documentation, and moved it to a different file to avoid confusion. thanks :)

ahmetb commented 4 years ago

Lets scrap the GH app if we can, and just have the Action. Then I look forward to simplifying the code as much as we can and deploy (maybe using Cloud Run Button).

rajatjindal commented 4 years ago

ok, i'll remove the github webhook based implementation from the code. Looking for feedback on how we can simplify things further.

ahmetb commented 4 years ago

cool, I opened several more issues in your repo to polish things up. Ideally this should be really easy to integrate. I think we've proven that.

rajatjindal commented 4 years ago

Thanks for taking out time to open issues, i will try to address them quickly

ahmetb commented 4 years ago

Since this is now maturing, we should look at onboarding more plugins to it. If we onboard several more plugins, it's likely we'll see some more feature requests.

In the meanwhile, @rajatjindal can you please make a small docs PR to krew developer guide to add a short section talking about "Automating plugin releases on krew-index" and link to your tool?

rajatjindal commented 4 years ago

sure. will do that

rajatjindal commented 4 years ago

we have added the documentation to the krew developer guide. closing this issue.

/close

k8s-ci-robot commented 4 years ago

@rajatjindal: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/krew-index/issues/374#issuecomment-583241025): >we have added the documentation to the krew developer guide. closing this issue. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.