* Make a dedicated, fast, workflow just for docs-internal only
Part of #1297
* make staging-build-pr only for github/docs
* prune later
* make it louder and clearer about disabling workflows
* does it merge?
* typo
* rename ref
* rename
* early access should be good to go
* far from perfect
* start with that
* gzip
* rearrange
* html_url
* correction of actions/checkout sha
* correction of actions/setup-node sha
* quote
* ooops
* actually deploy
* move @octokit/rest to dependencies
* await-sleep hack
* reinstall npm
* typo
* CONTEXT_NAME
* deployments:write permission
* pull-requests:read permission
* actions:read and statuses:write permissions
* private repo mention exception
* it's called github.run_id
* Apply suggestions from code review
Co-authored-by: James M. Greene <JamesMGreene@github.com>
* make CONTEXT_NAME optional (if it works)
* comment out CONTEXT_NAME
* simplifying
* going to run on on.pull_request instead
* remove comment
* only the 2-phase staging deploy on github/docs
* better if statement on label check
* refactor of staging-deploy script
* switch to npm install to get the deDependencies back
* using --only=dev
* updating comments
* event_name
* not on pushes to main
* add staging-commit-status-success
* testing testing
* fix linting error
* Remove other docs-internal references from staging-deploy-pr.yml
* Cleaning up new staging-commit-status-success script and usage
* Remove unnecessary environment refs
* Remove unnecessary fallback
Since the only event trigger is pull_request now instead of also push
* Remove unnecessary env vars from workflow
* docs-internal or docs but not both
* Don't provide unnecessary environment refs
* remove now moot exception
* setting it to pull_request_target
Co-authored-by: James M. Greene <JamesMGreene@github.com>
f68eb74d90