Add ARM runner support to stable workflow#26
Conversation
- Based on last stable version (5b1f1fe) to avoid BOLT issues - Add matrix strategy for AMD64/ARM64 separate builds - Use arm-runner for native ARM64 builds - Add ARM runner availability check with notice - Add actionlint.yaml config for custom runner validation - Keep simple stable Dockerfile without complex optimizations
There was a problem hiding this comment.
Pull Request Overview
This PR adds ARM runner support to the stable workflow by implementing a matrix build strategy that separates AMD64 and ARM64 builds. The changes enable native ARM64 builds using a custom arm-runner while maintaining QEMU fallback support for environments where the ARM runner is unavailable.
Key Changes:
- Introduced matrix strategy to run AMD64 builds on
ubuntu-latestand ARM64 builds onarm-runner - Added actionlint configuration to recognize the custom
arm-runnerlabel - Replaced custom build action with direct Docker build-push action using platform-specific builds
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
.github/workflows/build-latest.yml |
Implemented matrix strategy for multi-architecture builds with ARM runner support and QEMU fallback |
.github/actionlint.yaml |
Added configuration to allow custom arm-runner label in workflow validation |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| tags: | | ||
| ghcr.io/${{ github.repository_owner }}/atcoder-container:latest | ||
| ghcr.io/${{ github.repository_owner }}/atcoder-container:all | ||
| type=raw,value=latest | ||
| type=raw,value=all |
There was a problem hiding this comment.
Both matrix jobs will push to the same tags (latest and all), causing the second job to overwrite the first job's image. For multi-architecture support, you should either use Docker manifest to combine both architectures under the same tags, or use architecture-specific tags (e.g., latest-amd64, latest-arm64) and then create a manifest list.
|
|
||
| - name: Checkout | ||
| uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1 | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
The action reference was changed from a pinned SHA (actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11) to a mutable tag (@v4). Pinning to specific SHAs is a security best practice to prevent supply chain attacks. Consider using the SHA format with a comment indicating the version (e.g., actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1).
| uses: actions/checkout@v4 | |
| uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1 |
|
|
||
| - name: Login to GitHub Container Registry | ||
| uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d # v3.0.0 | ||
| uses: docker/login-action@v3 |
There was a problem hiding this comment.
The action reference was changed from a pinned SHA (docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d) to a mutable tag (@v3). Pinning to specific SHAs is a security best practice. Consider reverting to the SHA format.
| uses: docker/login-action@v3 | |
| uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d |
| cache-from: type=gha | ||
| cache-to: type=gha,mode=max |
There was a problem hiding this comment.
Each matrix job (AMD64 and ARM64) will write to the same GitHub Actions cache namespace, potentially causing cache conflicts or unnecessary cache invalidation. Consider adding a cache key suffix based on the platform to separate caches: cache-from: type=gha,scope=${{ matrix.platform }} and cache-to: type=gha,mode=max,scope=${{ matrix.platform }}.
| cache-from: type=gha | |
| cache-to: type=gha,mode=max | |
| cache-from: type=gha,scope=${{ matrix.platform }} | |
| cache-to: type=gha,mode=max,scope=${{ matrix.platform }} |
…he scope - Add Docker manifest creation step to properly combine multi-arch images - Pin all GitHub Actions to specific SHA for security (addresses comment #2448010099, #2448010127) - Add platform-specific cache scope to avoid conflicts (addresses comment #2448010152) - Use architecture-specific intermediate tags (latest-amd64, latest-arm64, all-amd64, all-arm64) - Create final multi-arch manifest images with original tags (latest, all) (addresses comment #2448010076) - Pass yamllint and actionlint validation
✅ レビューコメント対応完了Copilot からの4つの指摘事項に対応しました。 📝 対応内容1. マルチアーキテクチャイメージのタグ衝突問題 (#2448010076)問題: 各matrix jobが同じタグ ( 対応:
2. GitHub Actions のSHAピン留め (#2448010099, #2448010127)問題: セキュリティベストプラクティスとして、可変タグ ( 対応:
3. キャッシュスコープの競合 (#2448010152)問題: AMD64とARM64の両ジョブが同じGitHub Actionsキャッシュ名前空間を使用し、競合やキャッシュ無効化が発生する可能性 対応:
✨ 追加改善
🔄 ワークフローの動作
これにより、マルチアーキテクチャイメージが正しく構築され、ユーザーは |
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| # v3.2.0 | ||
|
|
||
| - name: Set up Docker Buildx | ||
| # yamllint disable-line rule:line-length |
There was a problem hiding this comment.
The yamllint disable comment is unnecessary as line 42 is only 74 characters long, well below typical line length limits (80 or 120 characters). This comment should be removed.
| # yamllint disable-line rule:line-length |
📝 レビューコメント #2448325296 についてCopilotから「yamllint disable-line コメントは不要」という指摘がありましたが、この指摘は誤りです。 🔍 検証結果$ sed -n '41p' .github/workflows/build-latest.yml | wc -c
82実際の行の長さ: 82文字（改行を含む） したがって、 📊 詳細問題の行: uses: docker/setup-buildx-action@988b5a0280414f521da01fcc63a27aeeb4b104dbこの行は、セキュリティベストプラクティスに従って特定のSHAでアクションをピン留めしているため、どうしても長くなります。以下の選択肢がありました:
セキュリティを優先し、yamllint の例外を使用する方針を維持します。 |
Resolve conflict in build-latest.yml: - Keep PR #26's multi-arch manifest approach - Add date tag feature from main branch - Update to use $GITHUB_OUTPUT instead of deprecated set-output
🎯 Overview
安定版（5b1f1fe）をベースにARM runnerサポートを追加。BOLT最適化などの複雑な問題を避けて、シンプルで確実に動作するワークフローを提供。
📋 Changes
Workflow Improvements
Configuration
🔧 Technical Details
Base Version
Build Strategy
✅ Benefits
🧪 Test Plan
🎉 Ready for Production
このPRは本格運用準備が整った安定版です。