Buildconfiguratie voor Azure Static Web Apps

De Azure Static Web Apps buildconfiguratie wordt mogelijk gemaakt door GitHub Actions of Azure Pipelines. Elke site heeft een YAML-configuratiebestand waarmee wordt bepaald hoe een site wordt gebouwd en geïmplementeerd. In dit artikel worden de structuur en opties van het bestand uitgelegd.

De volgende tabel bevat de beschikbare configuratie-instellingen.

Eigenschap	Beschrijving	Vereist
app_location	Deze map bevat de broncode voor uw front-endtoepassing. De waarde is relatief ten opzichte van de hoofdmap van de opslagplaats in GitHub en de huidige werkmap in Azure DevOps. Bij gebruik met skip_app_build: true, is deze waarde de uitvoerlocatie van de build van de app.	Yes
api_location	Deze map met de broncode voor uw API-toepassing. De waarde is relatief ten opzichte van de hoofdmap van de opslagplaats in GitHub en de huidige werkmap in Azure DevOps. Bij gebruik met skip_api_build: trueis deze waarde de uitvoerlocatie van de build van de API.	No
output_location	Als uw web-app een build-stap uitvoert, is de uitvoerlocatie de map waarin de openbare bestanden worden gegenereerd. Voor de meeste projecten is de output_location relatief ten opzichte van de app_location. Voor .NET-projecten is de locatie echter relatief ten opzichte van de uitvoermap voor publiceren.	No
app_build_command	Voor Node.js toepassingen kunt u een aangepaste opdracht definiëren om de toepassing voor statische inhoud te bouwen. Als u bijvoorbeeld een productiebuild wilt configureren voor een Angular toepassing maakt u een npm-script met de naam build-prod om uit te voeren ng build --prod en in te voeren npm run build-prod als de aangepaste opdracht. Als dit leeg blijft, probeert de werkstroom de npm run build opdrachten of npm run build:azure uit te voeren.	No
api_build_command	Voor Node.js toepassingen kunt u een aangepaste opdracht definiëren om de Azure Functions API-toepassing te bouwen.	No
skip_app_build	Stel de waarde in op om true het bouwen van de front-end-app over te slaan.	No
skip_api_build	Stel de waarde in op om true het bouwen van de API-functies over te slaan.	No
cwd (alleen Azure Pipelines)	Absoluut pad naar de werkmap. De standaardwaarde is $(System.DefaultWorkingDirectory).	No
build_timeout_in_minutes	Stel deze waarde in om de time-out van de build aan te passen. De standaardwaarde is 15.	No

Met deze instellingen kunt u GitHub Actions of Azure Pipelines instellen voor het uitvoeren van continue integratie/continue levering (CI/CD) voor uw statische web-app.

Bestandsnaam en -locatie

GitHub Actions

Het configuratiebestand wordt gegenereerd door GitHub en opgeslagen in de map .github/workflows , met de naam met de volgende indeling: azure-static-web-apps-<RANDOM_NAME>.yml.

Azure Pipelines

Het configuratiebestand wordt standaard opgeslagen in de hoofdmap van uw opslagplaats met de naam azure-pipelines.yml.

Configuratie compileren

Met de volgende voorbeeldconfiguratie wordt de opslagplaats gecontroleerd op wijzigingen. Wanneer doorvoeringen naar de main vertakking worden gepusht, wordt de toepassing gebouwd op basis van de app_location map en worden bestanden in de output_location naar het openbare web aangeboden. Bovendien is de toepassing in de api-map beschikbaar onder het pad van api de site.

GitHub Actions

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    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 }} # Used for GitHub integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations ######
          app_location: "src" # App source code path relative to repository root
          api_location: "api" # Api source code path relative to repository root - optional
          output_location: "public" # Built app content directory, relative to app_location - optional
          ###### End of Repository/Build Configurations ######

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
          action: "close"

In deze configuratie:

• De main vertakking wordt gecontroleerd op doorvoeringen.
• Een GitHub Actions werkstroom wordt geactiveerd wanneer een pull-aanvraag in de main vertakking wordt geopend, gesynchroniseerd, opnieuw geopend of gesloten.
• De build_and_deploy_job wordt uitgevoerd wanneer u doorvoeringen pusht of een pull-aanvraag opent voor de vertakking die in de on eigenschap wordt vermeld.
• De app_location verwijst naar de src map met de bronbestanden voor de web-app. Als u deze waarde wilt instellen op de hoofdmap van de opslagplaats, gebruikt u /.
• De api_location verwijst naar de api map met de Azure Functions-toepassing voor de API-eindpunten van de site. Als u deze waarde wilt instellen op de hoofdmap van de opslagplaats, gebruikt u /.
• De output_location verwijst naar de public map met de definitieve versie van de bronbestanden van de app. Het is relatief ten opzichte van app_location. Voor .NET-projecten is de locatie relatief ten opzichte van de uitvoermap voor publiceren.

