Closed fhoeben closed 8 months ago
jamesmortensen
commented
8 months ago Hi @fhoeben I attempted to do a test deploy from your branch, but I forgot that secrets in CircleCI are not available in forks. You can ignore my "deploy trigger" commits, or just roll them back. They shouldn't have any impact on anything you're doing.
I'm going to try to pull your changes directly into a test branch in docker-seleniarm so we can try a test deploy.
fhoeben
commented
8 months ago @jamesmortensen please note that I did not look at the deploy setups in the circle ci files yet. They will probably be broken as they refer to 'multi-arch targets' not present in the Makefile.
I think we should be able to just take the images created in the build job, combine them into a manifest files and push those, without the need to build anything or so in the final jobs. But I have to brush up on my docker CLI, but I see that it is now possible to build manifest locally. So we should be able to setup the job to everything but push the images and manifest removing the need to have access to any secrets to check the process.
jamesmortensen
commented
8 months ago The CircleCI build file should be functional. I made a deployment in September. It doesn't use what's in the Makefile due to the complexity of the build process. Instead, it relies on various shell scripts for reasons I probably won't be able to explain in detail at the moment, but mostly it's because I found it easier to debug if I can run the build process outside of CircleCI in order to debug it better. Also, keep in mind we support armhf (raspberry pi), there's also release notes generation, multiple tagging of images, and a lot of other supporting elements existing in the CircleCI configuration.
The job that does all the work is "deploy-multi-arch-full-grid". To keep the build process from taking too long, it's been setup to do a lot of the build process in parallel. If the build takes longer than 60 minutes, it will fail.
The build can only be triggered by a maintainer, because it relies on secrets, so you won't be able to trigger anything from a fork of docker-seleniarm. I'm trying to figure out how to do that. I tried force pulling your code into docker-seleniarm in a branch, but I ran into conflicts doing so since I think that may be based on docker-selenium instead of docker-seleniarm.
Ideally, we should use your research to find out what's wrong with the docker-seleniarm trunk, so that we understand the impact of changes and don't lose any functionality that's already in the build process. Are you able to build images locally and push them somewhere so we can manually validate them? I was working on replacing Debian with Ubuntu in the "ubuntu-base" branch before I got busy with relocating to the US.
I'm also going to attempt to do a release with Selenium 4.10, so that at least browsers can be updated.
Hope this helps, James
On Mon, Dec 18, 2023 at 1:31 AM Fried Hoeben @.***> wrote:
@jamesmortensen https://github.com/jamesmortensen please note that I did not look at the deploy setups in the circle ci files yet. They will probably be broken as they refer to 'multi-arch targets' not present in the Makefile.
I think we should be able to just take the images created in the build job, combine them into a manifest files and push those, without the need to build anything or so in the final jobs. But I have to brush up on my docker CLI, but I see that it is now possible to build manifest locally. So we should be able to setup the job to everything but push the images and manifest removing the need to have access to any secrets to check the process.
— Reply to this email directly, view it on GitHub https://github.com/seleniumhq-community/docker-seleniarm/pull/57#issuecomment-1859691703, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKBH2HK4ERCV5VWFN3SDQLYJ7WOVAVCNFSM6AAAAABAYQAAKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJZGY4TCNZQGM . You are receiving this because you were mentioned.Message ID: @.***>
fhoeben
commented
8 months ago Indeed I based my branch on the seleniumHQ repository as I wanted to build images with as minimal changes to their codebase to keep tracking them easy. I also got a comment from them they hope to incorporate arm builds into the main project in the near future, so I wanted to be as close to that as possible.
I did see the armhf support, but I didn't spend time on that (yet), so for now in this branch it is only arm64 and amd64. I also didn't keep the Makefile changes from your branch, there was quite a lot and so far I needed almost nothing of it to get the images (that was what I was referring to when I said the make targets are not available in my branch)
I was wrong about being able to generate manifests locally, that really does require images to be pushed to a registry beforehand. (As I saw in the build of my last commit)
I could push the images I build locally to docker hub, but that would only get us arm64 images. What I did instead is have the build mark the generated image tarballs as artifacts. So you can obtain the images by downloading the two tarballs and importing their images (that part of my last commit does work, although it gets them from cache instead of the artifacts):
I think I can update my branch so that a copy of yours (with access to the secrets) would be able to generate the manifest and push everything, so you could try it out. Looks like the config should then refer to $DOCKER_USERNAME and $DOCKER_PASSWORD, correct? Or are there more secrets needed?
jamesmortensen
commented
8 months ago You can go ahead and push the ARM64 images to DockerHub somewhere. The big challenge isn't pushing multi-arch images. It's whether or not the ARM images actually work with Selenium 4.11 and beyond. The problem is that something changed upstream between August and December that keeps docker-seleniarm on Selenium 4.10 instead of being able to update to 4.16.1.
If you can deploy ARM64 Docker images somewhere, based on Ubuntu, so I can validate that it works, I can then look at cherry picking those changes back into docker-seleniarm. Also, when you deploy them, please let me know which branch I should be looking at.
And, you're right. The end goal is we want to eventually merge all of this back into docker-selenium upstream, but we're not there yet until a lot of other things come into place. You can learn more about the plan here and the challenges: https://github.com/SeleniumHQ/docker-selenium/issues/1847
On Mon, Dec 18, 2023 at 6:06 AM Fried Hoeben @.***> wrote:
Indeed I based my branch on the seleniumHQ repository as I wanted to build images with as minimal changes to their codebase to keep tracking them easy. I also got a comment from them they hope to incorporate arm builds into the main project in the near future, so I wanted to be as close to that as possible.
I did see the armhf support, but I didn't spend time on that (yet), so for now in this branch it is only arm64 and amd64. I also didn't keep the Makefile changes from your branch, there was quite a lot and so far I needed almost nothing of it to get the images (that was what I was referring to when I said the make targets are not available in my branch)
I was wrong about being able to generate manifests locally, that really does require images to be pushed to a registry beforehand. (As I saw in the build of my last commit)
I could push the images I build locally to docker hub, but that would only get us arm64 images. What I did instead is have the build mark the generated image tarballs as artifacts. So you can obtain the images by downloading the two tarballs and importing their images (that part of my last commit does work, although it gets them from cache instead of the artifacts):
- https://output.circle-artifacts.com/output/job/4ef416ea-b36c-46df-ac57-a0de7956fdbd/artifacts/0/images/amd64.tar
I think I can update my branch so that a copy of yours (with access to the secrets) would be able to generate the manifest and push everything, so you could try it out. Looks like the config should then refer to $DOCKER_USERNAME and $DOCKER_PASSWORD, correct? Or are there more secrets needed?
— Reply to this email directly, view it on GitHub https://github.com/seleniumhq-community/docker-seleniarm/pull/57#issuecomment-1860312104, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKBH2CMMIVUWKHFDFDIAIDYKAWUHAVCNFSM6AAAAABAYQAAKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRQGMYTEMJQGQ . You are receiving this because you were mentioned.Message ID: @.***>
--
James
fhoeben
commented
8 months ago So I believe you can validate the images now based on the artifacts I mentioned in my previous comments (you could push based on those yourself).
The tests pass (with a minor change I added, to check there are any downloads before inspecting the name of the first download) so I hope/assume they work.
The changes to make the actual arm image build work on ubuntu (only arm64) are in https://github.com/fhoeben/docker-seleniarm/tree/add_chromium_arm64, this is again based on SeleniumHQ trunk, with my addition to add chromium.
Then the branch this PR is based on adds the Circle CI config.
I just squash and force pushed some changes to hopefully make it a bit clearer
fhoeben
commented
8 months ago @jamesmortensen I just setup my own CircleCI account and managed to build and push the images/manifests based on this branch (with a changed namespace)
Images:
diemol
commented
8 months ago I am merging this into https://github.com/seleniumhq-community/docker-seleniarm/tree/add_chromium_arm64_circle, so we can run CI without issues. If we need more changes, we can do more PRs towards that branch.
diemol
commented
8 months ago I see the build and test passes, but we need the secrets for the last part.
Thanks for contributing to the Docker-Selenium project! A PR well described will help maintainers to quickly review and merge it
Before submitting your PR, please check our contributing guidelines, applied for this repository. Avoid large PRs, help reviewers by making them as simple and short as possible.
Description
Motivation and Context
Types of changes
Checklist