Flux: [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-packagesfluxctl'. 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.