Deploying from release branches

[donniehale-awh]

Is there a way that the static web apps Github action can be used with a github model that uses release branches? I do have a React app successfully deploying to a static web app. I've read the workflow yaml file in detail.

Below I've listed the documents I've read - I think it's pretty extensive. From those documents and the "opinionated" approach that static web apps seems to take, it seems like I could get close with the Github action as it's currently implemented; but I don't think that the way we've typically managed releases and deployments is supported.

When we have a release candidate, we create a release branch. We tag that branch. Then we do deployments to Test, UAT, and Production environments from that branch / tag. This works extremely well for us. It also means that "main" corresponds to our "Development" environment, not production.

The shortest way I can think of to describe what is missing is a suffix or perhaps branch-suffix option to the Github action such that if the branch which triggers the workflow is "release/1.0", the suffix on the static web app URL could be set to something like "test".

I'm comfortable creating workflows to be triggered by Github releases or by workflow dispatches. And those can be on arbitrary branches. But from the documentation, it seems that if the branch that triggers the workflow is "release/1.0", then the Github action would try to make that the URL suffix (which is likely invalid, at least as is).

In addition, since "main" for us is for our "development" environment, we'd want to set the suffix for a merge to main to "dev". It doesn't seem like that is possible. I have seen the documentation for the production_branch option on the Github action. That would let us ensure that main does not deploy to production. But, if I read the docs correctly, the suffix for a merge to main would then be "main" rather than "dev".

If anyone can point me in a direction that can make this work, that would be great. Static web apps really seems like a great solution for a common application architecture. But its "opinionated-ness" about how branches map to environments is a bit inflexible for us at this point.

Thanks. Articles I've read:

https://docs.microsoft.com/en-us/azure/static-web-apps/build-configuration?tabs=github-actions#build-and-deploy

https://docs.microsoft.com/en-us/azure/static-web-apps/preview-environments

https://docs.microsoft.com/en-us/azure/static-web-apps/branch-environments

https://github.com/Azure/static-web-apps-deploy/blob/v1/action.yml

https://docs.microsoft.com/en-us/learn/paths/azure-static-web-apps/

[anthonychu]

I think this might be possible today but need to think about it a bit. Do you have a sample workflow file for how you'd like it to work? Particularly interested in how the workflow is structured to progress the deployment to each environment.

[donniehale-awh]

Thank you very much for the response. We have 3 workflows. Development is triggered by merges to main. Test is triggered by Github releases. And UAT/Production is workflow dispatches. Here's what I think are the relevant portions of the workflows.

Development (note the condition within the job)

on:
  pull_request:
    branches: [ main ]
    types:
      - closed

jobs:
  deploy_dev:
    name: Deploy to Development Environment

    # If the closing of the PR was because it was merged
    if: github.event.pull_request.merged == true

Test

on:
  release:
    types: [published]

When we create the Github release, it's from a branch named release/#.# (which could be a newly-created branch if it's the first Github release for that version) with a tag named ABC-#.#.#. Not sure if that matters, but wanted to provide the info.

UAT / Production

on:
  workflow_dispatch:
    inputs:
      releaseTag:
        description: 'Release tag (e.g. ABC-0.1.0)'
        required: true
        type: string
      targetEnvironment:
        description: 'Target Environment'
        required: true
        default: 'UAT'
        type: choice
        options:
        - UAT
        - Production

For UAT/Production, via a workflow dispatch, we enter the tag (as previously mentioned) and select the target environment.

Let me know if this answers your question and/or if you'd like additional information.

Thank you again for the courtesy of your reply.

[anthonychu]

This is a super interesting workflow @donniehale-awh!

You can do this using the new deployment_environment input parameter (so new that we haven't documented it yet!).

To deploy your main branch to development:

https://github.com/anthonychu/20220420-issue-staticwebapps-787/blob/main/.github/workflows/deploy-to-development.yml

name: Deploy to development

on:
  push:
    branches:
      - main

jobs:
  build_and_deploy_job:
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} 
          action: "upload"
          app_location: "/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "" # Built app content directory - optional
          deployment_environment: "development"

Deploy published releases to test:

https://github.com/anthonychu/20220420-issue-staticwebapps-787/blob/main/.github/workflows/deploy-to-test.yml

name: Deploy to test

on:
  release:
    types: [published]

jobs:
  build_and_deploy_job:
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} 
          action: "upload"
          app_location: "/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "" # Built app content directory - optional
          deployment_environment: "test"

Manually deploy a release to uat and production:

https://github.com/anthonychu/20220420-issue-staticwebapps-787/blob/main/.github/workflows/deploy-to-uat-production.yml

name: Deploy to uat/production

on:
  workflow_dispatch:
    inputs:
      releaseTag:
        description: 'Release tag (e.g. ABC-0.1.0)'
        required: true
        type: string
      targetEnvironment:
        description: 'Target Environment'
        required: true
        default: 'uat'
        type: choice
        options:
        - uat
        - production

jobs:
  build_and_deploy_job:
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
          ref: ${{ github.event.inputs.releaseTag }}
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
          repo_token: ${{ secrets.GITHUB_TOKEN }}
          action: "upload"
          app_location: "/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "" # Built app content directory - optional
          deployment_environment: "${{ github.event.inputs.targetEnvironment != 'production' && github.event.inputs.targetEnvironment || '' }}"

See the workflow runs here: https://github.com/anthonychu/20220420-issue-staticwebapps-787/actions

[anthonychu]

In the portal screenshot above, the production, test, and uat environments are showing main as their branches. We're looking into this. If you look at the GitHub Actions runs, they're correctly pulling and deploying the correct tags:

/cc @mishapos

[donniehale-awh]

@anthonychu This is fantastic! Thank you.

