Skip to content
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

Adds ARM arch to API docker build #1248

Closed
wants to merge 7 commits into from
Closed

Conversation

dngrhm
Copy link
Contributor

@dngrhm dngrhm commented Jul 27, 2022

Description

As a developer, I want to run the Stacks blockchain API on a Raspberry Pi or Apple Mx processor. This is needed as the amd64 docker builds run slowly. This pull request adds an ARM build to the API docker image that is pushed to the Docker hub. This should have no impact on developers of the API. The CI build will take a little longer.

Type of Change

  • New feature
  • Bug fix
  • API reference/documentation update
  • Other

Does this introduce a breaking change?

No breaking changes

Are documentation updates required?

Documentation updates are not required.

Testing information

To test, force a CI build.
Ensure that the build works and pushes an ARM build to Docker hub

Checklist

  • Code is commented where needed
  • Unit test coverage for new or modified code paths
  • npm run test passes
  • Changelog is updated
  • Tag 1 of @rafaelcr or @zone117x for review

@rafaelcr @wileyj Please review 🙏

Copy link
Collaborator

@rafaelcr rafaelcr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you!
I'd just like to see what @CharlieC3 thinks of adding this to our CI

@rafaelcr rafaelcr requested a review from CharlieC3 July 27, 2022 14:01
@CharlieC3
Copy link
Member

@rafaelcr Let's see the new build time first. It can lengthen it quite a bit since ARM has to be built inside an emulator (qemu).

@coveralls
Copy link
Collaborator

coveralls commented Jul 27, 2022

Coverage Status

Coverage decreased (-18.5%) to 57.873% when pulling b0e9c54 on dngrhm:master into edab62a on hirosystems:master.

@rafaelcr
Copy link
Collaborator

@CharlieC3 the build_publish step failed because this PR is from an external contributor 🤔 is there any other way we could test this besides recreating the changes into a new PR from us?

@CharlieC3
Copy link
Member

@rafaelcr The workflow will need to be modified so it can run from a fork, which would require a separate PR. We should have time to take a look at this next week.

@dngrhm
Copy link
Contributor Author

dngrhm commented Jul 27, 2022

The snapshots show the time increase for building with qemu. I'll look into how to shorten this up a bit. @wileyj has done some pretty amazing stuff to optimize the build for the blockchain docker images. I'll see what I can use from that.

CI build on my fork
image

Previous CI build on upstream
image

@wileyj
Copy link
Contributor

wileyj commented Jul 27, 2022 via email

@codecov-commenter
Copy link

codecov-commenter commented Aug 4, 2022

Codecov Report

Merging #1248 (db1c05a) into master (299705f) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1248   +/-   ##
=======================================
  Coverage   78.32%   78.33%           
=======================================
  Files          77       77           
  Lines       11034    11034           
  Branches     2463     2463           
=======================================
+ Hits         8642     8643    +1     
+ Misses       2279     2278    -1     
  Partials      113      113           

see 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Copy link
Member

@zone117x zone117x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great! Could we make it so that multiarch building is only performed on merges into master? An extra 30 minutes to CI for each PR is hard to swallow.

@CLAassistant
Copy link

CLAassistant commented Aug 5, 2022

CLA assistant check
All committers have signed the CLA.

@wileyj
Copy link
Contributor

wileyj commented Aug 8, 2022

This is great! Could we make it so that multiarch building is only performed on merges into master? An extra 30 minutes to CI for each PR is hard to swallow.

with QEMU, it's not that simple 😢

However, you can target which arches to build with docker buildx - for example, only build the arm64 arch when it's a release tag. else, build x86_64 as a default.

https://github.com/dngrhm/stacks-blockchain-api/blob/master/.github/workflows/ci.yml#L555-L563

I would argue this should be changed based on how the ci is triggered - setting a default env. var of linux/amd64, and if the run is a release tag, then add the arm arch.
psuedo code:

if <release tag is provided>; then
  docker_platforms="linux/arm64, linux/amd64, linux/amd64/v2, linux/amd64/v3"
else
  docker_platforms="linux/arm64"
fi

if arm builds are only performed on release tag (or some other non-common event), the build time shouldn't be a big problem since the additional time will only be added when something non-common happens.
for example you can see how i'm working this methodology into the stacks-blockchain CI:
stacks-network/stacks-core#3199
https://github.com/wileyj/stacks-blockchain/blob/feat/update-ci/.github/workflows/ci.yml

it's a little different than how the API workflow is setup, but it gives an idea of what i'm suggesting.
outside of that, i don't think it's possible to speed it up since QEMU is really slow.

I'm also skeptical of using a cache here @dngrhm - since this is a single build of a dockerfile, i'm not sure it adds anything to the workflow (unless i'm missing something). i.e. no other steps are using that cache, so it's not adding anything.

The only other thing that might possibly speed things up (but this is dubious at best, and has it's own issues) is using ramdisk to store the build files. But, there is a limit to the amount of storage available and it could result in bad workflow runs without any apparent reason as to why. There is also the fact that it may not speed things up enough to warrant using this method. I wouldn't do this, but it's an option.

@dngrhm
Copy link
Contributor Author

dngrhm commented Aug 9, 2022

Thanks for the feedback @wileyj!! I was skeptical of the cache as well. I added it as a test and haven't seen improvement from it. I removed the cache and updated the platform logic as you suggest.

@wileyj
Copy link
Contributor

wileyj commented Apr 6, 2023

Thanks for the feedback @wileyj!! I was skeptical of the cache as well. I added it as a test and haven't seen improvement from it. I removed the cache and updated the platform logic as you suggest.

oh snap, i think we have competing PR's: #1578

@zone117x
Copy link
Member

Closing in favor of #1578

@zone117x zone117x closed this Apr 20, 2023
@pradel pradel mentioned this pull request Apr 16, 2024
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants