Failing CI steps on PRs from forks (azure install and live tests)

[pjbull]

We currently have a process where forks from PRs run two steps in our CI pipeline that require access to repo secrets to run properly. These show up on failing tests in the PR, which can be confusing.

For example, see this recent PR: https://github.com/drivendataorg/cloudpathlib/actions/runs/3751066339

A few options:

• Don't run these tests on PRs from forks. Downside is that this means external contributions don't have live tests or azure install run against them.
• Skip these tests on PRs from forks, and only allow PRs from forks into a separate "staging" branch. Require that merges into master come from a local branch. Normal flow is that contributor PRs are pulled into staging if their tests pass and then into master if stating CI run comes back clean.
• Add a manual trigger for these steps, which we may be able to run on forks (not really sure if this is possible or not)
• Keep as is with failing tests that are a reminder to merge into a repo-local branch and create a PR that will run all the tests.

[jayqi]

The procedure described in this article sounds promising as a way for us to run the tests in a safe manner with maintainer approval: https://dev.to/petrsvihlik/using-environment-protection-rules-to-secure-secrets-when-building-external-forks-with-pullrequesttarget-hci

[pjbull]

This looks super helpful