Form to Wipe — Wdrażanie GitHub Actions

Ten przewodnik obejmuje implementację GitHub Actions Form to Wipe. Każde żądanie wipe to Pull Request. Reguły ochrony gałęzi wymuszają, że żądający nie może scalić swojego własnego PR. Gdy zatwierdzający go scali, przepływ pracy wykonuje polecenie erase i wysyła wyniki jako komentarz PR. Cała historia znajduje się w git — permanentna, przeszukiwalna i odporny na manipulacje. Żadna infrastruktura wymagana.

Jak to działa

1. Żądający otwiera Issue przy użyciu szablonu Wipe Request
2. Żądający tworzy gałąź i PR odnoszący się do issue
3. Kolega (nie żądający) przegląda i scala PR
4. GitHub Actions uruchamia: parsuje treść PR, rozwiązuje identyfikatory urządzeń, wysyła polecenia erase
5. Wyniki są wysyłane jako komentarz PR
6. Scalona PR to Twój dziennik audytu

Wymagania wstępne

• Repozytorium GitHub (publiczne lub prywatne z minutami Actions)
• Klient OAuth2 Jamf Platform API z uprawnieniami erase (zobacz Form to Wipe)
• Wyznaczony zespół zatwierdzającego w organizacji GitHub

Konfiguracja

Krok 1 — Fork lub Clone Repo

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

Lub skopiuj zawartość katalogu github-workflow/ do katalogu głównego Twojego repozytorium.

Krok 2 — Tajemnice Repozytorium

Przejdź do Settings → Secrets and variables → Actions → New repository secret i dodaj:

Tajemnice GitHub nigdy nie są rejestrowane ani wyświetlane w danych wyjściowych przepływu pracy. Token pobrany w czasie wykonywania jest maskowany przez add-mask.

Krok 3 — Reguły ochrony gałęzi

Jest to najważniejszy krok. Ochrona gałęzi jest tym, co wymusza, że nikt nie może zatwierdzić swojego własnego żądania wipe.

1. Przejdź do Settings → Branches → Add branch protection rule

2. Wzór nazwy gałęzi: main (lub Twoja gałąź domyślna)

3. Włącz następujące ustawienia:

   Ustawienie	Wymagane
   Require a pull request before merging	✅
   Require approvals — set to 1	✅
   Dismiss stale reviews when new commits are pushed	✅
   Require review from Code Owners	Zalecane
   Restrict who can dismiss pull request reviews	Zalecane
   Do not allow bypassing the above settings	✅ Krytyczne

"Do not allow bypassing" uniemożliwia administratorom repozytorium scalenie swoich własnych żądań. Bez tego ustawienia administratorzy mogą całkowicie pominąć zatwierdzenie.

Krok 4 — CODEOWNERS (Zalecane)

Utwórz .github/CODEOWNERS, aby wymagać recenzji od określonego zespołu dla każdego pliku w katalogu requests/:

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

Oznacza to, że każdy PR dotykający requests/ automatycznie wymaga recenzji od zespołu jamf-admins. Członkowie zespołu wciąż nie mogą zatwierdzić swoich własnych PR.

Krok 5 — Utwórz katalog żądań

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

Przepływ pracy uruchamia się na zdarzeniach pull_request → closed dla każdego PR, który dotyka requests/**.md.

Przesyłanie żądania wipe

Jako żądający

1. Otwórz Issue przy użyciu szablonu Device Wipe Request. Wypełnij wszystkie pola dokładnie tak jak są oznaczone. Zanotuj numer issue (np. #42).

2. Utwórz gałąź:

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

3. Utwórz plik żądania:

   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. Otwórz Pull Request — tytuł: Device Wipe Request — fixes #42. Poproś recenzję od kolegi.

Jako zatwierdzający

1. Przejrzyj PR — sprawdź, czy identyfikatory urządzeń i powód są uzasadnione
2. Potwierdź, że nie jesteś autorem PR (GitHub to wymusza, ale sprawdź)
3. Zatwierdź i Scal używając merge commit (nie squash, nie rebase — merge commit zachowuje pełną historię)
4. Przepływ pracy uruchamia się automatycznie przy scaleniu
5. Sprawdź komentarze PR dla wyników

Ścieżka audytu

Każdy scalony PR żądania wipe jest permanentnym rekordem audytu zawierającym:

Aby przeszukać przeszłe wipes:

# Wypisz wszystkie scalone PR wipu po etykiecie
gh pr list --label wipe-request --state merged

# Przeszukaj po identyfikatorze urządzenia
gh pr list --state merged --search "device 42"

Zagadnienia bezpieczeństwa

• Poświadczenia Jamf Platform API znajdują się jako tajemnice repozytorium — nigdy w kodzie przepływu pracy ani treściach żądań
• Ochrona gałęzi uniemożliwia samo-zatwierdzenie na poziomie platformy
• CODEOWNERS zapewnia, że tylko wyznaczeni administratorzy mogą zatwierdzić żądania wipe
• Przepływ pracy waliduje żądający ≠ zatwierdzający w czasie wykonywania jako drugie sprawdzenie
• Komentarze wyników przepływu pracy są dołączane do PR i nie mogą być zmieniane po fakcie
• Katalog requests/ gromadzi trwały, niezmienny zapis każdego wykonanego wipu

Ograniczenia vs. n8n