Publish the API with GitHub Actions
You added your API to your web app and they're both running locally. Now it's time to publish your API and your app to Azure Static Web Apps.
When you created the Azure Static Web Apps instance and asked it to watch your main branch, a GitHub Action was generated for you. The GitHub Action listens for commits and pull requests to your repository's main branch. Then when the GitHub Action detects these changes, it builds and publishes your app.
You may remember when you created the Azure Static Web Apps resource that you provided the folder location for your API project. You provided the default value of Api. However, since you didn't have an API in the Api folder at that time, Azure Static Web Apps didn't attempt to publish an API.
Now, everything changes.
GitHub Action configuration
The folder .github/workflows contains your GitHub Action file. The file contains the settings for the locations of your web app, API, and build artifacts. The locations you chose when you created your Azure Static Web Apps resource are now located in this file, as shown below:
app_location: '/Client' # App source code path api_location: '/Api' # Api source code path - optional output_location: 'wwwroot' # Built app content directory - optional
api_location is set to the correct value to point to your API in your Api folder.
Trigger the GitHub Action
The GitHub Action is ready to build and publish your web app and API once it detects a change to your main branch. You could either commit directly or create a pull request to the main branch. Both of these will trigger the GitHub Action. Changes that are detected on the main branch will trigger the GitHub Action to publish the app at the same URL for your live web site.
Sometimes you want to see your changes in a staging site before publishing to the live web site. Azure Static Web Apps lets you see preview your changes through preview URLs. You can create a preview URL by creating a pull request against the branch that your GitHub Action is watching. Your live web site won't be affected. Instead, a new staging version of your app is created. If you go back and check your pull request on GitHub you'll notice that a link to the staging version posted in the Conversation tab.
The following table shows how Azure Static Web Apps will publish your app to different URLs. Your app publishes to one URL while a pull request to the same branch publishes to another URL.
|main branch||Live web site URL||
|Pull Request #5||Preview URL||
You're currently working in the api branch. You'll make a pull request from your api branch to the main branch. When you create the pull request against the main branch, the GitHub Action publishes the app to a preview URL.
Once the workflow has completed building and deploying your app, the GitHub bot adds a comment to your pull request, which contains the URL of the pre-production environment. You can click on this link to see your staged changes.
Next, you'll create a pull request and visit the staged version of your app.