Skip to content

ci(docker): Add tests for macOS #636

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

Closed
wants to merge 34 commits into from
Closed

Conversation

MaxymVlasov
Copy link
Collaborator

@MaxymVlasov MaxymVlasov commented Feb 23, 2024

Put an x into the box if that apply:

  • This PR introduces breaking change.
  • This PR fixes a bug.
  • This PR adds new functionality.
  • This PR enhances existing functionality.

Description of your changes

How can we test changes

@MaxymVlasov MaxymVlasov changed the title fix: Add tests for arm64 and for macOS tests: Add tests for arm64 and for macOS Feb 23, 2024
@MaxymVlasov MaxymVlasov changed the title tests: Add tests for arm64 and for macOS ci: Add tests for arm64 and for macOS Feb 23, 2024
@antm-pp
Copy link
Contributor

antm-pp commented Feb 23, 2024

You may understand this better than me (and appreciate it's a work in progress so not trying to review it).

The macos-latest github runner is an amd host, and the only arm host is macos-14 (beta)

The ubuntu-latest (for private repo) is running in Azure according to this spec, and indicates it's an Intel(amd) processor.

I think there's limited ability to run an arm host as a github runner.

In terms of outcomes, (despite the comments on the other PR I've made about seeing differences between aarch64/arm64) isn't the principle test just for a build with buildx arg --platform linux/arm64 as well as the current linux/amd64. Effectively the whole workflow in parallel rather than just the multi-arch build step?

@MaxymVlasov
Copy link
Collaborator Author

MaxymVlasov commented Feb 24, 2024

arm64 exist for macOS 13. GH just not updated their docs
https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners

And matrix is a parallelism by itself, we build multiplatform image just to test that this will work, during the release

Check run workflows for the last commit
https://github.com/antonbabenko/pre-commit-terraform/actions/runs/8025437914

If there were no possibility to run arm64 runners, jobs would not start at all

@MaxymVlasov
Copy link
Collaborator Author

I will take a look at the container structure GHA next week. if it can be quickly fixed, I will use my fork (as it was some time ago), and merge this PR with all 4 checks.

If not - well, 2 arches for Ubuntu are still better than just 1 Ubuntu amd64 build.

Then we will be able to test your PR right away in GHA, just in case.

@MaxymVlasov MaxymVlasov mentioned this pull request Feb 26, 2024
4 tasks
@antm-pp
Copy link
Contributor

antm-pp commented Feb 27, 2024

So the matrix defined still only uses runs-on {{ matrix.os }} so how does the runs-on command have any concept of the architecture? I've never seen anything in github documentation to say they provide arm64 hosts (other than the recent addition of the Mac M1 processor). I can't see anywhere in the workflow that utilises the architecture specified.

This comment was marked as resolved.

@github-actions github-actions bot added the stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 5, 2024
@MaxymVlasov MaxymVlasov added on-hold Indicates that an issue or PR should not be auto-closed due to staleness. and removed stale Denotes an issue or PR has remained open with no activity and has become stale. labels Apr 5, 2024
Copy link

coderabbitai bot commented May 27, 2025

📝 Walkthrough

Summary by CodeRabbit

  • Chores
    • Expanded build and test coverage to include MacOS runners (both amd64 and arm64) in addition to existing Ubuntu runners.
    • Improved workflow reliability by disabling early termination on failure.
    • Enhanced Docker setup for MacOS runners to ensure compatibility and proper environment configuration.
    • Updated debug and binary download steps for broader OS support.

Summary by CodeRabbit

  • Chores
    • Updated automated build and test workflows to support both Linux and MacOS runners, including MacOS for both amd64 and arm64 architectures.
    • Improved workflow reliability by preventing early termination on failure.
    • Enhanced Docker setup and testing compatibility for MacOS environments.

Walkthrough

The build workflow configuration was updated to add MacOS amd64 and arm64 runners to the build matrix. A MacOS-specific step was introduced to set up Docker using a dedicated action before the Docker Buildx setup, conditional on Docker-related files changing.

Changes

File(s) Change Summary
.github/workflows/build-image-test.yaml Added os-type dimension with linux and darwin to build matrix; included MacOS amd64 and arm64 runners; introduced MacOS-only Docker setup step; updated container-structure-test URL to support MacOS binaries; set fail-fast to false; modified IMAGE env variable assignment.

Sequence Diagram(s)

sequenceDiagram
    participant GitHub Actions
    participant MacOS Runner
    participant Setup Docker Action
    participant Docker Buildx

    GitHub Actions->>MacOS Runner: Start job with matrix.os-type=darwin
    MacOS Runner->>Setup Docker Action: Run douglascamata/[email protected]
    Setup Docker Action->>MacOS Runner: Docker environment ready
    MacOS Runner->>Docker Buildx: Proceed with Docker Buildx setup and build steps
Loading

Suggested reviewers

  • antonbabenko

📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between dc6a939 and 948df60.

📒 Files selected for processing (1)
  • .github/workflows/build-image-test.yaml (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/build-image-test.yaml
⏰ Context from checks skipped due to timeout of 90000ms (3)
  • GitHub Check: MacOS ARM
  • GitHub Check: MacOS x64
  • GitHub Check: Ubuntu x64

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between dd939dd and 5badac2.

📒 Files selected for processing (1)
  • .github/workflows/build-image-test.yaml (2 hunks)

@MaxymVlasov MaxymVlasov changed the title ci: Add tests for arm64 and for macOS ci: Add tests for macOS May 27, 2025
@MaxymVlasov MaxymVlasov removed the on-hold Indicates that an issue or PR should not be auto-closed due to staleness. label May 28, 2025
@MaxymVlasov
Copy link
Collaborator Author

This works for mac x64.
Mac arm still need to figure out how to fix. Better do as separate PR

Copy link
Collaborator Author

@MaxymVlasov MaxymVlasov May 31, 2025

Choose a reason for hiding this comment

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

so, as Mac docker is still a linux VM which is not described anyhow in docker inspect metadata => I assume it have no difference with standard linux build, is it make any sense to test Mac-specific docker builds at all?

docker inspect of built image on Mac x64:
Screenshot_20250601-021051.png

docker info on Mac x64:
Screenshot_20250601-023506.png

For context - all that started as issue from #636. Linux arm tests whete added long time ago.
Mac x64 build works in this PR, Mac arm - still not, and according to build action used here for mac - it near impossible to make it run natively

@yermulnik

Copy link
Collaborator

Choose a reason for hiding this comment

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

I assume it have no difference with standard linux build, is it make any sense to test Mac-specific docker builds at all?

Might there be a difference around tool paths, libs, whatever the tests rely upon? Like those common diffs in POSIX (macOS) vs GNU (Linux)?
If not, then, given the info you provided, I agree that we can take macOS build as equal to Linux build.
Maybe call out for someone with macOS to validate tests provide the same outcome in Docker and on native Mac hardware? 🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Different tools inside linux VMs? Could be, but then it depends what users use - Docker Desktop, Rancher etc. and specific it version.

I'll close it for now, till we will face a mac-specific issues that are not detected by current tests

Copy link
Collaborator

Choose a reason for hiding this comment

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

It's probably that I didn't get the basic point of the message: did you mean that os: macos-13 os-type: darwin in reality is a linux ubuntu-based container? What make it macOS build then? Or did you mean that underlying host is Linux anyways and hence built artifacts (like pre-compiled binaries) should be the same anyways (kinda use the same set of instructions)? 🤔 I'm definitely of context of this PR and thus most probably am mixing up things 🤷🏻

Copy link
Collaborator Author

@MaxymVlasov MaxymVlasov Jun 2, 2025

Choose a reason for hiding this comment

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

os: macos-13 os-type: darwin is Mac, but colima spin-ups Linux VM to run docker

Colima means Containers on Lima. Since Lima is aka Linux Machines. By transitivity, Colima can also mean Containers on Linux Machines.

Copy link
Collaborator

Choose a reason for hiding this comment

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

So your concern is underlying host system and not container internals, right?

run: |
docker context ls
# Colima usually creates the socket at ~/.colima/default/docker.sock
DOCKER_SOCKET_PATH=$(docker context ls | awk '{print $4}' | grep colima)
Copy link
Collaborator

Choose a reason for hiding this comment

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

  • Using aws as cut is an anti-pattern
  • But if you change it to something like ... | awk -F$'\t' '$4 ~ /colima/ {print $3; exit}', the it makes sense (the exit is to produce only one string if there are more matches). Otherwise it should be something like ... | cut -f 4 | grep colima.

@MaxymVlasov MaxymVlasov changed the title ci: Add tests for macOS ci(docker): Add tests for macOS Jun 1, 2025
@MaxymVlasov MaxymVlasov closed this Jun 1, 2025
@MaxymVlasov MaxymVlasov deleted the fix_no_test_for_arm branch June 1, 2025 19:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants