GithubHelp home page GithubHelp logo

appservice-build's Introduction

GitHub Action for building Azure Web Apps

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

A repo for Sample apps and sample workflows.

This repository contains the GitHub Action for building Azure Web Apps on Linux using the Oryx build system. Currently, the following platforms can be built using this GitHub Action:

  • Golang
  • Java
  • .NET Core
  • Node
  • PHP
  • Python
  • Ruby

Note: as this list may become out of date, please refer to this document in the Oryx repository for a more accurate list of platforms and their versions that can be built.

If you are looking for a GitHub Action to deploy your Azure Web App, consider using azure/webapps-deploy.

If you are looking for a GitHub Action to build and deploy Azure Container Apps, consider using azure/container-apps-deploy-action

The definition of this GitHub Action is in action.yml.

End-to-End Sample Workflows

Dependencies on other GitHub Actions

  • actions/checkout
    • Checkout your Git repository content into the GitHub Actions agent

Other GitHub Actions

Sample workflow to build a web app

The following is a sample of a workflow that builds a web app in a repository whenever a commit is pushed:

on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Cloning repository
        uses: actions/checkout@v1

      - name: Building web app
        uses: azure/appservice-build@v3
        with:
          platform: <PLATFORM_NAME>
          platform-version: <PLATFORM_VERSION>
          source-directory: <SOURCE_DIR>
          output-directory: <OUTPUT_DIR>

Sample workflow to build and deploy an Azure Web App

The following is a sample workflow that builds a web app in a repository and then deploys it to Azure whenever a commit is pushed:

on: push

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Cloning repository
        uses: actions/checkout@v1

      - name: Building web app
        uses: azure/appservice-build@v3
        with:
          platform: <PLATFORM_NAME>
          platform-version: <PLATFORM_VERSION>
          source-directory: <SOURCE_DIR>
          output-directory: <OUTPUT_DIR>

      - name: Deploying web app to Azure
        uses: azure/webapps-deploy@v1
        with:
          app-name: <WEB_APP_NAME>
          publish-profile: ${{ secrets.AZURE_WEB_APP_PUBLISH_PROFILE }}

The following variables should be replaced in your workflow:

  • <WEB_APP_NAME>

    • Name of the web app that's being deployed
    • Required - Used only for the azure/webapps-deploy GitHub Action
  • <PLATFORM_NAME>

    • Programming platform used by the web app that's being deployed
    • Optional - Oryx will detect the provided application's platform if not provided
  • <PLATFORM_VERSION>

    • Version of programming platform used by the web app
    • Optional - Oryx will determine the version from source files if version was not set.
    • The following are the default versions used per platform if a version cannot be detected by Oryx:
  • <SOURCE_DIR>

    • Relative path (within the repo) to the source directory of the web app that's being deployed
    • Optional - The value of GITHUB_WORKSPACE environment variable will be used if not provided
  • <OUTPUT_DIR>

    • The directory where the build output will be copied to
    • Optional - The build output will not be copied to a separate directory if not provided

The following variable should be set in the GitHub repository's secrets store:

  • AZURE_WEB_APP_PUBLISH_PROFILE
    • The contents of the publish profile file (.publishsettings) used to deploy the web app; for more information on setting this secret, please see the azure/webapps-deploy action

Privacy

For more information about Microsoft's privacy policy, please see the PRIVACY.md file.

Security

Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include Microsoft, Azure, DotNet, AspNet, Xamarin, and our GitHub organizations.

For more information about Microsoft's privacy policy, please see the SECURITY.md file.

Disable Data Collection

To disable this GitHub Action from collecting any data, please set the environment variable ORYX_DISABLE_TELEMETRY to true, as seen below:

- name: Building web app
  uses: azure/appservice-build@v3
  env:
    ORYX_DISABLE_TELEMETRY: true

Contributing

For more information on contributing to this project, please see the CONTRIBUTING.md file.

License

For more information on contributing to this project, please see the LICENSE.md file.

appservice-build's People

Contributors

arroyc avatar cormacpayne avatar kichalla avatar microsoft-github-operations[bot] avatar qianz2 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

appservice-build's Issues

Run custom script using appservice-build

I would like to install a private repository when building a webapp. Right now we use a GITHUB ACCES TOKEN when deploying to a standard ubuntu server as following:

name: My App
on:
  push:
    branches:
      - main
env:
  AZURE_WEBAPP_NAME: my-app
  AZURE_WEBAPP_PACKAGE_PATH: '.'
  PYTHON_VERSION: '3.8' # supports 3.6, 3.7, 3.8)
jobs:
  build-and-deploy-to-Azure:
    runs-on: ubuntu-latest
    steps:
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@master
    - name: Setup Python ${{ env.PYTHON_VERSION }} Environment
      uses: actions/setup-python@v2
      with:
        python-version: ${{ env.PYTHON_VERSION }}
    - name: 'Install dependencies'
      run: |
        python -m pip install --upgrade pip
        git config --global url."https://${{ secrets.ACCESS_TOKEN }}@github".insteadOf https://github
        pip install -r requirements.txt
    - name: 'Deploy to Azure WebApp'
      uses: azure/webapps-deploy@v2
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

Notice the

git config --global url."https://${{ secrets.ACCESS_TOKEN }}@github".insteadOf https://github

And in our requirements.txt we have:

git+https://github.com/orgname/reponame.git#egg=reponame

But obviously this will fail with appservice-build because it has no access to our secrets.ACCESS_TOKEN during runtime. Is there any way to get this working while deploying to Azure Web Apps through GH Actions?

App Service Build Action failing with Error: While parsing a block mapping, did not find expected key.