Wijzig de waarden voor repo_token, actionen azure_static_web_apps_api_token niet omdat ze voor u zijn ingesteld door Azure Static Web Apps.

Azure Pipelines

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - checkout: self
    submodules: true
  - task: AzureStaticWebApp@0
    inputs:
      app_location: 'src' # App source code path relative to cwd
      api_location: 'api' # Api source code path relative to cwd
      output_location: 'public' # Built app content directory relative to app_location - optional
      cwd: '$(System.DefaultWorkingDirectory)/myapp' # Working directory - optional
      azure_static_web_apps_api_token: $(deployment_token)

In deze configuratie:

• De main vertakking wordt gecontroleerd op doorvoeringen.
• De app_location verwijst naar de src map met de bronbestanden voor de web-app. Deze waarde is relatief ten opzichte van de werkmap (cwd). Als u deze wilt instellen op de werkmap, gebruikt /u .
• De api_location verwijst naar de api map met de Azure Functions-toepassing voor de API-eindpunten van de site. Deze waarde is relatief ten opzichte van de werkmap (cwd). Als u deze wilt instellen op de werkmap, gebruikt /u .
• De output_location verwijst naar de public map met de definitieve versie van de bronbestanden van de app. Deze waarde is relatief ten opzichte van app_location. Voor .NET-projecten is de locatie relatief ten opzichte van de uitvoermap voor publiceren.
• De cwd is een absoluut pad dat verwijst naar de werkmap. De standaardinstelling is $(System.DefaultWorkingDirectory).
• De $(deployment_token) variabele verwijst naar het gegenereerde Azure DevOps-implementatietoken.

Notitie

app_location en api_location moeten relatief zijn ten opzichte van de werkmap (cwd) en submappen onder cwd.

Aangepaste buildopdrachten

Voor Node.js toepassingen kunt u nauwkeurige controle nemen over welke opdrachten worden uitgevoerd tijdens het app- of API-buildproces. In het volgende voorbeeld ziet u hoe u build definieert met waarden voor app_build_command en api_build_command.

Notitie

Op dit moment kunt u alleen en api_build_command definiëren app_build_command voor Node.js-builds. Als u de Node.js versie wilt opgeven, gebruikt u het engines veld in het package.json bestand.

GitHub Actions

...

with:
  azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
  repo_token: ${{ secrets.GITHUB_TOKEN }}
  action: 'upload'
  app_location: '/'
  api_location: 'api'
  output_location: 'dist'
  app_build_command: 'npm run build-ui-prod'
  api_build_command: 'npm run build-api-prod'

Azure Pipelines

...

inputs:
  app_location: 'src'
  api_location: 'api'
  app_build_command: 'npm run build-ui-prod'
  api_build_command: 'npm run build-api-prod'
  output_location: 'public'
  azure_static_web_apps_api_token: $(deployment_token)

Het bouwen van een front-end-app overslaan

Als u volledige controle over de build voor uw front-end-app nodig hebt, kunt u de automatische build overslaan en de app implementeren die in een vorige stap is gebouwd.

Ga als volgende te werk om het bouwen van de front-end-app over te slaan:

• Stel app_location de bestanden in die u wilt implementeren op de locatie.
• Stel skip_app_build in op true.
• Stel in output_location op een lege tekenreeks ('').

Notitie

Zorg ervoor dat het bestand ook naar de uitvoermap is staticwebapp.config.json gekopieerd.

GitHub Actions

...

with:
  azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
  repo_token: ${{ secrets.GITHUB_TOKEN }}
  action: 'upload'
  app_location: 'src/dist'
  api_location: 'api'
  output_location: ''
  skip_app_build: true

Azure Pipelines

...

inputs:
  app_location: 'src/dist'
  api_location: 'api'
  output_location: '' # Leave this empty
  skip_app_build: true
  azure_static_web_apps_api_token: $(deployment_token)

Het bouwen van de API overslaan

Als u het bouwen van de API wilt overslaan, kunt u de automatische build overslaan en de API implementeren die in een vorige stap is gebouwd.

Stappen om het bouwen van de API over te slaan:

