[windows] Publish fluxctl on chocolatey

[dholbach]

As fluxctl builds on Windows (cf #1214), and chocolatey.org was mentioned multiple times, it'd be great if we could publish it there as well to make it more accessible.

@geofflamrock indicated interest in taking a look. Anyone else?

[JimPruitt]

Not to step on anyone toes here, but I ran across this and decided to give it a go. The package is currently pending a review. https://chocolatey.org/packages/fluxctl/1.8.0

[dholbach]

Nice work, @JimPruitt! Please let us know how things go!

I have a couple of questions. Do you know more about this? What's the process for

• Uploading the package? Is it just a matter of taking the binary from the release page and uploading it to chocolatey.org? Can this be done my multiple people? Can this maybe even be automated?
• Downloading/installing it, so we can document it?

[JimPruitt]

Thanks @dholbach! Sorry if this is too verbose...

I should explain how this works. The choco package I built downloads the latest build from Weavworks and then installs that binary with a 'shim' that allows the command to be added to the PATH environment variable. So what I uploaded to chocolatey wasn't so much the fluxctl.exe, but instead was a .nupkg file that has the logic on where to download the file, check it against a sha256 checksum and then 'shim' the downloaded executable so that it's available from the command line.

Uploading Packages
As far as uploading packages, packages are submitted to Chocolatey.org and the guidelines and processes for submission are here: https://github.com/chocolatey/choco/wiki/CreatePackages . One of the guidelines states that the source code for the package should be publicly available. However, even with that in place, the package won't be trusted by the Chocolatey community if someone like me (an independent contributor) hosts and maintains the code. If the package came from Weaveworks itself then it's more 'trustable'. So, It would be better if Weaveworks assumed control of the code for building this package. (Perhaps then you're also likely to see more contributions.)

You're more than welcome to take what I've done here and host the code out of Weaveworks Github project if you wish. (My intention here was just to contribute to this really cool project!) I can do a PR for this if that helps?

Downloading/Installing
The code for building this package is kept here: https://github.com/JimPruitt/chocolatey-packages , and this particular package is encapsulated into a folder called 'fluxctl'. Here are the steps for getting up and running:

1. Install chocolatey on your build machine (see https://chocolatey.org/docs/installation on how to do this). You can build on Windows machines and (even better) Debian. (I assume a preference)
2. clone the repo at https://github.com/JimPruitt/chocolatey-packages
3. change your working directory to 'chocolatey-packages\fluxctl'. You should be in the same folder where the fluxctl.nuspec file is kept.
4. Type choco pack at the command prompt. This will build the .nupkg file (fluxctl.1.8.0.mupkg).
5. This .nupkg file is what you upload to chocolatey.org. But in order to do so, you'll have to register for an account (and get an API key - details at https://github.com/chocolatey/choco/wiki/CreatePackages)
6. Once you log in to chocolatey.org you can click 'upload' at the menu to upload the .nupkg file.

Automating/Testing
You also had asked 'can this be automated'? If you are talking about automating the build and automatically testing it - yes that can be achieved via something like a Jenkins pipeline and using Vagrant to automatically test the installation/uninstallation of the package as well as have it run a virus scan. (I believe this is what Chocolatey.org does as well.) This is where building on debian is especially useful.

[dholbach]

This is great stuff - thanks again @JimPruitt.

[dholbach]

It looks like https://chocolatey.org/packages/fluxctl/1.8.0 was approved - great job @JimPruitt!

What do we want to do next? AFAICS there's:

• 1.8.1 which was just released.
• We could move the relevant bits from https://github.com/JimPruitt/chocolatey-packages into the weaveworks/flux* namespace.
• Open maintenance on chocolatey.org up to the flux maintainers team too.
• Document in fluxctl.md.
• Look into automating the process.
• Add this to the flux release process.

I'm not sure if all of this makes sense and if we want to do this all as part of this issue. Please let me know what you think.

[JimPruitt]

Sorry for my delayed response. (was away from home over the holiday weekend) I'm in agreement with everything you had stated above.

I can start by creating a PR for the above (although I'm not sure how to organize my code offering in the flux repository).

I'll start with a top level folder and get feedback on the PR from there.

[dholbach]

Thanks Jim! Hope you had a great weekend.

I'm not quite sure what to respond in terms of the final place where the build files should live, but I started a discussion about it here: https://weave-community.slack.com/archives/C4U5ATZ9S/p1543305536162900

[JimPruitt]

Just bumping this old thread here. I've had to step away from this for a while to catch up on other efforts. I have updated the Chocolatey package that's published to Fluxctl V 1.9.0. (It's currently pending review) I'm still working on a way to automatically test this (using BoxStarter) such that my Github repo can be incorporated into the Weaveworks namespace. I'll keep working on this as time allows.

[chrisfowles]

Ran across this when checking if someone was planning to update the install doco. https://chocolatey.org/packages/fluxctl is a trusted package now. Can we update the doco to make it easier for windows users to install?

[dholbach]

Sure. Can somebody send a PR to https://github.com/fluxcd/flux/blob/master/docs/references/fluxctl.md with the relevant steps and links?

[chrisfowles]

No worries @dholbach - I'll take care of that today.

[kingdonb]

I can see that https://chocolatey.org/packages/fluxctl/ lists the nearly-latest version of fluxctl and is being updated somehow, although it does not reflect the latest release from a few days ago.

This is not a high priority to fix, as there are still zero changes in fluxctl 1.21.2 itself; I just want to understand the release process for chocolatey a bit and whether there is something I should be doing to ensure chocolatey gets updated as well?

(The fluxctl binary in homebrew by comparison is apparently updated by CI, or by some other process that feeds from it.)

[JimPruitt]

I can see that https://chocolatey.org/packages/fluxctl/ lists the nearly-latest version of fluxctl and is being updated somehow, although it does not reflect the latest release from a few days ago.

This is not a high priority to fix, as there are still zero changes in fluxctl 1.21.2 itself; I just want to understand the release process for chocolatey a bit and whether there is something I should be doing to ensure chocolatey gets updated as well?

(The fluxctl binary in homebrew by comparison is apparently updated by CI, or by some other process that feeds from it.)

Currently, the Chocolatey package itself is updated via a k8s job that is run manually. The job itself merely detects whether or not a new fluxctl release has been posted, then updates the Chocolatey package code to reference the new release, and finally submits a pull request to the Fluxctl Chocolatey Github project.

The process of building the .nupkg file and testing it is still a manual process.

At one point there was talk about automating this entire process as part of the fluxctl build; however, it was never seen through to completion. While, building the new chocolatey package is trivial enough, a build validation would need to occur test the installation of that package.

Chocolatey has released a test environment that could be used to test the package locally (before submission to Chocolatey.org); however, the following discussion we had on the matter seemed to indicate that using Vagrant (as required by the test platform) might not be compatible with the existing build process for FluxCtl.

I am certainly happy to reopen the discussion on how to incorporate the Chocolatey package update process (and test process) into the Fluxctl build and code-line (as it would make more sense to have this maintained by the project itself - as opposed to an independent maintainer).

Alternately, I don't mind maintaining the package during the interim.

[kingdonb]

That's fascinating. Thank you for explaining the situation. I don't have the bandwidth to pursue this myself at the moment though I'd be happy to review and merge a PR for it, but as the process is not fully automated for now (sounds like it is mostly automated) and as someone must remember to do it

I'm going to keep this issue open to memorialize the state of affairs and this decision (at least until we can say it's finished.)

[kingdonb]

I just noticed this: https://community.chocolatey.org/packages/fluxctl

It's current and up to date, and the modern Flux v2 is also being maintained thanks to @JimPruitt, with ongoing discussion about the maintenance and upkeep at:

• Request: Please add chocolatay installation for flux2 for Windows flux2#1440

(https://community.chocolatey.org/packages/flux)

Thanks so much for this!