Static Web App Maximum Number of Staging Environments

Introduction

I have recently had a build failure on Github when making a change to my blog. When I make changes to my blog I can create them on a separate branch, this allows me to test changes away from the “production” version before publishing them. When I raise a pull request, a github action will build my site and publish the code to the Azure Static Web App I have provisioned for this site. A web app has a number of “slots” which can be used for publishing versions of your code. This is really handy since I can publish changes and view the entire site on a complete separate URL before publishing them to the “real” URL. The free plan allows me to have 3 additional slots which means I can only have three pull requests open at any one time.

Error raised

I made some changes today and the build failed with the following message;

The content server has rejected the request with: BadRequest
Reason: This Static Web App already has the maximum number of staging environments (3). Please remove one and try again.

So the Static Web App hosted on Azure is saying that it will not let me publish my code because I have run out of staging environments…in other words I have no more preview slots available to publish to. I am running the free plan and I have reached my limit! That shouldn’t really happen though, so I need to work out why.

Check Github

Each slot will have a separate version of my code deployed to it. So the first thing I should check is whether I already have three pull requests open that I haven’t dealt with previously. If I head over to Github and open the repository I can see how many pull requests are currently open.

I can that I only have one pull request open, so this is not the cause. Also observe in the screenshot that the pull request number is #67.

Check Web app

The next thing to check is why I am out of slots. A basic web app will have one production slot which will typically be connected to your main branch. This is the version of your code that is presented if you go to your normal URL. It will also have three “preview” slots. This can be viewed in the Environments section of your web app in the Azure Portal.

So from this I can see that something isn’t right. In the screenshot above you can see that there are three preview slots present and are all associated with historic pull requests. These slots should only exist during the life of a pull request and once the pull request is complete, they should be purged. This ensures that during normal processing I will never run out of slots because (at least in theory) I will never have too many incomplete changes open at once.

Supposing that the pull requests listed for each slot were still open, then this would be a code review problem - I am trying to add a fourth set of changes for review but I already have three previous pull requests that I haven’t reviewed (#64, #65, #66). If that was the case, then I would resolve this by completing all the historic pull requests first therefore, freeing up the slots.

Identifying the issue

In this situation though, it seems to be a process problem. As I said earlier, once a pull request is completed my github action should purge the associated slot and so something isn’t quite right with my github actions. It would appear that I have introduced this issue when adjusting my github actions previously (doh). Somewhere along the way I made a change to my actions and in doing so left out an important block of code from my pull request YAML file.

Checking through my historic code, I can see that the last job in the file used to be one that occurred if the event was the closure of a pull request. It uses the static web apps deploy task to trigger the closure of a preview slot. Reinstating this block of code as the final step should resolve my issue. This block of code has an if statement that filters by an event_name of pull_request and an action type of closed, meaning that it will only be run if the pull request is closed.

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/[email protected]
        with:
          azure_static_web_apps_api_token: ${{ secrets.PORTAL_DEPLOYMENT_TOKEN }}
          action: "close"

Cleaning Up

Unfortunately, this won’t clean up the historic issues, so first I will need to remove the preview slots related to pull requests I have already closed. I can do this by going back to the Azure Portal, navigating to the environments section of the webapp, clicking one or more of the slots and pressing the delete button;

Testing the change

Once I have adjusted my yaml file I can rerun my github action to see if the preview site gets built.

Checking the preview slots in Azure, I can see that my code has been published, I can now go ahead and preview my changes using the browse link to the right of the slot;

Checking the fix has worked

We are almost done but the last thing to check is whether my fix to the github actions has worked. The publishing of the preview slot has succeeded simply because I purged all the historic preview slots. The real test is whether the lost provisioned for #67 will be purged once I have approved the pull request.

Now I have been able to review my changes, I am happy that it’s ready for publishing so I will go ahead and approve the change. This will write my changes back to the main branch and trigger my github action again. If everything has worked as intended, my changes will be published to the production environment and the preview slot will be purged.

First I will approve the pull request, this will merge my code back to the main branch;

Next I want to check whether my conditional step has been run by the github actions.

Things are working as intended! The next run ignored the publish because the pull request is closing, instead it has triggered the purge step as intended.

Ok, so I have cheated a little bit here…you might notice that my screenshot is from a different pull request (#68), that’s because I had to fix it twice. In order to test the actions worked properly, I had to merge the pull request, but it didn’t quite work as intended first time, so I had to adjust it on #68.

Final check, has the preview slot been purged…

67 is no more! I can now confirm that this error is resolved. I am now going to go away and have a word with myself about doing a better job of reviewing my code in future :)