• Stel apiRuntime in het bestandstaticwebapp.config.json in op de juiste runtime en versie. Raadpleeg Azure Static Web Apps configureren voor de lijst met ondersteunde runtimes en versies.

  {
    "platform": {
      "apiRuntime": "node:16"
    }
  }
  

• Stel skip_api_build in op true.
• Stel in api_location op de map met de ingebouwde API-app die moet worden geïmplementeerd. Dit pad is relatief ten opzichte van de hoofdmap van de opslagplaats in GitHub Actions en cwd in Azure Pipelines.

GitHub Actions

...

with:
  azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
  repo_token: ${{ secrets.GITHUB_TOKEN }}
  action: 'upload'
  app_location: "src" # App source code path relative to repository root
  api_location: "api" # Api source code path relative to repository root - optional
  output_location: "public" # Built app content directory, relative to app_location - optional
  skip_api_build: true

Azure Pipelines

...

inputs:
  app_location: 'src'
  api_location: 'api'
  output_location: 'public'
  skip_api_build: true
  azure_static_web_apps_api_token: $(deployment_token)

Time-out van build verlengen

De app- en API-builds zijn standaard beperkt tot 15 minuten. U kunt de time-out van de build verlengen door de eigenschap in te build_timeout_in_minutes stellen.

GitHub Actions

...

with:
  azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
  repo_token: ${{ secrets.GITHUB_TOKEN }}
  action: 'upload'
  app_location: 'src'
  api_location: 'api'
  output_location: 'public'
  build_timeout_in_minutes: 30

Azure Pipelines

...

inputs:
  app_location: 'src'
  api_location: 'api'
  output_location: 'public'
  build_timeout_in_minutes: 30
  azure_static_web_apps_api_token: $(deployment_token)

Omgevingsvariabelen

U kunt omgevingsvariabelen instellen voor uw build via de sectie van de env configuratie van een taak.

GitHub Actions

...

with:
  azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
  repo_token: ${{ secrets.GITHUB_TOKEN }}
  action: 'upload'
  app_location: 'src'
  api_location: 'api'
  output_location: 'public'
env: # Add environment variables here
  HUGO_VERSION: 0.58.0

Azure Pipelines

...

inputs:
  app_location: 'src'
  api_location: 'api'
  output_location: 'public'
  azure_static_web_apps_api_token: $(deployment_token)
env: # Add environment variables here
  HUGO_VERSION: 0.58.0

Ondersteuning voor Monorepo

Een monorepo is een opslagplaats die code voor meer dan één toepassing bevat. Standaard worden met de werkstroom alle bestanden in een opslagplaats bijgehouden, maar u kunt de configuratie aanpassen aan één app.

Als u een werkstroombestand wilt richten op één app, geeft u paden op in de push secties en pull_request .

GitHub Actions

Wanneer u een monorepo instelt, wordt elke statische app-configuratie beperkt tot alleen bestanden voor één app. De verschillende werkstroombestanden staan naast elkaar in de map .github/workflows van de opslagplaats.

├── .github
│   └── workflows
│       ├── azure-static-web-apps-purple-pond.yml
│       └── azure-static-web-apps-yellow-shoe.yml
│
├── app1  👉 controlled by: azure-static-web-apps-purple-pond.yml
├── app2  👉 controlled by: azure-static-web-apps-yellow-shoe.yml
│
├── api1  👉 controlled by: azure-static-web-apps-purple-pond.yml
├── api2  👉 controlled by: azure-static-web-apps-yellow-shoe.yml
│
└── README.md

In het volgende voorbeeld ziet u hoe u een paths knooppunt toevoegt aan de secties en pull_request van een bestand met de push naam azure-static-web-apps-purple-pond.yml.

on:
  push:
    branches:
      - main
    paths:
      - app1/**
      - api1/**
      - .github/workflows/azure-static-web-apps-purple-pond.yml
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main
    paths:
      - app1/**
      - api1/**
      - .github/workflows/azure-static-web-apps-purple-pond.yml

In dit voorbeeld activeren alleen wijzigingen in de volgende bestanden een nieuwe build:

• Alle bestanden in de map app1
• Alle bestanden in de map api1
• Wijzigingen in het werkstroombestand azure-static-web-apps-purple-pond.yml van de app

Azure Pipelines

Als u meer dan één toepassing in één opslagplaats wilt ondersteunen, maakt u een afzonderlijk werkstroombestand en koppelt u deze aan verschillende Azure-pijplijnen.

Volgende stappen

Pull-aanvragen in de pre-productieomgevingen controleren