K6: Installers / packaging

[ragnarlonn]

Create installers and packages that make it simple to install k6 for a large set of users

Imported from https://trello.com/c/rrMtv2Op/92-installers-packaging

[ragnarlonn]

Emily Ekberg
I've used InnoSetup for Windows installers before: http://www.jrsoftware.org/isinfo.php

Relevant Homebrew docs:

https://github.com/Homebrew/brew/blob/master/docs/brew-tap.md
https://github.com/Homebrew/brew/blob/master/docs/Formula-Cookbook.md
(They want you to be fairly known before getting your formula into the core.)

For Debian, we definitely don't want to cheap out and build only binary packages with some half-baked build process, that's frowned upon by debian people. We wanna do this properly.
Nov 7 at 11:00 AM (edited) - Reply - Add Link as Attachment - Delete

[liclac]

Could someone get on this?

At the very least, I want a Homebrew tap:

brew tap loadimpact/k6
brew install k6

[diego-plan9]

I have some Debian packaging familiarity (as I'm currently the maintainer of a small package with sporadic releases under the Debian Python Modules Team umbrella) that I'd be more than happy to put to good use for k6!

My main concern is about the timing, as I'd need to combine getting more familiar with go+k6 with the rest of my duties, and I'm not sure how well it would play into the release plans. Still, the main effort might not be on the purely technical front but on following the Debian packaging procedures, so maybe that concern about the time is not so pressing.

[liclac]

I'd love that! I'll gladly help out any way I can, but my experience with Debian packaging is limited to packaging another project as a PPA years ago…

[diego-plan9]

An update on the Debian packaging - as of today, the following libraries (either direct dependencies of k6 or second-level dependencies) on RFS status:

api2go, goja, goquery, null.v3, regexp2, null.v2, inflector, cascadia, dnscache, snaker

In practice it means that the core of the packaging work and procedures have been done, and the packages are awaiting to be reviewed and eventually uploaded (provided no further adjustments are required to conform to the Debian guidelines, etc) to the repository by a Debian developer.

The next steps will happen once #195 is completed and the dependency on otto is dropped, as that is when I will proceed with finally packaging k6. Unfortunately I can't give an exact timeline on when all the process would be completed, as it depends on the reviews and the Debian volunteers, but we are getting closer!

[ragnarlonn]

@liclac @diego-plan9 Shall we rename this issue so it only concerns the debian packaging? We already have a homebrew package, and I think it might be a good idea to create a new issue for the Windows installer, and then place a bounty on it.

[liclac]

👍

[liclac]

@diego-plan9 Update: #195 is implemented, otto is no longer a dependency; package away!

[diego-plan9]

Thanks, @liclac! I noticed and did some preliminary packaging tests yesterday: it seems we might need to update a couple of dependencies that were already on Debian but not recent enough for our needs in the process, but other than that is looking good - I'll update this issue when I have a more solid picture!

[diego-plan9]

An status update: all the dependencies introduced by k6 are finally sponsored and on the Debian repositories. There are still two dependencies that need to be updated (color and isatty), as they were already in Debian and updating them needed to be postponed until the freeze was over.

Which brings me to the second point: the new version of Debian will be released 2017-06-17! In practice, it means that after that date updating the two remaining dependencies should be a matter of days, and also means that we can move to using go 1.8 safely.

[robingustafsson]

@diego-plan9 Thanks for sharing, that's good news indeed! Then we should be able to move forward with https://github.com/loadimpact/k6/issues/188 soon.

[diego-plan9]

Another status update: at this moment, the dependencies for k6 version 0.17.1 are all in the Debian repositories ... except unfortunately for babel-standalone, which is the main blocker, and a pretty industrious one.

The reason is that, according to Debian policies, the babel-standalone files included in the k6 distribution are akin to binaries, and they need to be produced from the source (ie. regular node-babel), which in practice means a package that provides babel-standalone needs to be on the Debian repositories. The process for packaging it should be pretty similar to the work done for the rest of the dependencies, but due to me not being familiar with the node toolchain and intricacies, and due to the fact that there seems to be quite a number of nodejs dependencies (most of them would need to be produced by the recently packaged node-babel, I'm unsure how long it will take to finally produce the babel-standalone package.

I do intend to get them packaged eventually, but as discussed on private, an alternative would be to provide non-Debian compliant .deb files in the meantime. The gist of the work is on the alioth VCS and more details can be found on the private k6-debian repository (and I'd be happy to assist in any particulars!).