次の方法で共有


Azure Static Web Apps のビルド構成

Azure Static Web Apps のビルド構成では、GitHub Actions または Azure Pipelines が使用されます。 サイトごとに、サイトのビルドとデプロイの方法を制御する YAML 構成ファイルがあります。 この記事では、ファイルの構造とオプションについて説明します。

使用可能な構成設定について、次の表で説明します。

プロパティ 内容 必須
app_location このフォルダーには、フロントエンド アプリケーションのソース コードが含まれています。 値は、GitHub のリポジトリのルートと Azure DevOps の現在の作業フォルダーに対して相対的です。 skip_app_build: true と一緒に使用すると、この値はアプリのビルド出力の場所になります。 はい
api_location このフォルダーには、API アプリケーションのソース コードが含まれています。 値は、GitHub のリポジトリのルートと Azure DevOps の現在の作業フォルダーに対して相対的です。 skip_api_build: true と一緒に使用すると、この値は API のビルド出力の場所になります。 いいえ
output_location Web アプリでビルド ステップを実行する場合、出力場所は、パブリック ファイルが生成されるフォルダーになります。 ほとんどのプロジェクトでは、output_locationapp_location に対して相対的です。 ただし、.NET プロジェクトの場合、その場所は出力フォルダーに対する相対パスです。 いいえ
app_build_command Node.js アプリケーションの場合は、静的コンテンツ アプリケーションをビルドするためのカスタム コマンドを定義できます。

たとえば、Angular アプリケーションの運用ビルドを構成するには、build-prod という名前の npm スクリプトを作成して ng build --prod を実行し、カスタム コマンドとして npm run build-prod を入力します。 空白のままにすると、ワークフローでは npm run build または npm run build:azure コマンドの実行が試みられます。
いいえ
api_build_command Node.js アプリケーションの場合、Azure Functions API アプリケーションをビルドするためのカスタム コマンドを定義できます。 いいえ
skip_app_build フロントエンド アプリのビルドをスキップするには、値を true に設定します。 いいえ
skip_api_build API 関数のビルドをスキップするには、値を true に設定します。 いいえ
cwd
(Azure Pipelines のみ)
作業フォルダーへの絶対パス。 既定値は $(System.DefaultWorkingDirectory) です。 いいえ
build_timeout_in_minutes ビルド タイムアウトをカスタマイズするには、この値を設定します。 既定値は 15 です。 いいえ

これらの設定を使用すると、静的 Web アプリの継続的インテグレーションと継続的デリバリー (CI/CD) を実行するために、GitHub Actions または Azure Pipelines を設定できます。

ファイル名と場所

GitHub アクションによって構成ファイルが生成され、.github/workflows フォルダーに格納されます。名前は次の形式で す: azure-static-web-apps-<RANDOM_NAME>.yml

[ビルド構成]

次のサンプル構成では、リポジトリの変更を監視します。 コミットが main ブランチにプッシュされると、app_location フォルダーからアプリケーションがビルドされ、output_location 内のファイルがパブリック Web に提供されます。 さらに、api フォルダー内のアプリケーションが、サイトの api パスで使用可能になります。

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"

この構成では次のようになります。

  • main ブランチのコミットが監視されます。
  • ブランチで pull request が開かれた、同期された、再度開かれた、または閉じられたときに、GitHub Actions のワークフローがトリガーmainされます。
  • on プロパティにリストされているブランチに対してコミットをプッシュするか pull request を開くと、build_and_deploy_job が実行されます。
  • app_location は、Web アプリのソース ファイルが格納されている src フォルダーを指します。 この値をリポジトリのルートに設定するには、/ を使用します。
  • api_location は、サイトの API エンドポイントの Azure Functions アプリケーションが格納されている api フォルダーを指します。 この値をリポジトリのルートに設定するには、/ を使用します。
  • output_location は、アプリのソース ファイルの最終バージョンが格納されている public フォルダーを指します。 これは、app_location に対する相対パスです。 .NET プロジェクトの場合、その場所は発行出力フォルダーに対する相対パスです。

repo_tokenaction、および azure_static_web_apps_api_token の値は、Azure Static Web Apps によって設定されるため、変更しないでください。

Close Pull Request ジョブは、ビルドとデプロイをトリガーしたプル要求を自動的に閉じます。 このオプションのジョブは、プロセスを機能させるために必要ありません。

