Docker arm64 support (Apple Silicon M1) #1300
Comments
|
@felixblaschke -- What's your recommendation? What needs to happen? |
|
We need to wait for release of puppeteer/puppeteer#7099 because otherwise can't even Then we need to configure the docker image to work with arm64 linux images. The Next the built backstop docker image needs to be multi-arch build. (https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/) |
|
@garris now that step 1 that was described by @felixblaschke seems to be resolved, how can we get m1 support? who can take the next steps? |
|
Thanks @torbenberger, my question is, will the new image be backwards compatible? If the new assets will be backwards compatible then you would just need to rework the build scripts and create a pull request for me. I don't have an M1 device so I'd need you to validate the new builds. Does that make sense? |
|
@garris what do you mean by backwards compatible? not quite understanding tbh. i have an m1 mac so i could validate the new builds :-) |
|
Hi @torbenberger, sorry, my question is, will the new image continue to work on non-M1 hardware? |
|
@garris |
|
@torbenberger yes, I am not super knowledgeable about docker or M1 -- I don't want to break existing implementations so I just need someone to explain how this would work. |
|
Hi Was any progress made on this? |
|
@apswak no progress here. I am a high-level docker user -- so I would need help to understand the most compatible way I can add support for this. (This is a little baffling since I thought docker is supposed to solve the hardware abstraction problem 🤷♂️) |
|
Shoot. Just ran into this after getting a new laptop (which is going to become more common with the new MacBook Pros out) @felixblaschke any guidance you can add for updating the Docker image? |
No sorry, I use a secondary x86 device or VM to execute tests. |
|
I was able to get Backstop
Example config: {
dockerCommandTemplate:
'docker run --rm -it --net="host" --platform linux/amd64 --mount type=bind,source="{cwd}",target=/src backstopjs/backstopjs:{version} {backstopCommand} {args}',
engine: 'puppeteer',
engineOptions: {
args: ['--no-sandbox', '--disable-dev-shm-usage', '--single-process'],
}
}I didn't have luck getting |
|
@cdeutsch what error did you get with v5.4.4? |
|
@garris for |
|
@cdeutsch as a forward fix, maybe a newer version of puppeteer might address this issue? |
|
I was able to build an M1 compatible Docker image by doing the following:
Unfortunately Debian 9 uses chromium The version difference (or just the Debain version of chromium) is leading to slight differences in rendering, so this wouldn't be backward compatible; but it did render the same across an Intel versus ARM Mac. I could share the Docker Image I made for people in this scenario (after more testing) or Backstop itself could publish one using the changes above. Alternatively we'll have to wait for puppeteer to include an arm64 version of chromium. puppeteer/puppeteer#7740 |
|
@cdeutsch thank you for this workaround! I'd like to see if the puppeteer team has any response to your request before making an official BackstopJS patch (the rendering difference will likely cause some headaches) Let's give it a week or so. Cheers! |
|
@cdeutsch workaround kind of got things working for me on my Mac, however with lots of tests it just hangs after taking the last screenshot, doesn't seem to with smaller test numbers if I use filtering. Sadly it is failing completely for me on CI, not closing the browser, i.e. opens the 10 that I have set in concurrency but just sits after trying to close them all until CI times it out. |
|
@DEfusion I have I occasionally get hangs after 3 or 4 full runs. No idea why. I had similar issues using stock backstop 4.3.2 and always assumed it was the quirky frontend I was trying to test. |
I tried that locally and on CI but sadly still getting hangs on CI; stopped at 133/492 scenarios at Close Browser again. I've had issues with it hanging in the past (pre M1) when the compare limit was high locally (usually with big images to compare) and have tried to dig into Backstop to see why, guess I'll give that another look. |
|
So I've had some success by switching to 6.0.1 and playwright, the suite runs completely on my machine and CI with the below changes. Playwright seems to install its own chromium but without installing it manually in Docker it complained that it needed dependencies installing which I couldn't get to install via The change to the browser has resulting in very minor differences from text rendering but that happens from time to time anyway with browser bumps. // backstop.config.js
onBeforeScript: 'playwright/onBefore.js',
onReadyScript: 'playwright/onReady.js',
engine: 'playwright',
engineOptions: { browser: 'chromium' },
asyncCaptureLimit: parseInt(process.env.BACKSTOP_CAPTURE_CONCURRENCY || 5, 10),
asyncCompareLimit: parseInt(process.env.BACKSTOP_COMPARE_CONCURRENCY || 10, 10),# Dockerfile
- RUN echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list
+ RUN apt-get -y install chromium
- RUN npm install -g --unsafe-perm=true --allow-root backstopjs@${BACKSTOPJS_VERSION}
+ RUN PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true npm install -g --unsafe-perm=true --allow-root backstopjs@${BACKSTOPJS_VERSION} |
|
Wow -- great progress! If we make this change would this break anything for puppeteer+docker users? Maybe just rendering differences? |
|
hello, @cdeutsch , can you please share your docker file? thank you! |
|
My work got busy, but it's still on my radar if I can find time. I'm not a linux guru so figuring out the best way to get chromium to work in the docker container and still support path will be the hardest part. |
|
Is it possible to explore decoupling chromium? Using Behat and some of the other testing frameworks this hasn't been so painful, because Behat itself doesn't include Chromium. So, I can spin up a Chromium service in my docker setup and then just point Behat at that running service. I think part of the pain here comes from Puppeteer itself trying to install Chrome/Chromium from NPM and having issues due to the binary. |
|
@mikemadison13 that is what @cdeutsch did above. There are just some details which need to be ironed out wrt validating that this solution will build and run universally. Also, a question I haven't asked yet... I don't really understand why some versions of chrome won't run in a container hosted on different hardware. I thought container architecture solved this problem. Maybe there is an article someone could recommend? |
|
I did run through this same issue and I was able to overcome this issue by modifying my docker file to platform specific. Platform flag helped me to get rid of the chromium issues . Hope it may helps someone who is building using Dockerfile . |
|
Update: A list.manifest.json will be created and showing I dont know if Windows users would fetch the arm64 arch image if I only build it only for arm64, but i think so. Therefore I stumbled up on docker buildx imagetools create. (!) You can add --dry-run so you can see the output of the list.manifest first and it won't be pushed directly The command i've used was: I'm currently very busy as well, but maybe i'll try to play around to get this out of the box for all arch. When I have success I will create an MR/PR. |
|
@garris from my understanding of the issue, the changes would be totally unrelated to the current Docker image. It would be like you have separate images, they would only share the name and version number. When the build is done, the images are published with their name, version and architecture. When a current user pulls the Backstop image, they get the current image. When the M1 user pulls the image, they'd get the ARM version of the image (as in, it would be a different image). Here's some information about it: Here's an example image using separate architectures (notice the "OS/ARCH" dropdown) and here's how the GitHub actions for the image look like. The |
|
There seems to be a new version of Docker that relies on Rosetta to fix this issue (at least it fixed it for me.) My setup:
My tests run well now (albeit possibly slower than they do on an Intel Mac.) |
|
@garris If I would create a PR to include support for a multiarch docker build (amd64, arm64) - would you consider to merge that - just asking before I am going to put my free time on this ;)? |
|
@tkrah Thank you so much for the offer here. Yes I would consider this -- but I would want to understand the impact... I have a very simple build & deploy process -- would like to understand what kind of changes I would need to make on my end -- for example, I assume I would have to push multiple docker builds etc. But also -- and possibly more important, @ukrutt mentioned here that simply bumping versions resolved the issue. Was wondering if you had tried this and what were the results? |
|
ukrutts solution does not help, it is still emulated with rosetta and still too slow to be useful if you want to have acceptable runtimes with many tests, a native image is the solution to the problem. |
|
Can someone here with an arm64 platform try to build the image and confirm it is functional? @felixblaschke or @torbenberger maybe? Edit: I got an owner of a arm64 M1 to test that image and got a positive answer, but it does not harm to have multiple success reports. |
|
Has the docker-image been updated to reflect the latest change? From what I can tell, https://hub.docker.com/r/backstopjs/backstopjs/ was last updated 5 months ago. Seeing this was merged 5 days ago, I'm going to assume that the currently hosted image doesn't include these changes yet. |
@FinnBueno No of cause this is not yet released, it was merged yesterday btw. @garris is working on that I assume for version 6.2.0. |
My bad, I now see that it was indeed merged yesterday. I asked because me and my team actually hit this roadblock today and I was very glad to see a solution was just merged. I'll be trying to run this with a self-built image for now, thanks! |
What a lucky coincidence that I did that PR last week 😂 I hope it works for you and your team. |
|
I can confirm that I am indeed working to get @tkrah 's solution out -- I hope to push new docker builds out tomorrow morning before my day explodes 😅 |
|
📣 New docker arm64 support for Apple Silicon has been deployed! Many thanks to @tkrah for this fix addressing the issue dating back at least 2 years! Please post your results here if there are any issues. Cheers! |
|
@garris can be closed here imho - people open new issues anyway already ;-). btw you missed to create or push the 6.2.0 tag. |
|
Thank you. Yes, I will push a new version soon. |
The currently available docker images are only available to amd64 architecture:
https://hub.docker.com/r/backstopjs/backstopjs/tags?page=1&ordering=last_updated
Soon Apple will change to architecture of all Macbooks to arm64. The current Macbook Pro 13 inch is already available with the M1 processor.
Therefore we need backstopjs images that are compatible with arm64.
The text was updated successfully, but these errors were encountered: