Form to Wipe — GitHub Actions Deployment

This guide covers the GitHub Actions implementation of Form to Wipe. Every wipe request is a Pull Request. Branch protection rules enforce that the requestor cannot merge their own PR. When an approver merges it, the workflow executes the erase command and posts results as a PR comment. The entire history lives in git — permanent, searchable, and tamper-evident. No infrastructure required.

How It Works

1. Requestor opens an Issue using the Wipe Request template
2. Requestor creates a branch and PR referencing the issue
3. A teammate (not the requestor) reviews and merges the PR
4. GitHub Actions runs: parses the PR body, resolves device IDs, sends erase commands
5. Results are posted as a PR comment
6. The merged PR is your audit log

Prerequisites

• GitHub repository (public or private with Actions minutes)
• Jamf Platform API OAuth2 client with erase privileges (see Form to Wipe)
• A designated approver team in your GitHub organization

Setup

Step 1 — Fork or Clone the Repo

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

Or copy the github-workflow/ directory contents to your own repo root.

Step 2 — Repository Secrets

Go to Settings → Secrets and variables → Actions → New repository secret and add:

GitHub secrets are never logged or exposed in workflow output. The token retrieved at runtime is masked via add-mask.

Step 3 — Branch Protection Rules

This is the most critical step. Branch protection is what enforces that no one can approve their own wipe request.

1. Go to Settings → Branches → Add branch protection rule

2. Branch name pattern: main (or your default branch)

3. Enable the following settings:

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

"Do not allow bypassing" prevents repository admins from merging their own requests. Without this setting, admins can bypass approval entirely.

Step 4 — CODEOWNERS (Recommended)

Create .github/CODEOWNERS to require review from a specific team for any file in the requests/ directory:

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

This means any PR touching requests/ automatically requires a review from the jamf-admins team. Team members still cannot approve their own PRs.

Step 5 — Create the Requests Directory

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

The workflow triggers on pull_request → closed events for any PR that touches requests/**.md.

Submitting a Wipe Request

As a requestor

1. Open an Issue using the Device Wipe Request template. Fill out all fields exactly as labeled. Note the issue number (e.g. #42).

2. Create a branch:

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

3. Create the request file:

   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. Open a Pull Request — title: Device Wipe Request — fixes #42. Request review from a teammate.

As an approver

1. Review the PR — verify the device IDs and reason are legitimate
2. Confirm you are not the PR author (GitHub enforces this, but verify)
3. Approve and Merge using a merge commit (not squash, not rebase — merge commit preserves the full history)
4. The workflow runs automatically on merge
5. Check the PR comments for results

Audit Trail

Every merged wipe request PR is a permanent audit record containing:

To search past wipes:

# List all merged wipe PRs by label
gh pr list --label wipe-request --state merged

# Search by device ID
gh pr list --state merged --search "device 42"

Security Considerations

• Jamf Platform API credentials live as repository secrets — never in workflow code or request bodies
• Branch protection prevents self-approval at the platform level
• CODEOWNERS ensures only designated admins can approve wipe requests
• The workflow validates requestor ≠ approver at runtime as a second check
• Workflow result comments are appended to the PR and cannot be altered after the fact
• The requests/ directory accumulates a permanent, immutable record of every wipe executed

Limitations vs. n8n