Deploy to Azure Static Web Apps is not reliable

[SimonSimCity]

Is there any way of not-having the job "Deploy to Azure Static Web Apps" report as a failing job - specially if the reason is: This Static Web App already has the maximum number of staging environments (3). Please remove one and try again.?

It makes it hard to see which PRs actually require additional treatment (e.g. not according to linting rules or tests failing) and on which there's just a deploy-job failing...

[SimonSimCity]

Just found https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error but don't know if its a good fit here. I still want to see that the job failed, but I don't want to have the job as a required check.

[kkuepper]

As StackOverflow described there were zombie environments from abandoned pull requests. I deleted those now.

[kkuepper]

Right now we're on a free plan only allowing us 3 staging environments. If we switched to a paid plan that would be increased to 10.

[SimonSimCity]

We can also decide that we will just live with this 🙃 Just wanted to note down and take a decision on a pain-point I see for maintaining the project.

[SimonSimCity]

Looked a bit into this and decided to propose to add continue-on-error for that workflow. I've looked at stuff like avoiding this if there are more than 3 open PRs (gh pr list --repo bcc-code/bmm-web --json number --jq '.[].number' | wc -l combined with https://stackoverflow.com/a/62436027/517914) but then we'd have to check how many earlier PRs there are, which quickly could get cumbersome for little effect.

See #131. If we don't want it this way, I'd leave it and just accept that some PRs will have a red workflow-indicator in their listing for no code-related reason.

[SimonSimCity]

Got a rework by @adelinn, now supports up to 10 instances