kubefirst 2.3.5

[claywd]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[claywd]

Any guidance you can give on the following would be super appreciated.

 Already downloaded: /github/home/.cache/Homebrew/downloads/482f67d791f1a6d4b4f00eb38995ba722b9e3f9b1bb0739c2a5580d46408e1cb--kubefirst-2.3.3.tar.gz
  ==> Verifying checksum for '482f67d791f1a6d4b4f00eb38995ba722b9e3f9b1bb0739c2a5580d46408e1cb--kubefirst-2.3.3.tar.gz'
  Error: kubefirst: SHA256 mismatch

[chenrui333]

Minitest::Assertion: Expected /v2\.3\.3/ to match "".

[claywd]

still working on this. Not expecting linuxbrew to succeed

[claywd]

Not sure why this isn't working in the test but locally on my linux host the flags seem to be working find. What's the best way to replicate the test locally for linuxbrew?

[p-linnane]

brew test --verbose --debug kubefirst. You can open a shell by pressing 5 after it fails and investigate.

[claywd]

So I started testing by installing using the recipe and --build-from-source and... it doesn't work with the recipe but it works when I used the commands from the recipe in my shells. Tested on linux and macos. if I provide the ldflags, it builds fine and the version is displayed as expected, but not when I run the recipe even though the commands I'm running match the recipe.

[Bo98]

I can reproduce the same issue with the binaries at: https://github.com/kubefirst/kubefirst/releases/tag/v2.3.5, so this seems like a regression upstream.

[alebcay]

I'd like to add, when building locally, I experience the hanging issue with any kubefirst invocation, including just kubefirst or kubefirst --help.

[alebcay]

Is this really ready to merge? The formula has been modified to remove all the bits that caused the hanging, but from what I can tell the hanging still seems to be an issue for any end user.

[p-linnane]

Is this really ready to merge? The formula has been modified to remove all the bits that caused the hanging, but from what I can tell the hanging still seems to be an issue for any end user.

My apologies. I didn't see your other comment about the additional hangs.

[claywd]

lgtm @p-linnane The hanging is something we are going to address on a per command basis as there are times when we actually do want the terminal to hang for experience reasons. Our product just underwent its biggest architecture shift simulataneously with its biggest feature release since its inception and will have more iterations to fine tune the user experience. I think this is ready to merge as is.

[claywd]

@alebcay can you approve?

[Bo98]

So just to confirm: shell completions which is being removed here is intentional and will no longer be supported?

[alebcay]

Please confirm this @k8swrangler, due to the hanging issue we cannot ship completions out of the box. Users will have to run kubefirst completion > some_file.sh and Ctrl + C on their own after installing.

[Bo98]

To clarify: kubefirst completion doesn't generate the files. The user would need to pipe that to the appropriate locations and hit Ctrl+C.

[alebcay]

Thanks, edited my comment to make that clear.

[claywd]

Shell command completion is one of those things that is almost never used in our app so it's not a priority. This cli is more an initial interface to the actual app which has grown beyond the cli

[alebcay]

Apart from Bo's comment/question which should be addressed, I'm 👍 with this (with the understanding that end users may be negatively impacted) as long as we get an issue opened upstream and link to it from this PR or from the formula. It allows contributors/maintainers here to remember that we ran into this and track resolution (can hopefully add completion generation back then), and gives us a place that we can point end users to for root cause.

[claywd]

Apart from Bo's comment/question which should be addressed, I'm 👍 with this (with the understanding that end users may be negatively impacted) as long as we get an issue opened upstream and link to it from this PR or from the formula. It allows contributors/maintainers here to remember that we ran into this and track resolution (can hopefully add completion generation back then), and gives us a place that we can point end users to for root cause.

I think what I'm getting at is that shell completions for this cli are not valuable to us. Would be better to let it die rather than open an issue and track a feature we will probably never reimplement.

[alebcay]

I've opened konstructio/kubefirst#1902 so that we have a place to point any further user concerns/feedback to.

[github-actions]

🤖 An automated task has requested bottles to be published to this PR.