Package CLI plugin with krew

[dhiltgen]

See https://krew.sigs.k8s.io/docs/developer-guide/distributing-with-krew/

[mikeroySoft]

https://github.com/mikeroySoft/krew-index Looks like we just need to submit a PR from there to the krew-index upstream once buildkit-cli is live

Looking for input on Caveats and anything else I'm missing or got wrong in the .yaml https://github.com/mikeroySoft/krew-index/blob/master/plugins/buildkit-cli.yaml

[mikeroySoft]

That said, do we want to maintain the buildkit-cli.yaml in this repo somewhere?

[mikeroySoft]

Looking at perhaps using this to automate things: https://github.com/marketplace/actions/krew-plugin-release

[Vad1mo]

Looking at perhaps using this to automate things: https://github.com/marketplace/actions/krew-plugin-release

There is now https://github.com/rajatjindal/krew-release-bot

Any chance we might help you to get the buildkit-cli-for-kubectl available as a krew plugin?

[dhiltgen]

Good question @Vad1mo. @mikeroySoft how's your investigation coming?

[mikeroySoft]

Well I've got builtkit-cli.yaml written and that is working for me locally. What I'm a bit unsure of is where it should belong within this repo. I haven't started trying the krew-plugin-release GitHub action yet tho, but I'm happy to once we figure out where the plugin code should live.

[dhiltgen]

I haven't investigated this, but from a very quick perusal of what manifests look like, it seems like it has to be generated when we do a release so it has the right checksums and version strings. The current release process is documented at https://github.com/vmware-tanzu/buildkit-cli-for-kubectl/blob/main/docs/release.md

I think it probably makes sense to implement this in the Makefile so that make dist creates the manifest aligned with the artifacts it's producing. That way you can test locally to ensure it works properly before submitting a PR. Ultimately the release.yaml file calls this build target and overrides the VERSION with the specfied version from the git tag that triggered the release.

[mikeroySoft]

Sorry for not making much progress here... I picked up the ball and got looking into it again, and an approach that was suggested to me would be that right after the build step , we could add a step like the following to get the checksums and add them as outputs, using the ::set-output syntax, something like this:

 - name: Generate checksums
      id: checksums
      shell: bash
      env:
        VERSION: ${{ steps.get_version.outputs.VERSION }}
      run: |
        echo "::set-output name=darwin::$( shasum --algorithm 256 darwin-$VERSION.tar | cut -f1 -d ' ' )"
        echo "::set-output name=linux::$( shasum --algorithm 256 linux-$VERSION.tar | cut -f1 -d ' ' )"
        echo "::set-output name=windows::$( shasum --algorithm 256 windows-$VERSION.tar | cut -f1 -d ' ' )"

We could then consume those outputs (steps.checksums.outputs.darwin, steps.checksums.outputs.linux, steps.checksums.outputs.windows) in a separate step to update the buildkit-cli.yaml.

Still unclear where buildkit-cli.yaml should live tho. I'm sure there's an example I just haven't seen yet tho.

@Vad1mo, would rajatjindal/krew-release-bot work in concert with that, or instead of it?

[dhiltgen]

We could implement this as discrete steps in the github CI plumbing, but my suspicion is that might be more complicated that way.

If we check in a templatized file called ./buildkit-cli.yaml.tmpl at the top of the tree that looks something like this (shortened for brevity)

apiVersion: krew.googlecontainertools.github.com/v1alpha2
kind: Plugin
metadata:
  name: build
spec:
  version: %%VERSION%%
...
  platforms:
  - selector:
      matchLabels:
        os: darwin
        arch: amd64
    uri: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl/releases/download/%%VERSION%%/darwin-refs.tags.%%VERSION%%.tgz
    sha256: %%DARWIN_HASH%%
    bin: kubectl-build
  - selector:
      matchLabels:
        os: linux
        arch: amd64
    uri: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl/releases/download/%%VERSION%%/linux-refs.tags.%%VERSION%%.tgz
    sha256: %%LINUX_HASH%%
...

then update the dist target in the Makefile to look something like this...

...
.PHONY: dist
dist: $(CI_BUILD_TARGETS) $(CI_ARCHIVES)
    sed -e "s/%%VERSION%%/$(VERSION)/g" \
      -e "s/%%DARWIN_HASH%%/$$(shasum --algorithm 256 ./bin/darwin.tgz)/g" \
      -e "s/%%LINUX_HASH%%/$$(shasum --algorithm 256 ./bin/linux.tgz)/g" \
      -e ... \
      ./buildkit-cli.yaml.tmpl > ./bin/buildkit-cli.yaml

A major benefit of the above approach is you can test locally without having to iterate through CI on your PR. (We can make it fancier later with further makefile magic to make the set of platforms more dynamic and tied to $(CI_ARCHIVES))

With that then I think you just need one added block in the release CI to publish that artifact as well.

[mikeroySoft]

okay, making progress.. I've got the makefile updated and sed is working now... the '/' delimiter was causing some issues apparently, sed would fail at the second -e: sed: 1: "s/%%DARWIN_HASH%%/97f9d ...": bad flag in substitute command: 'b'

after some head scratching and stack overflowing, I changed the delimiters to ~ and now everything succeeds.

I'll submit my PR for that shortly and have a look at the release CI workflow.

[mikeroySoft]

okay, PR is submitted, 2 commits… one is for the makefile to update the buildkit-cli.yaml based on the .tmpl during ‘make dist’ which works locally… The other is to automate the submitting of the plugin to krew-index using github actions… seemed fairly straightforward, but I’m not sure how to test the github action step.

They work independently, but the releaser seemed pretty trivial so I’m hoping it makes sense to keep both, but maybe it's clutter.

https://github.com/vmware-tanzu/buildkit-cli-for-kubectl/pull/72

[mikeroySoft]

Initial PR submitted to get v0.1.2 into krew-index so we can automate going forward: https://github.com/kubernetes-sigs/krew-index/pull/1105