Tim Deschryver

Get access to the deployed Azure Static Webb App URL within your GitHub Workflow

The Azure logoThe Playwright logo
@tim_deschryver

Hey you. If you're here it probably means four things:

If this is you, you don't have to look any further because I got you covered!

When you create an Azure Static Web App within the Azure Portal and configure it to use GitHub with GitHub Actions, it automatically generates a GitHub workflow for you. The workflow file is also added to your GitHub repository, and it defines some pre-configured steps to build and deploy your SWA.

When I migrated my blog to be a SWA, the workflow that was generated looked like this:

The workflow uses Azure/static-web-apps-deploy GitHub Action to build the application, and deploy it to your Azure resource. The workflow is triggered when a pull request is opened, or when a push is made against the main branch.

What I was missing here is a way to make sure I don't break my blog when I make changes. Believe me when I say that the timing is always bad when something is broken. This happened to me numerous times in the past, especially because my blog is written with SvelteKit, which is undergoing changes regularly toward a stable v1 release.

I don't want to manually verify my blog I make changes because this can be time-consuming, and I always forgot something. That's why I wanted to add a safety check within the workflow. Automated tests to check if everything is working as expected. Of course, I immediately grabbed to Playwright for this task.

Just like the GitHub workflow that was generated, Playwright is also able to create a workflow for you. Just install Playwright with the init script, and work your way through the step wizard.

When you've completed the wizard, you'll end up with a new GitHub workflow file. In my case, this looked like the following file.

The workflow installs Playwright and executes the test suite when a push is made against the main branch, or when a Pull Request is opened.

To run these tests within my Azure workflow, I simply copy-pasted its content into the SWA workflow file, which gives the following result:

To get the most value out of these tests at this stage, you have to run them against the deployed environment.

Therefore, we need to know the deployed URL. The docs mention there's a convention to build the preview URL, which looks like https://<SUBDOMAIN-PULL_REQUEST_ID>.<AZURE_REGION>.azurestaticapps.net. But this also doesn't take into account that we also have our live environment when we push to main. Ideally, we also want to verify that this continues to work.

But there has to be a better way. Luckily, there's the output variable static_web_app_url that's defined on the Azure/static-web-apps-deploy GitHub Action.

With this knowledge, all we have to do is include the static_web_app_url variable to the output variables of the build job. This way, we can access the variable within the test job to configure Playwright. To run the Playwright tests against the preview environment, assign the output variable to the PLAYWRIGHT_TEST_BASE_URL environment variable within the test job.

Now, with this change, no more faux-passes reach the live environment of my blog ๐Ÿคž. And if they do, I'm notified about it.

Support me

I appreciate it if you would support me if have you enjoyed this post and found it useful, thank you in advance.

Buy Me a Coffee at ko-fi.com PayPal logo
Support the blog Share on Twitter Discuss on Twitter Edit on GitHub