pull request が開かれると、Azure Static Web Apps GitHub アクションによってアプリがビルドされ、ステージング環境にデプロイされます。 その後、Close Pull Request ジョブは、pull request がまだ開いているかどうかを確認し、完了メッセージで閉じます。

このジョブは、pull request ワークフローを整理し、古い pull request を防ぐのに役立ちます。 ランタイムが pull request を自動的に閉じると、リポジトリは最新の状態のままになり、チームに状態が通知されます。

Close Pull Request ジョブは Azure Static Web Apps GitHub Actions ワークフローの一部であり、マージ後の pull request を閉じます。 Azure/static-web-apps-deploy アクションは、認証に azure_static_web_apps_api_token を必要とするアプリを Azure Static Web Apps にデプロイします。

カスタム ビルド コマンド

Node.js アプリケーションの場合、アプリまたは API のビルド プロセス中に実行されるコマンドをきめ細かく制御できます。 次の例は、app_build_commandapi_build_command の値を使用してビルドを定義する方法を示しています。

Note

現在、Node.js ビルド用の app_build_commandapi_build_command のみを定義できます。 Node.js バージョンを指定するには、package.json ファイル内の engines フィールドを使用します。

...

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'

フロントエンド アプリのビルドをスキップする

フロントエンド アプリのビルドを完全に制御する必要がある場合は、前のステップでビルドしたアプリの自動ビルドとデプロイをバイパスできます。

フロントエンド アプリのビルドをスキップするには:

  • app_location をデプロイするファイルの場所に設定します。
  • skip_app_buildtrue に設定します。
  • output_location を空の文字列 ('') に設定します。

注意

"出力" ディレクトリに staticwebapp.config.json ファイルもコピーされていることを確認してください。

...

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

API のビルドをスキップする

API のビルドをスキップする場合、自動ビルドをバイパスし、前の手順でビルドした API をデプロイできます。

API のビルドをスキップする手順:

  • staticwebapp.config.json ファイルで、apiRuntime を正しいランタイムとバージョンに設定します。 サポートされているランタイムとバージョンの一覧については、「Azure Static Web Apps の構成」を参照してください。
    {
      "platform": {
        "apiRuntime": "node:16"
      }
    }
    
  • skip_api_buildtrue に設定します。
  • api_location は、デプロイするビルド済み API アプリを含むフォルダーに設定します。 このパスは、GitHub Actions のリポジトリ ルートおよび Azure Pipelines 内の cwd に対して相対的です。
...

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

ビルド タイムアウトの延長

既定では、アプリと API のビルドは 15 分に制限されています。 build_timeout_in_minutes プロパティを設定することで、ビルド タイムアウトを延長できます。

...

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

デプロイ シークレットを使用せずにワークフローを実行する

一部のシークレットが見つからない場合でも、ワークフローを処理し続ける必要がある場合があります。 SKIP_DEPLOY_ON_MISSING_SECRETS 環境変数を true に設定して、定義されたシークレットなしで続行するようにワークフローを構成します。

この機能を有効にすると、サイトのコンテンツをデプロイせずにワークフローを続行できます。

...

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:
  SKIP_DEPLOY_ON_MISSING_SECRETS: true

環境変数

ビルドの環境変数を設定するには、ジョブの構成の env セクションを使用します。

Oryx で使用される環境変数の詳細については、「Oryx 構成」を参照してください。

...

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

Monorepo のサポート

Monorepo は、複数のアプリケーションのコードが格納されているリポジトリです。 ワークフローでは、既定でリポジトリ内のすべてのファイルを追跡しますが、1 つのアプリを対象とするように構成を調整できます。

1 つのアプリに対してワークフロー ファイルをターゲットにするには、push セクションと pull_request セクションにパスを指定します。

monorepo を設定すると、各静的アプリ構成のスコープは、1 つのアプリのファイルのみになります。 リポジトリの .github/workflows フォルダー内で異なるワークフロー ファイルが同時に存在します。

├── .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

次の例では、azure-static-web-apps-purple-pond.yml という名前のファイルの push セクションと pull_request セクションに paths ノードを追加する方法を示しています。

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

この例では、次のファイルに加えられた変更によってのみ、新しいビルドがトリガーされます。

  • app1 フォルダー内のすべてのファイル
  • api1 フォルダー内のすべてのファイル
  • アプリの azure-static-web-apps-purple-pond.yml ワークフロー ファイルへの変更

次のステップ