Some follow-up questions:

1. Will the uses: Azure/static-web-apps-deploy@v1 get a version of the action which has the deployment_environment option?

2. Is the literal value specified for the deployment_environment option the suffix that is appended to the URL? Maybe you could paste examples of the resulting URLs for development, test, and uat? We typically just use dev, so I want to confirm my expectations.

3. What are the semantics of the deployment_environment option with respect to the "production" environment? If it's the literal value production, does it go to the production environment? Or does the option need to not exist or be empty to indicate "production"?

I think that's what you're trying to address with this in the last workflow:

deployment_environment: "${{ github.event.inputs.targetEnvironment != 'production' && github.event.inputs.targetEnvironment || '' }}"

But the || '' at the end doesn't look right to me, or I'm misunderstanding it.

Thanks again!

[anthonychu]

Will the uses: Azure/static-web-apps-deploy@v1 get a version of the action which has the deployment_environment option?

Yes it understands the deployment_environment input but will generate a warning right now. The warning should go away soon.

Is the literal value specified for the deployment_environment option the suffix that is appended to the URL? Maybe you could paste examples of the resulting URLs for development, test, and uat? We typically just use dev, so I want to confirm my expectations.

Yes. It's the name of the environment and it appears in the URL like https://happy-pond-09c65c100-uat.eastasia.1.azurestaticapps.net/

What are the semantics of the deployment_environment option with respect to the "production" environment? If it's the literal value production, does it go to the production environment? Or does the option need to not exist or be empty to indicate "production"?

I know empty works. @mishapos Is there another value that also indicates production?

[anthonychu]

But the || '' at the end doesn't look right to me, or I'm misunderstanding it.

This is a hack syntax to mimic a ternary operator in GitHub Actions.

"${{ github.event.inputs.targetEnvironment != 'production' && github.event.inputs.targetEnvironment || '' }}"

This means if it's not production, it'll just the targetEnvironment input, else use empty string.

[donniehale-awh]

Again, excellent! I'm going to try this as soon as I get the opportunity. One other subtlety I didn't bring up is that the build commands for our environments are slightly different because we use the React .env file paradigm for configuration information. I know there's the app_build_command parameter, but I want to make sure I've verified using that before I declare victory for us.

I expect I'll be checking back here sometime this week with results and possibly comments.

Thanks again.

[anthonychu]

What do you need for the .env files to work? Do you need to set an environment variable so it picks up the right file for each environment?

[donniehale-awh]

We're following the approach here: https://create-react-app.dev/docs/adding-custom-environment-variables/

We have a .env file per environment (e.g. .env.development). They contain environment-specific settings like the base URL to an asp.net core API application.

Then we add scripts to package.json, e.g.:

  "scripts": {
    "start": "rimraf ./build && env-cmd -f .env.local react-scripts start",
    "build:development": "env-cmd -f .env.development npm run build",
    "build:test": "env-cmd -f .env.test npm run build",
    "build:uat": "env-cmd -f .env.uat npm run build",
    "build:production": "env-cmd -f .env npm run build",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },

So the app_build_command for development would be npm run build:development.

Does that answer your question?

[donniehale-awh]

Since I have your attention, a hopefully quick question: Is there any way to create an Azure Static Web App without being forced into the Github login (or without any up-front connection to a repository)? The Azure portal seems to require it, and the docs for the Azure CLI command seem to imply that it's required: https://docs.microsoft.com/en-us/cli/azure/staticwebapp?view=azure-cli-latest#az-staticwebapp-create

Since I'm going to write our own workflows, it would be ideal if I could create the Azure Static Web App without any up-front repository connection, grab the management token, and use it with my workflows.

Thanks again.

[marianfoo]

Hey @donniehale-awh ,
i had the same requirement and created this workflow:
https://github.com/ui5-community/bestofui5-website/blob/main/.github/workflows/azure_static_create.yml
It creates first the app with the GitHub Branch Name, but that also can be a input.
Before that i login with credentials and after the creation can get the api key to use Azure/static-web-apps-deploy.
Does that help you or what was your solution?

[donniehale-awh]

@anthonychu I tried using deployment_environment for our development workflow:

      - name: Build and Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_AGREEABLE_OCEAN_0499C140F }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/Source/my-web" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "build" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######
          app_build_command: npm run build:development
          deployment_environment: dev

I saw the warning you mentioned. The build worked correctly. I'm seeing the "development" version of the app.

However, the environment "name" and "suffix" is "3", i.e. not "dev". In the "Environments" section of the Azure portal for the app, the "Name" of the preview deployment is "#3 - Devops/ow 5 web deployment". And the URL suffix is "-3" rather than "-dev". It looks like the "3" comes from the PR#.

Is there a way to correct this? Is this what you would expect? From our previous discussions, I was expecting the environment to be named "dev" and the suffix to be "-dev". Thoughts?

[donniehale-awh]

Maybe it's because my trigger is pull_request, and your example above was on push? Is there some built-in logic in the action that's sort of "hard coded" if the triggering event is a PR?

[donniehale-awh]

I think that was the issue. I changed the trigger to push, and now the name and suffix are dev. Sorry for the false alarm. I think we can live with push - it has the advantage of running even if it's a direct push to main rather than a PR.

[donniehale-awh]

The test deploy triggered on a Github release being published succeeded. Phenomenal!

[donniehale-awh]

Getting back to you, @anthonychu. Deployments are working to dev, test, and uat as preview/staging environments and to production as the production environment. The latter two (uat and production) are triggered by workflow dispatches.

I wouldn't mind an answer to my earlier question about creating a new Azure Static Web App without being forced to immediately connect to a repository. See: #787 (comment)

But other than that, the point of my question in this discussion has been answered. Thank you.