Binary for Linux ARM64
radu-matei opened this issue · comments
It would be great if there was a binary for Linux ARM64.
See the release workflow for how the other binaries are built and uploaded.
@radu-matei I'll take a stab at this !!
I see this issue was closed but I was looking for the linux aarch64 binary today and couldn't find it in any of the release downloads. According the release notes, it should be present in the v0.9.0-rc.1 release downloads right? Can always use the crate but just wanted to make you all aware.
uh oh, I see the builds are working fine but pushing to Azure Blob has the issue
I believe #355 should fix the blob issue.
As for the missing aarch build, I think at one point we lost the blobs and the artifacts were re-uploaded; perhaps this combination was missed/skipped somehow? cc @thomastaylor312
@vdice / @thomastaylor312 any update on this issue? Should I re-open it or file a new issue?
@jpflueger let's re-open. With the blob-store action update/fix, we should get arm64 builds on future releases but we need to figure out how to get them added to existing releases (or a subset).
Which releases would help unblock your efforts? Based on the linked context (fermyon/installer#117), perhaps a 0.8.x version is needed. One approach could be to cut a new 0.8.2 tag representing the existing 0.8.1 release with #355 added.
A 0.8.2 release is exactly what I need. We could also push a v0.9.0-rc.2 release and I could test that out as well. Not sure when the next release for bindle-server is coming but my overall goal would be to remove the bindle-server binary from the local installer and use the binaries from a GitHub release instead, following the same pattern used for hippo. Whatever is easiest for you, as long as there is a url in this form:
https://bindle.blob.core.windows.net/releases/bindle-${var.version}-${var.os}-${var.arch}.tar.gz
It would be nice if the release assets were linked to the release in a similar fashion to hippo link to hippo release just for consistency but that may be a different issue.
Thanks @jpflueger. I'll defer to @thomastaylor312 for ETA on the next 0.9.0 rc, but I can try to assist with a 0.8.2 release (#359).
It would be nice if the release assets were linked to the release in a similar fashion to hippo link to hippo release just for consistency but that may be a different issue.
I would also definitely be in support of attaching artifacts to the GitHub release itself, either in addition to or instead of uploading to Azure Blob Store. Indeed, I'd say we create a separate issue/request for this.
Re: 0.8.2: I've cherry-picked relevant CI commits into the release/0.8 branch #359 and have pushed the v0.8.2 tag; alas, I'm seeing apt failures on the release run for this event. Turns out, the same failure was seen in a recent merge event (yesterday) that I've only noticed now. So, I don't think it is a transient error and a fix will be needed on main. Then, we can cherry-pick in to release/0.8.
I need to get one more fix in before an RC2. Hoping to have time by EOW or very beginning of next week.
@vdice I have a sneaking suspicion that those apt problems are caused by the recent update on GH actions to use ubuntu 22 over 20 for ubuntu-latest
Ok, the v0.8.2 release now has links to artifacts, including the linux aarch64/arm64 binary. @jpflueger hopefully this binary is useful for your purposes.
As an aside, the publish crate step failed for the release. I'm not sure if this is known and/or if it is applicable to any tagged release (it has been awhile since our last v* release). Thoughts @thomastaylor312 ?
@vdice That is because I think we forgot to bump the version in Cargo.toml to 0.8.2 on the release branch. Should probably add that and then manually cargo publish
@thomastaylor312 thanks, that did the trick! The binaries and v0.8.2 crate look to have been published successfully.