Coding Stephan

Deploy to Azure Static Web App the slim way

Have you ever used Azure Static Web Apps, and used the portal wizard to set it up? Then you’re probably using the Azure Static Web App deploy Github Actions. Which is a humongous Github Action (1.6 GB docker container), that is also capable of automatically discovering how to build any of the supported apps.

What if you don’t need any of the auto build capabilities? Microsoft does not officially support any other way to deploy to Azure Static Web Apps, so you’re out of luck. They might be some other way, read on if you want to know more.

Github Action screenshot

Frustration leads to new solutions

I was super annoyed by the enormous download that happened every time I was doing a minor change to some markdown file. A simple deploy of some static files should not need a 1.6 GB docker container download. The need for a deployment token was also something I could no longer bear seeing. With this frustration I though lets do something about it.

I figured out you can also deploy to SWA using the Static Web App cli, though they are not recommending it for any production stuff.

Introducing Azure Static Web Apps Deploy (Small)

Azure Static Web Apps Deploy (Small) is my new preferred method to deploy to Azure Static Web Apps. It is a composite Github action. This means that it just a collection of other Github Actions tied together.

Features

I won’t be repeating all the docs about this action here, but here are the main features:

  • ⚡ Fast, minimal, and easy to use
  • 🔑 Supports both federated credentials (recommended) and deployment token (why?)
  • 📦 Installs and uses the SWA CLI

Action explained (deep dive)

If you supplied the parameters for federated credentials, it will use those to call Azure/login@v2, followed by a small PowerShell script to use the Azure CLI to fetch the deployment token from Azure. At this point it should have the token, either because you supplied it or because it loaded it with the Azure CLI.

And finally it will call the deploy.ps1 script. This is where the rest of the magic happens.

  1. Install the swa cli if not installed yet (if you where to deploy multiple web apps in one pipeline it will only install once)
  2. Deploy the app using the cli and the collected token
  3. Output the url that is given by the cli (if captured), which currently does not really work. It has something to do with redirecting outputs and starting another process to deploy the actual app.
  4. Alternatively, use a hidden api to load details about the Static Web App
  5. Set the output variable deployment_url to the actual url where your website should now be reachable.

This new github action was the result of some frustration, but it should help you deploy your static web apps faster. As an added bonus you can finally use federated credentials to deploy your app. Meaning you can renew the deployment token as often as you want.

For me this feels like a small contribution in making the world a little bit greener. Thing of all the Github action minutes (a.k.a. Compute/power usage) that are saved this way. My rough estimates show that it saves 1 minute on Build Azure/static-web-apps-deploy@vl and 1 minute on the actual deploy. It seems I’m saving like 2 minutes on each deploy, the more people switching to this new way the better. So please share this with others that work with Azure Static Web Apps.

Hidden API

What is up with this “hidden API” you mentioned. The SWA cli is not really the recommended way to deploy to Azure Static Web Apps. And in fact it is not the node module deploying to Azure. The node module downloads a hidden binary (yes an executable) which is used to deploy to Azure. It then shows the output from this module to the user calling the deploy command. Meaning they start yet another process to deploy and they redirect output.

This does not really work well with PowerShell calling the module and trying to capture the output. When looking into deploying in some other way I figured out you can also load the URL (and some other data) using PowerShell.

$info = Invoke-RestMethod -Uri "https://content-am2.infrastructure.6.azurestaticapps.net/api/upload/validateapitoken?apiVersion=v1&deploymentCorrelationId=$(New-Guid)" `
    -Method Post -ErrorAction SilentlyContinue `
    -UserAgent "staticsites-swacli-client" `
    -ContentType "application/json; charset=utf-8" `
    -Headers @{
    Authorization = "token $env:SWA_CLI_DEPLOYMENT_TOKEN"
    }
$url = $info.response.siteUrl
Write-Host "✅ Deployment URL from api: $url"

Use this code at your own risk. I have no clue for how long it will work and if the numbers in the url some how relate to numbers from the deployment token. As some sort of load balancing thingy.

Deploying Maester results to SWA

I have several Static Web Apps for various experiments, recently I figured out that it is a great spot to host maester test results. And let me show you how you can do just that.

Azure Static Web Apps, has built-in authentication, lets use that to securely host our Maester test results.

Prerequisites

  1. Create an empty static web app, do not configure any auto deployment
  2. Grant the Maester service principal (configured with federated credentials) Contributor access to the Static web app.
  3. Write down the Static Web app name and add it as Action secret with the name SWA_NAME
  4. Deploy once, with the new workflow below
  5. In the Azure Portal, invite yourself (Entra ID) to the admin role.

SWA config

Add a config\staticwebapp.config.json file to your maester repository, with the following content:

{
  "routes": [
    
    {
      "route": "/.auth/login/github",
      "statusCode": 404
    },
    {
      "route": "/*",
      "allowedRoles": ["admin"]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  }
}

This config will disable Github login and force all requests to be authenticated with the admin role. All unauthenticated requests are redirected to an Entra login screen.

Modify your action

In your maester.yml workflow, right below the Maester action you add the following code:

    - name: 📦 Move files
      shell: pwsh
      run: |
        # Create a directory dist if it doesn't exist
        if (-not (Test-Path -Path "dist")) {
          New-Item -ItemType Directory -Path "dist"
        }
        # Copy files in test-results to dist
        Copy-Item -Path "test-results/*" -Destination "dist" -Recurse -Force
        # Rename test-results.html to index.html
        if (Test-Path -Path "dist/test-results.html") {
          Rename-Item -Path "dist/test-results.html" -NewName "index.html"
        }        
    - name: 🚀 Deploy results to SWA
      uses: svrooij/azure-static-web-app-deploy-action@main
      with:
        tenant_id: ${{ secrets.AZURE_TENANT_ID }}                # Required for federated credentials
        client_id: ${{ secrets.AZURE_CLIENT_ID }}                # Required for federated credentials
        static_web_app_name: ${{ secrets.SWA_NAME }}             # Required for federated credentials
        app_location: 'dist'                                     # Optional, default '.'
        api_location: ''                                         # Optional, default 'api'
        swa_environment: 'production'                            # Optional, default 'production'
        swa_config_directory: 'config'

This will copy the results to the dist folder and rename the test-results.html to index.html. This would also be the point where you can add extra files if you want. And then finally it will deploy the content of the dist folder together with the config file in the config directory to the Azure Static Web App.

Once you run your workflow it should display the Static web app url in the logs, try to access it! I things went well, you’re redirected to the Microsoft login screen.

Grant access

Go back to the Azure portal and browse for your Static Web App.

  1. Open the Settings menu
  2. Click Role management
  3. Click Invite
  4. Fill in your email address, be sure to select provider Azure Active Directory
  5. Fill in the role to admin, this is important. It is the role we defined in the config file.
  6. Click generate and copy the link.
  7. Open the link in the correct Edge profile and accept the consent (if you haven’t already)

Grant access to Static Web App

Maester results securely hosted for free

Static web Apps have a Free plan, the free plan supports basic authentication. Making it a great place to host the Maester results for everybody in your organization (you invite) to see. In a future version you might want to automate the inviting part, but for now this seems like a pretty decent solution.

Conclusion

With this new Github action, you can save roughly 2 minutes on each deploy of your Azure Static Web App deployment. And if you followed along this far, you might also have set-up Maester and possibly configured your workflow to publish them to a free Azure Static Web App?

Let me know what you think! And please press that star ⭐ button on the github action