publish arm64 builds in linux repos

[mstoykov]

We now run tests and build arm64 binaries of k6, but don't have deb or rpm packages.

Original report from the community forum

[adeniyistephen]

@MStoykov Hi, nice issue, can I contribute to this? basically, I think what needed to be done here is to create a deb or rpm package for the binaries right? please kindly provided pointers.

[imiric]

Hi @adeniyistephen, thanks for your interest in working on this.

The way forward would be to add RPM/DEB arm64 package building to build-release.sh, and change the CI workflow to pull the packages from the build artifact and pass it to the k6packager Docker image, possibly changing some of the packaging scripts.

Since the k6packager image and package hosting is managed privately by us, this would be difficult to test for an external contributor. So in this case it would be better if this is done by an internal member of the team, sorry.

But you're welcome to contribute to some of the other open issues. See the good-first-issue and upcoming hacktoberfest labels.

[svenwal]

Want to push this. Since the new MacBook Pro is out the need for k6 on ARM is increasing dramtically

[na--]

@svenwal, we already have an ARM Mac (and Linux, for that matter) version of k6, see the *-macos-arm64.zip assets in our releases: https://github.com/grafana/k6/releases/tag/v0.35.0

FWIW, homebrew also appear to build a version for ARM: https://github.com/Homebrew/homebrew-core/blob/master/Formula/k6.rb#L9-L10

This issue is about having automated Linux .deb and .rpm packages in https://dl.k6.io/ with the arm64 linux version. And we'll probably accept a PR with this, if someone wants to contribute it.

[blankenshipz]

I just ran into this issue; I'm trying to build a docker image on an M1 that installs K6 and the architecture isn't supported.

@na--

Is this change as simple as adding arm64 to this line? https://github.com/grafana/k6/blob/master/packaging/bin/create-deb-repo.sh#L52

[na--]

I haven't looked at it in detail, so I can't be sure, but I imagine there's more to it... @imiric, any thoughts?

@blankenshipz, for an arm64 docker image, you don't really need rpm or deb packages though. You can build k6 from source like we do in our official Dockerfile, just add GOOS=darwin GOARCH=arm64 as we do in the arm64 builds we upload to GitHub.

[imiric]

For that DEB script, that's likely the only change, but we'd also want to do it for RPMs.

Like I mentioned above, since this is an internal release process, it would be difficult for an external contributor to test it, so we should eventually prioritize it.

In the meantime, like Ned says, you can download our arm64 build from the releases page, or build your own with the GOOS/GOARCH env vars.

[clouedoc]

For information, this is still a problem as of today. I want to include k6 in my devcontainer; so I'll have to add different installation steps depending on the architecture of the consumer.

[dmartin]

We also install k6 into a devcontainer, and had to stop using the deb package in order to support arm hosts. While it'd be nice to have the packages available on both architectures, here is the relevant part of our devcontainer Dockerfile for now:

# syntax=docker/dockerfile:1

ARG TARGETARCH
ARG K6_VERSION=0.45.0

RUN wget -q -O k6.tar.gz "https://github.com/grafana/k6/releases/download/v${K6_VERSION}/k6-v${K6_VERSION}-linux-${TARGETARCH}.tar.gz" \
  && tar xzf k6.tar.gz \
  && mv k6-v${K6_VERSION}-linux-${TARGETARCH}/k6 /usr/bin/ \
  && chmod +x /usr/bin/k6 \
  && rm -rf k6-v${K6_VERSION}-linux-${TARGETARCH} \
  && rm k6.tar.gz

[clouedoc]

@dmartin thanks for sharing your solution 👀

Here is mine; it's a few lines written in a setup.sh that devcontainer.json launches after creation:

## k6 installation -- arm machines
if [ "$(uname -m)" = "aarch64" ]; then
	K6_TAR_LINK=https://github.com/grafana/k6/releases/download/v0.45.0/k6-v0.45.0-linux-arm64.tar.gz
	curl -OL $K6_TAR_LINK
	tar -xzf k6-v0.45.0-linux-arm64.tar.gz
	sudo mv k6-v0.45.0-linux-arm64/k6 /usr/local/bin/k6
	rm -rf k6-v0.45.0-linux-arm64*
else ## k6 installation -- other architectures (pray that it works)
	sudo gpg -k
	sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
	echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
	sudo apt-get update
	sudo apt-get install k6
fi

I didn't really test the non-arm version, so it might actually require to put a -y here and here... Your mileage may vary.

[cwegener]

Since the k6packager image and package hosting is managed privately by us, this would be difficult to test for an external contributor. So in this case it would be better if this is done by an internal member of the team, sorry.

Any news on an internal resource starting to work on this?

I know people like docker stuff ... but OS packaging still exists too.

[mstoykov]

If we work on something there is usually open PRs or have further discussions. We also do look at thumbs up - so there isn't a need to comment :)

If someone wants I guess you can try to figure out what will be required so that you can help us - but ultimately I would argue this isn't particularly high in the priority list.

[cwegener]

Without being able to see what the k6packager does, I don't think it makes sense for me to do any work on this.

If there's no realistic timeline for this feature, can you close this issue instead then?

[mstoykov]

Without being able to see what the k6packager does, I don't think it makes sense for me to do any work on this.

@cwegener if you search for k6packager you will find it is build in a github action and then used again in the docker-compose it is build from. Practically everything you want is in the folder packaging or as part of the build workflow which also haves all the packaging and release stuff.

If there's no realistic timeline for this feature, can you close this issue instead then?

if that was how project closes issues - most issues will be closed and then reopened all the time.