Add support to publish Snaps using goreleaser

[mhalano]

Add support to publish Snaps using goreleaser

Closes #351

[mhalano]

I need to do some review in the code. I think I will need a special authorization to use the classic confinement instead of strict one. I already submit the request and if and when I get it, I will do changes in the code. Please stay tuned.

[ahmetb]

Any updates?

[mhalano]

Any updates?

@ahmetb No updates yet. I need what we call a 'classic' confinement to snap, but it has been a little hard to get an answer about my request.

[mhalano]

@ahmetb Just to keep you on the loop: I'm still working on it. They answer me back some days ago, and now I'm trying to a new line of action to be approved. Permissions with Snap can be hard, but I think I will make it. Stay tuned.

[mhalano]

@ahmetb The process to get (or not) the final approval for classic confinement is almost done. I already submitted a version with the classic confinement to the store, and I will make the final code and submit the PR to your repo ASAP.

[mhalano]

@ahmetb Everything is now in place. I got the approval I needed, and now the PR is complete. We can discuss further how to deploy Snaps automagically as part of the pipeline, together with the other assets.

[ahmetb]

Thanks. How do we do that? Is that something Goreleaser does or we need to authenticate and upload a different way?

[mhalano]

We can use GitHub Actions. Do you already use it to publish the assets?

[ahmetb]

@mhalano yeah, we upload to GitHub Releases using GitHub Actions. What's involved here? Do we need to call an external API to upload assets?

[mhalano]

We need the command snapcraft in the PATH of builder (container or VM) so it can build the Snapcraft. I will look about more details how to add a step to publish the .snap file generated by the Goreleaser.

[mhalano]

I sent to your email an invitation to manage with me the Snap in the Snap Store.

Here there is a build system in place integrated with GitHub, but the problem it demands a snapcraft.yaml, so we need to take the long way and do the commands manually to use snapcraft to login and push the assets.

[mhalano]

Here it is a very interesting page about a GitHub Action that could solve the problem. What do you think?

[ahmetb]

so we need to take the long way and do the commands manually to use snapcraft to login and push the assets.

At that point I might question do we actually need this distribution method. So far I am spending zero effort on releases in the upstream repo and anyone packaging this software in apt/yum like repos are regularly picking up the releases from here.

very interesting page about a GitHub Action that could solve the problem

Yeah, if we can't automate it with a GitHub Action then we probably should leave it out of this upstream repo. I'm happy to add a token or whatever to GitHub repo secrets, but you should probably first test this on your fork and send the changes here.

[mhalano]

@ahmetb I added a commit that adds the Snapcraft to the build system, and now it's building correctly. I just got a problem with bats execution in my local machine because absence of assets. Can you help me with that, triggering your pipeline?

[mhalano]

I think it's done. You will need to create an Ubuntu SSO account and to install snapcraft tool to get the token with this command:

snapcraft export-login --snaps kubectx --channels "edge stable" --acls package_upload -

When you execute this command, it will open a webpage to login with your Ubuntu SSO account. That should be a no brainer.

Then you have to create a secret called SNAPCRAFT_TOKEN.

[ahmetb]

I just got a problem with bats execution in my local machine because absence of assets.

you should be able to run bats locally or in your fork. maybe things broke since the last time we ran it.

[ahmetb]

@mhalano I've started to think this alternative approach:

What if you had a separate ~empty repository where you have a GitHub Action that runs once per day to see if there's a new tag on ahmetb/kubectx (by keeping track of last seen version in git), and when there's a new release, you'd wget the published assets and upload a snap release from your repo? That way:

1. we keep build times low in this repo
2. we don't have to maintain per-distribution-method details in the upstream repo (I don't think we have any today, despite kubectx is packaged for many package managers)
3. you can better manage what goes to Snap (description, versions etc) by taking me out of the loop as you'd be the packager.

Executing on this possibility probably depends on what goreleaser spits out here and whether you can repeat the same functionality on a separate repo.

[mhalano]

@ahmetb I really like the way we are going to. I think the use of Goreleaser is a nice approach and in the future we could have packaging for other formats. I think this is important because sometimes if you depend on distro-packaging, like in kubectx case, to get the software installed nicely, using a package management solution, you probably need to sit and wait, dying in the process. I created the Snap version because I use kubectx/kubens and like them a lot, but Debian still didn't package and Ubuntu neither. Snap is nicer because is cross-distro and easier to create than Flatpak

[mhalano]

I just got a problem with bats execution in my local machine because absence of assets.

you should be able to run bats locally or in your fork. maybe things broke since the last time we ran it.

The problem seems to be the directory name. The directory present inside dist/ is called kubectx_linux_amd64_v1 with _v1 in the end.

[ahmetb]

Ah it seems like goreleaser itself has changed. No idea where that _v1 comes from. master branch's probably broken too.

[ahmetb]

opened https://github.com/goreleaser/goreleaser/issues/3192 to track the binary name change issue, but feel free to send a PR to master pinning goreleaser version to 1.7.0 for the time being.

[mhalano]

@ahmetb I added a commit to change Goreleaser version from latest to 1.7.0 and at least the CI pipeline worked flawlessly (I didn't try the release pipeline). I read the answer for your Goreleaser issue and it seems a quite tricky problem to solve. Not impossible, just tricky.

[mhalano]

Hello, I saw you released a new version and now I'm working to rebase my changes on it and also release a new version on Snap Store.

[mhalano]

@ahmetb please review my final PR. I also released on Snap Store the version 0.9.5 of kubectx.

[ahmetb]

Thanks for the patience here. It’ll go out with the new release, hopefully not too far from now.