fix(ci): skip the SWA upload on Dependabot pull requests

[bgard68]

Makes #104 and #105 mergeable. Without this, no Dependabot pull request on frontend can ever pass Build & Deploy Frontend — and since that is a required check, none of them can ever merge.

What happens

deployment_token was not provided.
The deployment_token is required for deploying content.

Dependabot pull requests run with a restricted token and no access to repository secrets, whatever branch they sit on. So secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_... arrives empty and the action stops.

Why the existing guard did not catch it

The step already skipped forks, for exactly this reason:

# Skip for PRs from forks: secrets are not exposed to them, so the deploy would fail
# confusingly rather than meaningfully. Pushes and same-repo PRs still deploy.
if: >-
  github.event_name != 'pull_request' ||
  github.event.pull_request.head.repo.full_name == github.repository

The reasoning was right; the test was too narrow. Dependabot's branches live in this repository, so head.repo.full_name == github.repository is true, the guard passed, and the step ran anyway — failing in precisely the confusing way the comment was written to prevent.

The control: #123 passed this same check on the same code an hour earlier. That branch was mine rather than Dependabot's, so the secret was available. Nothing about the code differs.

This is not a stale check and not something a rebase or re-run could fix. #104 and #105 have both been recreated onto current frontend, carry the nanoid 3.3.18 fix, and are 0 commits behind — and they still fail, because this is structural.

The change

if: >-
  github.event_name != 'pull_request' ||
  (github.event.pull_request.head.repo.full_name == github.repository &&
   github.event.pull_request.user.login != 'dependabot[bot]')

Keyed on the pull request author, not github.actor — re-running a Dependabot workflow by hand makes the actor a human while the token stays restricted.

Preferred over the action's skip_deploy_on_missing_secrets: true, which would also silently tolerate a genuinely missing secret on a real deploy. This states the condition it means.

What still runs on Dependabot pull requests

Everything that gates quality:

• npm ci
• npm audit --audit-level=high
• the frontend test suite
• the CSP connect-src check
• the docs drift check

Only the upload is skipped, and it could not have succeeded. builddeploy is the last step in the job and its id is referenced nowhere, so the job simply succeeds. Pushes to frontend and ordinary same-repo pull requests deploy exactly as before.

After this merges

#104 and #105 need one more @dependabot recreate so they pick up the fixed workflow on a fresh commit — check results belong to a commit, so merging this will not retroactively clear their current red X.

🤖 Generated with Claude Code

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://salmon-field-054249810-125.centralus.7.azurestaticapps.net