Skip to content

test(ci): add container compatibility test (#32 / #243) - #453

Merged
nanasess merged 4 commits into
masterfrom
test/container-compatibility
May 31, 2026
Merged

nanasess merged 4 commits into
masterfrom
test/container-compatibility

Conversation

@nanasess

@nanasess nanasess commented May 31, 2026 •

Copy link
Copy Markdown
Owner

Overview

Adds a permanent container-test.yml workflow that verifies the action works when used inside a container: image:, and documents the required steps for container usage in the README.

Containers such as ruby / elixir:slim have 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.2 failed, which let us pin down two distinct causes:

  1. apt-key was removed in Debian 12 (bookworm) and later — only the bullseye-based ruby:3.2.2 succeeded before, while the bookworm-based images (ruby:latest / elixir:slim / node:slim / debian:stable-slim) failed with apt-key: command not found.
  2. Mismatch between the chromeapp value and the package name — the action decides whether Chrome is present via dpkg -s <chromeapp>, so passing the binary alias google-chrome makes that check miss and forces the action down the broken apt-key install path.

The established workaround (3 requirements)

  1. Install prerequisites before actions/checkout (git sudo gnupg ca-certificates curl unzip jq wget) — checkout itself needs git, which slim images do not ship.
  2. Install google-chrome-stable yourself using the signed-by keyring scheme (the action's built-in Chrome install relies on the removed apt-key).
  3. Pass chromeapp: google-chrome-stable so 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, mirroring test.yml
    • matrix: ruby:3.2.2 / ruby:latest / elixir:slim / node:slim / debian:stable-slim (covers both bullseye and bookworm)
    • plain actions/checkout → uses: ./ so it gates the actual pushed / PR code
    • smoke test via google-chrome-stable --version / chromedriver --version
  • README.md: adds a "Usage in a Container" section documenting the 3 requirements above

Verification

  • During development, parity was confirmed end-to-end across 5 images × (master shell version / issue-159 TS version) = 10 jobs (all green), proving PR feat: Rewrite in native TypeScript (#159) #446 (the TypeScript rewrite) behaves the same as the shell version in containers.
  • The (B)-form run under the pull_request trigger for this PR: see this PR's Checks (all 5 jobs green).

🤖 Generated with Claude Code

nanasess and others added 4 commits May 31, 2026 15:32
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]>
@coderabbitai

coderabbitai Bot commented May 31, 2026 •

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

このPRは、setup-chromedriver アクションをコンテナ環境で実行・検証するための自動テストワークフローを追加し、その使用方法を説明するドキュメントセクションを追記しています。コンテナ環境では GitHub-hosted runner の前提条件が揃わないため、事前パッケージ導入から Chrome インストール、動作確認までを段階的に実装。

Changes

コンテナ環境対応

Layer / File(s) Summary
Container test workflow
.github/workflows/container-test.yml
複数コンテナイメージ(ruby:3.2.2 / ruby:latest / elixir:slim / node:slim / debian:stable-slim)でのマトリクステスト。actions/checkout 前に git、sudo、curl、gnupg 等を apt-get で導入し、公式キーリング方式で Google Chrome stable をインストール。setup-chromedriver を chromeapp: google-chrome-stable で実行し、両バイナリの --version で疎通確認。
Container usage documentation
README.md
「Usage in a Container」セクションを追加。コンテナ内実行時の事前パッケージ準備、signed-by 鍵方式による Google Chrome 手動インストール、chromeapp に dpkg パッケージ名を指定する条件、および GitHub Actions YAML 実装例を記述。

Sequence Diagram

sequenceDiagram
  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
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 Container に Chrome を呼び込む
apt-get と keyring の手で整えて
ワークフロー走れば chromedriver も従う
Linux の画面に祝いの火が灯る
隔たりなく動く、それが今日の喜び ✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed プルリクエストのタイトルは「test(ci): add container compatibility test (#32 / #243)」であり、このPRの主要な変更はコンテナ実行環境での互換性テストワークフローの追加です。タイトルはこの主要な目的を明確に反映しており、簡潔で具体的です。

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch test/container-compatibility

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

Comment @coderabbitai help to get the list of available commands and usage tips.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

Comment thread README.md Resolved

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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

📥 Commits

Reviewing files that changed from the base of the PR and between f681ee8 and 489e209.

📒 Files selected for processing (2)
  • .github/workflows/container-test.yml
  • README.md

Comment thread .github/workflows/container-test.yml Resolved
@nanasess nanasess changed the title test(ci): コンテナ実行の互換テストを追加 (#32 / #243) test(ci): add container compatibility test (#32 / #243) May 31, 2026
@nanasess
nanasess merged commit 686e44e into master May 31, 2026
29 checks passed
@nanasess
nanasess deleted the test/container-compatibility branch May 31, 2026 07:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant