Form to Wipe — GitHub Actions Deployment

このガイドは Form to Wipe の GitHub Actions 実装をカバーしています。すべてのワイプリクエストはプルリクエストです。ブランチ保護ルールは、要求者が自分の PR をマージできないことを強制します。承認者がマージすると、ワークフローはイレースコマンドを実行し、結果を PR コメントとしてポストします。履歴全体は git 内に存在します。永続的で検索可能で、改ざん防止です。インフラストラクチャは必要ありません。

動作原理

1. リクエスト者が Wipe Request テンプレートを使用して Issue を開く
2. リクエスト者がブランチを作成し、Issue を参照する PR を作成
3. チームメイト（リクエスト者ではない）が PR をレビューしてマージ
4. GitHub Actions が実行される: PR ボディを解析し、デバイス ID を解決し、イレースコマンドを送信
5. 結果を PR コメントとしてポスト
6. マージされた PR があなたの監査ログ

前提条件

• GitHub リポジトリ（パブリックまたはプライベート、Actions 分付き）
• イレース権限を持つ Jamf Platform API OAuth2 クライアント（Form to Wipe を参照）
• GitHub 組織内の指定された承認者チーム

セットアップ

ステップ 1 — リポジトリをフォークまたはクローン

git clone https://github.com/YOUR_ORG/FTW-Form-to-Wipe.git
cd FTW-Form-to-Wipe

または、github-workflow/ ディレクトリの内容をあなたの組織のリポジトリルートにコピーします。

ステップ 2 — リポジトリシークレット

Settings → Secrets and variables → Actions → New repository secret に移動して、以下を追加します。

GitHub シークレットはログに記録されず、ワークフロー出力で公開されません。実行時に取得されたトークンは add-mask 経由でマスクされます。

ステップ 3 — ブランチ保護ルール

これが最も重要なステップです。ブランチ保護は、誰も自分のワイプリクエストを承認できないことを強制するものです。

1. Settings → Branches → Add branch protection rule に移動

2. ブランチ名パターン: main（またはあなたのデフォルトブランチ）

3. 次の設定を有効にします。

   設定	必須
   Require a pull request before merging	✅
   Require approvals — 1 に設定	✅
   Dismiss stale reviews when new commits are pushed	✅
   Require review from Code Owners	推奨
   Restrict who can dismiss pull request reviews	推奨
   Do not allow bypassing the above settings	✅ 重要

"Do not allow bypassing" リポジトリ管理者が自分のリクエストをマージするのを防止します。この設定がないと、管理者は承認を完全にバイパスできます。

ステップ 4 — CODEOWNERS（推奨）

.github/CODEOWNERS を作成して、requests/ ディレクトリ内のファイルに対して特定のチームからのレビューを要求します。

# .github/CODEOWNERS
requests/   @your-org/jamf-admins

これは、requests/ に触れる PR が自動的に jamf-admins チームからのレビューを要求することを意味します。チームメンバーは依然として自分の PR を承認することはできません。

ステップ 5 — リクエストディレクトリを作成

mkdir requests
echo "# Wipe Requests\n\nMerged PRs in this directory represent executed device wipes." > requests/README.md
git add requests/
git commit -m "Add requests directory"
git push

ワークフローは、requests/**.md に触れる PR の pull_request → closed イベント時にトリガーされます。

ワイプリクエストを送信

リクエスト者として

1. Device Wipe Request テンプレートを使用して Issue を開きます。 すべてのフィールドをラベルの通りに入力してください。Issue 番号を記録してください（例: #42）。

2. ブランチを作成します。

   git checkout -b wipe/issue-42-device-wipe
   

3. リクエストファイルを作成します。

   cat > requests/wipe-$(date +%Y%m%d-%H%M%S).md << 'EOF'
   **Tenant Name:** Production
   **Tenant ID:** aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
   **Device Type:** computer
   **Device IDs:** 42,87
   **Reason:** Employee offboarding — devices not returned
   **Find My PIN:**
   EOF
   
   git add requests/
   git commit -m "Wipe request for devices 42, 87 - fixes #42"
   git push -u origin wipe/issue-42-device-wipe
   

4. プルリクエストを開きます。 タイトル: Device Wipe Request — fixes #42。チームメイトからレビューをリクエストしてください。

承認者として

1. PR をレビューします。デバイス ID と理由が正当であることを確認してください。
2. あなたが PR 作者ではないことを確認してください（GitHub がこれを強制しますが、確認してください）。
3. マージコミットを使用して承認して Merge します（スクワッシュやリベースではなく、マージコミット）。
4. ワークフローはマージ時に自動的に実行されます。
5. PR コメントで結果をチェックしてください。

監査証跡

すべてのマージされたワイプリクエスト PR は、以下を含む永続的な監査レコードです。

過去のワイプを検索するには。

# ラベルでマージされたすべてのワイプ PR をリストアップ
gh pr list --label wipe-request --state merged

# デバイス ID で検索
gh pr list --state merged --search "device 42"

セキュリティの考慮事項

• Jamf Platform API 認証情報はリポジトリシークレットとして存在します。ワークフローコードやリクエストボディには含まれません。
• ブランチ保護はプラットフォームレベルで自己承認を防止します。
• CODEOWNERS は指定された管理者のみがワイプリクエストを承認できることを確認します。
• ワークフローは実行時にリクエスト者≠承認者を検証する 2 番目のチェックとして機能します。
• ワークフロー結果コメントは PR に追加され、その後に変更することはできません。
• requests/ ディレクトリは、実行されたすべてのワイプの永続的で不変なレコードを蓄積します。

n8n との制限事項の比較