Hi Team,

I have created the below reusable composite action, but while calling the action, I am being encountered with following error. Could you please help me fix it, if am doing something wrong?

Composite actions path: https://gist.github.com/veereshkumarn/faeaed6dc73fb662d16fb8a0b04425b1#file-appservice-build-yaml
CI-Workflow File: https://gist.github.com/veereshkumarn/8054351c65b3205eae2b53d5452b85f8#file-ci_workflow-yaml
Error Details:
Error: /home/runner/work/paas-workflow/./.github/actions/azure-webapp-build/action.yaml: (Line: 9, Col: 120, Idx: 494) - (Line: 9, Col: 1[3](https://github.com/owner/paas-workflow/actions/runs/4012756665/jobs/6891450618#step:3:3)4, Idx: 508): While parsing a block mapping, did not find expected key. Error: System.ArgumentException: Unexpected type '' encountered while reading 'action manifest root'. The type 'MappingToken' was expected. at GitHub.DistributedTask.ObjectTemplating.Tokens.TemplateTokenExtensions.AssertMapping(TemplateToken value, String objectDescription) at GitHub.Runner.Worker.ActionManifestManager.Load(IExecutionContext executionContext, String manifestFile) Error: Fail to load /home/runner/work/devsecops-101[5](https://github.com/owner/paas-workflow/actions/runs/4012756665/jobs/6891450618#step:3:5)529-paas-workflow/paas-workflow/./.github/actions/azure-webapp-build/action.yaml

entrypoint.sh assumes public github.com server

The current entrypoint.sh file assumes that the repository is hosted on github.com and throws an error when run from Github Enterprise server:

url="https://api.github.com/repos/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}/jobs"

https://api.github.com needs to be replaced with ${GITHUB_API_URL} as documented here. I will send a PR for this.

Proxy configuration

Hello,
Is it possible to use this action with a non-public web apps(app services)?
we use an application with azure vnet integration,all 0.0.0.0 traffic redirect to virtual appliance/proxy.
we cannot complete this task using the ubuntu-latest runner, we have our own for internal connection
no matter what we do, this action does not work.

curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

env:
HTTP_PROXY: 'http://xxx:9400'
HTTPS_PROXY: 'http://xxx:9400'
NO_PROXY: xxx
NODE_EXTRA_CA_CERTS: xxx

Doesn't help.
Thank you!

example of pipeline:

name: Deployment to Production

on:  
  workflow_dispatch:

env:
  AZURE_WEBAPP_NAME: xxx-backend # set this to your application's name
  AZURE_WEBAPP_PACKAGE_PATH: 'backend' # set this to the path to your web app project, defaults to the repository root
  PYTHON_VERSION: '3.10.8'

jobs:
  build:
    runs-on: private-runner
    env:
        HTTP_PROXY: 'http://xxx:9400'  
        HTTPS_PROXY: 'http://xxx:9400'
        NO_PROXY: 127.0.0.1,localhost,,azurewebsites.net
        NODE_EXTRA_CA_CERTS:xxx
        
    environment: Production
    steps:
    - uses: actions/checkout@v3
    - name: Set up Python 3.x
      uses: actions/setup-python@v2
      with:
        python-version: ${{ env.PYTHON_VERSION }}

    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/requirements.txt
    - name: Building web app
      uses: azure/appservice-build@v3
      with:
        platform: python
        platform-version: ${{ env.PYTHON_VERSION }} # Change this to the appropriate version
        source-directory: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }} # This is the source directory

    - name: Deploy web App using GH Action azure/webapps-deploy
      uses: azure/webapps-deploy@v2
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        publish-profile: ${{ secrets.xxxx_PROD }}
        package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

No ARM control over build properties

There is a critical github workflow initialization capability which exists for Azure static websites, that apparently does not exist for Azure App Services. According to the static website ARM grammar, the following path properties can be specified in the static website ARM template:

    "repositoryToken": "string",
    "repositoryUrl": "string",
    "buildProperties": {
      "appLocation": "string",  //path within the repo, to the app that must be built.
      "apiLocation": "string",   //path to API code, if applicable.
      "outputLocation": "string" //path to the bits, after build completes.
    }

When a static website ARM template is deployed, a github workflow action file is automatically created and checked into the repo. That workflow action file is populated with the buildProperties supplied above, as shown below:

      - 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_YELLOW_DESERT_083CEBA0F }}
          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: "/aliriam-rfp-poc" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "dist/aliriam-rfp-poc" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######

In contrast, the Azure App Service ARM grammar does not have the ability to specify these build-related paths. Thus the github workflow file that is generated - does not have the correct app path(s). It is automatically a failed deployment. To be clear, unlike the static website ARM grammar, the App Service ARM grammar does not directly describe any repo properties. Instead it depends on a Microsoft.Web/sites/sourcecontrols sub-grammar, which unfortunately also does not have build-path properties.

Furthermore, the Azure portal App Service "create resource" blade also does not seem to support such build properties. Apparently the only way I can set these build-path properties, is by hand-editing the github workflow file after my Azure App Service resource has already been deployed. This is very awkward, and largely undermines the point of having ARM templates.

Indeed, the "awkward" goes a step further because the auto-generated github workflow file contains default references to "myapp", which has no relationship to what my app is called, or the folders used by my app. Notice:

      - name: dotnet publish
        run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp

Even if there was a way to compensate by embedding the proper build path into to the DOTNET_ROOT variable, the appended myapp will still be wrong.

So again, it looks like I'm stuck doing post-deployment manual fixes to the auto-generated github workflow file. Is there some trick I am overlooking? Right now this looks like a critical missing capability for ARM deployments.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.