Repository navigation
test(ci): add container compatibility test (#32 / #243) - #453
Conversation
ruby / elixir / 最小 Debian イメージで container: image: 実行した際の 互換性を検証する workflow_dispatch 専用ワークフローを新設。 - Issue 案内のワークアラウンド (前提パッケージ + google-chrome 事前導入) を encode し、それで action が成功することを保証する - *-slim は git 未収録のため checkout 前に前提パッケージを導入 - ref 入力で master (シェル版) / issue-159 (PR #446 TS版) を切替可能 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
workflow_dispatch 専用ワークフローは default ブランチに無いと API 起動 できないため、自ブランチで検証可能なよう調整。 - push (test/container-compatibility 限定) トリガーを追加 - ref を matrix 軸化し master (シェル版) / issue-159 (TS版) を一括検証 - checkout ref を matrix.ref に変更 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
実走で判明した #243 の根本原因に対応: - action は dpkg -s <chromeapp> で chrome 存在判定するため、binary 別名 google-chrome を渡すと判定失敗 → apt-key 経路に突入 - apt-key は Debian 12 (bookworm) で削除済みのため elixir/node/debian-slim および ruby:latest が command not found で失敗 (bullseye の ruby:3.2.2 のみ成功していた) - 導入済みパッケージ名 google-chrome-stable を chromeapp に渡し、壊れた apt-key 経路を回避するワークアラウンドに修正 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
container-test.yml を比較検証ツールから常設ゲートへ変更: - on.push / on.pull_request (paths '!*.md') を追加、test.yml と同形式に - ref matrix 軸と固定 ref checkout を撤廃し、素の checkout + uses: ./ で push/PR の対象コード自体を検証 - イメージは全5種維持 (bullseye/bookworm 両系統を網羅) README に「Usage in a Container」節を追加し、コンテナ実行に必要な3要件を 明記 (#32 / #243): 1. checkout 前に前提パッケージ導入 (git sudo gnupg curl unzip jq wget) 2. signed-by keyring 方式で google-chrome-stable を事前導入 3. chromeapp: google-chrome-stable を渡す (dpkg -s がパッケージ名一致を要求) Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
📝 WalkthroughWalkthroughこのPRは、setup-chromedriver アクションをコンテナ環境で実行・検証するための自動テストワークフローを追加し、その使用方法を説明するドキュメントセクションを追記しています。コンテナ環境では GitHub-hosted runner の前提条件が揃わないため、事前パッケージ導入から Chrome インストール、動作確認までを段階的に実装。 Changesコンテナ環境対応
Sequence DiagramsequenceDiagram
participant Container as Container environment
participant Checkout as actions/checkout
participant APT as apt-get
participant Chrome as Google Chrome
participant SetupAction as setup-chromedriver
participant Verify as Binary verification
Container->>Checkout: Initialize
Checkout->>APT: Prerequisites (git, sudo, curl, gnupg)
APT->>Chrome: Install google-chrome-stable
Chrome->>SetupAction: Chrome executable ready
SetupAction->>SetupAction: Execute with chromeapp parameter
SetupAction->>Verify: Install chromedriver
Verify->>Verify: chrome --version, chromedriver --version
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Code Review
This pull request adds a new section to the README.md documenting how to use the action inside a container, detailing the required prerequisites and manual Google Chrome installation. The review feedback suggests a robust improvement to the Chrome installation steps by using the modern /etc/apt/keyrings/ directory instead of /usr/share/keyrings/ and ensuring the directory is created beforehand.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/workflows/container-test.yml (1)
41-48: ⚡ Quick winコンテナイメージのタグが固定されていません。
ruby:latest、elixir:slim、node:slim、debian:stable-slimなどの可変タグを使用すると、テストの再現性が失われます(同じコミットでも、実行時期により異なるベースイメージでテストされる可能性があります)。互換性テストとして「現時点の最新イメージ」を検証する意図であれば現状のままでも許容できますが、再現性を重視する場合は具体的なバージョンタグまたはダイジェストでピン留めすることを推奨します。
例:
ruby:3.2.2→ruby:3.2.2-bookworm、ruby:latest→ruby:3.3.0など。As per coding guidelines での静的解析ツール(zizmor)も unpinned-images として指摘しています。
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/container-test.yml around lines 41 - 48, The workflow uses unpinned container images in the matrix (entries like "ruby:latest", "elixir:slim", "node:slim", "debian:stable-slim") which breaks reproducibility; update the matrix image list so each entry is a specific version tag or an immutable digest (e.g., replace ruby:latest with a concrete ruby X.Y.Z or ruby:X.Y.Z-bookworm, and similarly pin elixir, node and debian), then ensure the container.image that references matrix.image continues to use those pinned values; optionally add a short comment explaining the chosen pinning strategy for future maintainers.README.md (1)
123-128: ワークフローとドキュメント間の一貫性を保つ運用を推奨します。Google Chrome のインストール手順は
.github/workflows/container-test.yml(lines 74-79) と README.md (lines 123-128) の両方に記載されています。現在は一致していますが、将来的にインストール手順を変更する際は、両方を同期して更新する必要があります。定期的に以下を確認することを推奨します:
#!/bin/bash # Description: Verify Chrome installation steps are consistent between workflow and README # Extract Chrome installation steps from workflow workflow_steps=$(sed -n '/Install Google Chrome/,/apt-get install -y google-chrome-stable/p' .github/workflows/container-test.yml | grep -E '^\s+(wget|echo|apt-get|gpg)' | sed 's/^[[:space:]]*//') # Extract from README (line numbers may change, use markers) readme_steps=$(sed -n '/# 2\. Install Google Chrome via the signed-by keyring scheme/,/apt-get install -y google-chrome-stable/p' README.md | grep -E '^\s+(wget|echo|apt-get)' | sed 's/^[[:space:]]*//') # Basic comparison (manual review recommended) echo "=== Workflow steps ===" echo "$workflow_steps" echo "" echo "=== README steps ===" echo "$readme_steps"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@README.md` around lines 123 - 128, The README.md Chrome install snippet and the workflow snippet in .github/workflows/container-test.yml (currently around lines 74-79) must remain identical; add a small CI verification job (e.g., container-test or docs-lint) that compares the README section titled "# 2. Install Google Chrome via the signed-by keyring scheme" against the workflow block "Install Google Chrome" and fails if they diverge, or alternatively centralize the install snippet as a single source of truth (include file or template) referenced by both README.md and the workflow so updates to the install steps only happen in one place.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/container-test.yml:
- Around line 24-32: The path exclusion patterns "!*.md" only match Markdown
files at the repository root; update both occurrences of the literal pattern
"!*.md" in the workflow to "!**/*.md" so nested Markdown files (e.g., docs/*.md,
.github/*.md) are also excluded; ensure you change the pattern under both the
push and pull_request paths blocks that currently contain "!*.md".
---
Nitpick comments:
In @.github/workflows/container-test.yml:
- Around line 41-48: The workflow uses unpinned container images in the matrix
(entries like "ruby:latest", "elixir:slim", "node:slim", "debian:stable-slim")
which breaks reproducibility; update the matrix image list so each entry is a
specific version tag or an immutable digest (e.g., replace ruby:latest with a
concrete ruby X.Y.Z or ruby:X.Y.Z-bookworm, and similarly pin elixir, node and
debian), then ensure the container.image that references matrix.image continues
to use those pinned values; optionally add a short comment explaining the chosen
pinning strategy for future maintainers.
In `@README.md`:
- Around line 123-128: The README.md Chrome install snippet and the workflow
snippet in .github/workflows/container-test.yml (currently around lines 74-79)
must remain identical; add a small CI verification job (e.g., container-test or
docs-lint) that compares the README section titled "# 2. Install Google Chrome
via the signed-by keyring scheme" against the workflow block "Install Google
Chrome" and fails if they diverge, or alternatively centralize the install
snippet as a single source of truth (include file or template) referenced by
both README.md and the workflow so updates to the install steps only happen in
one place.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e9c29459-076f-4926-a5ec-55a1ffdcfccb
📒 Files selected for processing (2)
.github/workflows/container-test.ymlREADME.md
Overview
Adds a permanent
container-test.ymlworkflow that verifies the action works when used inside acontainer: image:, and documents the required steps for container usage in the README.Containers such as
ruby/elixir:slimhave long been reported as failing (#32 / #243). Until now we have responded to each report with "install sudo separately", but there was no CI to catch regressions. This PR encodes that workaround and verifies it continuously.Root cause of #243, confirmed live
In the first run (a ref-matrix variant), every image except
ruby:3.2.2failed, which let us pin down two distinct causes:apt-keywas removed in Debian 12 (bookworm) and later — only the bullseye-basedruby:3.2.2succeeded before, while the bookworm-based images (ruby:latest/elixir:slim/node:slim/debian:stable-slim) failed withapt-key: command not found.chromeappvalue and the package name — the action decides whether Chrome is present viadpkg -s <chromeapp>, so passing the binary aliasgoogle-chromemakes that check miss and forces the action down the broken apt-key install path.The established workaround (3 requirements)
actions/checkout(git sudo gnupg ca-certificates curl unzip jq wget) — checkout itself needsgit, which slim images do not ship.google-chrome-stableyourself using thesigned-bykeyring scheme (the action's built-in Chrome install relies on the removedapt-key).chromeapp: google-chrome-stableso it matches the installed package name and the action stays on the "already installed" path instead of the apt-key path.Changes
.github/workflows/container-test.yml(new)on.push/on.pull_request(paths: ['**', '!*.md']) +workflow_dispatch, mirroringtest.ymlruby:3.2.2/ruby:latest/elixir:slim/node:slim/debian:stable-slim(covers both bullseye and bookworm)actions/checkout→uses: ./so it gates the actual pushed / PR codegoogle-chrome-stable --version/chromedriver --versionREADME.md: adds a "Usage in a Container" section documenting the 3 requirements aboveVerification
pull_requesttrigger for this PR: see this PR's Checks (all 5 jobs green).🤖 Generated with Claude Code