Form to Wipe — Déploiement GitHub Actions

Ce guide couvre l'implémentation GitHub Actions de Form to Wipe. Chaque demande d'effacement est une Pull Request. Les règles de protection des branches imposent que le demandeur ne peut pas fusionner sa propre PR. Lorsqu'un approbateur la fusionne, le workflow exécute la commande d'effacement et affiche les résultats comme un commentaire PR. Tout l'historique réside dans git — permanent, searchable et résistant à la falsification. Aucune infrastructure requise.

Comment ça marche

1. Le demandeur ouvre un problème en utilisant le modèle Wipe Request
2. Le demandeur crée une branche et une PR référençant le problème
3. Un coéquipier (pas le demandeur) révise et fusionne la PR
4. GitHub Actions exécute : analyse le corps de la PR, résout les ID d'appareil, envoie les commandes d'effacement
5. Les résultats sont affichés comme un commentaire PR
6. La PR fusionnée est votre journal d'audit

Prérequis

• Repository GitHub (public ou privé avec Actions minutes)
• Client OAuth2 de l'API Jamf Platform avec privilèges d'effacement (voir Form to Wipe)
• Une équipe d'approbateurs désignée dans votre organisation GitHub

Configuration

Étape 1 — Forker ou cloner le repository

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

Ou copiez le contenu du répertoire github-workflow/ à la racine de votre propre repository.

Étape 2 — Secrets du repository

Allez à Settings → Secrets and variables → Actions → New repository secret et ajoutez :

Les secrets GitHub ne sont jamais enregistrés ou exposés dans la sortie du workflow. Le jeton récupéré lors de l'exécution est masqué via add-mask.

Étape 3 — Règles de protection des branches

C'est l'étape la plus critique. La protection des branches est ce qui impose que personne ne peut approuver sa propre demande d'effacement.

1. Allez à Settings → Branches → Add branch protection rule

2. Motif de nom de branche : main (ou votre branche par défaut)

3. Activez les paramètres suivants :

   Paramètre	Requis
   Require a pull request before merging	✅
   Require approvals — set to 1	✅
   Dismiss stale reviews when new commits are pushed	✅
   Require review from Code Owners	Recommandé
   Restrict who can dismiss pull request reviews	Recommandé
   Do not allow bypassing the above settings	✅ Critique

"Do not allow bypassing" empêche les administrateurs du repository de fusionner leurs propres demandes. Sans ce paramètre, les administrateurs peuvent contourner complètement l'approbation.

Étape 4 — CODEOWNERS (Recommandé)

Créez .github/CODEOWNERS pour exiger une révision d'une équipe spécifique pour tout fichier du répertoire requests/ :

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

Cela signifie que toute PR touchant requests/ nécessite automatiquement une révision de l'équipe jamf-admins. Les membres de l'équipe ne peuvent toujours pas approuver leurs propres PR.

Étape 5 — Créer le répertoire des demandes

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

Le workflow se déclenche sur les événements pull_request → closed pour toute PR qui touche requests/**.md.

Soumettre une demande d'effacement

En tant que demandeur

1. Ouvrir un problème en utilisant le modèle Device Wipe Request. Remplissez tous les champs exactement comme indiqué. Notez le numéro du problème (par exemple #42).

2. Créer une branche :

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

3. Créer le fichier de demande :

   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. Ouvrir une Pull Request — titre : Device Wipe Request — fixes #42. Demander une révision à un coéquipier.

En tant qu'approbateur

1. Réviser la PR — vérifier que les ID d'appareil et la raison sont légitimes
2. Confirmer que vous n'êtes pas l'auteur de la PR (GitHub l'impose, mais vérifiez)
3. Approuver et Fusionner en utilisant un commit de fusion (pas squash, pas rebase — le commit de fusion préserve l'historique complet)
4. Le workflow s'exécute automatiquement à la fusion
5. Vérifier les commentaires PR pour les résultats

Journal d'audit

Chaque PR de demande d'effacement fusionnée est un dossier d'audit permanent contenant :

Pour rechercher les effacements antérieurs :

# Lister toutes les PR d'effacement fusionnées par étiquette
gh pr list --label wipe-request --state merged

# Rechercher par ID d'appareil
gh pr list --state merged --search "device 42"

Considérations de sécurité

• Les accréditations API Jamf Platform résident en tant que secrets du repository — jamais dans le code de workflow ou les corps de demandes
• La protection des branches empêche l'auto-approbation au niveau de la plateforme
• CODEOWNERS garantit que seuls les administrateurs désignés peuvent approuver les demandes d'effacement
• Le workflow valide requestor ≠ approbateur lors de l'exécution comme deuxième contrôle
• Les commentaires de résultats du workflow sont ajoutés à la PR et ne peuvent pas être modifiés après coup
• Le répertoire requests/ accumule un dossier permanent et immuable de chaque effacement exécuté

Limitations par rapport à n8n