-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Release to build arm64 image #216
Conversation
@@ -167,3 +203,4 @@ jobs: | |||
username: ${{ secrets.DOCKERHUB_USERNAME }} | |||
password: ${{ secrets.DOCKERHUB_TOKEN }} | |||
tags: latest,${{ steps.version.outputs.number }} | |||
platform: linux/amd64,linux/arm64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the Dockerfile only adds the authn-linux64 binary. You may need to make both binaries available in the build context and then somehow use ARG TARGETPLATFORM
to add the correct one?
- uses: actions/upload-artifact@v2 | ||
with: | ||
name: authn-linux64arm | ||
path: dist/authn-linux64arm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you might be able to verify the linux64Arm
step by running it in your fork, grabbing the artifact, and making sure it executes as expected
@cainlevy, I'm going to close this PR due to the complexity of automating an arm64 build on Github's amd based runners. Basically what I've found is that I'll have to use Qemu + docker buildx to do the actual build. On my intel mac, this takes nearly 10 minutes. Then to fit into the current build pipeline without major refactoring, you would have to extract the built authn binary from the image and upload as an artifact. One route that I found that would help built time is using buildJet to get an ARM runner, but this is a paid service. To work around this, I'm going to build our keratin images by hand and store in our own ECR, and when we need to update I'll update the image. If/when Github gets their act together and adds ARM runners, I might reopen and finish the implementation. Thanks, |
Understood! GitHub really does need better runners. |
@xcskier56 have you looked much at what the cost would be for the BuildJet runners? I have enough interest in ARM image availability I might be willing to sponsor, especially if it's pure pay-per-minute since we don't release that often. Self hosting ECR is enough of a pain I think offering an official ARM image could be a worthwhile addition. |
@AlexCuse, it's been really cheap. I don't know how long a build takes, but if its in the 3-5 minute range, it'll be 1-2 cents per release. Buildjet was super simple to setup and get working. There may be a few cache oddities if you want to optimize, but was quick and cheap to do |
If it's that cheap I may look into getting signed up over next few weeks. I could probably use their runners for some other projects too. There aren't a ton of weaknesses for GitHub CI but this one makes me pull my hair out. |
It is really cheap and took me like 5 minutes to get it running.
The place you'll likely run into issues is making sure Go is installed on the machine. We use Ruby installed directly on the runner which took me a bit to get going. However, if you use a docker image for building then this might just work. One other thing I ran into is that sometimes Docker hub rate-limits pulls for buildjet. All you have to do is add some credentials so that you're not pulling images anonymously. This is in their documentation |
This was a quick PR that I'm very positive will NOT work but should be a starting point for discussion. @cainlevy please let me know of any updates I should make.
Thanks!