With the Azure App Service Actions for GitHub, you can automate your workflow to deploy Azure Web Apps or Azure Web Apps for Containers using GitHub Actions.

Get started today with a free Azure account.

This repository contains GitHub Action for Azure WebApp to deploy to an Azure WebApp (Windows or Linux). The action supports deploying a folder, *.jar, *.war, and *.zip files (except msBuild generated packages).

You can also use this GitHub Action to deploy your customized image into an Azure WebApps container.

For deploying container images to Kubernetes, consider using Kubernetes deploy action. This action requires that the cluster context be set earlier in the workflow by using either the Azure/aks-set-context action or the Azure/k8s-set-context action.

The definition of this GitHub Action is in action.yml. startup-command is applicable only for Linux apps and not for Windows apps. Currently startup-command is supported only for Linux apps when SPN is provided and not when publish profile is provided.

NOTE: you must have write permissions to the repository in question. If you're using a sample repository from Microsoft, be sure to first fork the repository to your own GitHub account.

• Checkout your Git repository content into GitHub Actions agent.

• Authenticate using Azure Web App Publish Profile or using the Azure Login Action. Examples of both are given later in this article.

  The action supports using publish profile for Azure Web Apps (both Windows and Linux) and Azure Web Apps for Containers (both Windows and Linux).

Note: As of October 2020, Linux web apps will need the app setting WEBSITE_WEBDEPLOY_USE_SCM set to true before downloading the publish profile from the portal. This requirement will be removed in the future.

The action does not support multi-container scenario with publish profile.

• Enable Run from Package, otherwise remote build will take time and the deployment will take longer.

• To build app code in a specific language based environment, use setup actions:

  • Setup DotNet Sets up a dotnet environment by optionally downloading and caching a version of dotnet by SDK version and adding to PATH.
  • Setup Node sets up a node environment by optionally downloading and caching a version of node - npm by version spec and add to PATH
  • Setup Python sets up Python environment by optionally installing a version of python and adding to PATH.
  • Setup Java sets up Java app environment optionally downloading and caching a version of java by version and adding to PATH. Downloads from Azul's Zulu distribution.

• To build and deploy a containerized app, use docker-login to log in to a private container registry such as Azure Container registry.

Once login is done, the next set of Actions in the workflow can perform tasks such as building, tagging and pushing containers.

Note: Workflow samples with sample application code and deployment procedure for various runtime environments are given at https://github.com/Azure/actions-workflow-samples/tree/master/AppService.

For example, if You want to deploy a Java WAR based app, You can follow the link https://github.com/Azure-Samples/Java-application-petstore-ee7 in the sample workflow templates.

0. Review the pre-requisites outlined in the "Dependencies on Other Github Actions" section above.
1. Create a web app in Azure using app service. Follow the tutorial Azure Web Apps Quickstart.
2. Pick a template from the following table depends on your Azure web app runtime and place the template to .github/workflows/ in your project repository.
3. Change app-name to your Web app name created in the first step.
4. Commit and push your project to GitHub repository, you should see a new GitHub Action initiated in Actions tab.

# File: .github/workflows/workflow.yml

on: push

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout Github Action' 
      uses: actions/checkout@master

    - name: Setup Node 10.x
      uses: actions/setup-node@v1
      with:
        node-version: '10.x'
    - name: 'npm install, build, and test'
      run: |
        npm install
        npm run build --if-present
        npm run test --if-present

    - name: 'Run Azure webapp deploy action using publish profile credentials'
      uses: azure/webapps-deploy@v2
      with:
        app-name: node-rn
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}

on: [push]

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout Github Action'
      uses: actions/checkout@master

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

Webapps deploy Actions is supported for the Azure public cloud as well as Azure government clouds ('AzureUSGovernment' or 'AzureChinaCloud') and Azure Stack ('AzureStack') Hub. Before running this action, login to the respective Azure Cloud using Azure Login by setting appropriate value for the environment parameter.

For any credentials like Azure Service Principal, Publish Profile etc add them as secrets in the GitHub repository and then use them in the workflow.

The above example uses app-level credentials i.e., publish profile file for deployment.

Follow the steps to configure the secret:

