Update Docker file to be multi-platform

[roslynwythe]

Overview

We need to update our Docker file to support multiple platforms, in order to resolve a problem experienced by users with mac M1 processors

Action Items

• Fork the repository ghpages-docker
• Create an issue branch from the main branch
• Edit .github/workflows/build-and-push-to-docker-hub.yml workflow and/or Dockerfile to support platforms linux/amd64 and linux/arm64
• Create a personal dockerhub account
• Create secrets DOCKER_USERNAME and DOCKER_PASSWORD from the dockerhub account
• Test the new Docker image hackforlaops/ghpages:latest in your dockerhub account on these platforms
  • Windows 64-bit
  • Mac with Apple M1 or later
• Submit Pull Request to the ghpages-docker repository

Resources/Instructions

• Docker file
• Docker documentation: multiplatform images
• This issue was created from ER: New Developers with Mac processors are having problems running docker image #5644

[roslynwythe]

@fyliu could you kindly review this issue? Also would it be appropriate for me to use your https://github.com/hackforla/docker-mkdocs/blob/main/.github/workflows/build-image.yml as a reference?

[fyliu]

@roslynwythe Maybe my workflow file could serve as an example?

---

I have a question: do you know if PRs made from a fork is able to run workflows in the main repo? I'm guessing no, because it feels like a security risk if it did.

I know that PRs from same repo branches are able to run workflows with the repo secrets, so that someone making a PR with the workflow file tagging hackforlaops/ghpages-test6269:latest would cause the repo to build and push that image. It was annoying when someone from my team made an unmerged change in a PR that caused ghpages to build the docs from his branch. The ghpages site should always show the latest merged changes of course. I suspect that's the major reason the website team makes everybody develop on forks.

---

Anyway, the issue is that dockerhub credentials in github secrets wouldn't replicate over when forking the repo.

What I did was

• fork the repo
• create a personal dockerhub account (fyliu)
• set the credentials in my fork using the same secret names as the one in the upstream repo (DOCKER_USERNAME and DOCKER_PASSWORD from build-and-push-to-docker-hub.yml in your case)

That allowed my fork's workflow to push the images to my personal dockerhub repo for testing. I didn't have to change the image tag since it's a different dockerhub repo.

fyliu/mkdocs repo
hackforlaops/mkdocs repo

[ExperimentsInHonesty]

This issue will have to have a second developer assigned after the first person does the work, so that they can test it in the environment the other developer does not have. That needs to be mentioned in the instructions.

[roslynwythe]

@ExperimentsInHonesty I updated the Action Items to reflect the advice of @fyliu to have the dev perform testing in their personal dockerhub account. But I'm unclear on what will happen after the dev submits the Pull Request to the ghpages-docker repository. How will a second developer be able to generate and test an image on the hackforla dockerhub prior to merging the PR? And should the second developer be someone who already has write access to the ghpages-docker repo?

[ExperimentsInHonesty]

@roslynwythe I am going to add this to the agenda for this weeks Ops repo meeting and ask their advice.

• 2024 DevOps Community of Practice Agendas ops#100 (comment)

[ExperimentsInHonesty]

@roslynwythe The Ops community passed on it and suggested we reach out to engineering. I will add it to their agenda and attend their meeting.

[ExperimentsInHonesty]

On ops, there is an issue that probably will need to be moved to engineering or combined with this issue https://github.com/hackforla/ops/issues/128

[ExperimentsInHonesty]

Turns out that new people with an M1 are not reporting problems (@tony1ee). So we are closing as unplanned