Form to Wipe — Implementación de GitHub Actions

Esta guía cubre la implementación de GitHub Actions de Form to Wipe. Cada solicitud de borrado es un Pull Request. Las reglas de protección de rama garantizan que el solicitante no pueda fusionar su propio PR. Cuando un aprobador lo fusiona, el flujo de trabajo ejecuta el comando de borrado y publica los resultados como un comentario de PR. Todo el historial vive en git — permanente, buscable y a prueba de manipulaciones. No se requiere infraestructura.

Cómo funciona

1. El solicitante abre un Issue usando la plantilla de Solicitud de borrado
2. El solicitante crea una rama y PR referenciando el issue
3. Un compañero de equipo (no el solicitante) revisa y fusiona el PR
4. GitHub Actions se ejecuta: analiza el cuerpo del PR, resuelve IDs de dispositivos, envía comandos de borrado
5. Los resultados se publican como un comentario de PR
6. El PR fusionado es su registro de auditoría

Requisitos previos

• Repositorio de GitHub (público o privado con minutos de Actions)
• Cliente OAuth2 de la Jamf Platform API con privilegios de borrado (ver Form to Wipe)
• Un equipo de aprobadores designado en su organización de GitHub

Configuración

Paso 1 — Clonar o fork el repositorio

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

O copie el contenido del directorio github-workflow/ a la raíz de su propio repositorio.

Paso 2 — Secretos del repositorio

Vaya a Settings → Secrets and variables → Actions → New repository secret y agregue:

Los secretos de GitHub nunca se registran ni se exponen en la salida del flujo de trabajo. El token recuperado en tiempo de ejecución se enmascara mediante add-mask.

Paso 3 — Reglas de protección de rama

Este es el paso más crítico. La protección de rama es lo que garantiza que nadie pueda aprobar su propia solicitud de borrado.

1. Vaya a Settings → Branches → Add branch protection rule

2. Patrón de nombre de rama: main (o su rama predeterminada)

3. Habilite la siguiente configuración:

   Configuración	Requerido
   Requiere un pull request antes de fusionar	✅
   Requerir aprobaciones — establecer en 1	✅
   Descartar revisiones antiguas cuando se envían nuevas confirmaciones	✅
   Requerir revisión de propietarios de código	Recomendado
   Restringir quién puede descartar revisiones de pull request	Recomendado
   No permitir el bypass de la configuración anterior	✅ Crítico

"No permitir bypass" evita que los administradores del repositorio fusionen sus propias solicitudes. Sin esta configuración, los administradores pueden omitir la aprobación por completo.

Paso 4 — CODEOWNERS (Recomendado)

Cree .github/CODEOWNERS para requerir revisión de un equipo específico para cualquier archivo en el directorio requests/:

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

Esto significa que cualquier PR que toque requests/ requiere automáticamente una revisión del equipo jamf-admins. Los miembros del equipo aún no pueden aprobar sus propios PRs.

Paso 5 — Cree el directorio de solicitudes

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

El flujo de trabajo se activa en eventos pull_request → closed para cualquier PR que toque requests/**.md.

Envío de una solicitud de borrado

Como solicitante

1. Abra un Issue usando la plantilla de Solicitud de Borrado de Dispositivo. Complete todos los campos exactamente como se etiquetan. Tenga en cuenta el número del issue (ej. #42).

2. Cree una rama:

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

3. Cree el archivo de solicitud:

   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. Abra un Pull Request — título: Device Wipe Request — fixes #42. Solicite revisión de un compañero.

Como aprobador

1. Revise el PR — verifique que los IDs de dispositivos y el motivo sean legítimos
2. Confirme que no es el autor del PR (GitHub lo aplica, pero verifique)
3. Apruebe y Fusione usando un merge commit (no squash, no rebase — merge commit preserva el historial completo)
4. El flujo de trabajo se ejecuta automáticamente en la fusión
5. Verifique los comentarios del PR para los resultados

Registro de auditoría

Cada PR de solicitud de borrado fusionado es un registro de auditoría permanente que contiene:

Para buscar borrados anteriores:

# Enumera todos los PRs de solicitud de borrado fusionados por etiqueta
gh pr list --label wipe-request --state merged

# Busca por ID de dispositivo
gh pr list --state merged --search "device 42"

Consideraciones de seguridad

• Las credenciales de la Jamf Platform API viven como secretos del repositorio — nunca en código de flujo de trabajo o cuerpos de solicitud
• La protección de rama evita la autoaprobación a nivel de plataforma
• CODEOWNERS asegura que solo los administradores designados puedan aprobar solicitudes de borrado
• El flujo de trabajo valida solicitante ≠ aprobador en tiempo de ejecución como una segunda verificación
• Los comentarios de resultado del flujo de trabajo se adjuntan al PR y no se pueden alterar después del hecho
• El directorio requests/ acumula un registro permanente e inmutable de cada borrado ejecutado

Limitaciones vs. n8n