Use default permissions for the deploy GITHUB_TOKEN regarding the contents scope

[elasticdog]

There was a mismatch between the documentation and some of the examples for how these deployments work. The default access for a GITHUB_TOKEN normally includes read/write access to the "contents" scope, but the example starter-workflows made it more restrictive. I'm seeing a failure of the actions/deploy-pages step to set the expected output.page_url, and I'm guessing it has to do with this restriction.

This is the warning annotation on the workflow run:

Environment URL '' is not a valid http(s) URL, so it will not be shown as a link in the workflow graph.

See:

• https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
• https://github.com/actions/starter-workflows/blob/main/pages/static.yml
• https://github.com/actions/deploy-pages

[elasticdog]

bors r+

[bors]

Build succeeded:

• check workflow status
• test workflow status

[elasticdog]

I was wrong with how I interpreted the default permissions, because there are actually two repository-level settings, the permissive and the restricted. Out of the box, this repo was already set to restrictive, so setting contents: read wasn't dropping privileges, it was already the default.

That said, I tried switching to permissive and triggering the workflow again to see if having contents: write would make a difference for the URL error, and it did not help. I'll poke around the upstream repo and file an issue if I can't find anything about the output.page_url being empty.