deploy-site-task.yml's caller-stub example may bind environment: on an unsupported uses: job

[ptr727]

Found while disposing of a CodeRabbit finding on PR #941 (a follow-up to #929/#938).

The gap

docs/reusable-workflows.md's documented deploy-site.yml caller-stub example (the "Deploy-site." section, around line 560) has the caller's deploy: job carry both:

  deploy:
    ...
    environment: ${{ inputs.environment }}
    uses: ptr727/ProjectTemplate/.github/workflows/deploy-site-task.yml@<sha> # <tag>
    with:
      environment: ${{ inputs.environment }}
    secrets:
      DEPLOY_SSH_PRIVATE_KEY: ${{ secrets.DEPLOY_SSH_PRIVATE_KEY }}

environment: is bound on the same job that also has uses:, specifically so ${{ secrets.DEPLOY_SSH_PRIVATE_KEY }} in that job's own secrets: mapping resolves from the environment-scoped secret store rather than the repository/organization store, per the surrounding prose.

GitHub's own "Supported Keywords for Reusable Workflow Jobs" reference page states that a job calling a reusable workflow may carry only: name, uses, with, with.<input_id>, secrets, secrets.<secret_id>, secrets.inherit, strategy, needs, if, concurrency, permissions. environment is not in that list.

If GitHub actually rejects or silently ignores environment: on a uses: job, the documented caller-side mechanism for resolving DEPLOY_SSH_PRIVATE_KEY (and, since #938, SITE_AUTH_TOKEN_ID/SITE_AUTH_TOKEN) from an environment-scoped secret store may not work as designed.

This predates #929/#938 entirely (the DEPLOY_SSH_PRIVATE_KEY mechanism already relies on it) and has never been exercised in production: the Stage 5 rollout checklist item "the environment-secret handoff in the deploy-site adoption... observed on Blog's first live deploy run" is still unchecked.

Ask

Confirm, ideally with a real workflow run (a caller job with both environment: and uses:, mapping an environment-scoped secret), whether:

• GitHub hard-errors on this combination at workflow-parse time,
• GitHub silently ignores the environment: key (so the secret resolves from the repo/org store instead, defeating the design's intent), or
• the reference page is stale/incomplete and the combination actually works.

Then either fix the documented caller-stub mechanism (e.g. an intermediate environment-bound job, secrets: inherit, or another shape) or confirm it's fine and where the reference page misleads. Blog's deploy-site-task.yml adoption (tracked in docs/reusable-workflows.md's Stage 5 rollout) is the natural first real-world test, but ideally this is confirmed before that adoption relies on it.