fix(ci): degrade gracefully when Actions may not open PRs

[Jayanth Reddy Bujula (jbujula)]

Follow-up to #1441, found by actually running the new workflow instead of assuming it worked.

Run: https://github.com/microsoft/powerplatform-build-tools/actions/runs/31760462499

What happened

Every meaningful step passed - npm ci, npm update, audit-overrides.js, and npm run ci (build + test) - and the branch was pushed. Then the final step failed:

pull request create failed: GraphQL: GitHub Actions is not permitted to create or approve pull requests (createPullRequest)

That is the repo/org policy Settings > Actions > General > "Allow GitHub Actions to create and approve pull requests", which is disabled here. It is not something the workflow can fix, and no token change helps - it applies to GITHUB_TOKEN-driven Actions runs regardless of permissions:.

The run was still valuable: I opened its output by hand as #1461, which upgrades nanoid 3.3.17 -> 3.3.18, clearing GHSA-2v37-7h3g-55p8 (HIGH). That is the advisory I had documented on #1433, #1440 and #506 as "not fixable yet" because 3.3.18 was not mirrored on packagefeedproxy.microsoft.io. The mirror synced, and the automation caught it on its first run with zero human input - which is precisely the Dependabot blind spot (overrides-pinned transitives) this was built for.

The change

Failing the whole run for a policy the workflow cannot satisfy would put a red X on the weekly job every week, which reliably trains people to stop looking at it. But silently passing would hide real breakage. So the step now distinguishes the two:

Outcome	Behavior
The policy error	::warning:: + job summary with a prefilled compare link and the full PR body, exit 0
Any other error	stderr printed, exit 1 (unchanged)

The underlying gh error is printed in both cases. Because the branch is already pushed and green at that point, the work is recoverable in one click from the summary.

If an admin enables the setting, nothing here needs to change - future runs will simply open their own PRs and never hit the fallback.

Verification

Tested with a stubbed gh reproducing the exact stderr:

• policy error -> warning emitted, summary written with the compare URL, exit 0
• unrelated error (some other unrelated API error) -> exit 1, fallback not triggered, so genuine failures are not masked
• yaml.load parses the workflow; bash -n clean on the extracted step script

[Jayanth Reddy Bujula (jbujula)]

This is no longer hypothetical - the failure this PR fixes happened again today.

The weekly cron (0 6 * * 1) fired this morning, Mon Aug 17. It did all of its work, pushed bot/dependency-refresh-20260817, and then failed on the PR step exactly as described here. Same thing in powerplatform-cli-wrapper (#517), which now also has an orphaned bot/dependency-refresh-20260817.

So the repo is now accumulating one dead branch per week, per repo, each with a red X on a job nobody can fix from the workflow:

• bot/dependency-refresh-20260814 (from the first run)
• bot/dependency-refresh-20260817 (from today)

Both contain real, green, useful work. The 0814 one is #1461.

Still merges cleanly

Re-checked against current main today: .github is the only tree that differs (8acce58 vs 7681ad9). package.json and package-lock.json on this branch are byte-identical to main, so there is no drift and nothing to rebase.

To restate the behavior, since it is the part worth reviewing carefully:

Outcome	Behavior
The "Actions is not permitted to create or approve pull requests" policy error	::warning:: + job summary containing a prefilled compare link and the full PR body, exit 0
Any other error	stderr printed, exit 1 - unchanged

The gh stderr is printed either way, so nothing is hidden. Verified with a stubbed gh reproducing the exact message: policy error -> exit 0 with summary written; unrelated error -> exit 1, fallback not triggered.

If an admin instead enables Settings > Actions > General > "Allow GitHub Actions to create and approve pull requests", this code never runs and future weeks open their own PRs. Both paths are fine; this just stops the weekly red X and the silent branch pile-up in the meantime.