Form to Wipe — GitHub Actions 배포

이 가이드는 Form to Wipe의 GitHub Actions 구현을 다룹니다. 모든 초기화 요청은 Pull Request입니다. 브랜치 보호 규칙은 요청자가 자신의 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. Pull Request를 엽니다 — 제목: 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는 지정된 관리자만 초기화 요청을 승인할 수 있도록 합니다
• 워크플로우는 런타임에 요청자 ≠ 승인자를 두 번째 확인으로 검증합니다
• 워크플로우 결과 댓글은 PR에 추가되며 사실 후에는 변경할 수 없습니다
• requests/ 디렉토리는 실행된 모든 초기화의 영구적이고 불변의 기록을 누적합니다

n8n 대비 제한 사항