Homebrew publish on release does not work

[sbueringer]

Looks like our homebrew action does not work / probably never worked before.

It seems to depend on a personal access token which we don't really want to use.

For more context, see: https://kubernetes.slack.com/archives/C8TSNPY4T/p1653909691012589

xref: Action logs: https://github.com/kubernetes-sigs/cluster-api/actions/workflows/update-homebrew-formula-on-release.yml

/kind bug [One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

[sbueringer]

I would suggest to drop the current action.

It's not really useful to keep it failing going forward.

@CecileRobertMichon @fabriziopandini @enxebre @vincepri Opinions?

[fabriziopandini]

+1 to drop current action

We should investigate how this is done in the Kubernetes project, because relying on personal tokens is not sustainable

[sbueringer]

Opened PR https://github.com/kubernetes-sigs/cluster-api/pull/6816 to drop the action. I would keep the issue around to look for a new solution.

[killianmuldoon]

Related to #4370

[fabriziopandini]

/triage accepted

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[fabriziopandini]

/lifecycle frozen /help

cc @ykakarap possible improvement to the release automation

[k8s-ci-robot]

@fabriziopandini: This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

In response to this:

/lifecycle frozen /help

cc @ykakarap possible improvement to the release automation

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.

[sbueringer]

Disclaimer: Probably hard to automate entirely as we don't want to use personalized GitHub tokens and it's non trivial to push to community owned forks like the cherry pick bot.

But maybe there's prior art or ways to optimize the manual process a bit

[fabriziopandini]

I was thinking something like kpromo, so we create the PR automatically but using personal github token but I agree the first step should be checking how this is done in K8s

[sbueringer]

Sounds good as a fallback.

Just remembered that kubectl is available via homebrew, so we can definitely ask the k/k release team how they are doing it.

[ykakarap]

During the v1.3.2/v1.2.9 release we observed that homebrew seems to have introduced some kind of automation to automatically pick up the new version of clusterctl when available. That automation should take care of doing the homebrew publishing steps for our releases. Let's keep an eye on that automation to be sure that it continues to do what the bump process.

cc @alexander-demicev

[alexander-demicev]

Seems like the issue is resolved by introduction of a bump bot in homebrew, see this thread for context https://kubernetes.slack.com/archives/C8TSNPY4T/p1673372872896449?thread_ts=1673227707.288409&cid=C8TSNPY4T

[furkatgofurov7]

@ykakarap @sbueringer looks like we can close this issue as completed, then?

[sbueringer]

Fine for me!

[furkatgofurov7]

Hey folks, I was checking it a bit, but I could not find a automated bot PR for clusterctl in homebrew repo. I could only find https://github.com/Homebrew/homebrew-core/pull/120231 that we did not open, but this seems to be not from the bot rather a homebrew maintainer?

[sbueringer]

I think the maintainer is running a bot with his account. There are a lot of PRs opened under his name with those PR descriptions:

But we can also just ask him if he runs a bot or if he runs a script from time to time.

[furkatgofurov7]

I think the maintainer is running a bot with his account. There are a lot of PRs opened under his name with those PR descriptions:

But we can also just ask him if he runs a bot or if he runs a script from time to time.

Sure, waiting for response here: https://github.com/Homebrew/discussions/discussions/4260

[furkatgofurov7]

Based on the conversation with homebrew maintainers, here are my findings:

• there are different ways to open the PR in homebrew AFAIU, and it can be via a bot, a script, or manually
• homebrew repo has a bot, which tracks the formulaes in the Github workflow https://github.com/Homebrew/homebrew-core/blob/91c2e435b2f354084c9183c602081840ac9558e3/.github/workflows/autobump.yml#L15 running once a day and automatically opens the PR once it detects the new release.
• clusterctl is already in the list and in the past, bot opened clusterctl bumping PRs for us: https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+author%3ABrewTestBot+clusterctl+is%3Aclosed. When I compared the dates of CAPI release (i.e CAPI v1.1.3, released on March 8th, 2022) vs bot opening the PR (i.e clusterctl 1.1.3, merged on March 10th, 2022), there is a difference of [min 1 - max 3] days between them. By then, seems we were okay with that delay but not sure what has changed now?

Side notes:

• k/k repo also has the same configuration for kubectl but as I noticed, they also tend to open the PR manually most of the time without waiting for the bot to do it.
• sometimes bot opened PR build can fail for some reasons (i.e https://github.com/Homebrew/homebrew-core/pull/108335#issuecomment-1219224625), so if that is the case, anyways the manual PR needs to be opened. But that is alreaady tracked if we decide to fully rely on bot.

[sbueringer]

Maybe we should just continue checking if the PR is already open and otherwise open it ourselves. Instead of waiting a few days and then potentially still opening the PR ourselves.

[sbueringer]

@furkatgofurov7 WDYT should we do with this issue?

I think basically documenting that we should check if the PR exists and create it otherwise should be fine (which is what we currently have documented) and we can close this issue.

I'm not sure it makes sense to invest in more automation given that we have no good idea on how to do it.

[furkatgofurov7]

@sbueringer I am fine with closing it. My intention reaching out to maintainers of homebrew was to clarify if we really have an automation in place or not.

I'm not sure it makes sense to invest in more automation given that we have no good idea on how to do it.

well, as I mentioned above:

• clusterctl is already in the list and in the past, bot opened clusterctl bumping PRs for us: https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+author%3ABrewTestBot+clusterctl+is%3Aclosed. When I compared the dates of CAPI release (i.e CAPI v1.1.3, released on March 8th, 2022) vs bot opening the PR (i.e clusterctl 1.1.3, merged on March 10th, 2022), there is a difference of [min 1 - max 3] days between them. By then, seems we were okay with that delay but not sure what has changed now?

some kind of automation is there, but it is not quick enough to open a PR right away and takes time (in days 😄), but we usually open a PR right away during releasing process, which makes it useless IMO. So, I do agree on not investing more time on finding/implementing a new automation around it.

[sbueringer]

Yup agree the automation on the homebrew side is not very useful to us.

It basically comes down to: are we fine with opening the PR manually or do we want to invest in finding a way to automate it.

I just don't see a way to automate it without someone configuring their personal GitHub token somewhere, which seems like a no-go. The alternative is probably to create a special GitHub user (not sure if possible given GitHub terms and conditions and upcoming enforced 2FA) / GitHub application / .. (like Kubernetes has for Prow (?)). But that seems way too much effort.

[sbueringer]

Just discussed this again. It's simply not worth the effort to implement and maintain the automation.

Let's just open the PRs manually.

/close

[k8s-ci-robot]

@sbueringer: Closing this issue.

In response to this:

Just discussed this again. It's simply not worth the effort to implement and maintain the automation.

Let's just open the PRs manually.

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