• Note: As of October 2020, Linux web apps will need the app setting WEBSITE_WEBDEPLOY_USE_SCM set to true before continuing with next step of downloading the publish profile. This requirement will be removed in the future.
• Download the publish profile for the WebApp from the portal (Get Publish profile option)
• While deploying to slot, download the publish profile for slot. Also specify the slot-name field with the name of the slot.
• Define a new secret under your repository settings, Add secret menu
• Paste the contents for the downloaded publish profile file into the secret's value field
• Now in the workflow file in your branch: .github/workflows/workflow.yml replace the secret for the input publish-profile: of the deploy Azure WebApp action (Refer to the example above)

Use Azure Login with a service principal that's authorized for Web app deployment. Once login is done, the next set of Azure actions in the workflow can re-use the same session within the job.

on: [push]

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout Github Action'
      uses: actions/checkout@master

    - name: 'Login via Azure CLI'
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

The previous sample workflow depends on user-level credentials stored as a secret named AZURE_CREDENTIALS in your repository. The value of this secret is expected to be a JSON object that represents a service principal (an identifer for an application or process) that authenticates the workflow with Azure.

To function correctly, this service principal must be assigned the Contributor role for the web app or the resource group that contains the web app.

The following steps describe how to create the service principal, assign the role, and create a secret in your repository with the resulting credentials.

1. Open the Azure Cloud Shell at https://shell.azure.com. You can alternately use the Azure CLI if you've installed it locally. (For more information on Cloud Shell, see the Cloud Shell Overview.)

2. Use the az ad sp create-for-rbac command to create a service principal and assign a Contributor role:

   az ad sp create-for-rbac --name "{sp-name}" --sdk-auth --role contributor \
       --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Web/sites/{app-name}
   

   Replace the following:

   • {sp-name} with a suitable name for your service principal, such as the name of the app itself. The name must be unique within your organization.
   • {subscription-id} with the subscription you want to use
   • {resource-group} the resource group containing the web app.
   • {app-name} with the name of the web app.

   This command invokes Azure Active Directory (via the ad part of the command) to create a service principal (via sp) specifically for Role-Based Access Control (RBAC) (via create-for-rbac).

   The --role argument specifies the permissions to grant to the service principal at the specified --scope. In this case, you grant the built-in Contributor role at the scope of the web app in the specified resource group in the specified subscription.

   If desired, you can omit the part of the scope starting with /providers/... to grant the service principal the Contributor role for the entire resource group:

   az ad sp create-for-rbac --name "{sp-name}" --sdk-auth --role contributor \
       --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group}
   

   For security purposes, however, it's always preferable to grant permissions at the most restrictive scope possible.

3. When complete, the az ad sp create-for-rbac command displays JSON output in the following form (which is specified by the --sdk-auth argument):

   {
     "clientId": "<GUID>",
     "clientSecret": "<GUID>",
     "subscriptionId": "<GUID>",
     "tenantId": "<GUID>",
     (...)
   }

4. In your repository, use Add secret to create a new secret named AZURE_CREDENTIALS (as shown in the example workflow), or using whatever name is in your workflow file.

5. Paste the entire JSON object produced by the az ad sp create-for-rbac command as the secret value and save the secret.

NOTE: to manage service principals created with az ad sp create-for-rbac, visit the Azure portal, navigate to your Azure Active Directory, then select Manage > App registrations on the left-hand menu. Your service principal should appear in the list. Select a principal to navigate to its properties. You can also manage role assignments using the az role assignment command.

This sample assumes the node-rnc web application has been previously configured to authenticate against the private registry. If you wish to set private registry authentication settings on the workflow, you can either use:

• The command az webapp config container to configure the registry url, username and password.

• Setup the authentication settings using azure/appservice-settings action, like this for example

    - name: Set Web App ACR authentication
      uses: Azure/appservice-settings@v1
      with:
       app-name: 'node-rnc'
       app-settings-json: |
         [
             {
                 "name": "DOCKER_REGISTRY_SERVER_PASSWORD",
                 "value": "${{ secrets.REGISTRY_PASSWORD }}",
                 "slotSetting": false
             },
             {
                 "name": "DOCKER_REGISTRY_SERVER_URL",
                 "value": "https://contoso.azurecr.io",
                 "slotSetting": false
             },
             {
                 "name": "DOCKER_REGISTRY_SERVER_USERNAME",
                 "value": "${{ secrets.REGISTRY_USERNAME  }}",
                 "slotSetting": false
             }
         ]

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.