Déploie sur Azure Functions en utilisant GitHub Actions

Vous pouvez utiliser un workflow GitHub Actions pour construire et déployer automatiquement votre code de fonction sur Azure en utilisant le Azure/functions-actionfichier .

Pour déployer en utilisant GitHub Actions, suivez ces trois étapes clés :

Créez une identité managée attribuée par l’utilisateur dans Azure avec un identifiant fédéré qui fait confiance à votre dépôt GitHub, et attribuez-lui le rôle de Contributeur du site web dans votre application de fonction.
Ajoutez l'ID client, l'ID de locataire et l'ID d'abonnement de l'identité comme secrets de dépôt dans GitHub.
Ajoutez un fichier YAML de workflow à votre dépôt qui utilise azure/login avec OpenID Connect (OIDC) pour s’authentifier, puis appelle Azure/functions-action pour déployer.

Lorsque vous utilisez le portail Azure pour activer GitHub Actions, Fonctions effectue automatiquement ces tâches, à la fois dans votre abonnement Azure et dans votre dépôt GitHub.

Créer une configuration de workflow pour Azure Functions

Vous maintenez un fichier YAML (.yml) qui définit la configuration du workflow dans le /.github/workflows/ chemin de votre dépôt. Cette définition contient les actions et les paramètres qui composent le flux de travail, qui est spécifique au langage de développement de vos fonctions.

Choisissez une méthode pour créer votre fichier de workflow à l’aide du sélecteur en haut de l’article :

Method	Idéal pour	Prise en charge OIDC
Modèle de flux de travail	Contrôle total : copier un modèle prêt OIDC et le personnaliser	Nécessite une configuration
portail Azure	Configuration la plus simple : Portal peut créer pour vous l’identité, les identifiants et le fichier de workflow	Configuré pour vous
Marché GitHub	GitHub-first : commencer par les modèles intégrés du Marketplace de GitHub	Nécessite une modification de configuration et de gabarit

Vue d’ensemble de l'authentification

GitHub Actions doit s’authentifier avec Azure pour déployer votre code. Cet article utilise OpenID Connect (OIDC), qui est la méthode d’authentification recommandée. L’OIDC utilise des identifiants fédérés pour créer une relation de confiance entre votre dépôt GitHub et une identité managée attribuée par l’utilisateur dans Microsoft Entra. Aucun secret n’est stocké sur GitHub.

Exemple d’authentification OIDC

L’exemple en ligne suivant montre le modèle principal d’authentification et de déploiement OIDC utilisé dans tous les modèles de workflow :

permissions:
  id-token: write
  contents: read

steps:
  - name: 'Login via OIDC'
    uses: azure/login@v3
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  - name: 'Deploy to Azure Functions'
    uses: Azure/functions-action@v1
    with:
      app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
      package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}

Considérations d’authentification OIDC sur GitHub Actions

L’OIDC utilise la fédération des identités de charge de travail et ne prend en charge que les identités managées attribuées par l’utilisateur.
Lorsque vous activez un déploiement basé sur GitHub Actions dans le portail Azure, l’authentification OIDC est utilisée par défaut.
Avec OIDC, l'ID client, l'ID de locataire et l'ID d'abonnement de l'identité gérée sont stockés comme des secrets du dépôt GitHub.
Utilisez le contrôle d’accès basé sur les rôles Azure (Azure RBAC) pour limiter l’accès uniquement aux ressources Azure nécessaires à votre déploiement.

Prérequis

Un compte Azure avec un abonnement actif. Créez un compte gratuitement.
Un compte GitHub. Si vous n’en avez pas, inscrivez-vous gratuitement.
Code source du Project dans un dépôt GitHub.
Une compréhension de base des flux de travail GitHub Actions. Si vous débutez sur GitHub Actions, consultez Comprendre GitHub Actions.
Une application fonctionnelle hébergée sur Azure (uniquement en code ou basée sur conteneur).
(Déploiements de conteneurs uniquement) Un registre de conteneurs existant, tel que Azure Container Registry.

Azure CLI, lorsque vous développez localement. Vous pouvez également utiliser la Azure CLI dans Azure Cloud Shell.

Créer une identité managée pour le déploiement GitHub Actions

OpenID Connect (OIDC) est la méthode d’authentification recommandée pour les déploiements GitHub Actions sur Azure Functions. Avec OIDC, vous configurez une identité managée attribuée par l’utilisateur dans Azure et créez une relation de confiance avec votre dépôt GitHub. Le workflow peut alors s’authentifier avec Azure sans stocker les identifiants comme secrets.

Utilisez la commande az identity create pour créer une identité managée affectée par l’utilisateur :
```
az identity create --name myGitHubDeployIdentity --resource-group <RESOURCE_GROUP> \
--query "{clientId: clientId, tenantId: tenantId}" -o table
```
Remplacez <RESOURCE_GROUP> par le nom de votre groupe de ressources.
À partir de la sortie, notez les valeurs clientId et tenantId. Obtenez aussi votre ID d’abonnement :
```
az account show --query "{subId: id}" -o table
```
Vous aurez besoin de ces trois valeurs plus tard, lorsque vous ajoutez des identifiants à GitHub.

Utilisez la commande az role assignment create pour attribuer le rôle Website Contributor à l’identité gérée, avec pour étendue votre application de fonction :

IDENTITY_PRINCIPAL=$(az identity show --name myGitHubDeployIdentity --resource-group <RESOURCE_GROUP> --query 'principalId' -o tsv)
FUNCTION_APP_ID=$(az functionapp show --name <APP_NAME> --resource-group <RESOURCE_GROUP> --query 'id' -o tsv)
az role assignment create --assignee $IDENTITY_PRINCIPAL --role "Website Contributor" --scope $FUNCTION_APP_ID

Remplacez <APP_NAME> et <RESOURCE_GROUP> par les noms de votre application et de votre groupe de ressources, respectivement.

Utilisez la commande az identity federated-credential create pour créer des informations d’identification fédérées qui font confiance aux jetons provenant de votre dépôt GitHub :
```
az identity federated-credential create \
    --identity-name myGitHubDeployIdentity \
    --resource-group <RESOURCE_GROUP> \
    --name github-deploy-credential \
    --issuer https://token.actions.githubusercontent.com \
    --subject repo:<GITHUB_ORG>/<REPO_NAME>:ref:refs/heads/<BRANCH_NAME> \
    --audiences api://AzureADTokenExchange
```
Remplacez <RESOURCE_GROUP>, <GITHUB_ORG>, <REPO_NAME> et <BRANCH_NAME> par vos valeurs. Le sujet doit correspondre à la branche qui déclenche votre flux de travail.

(Optionnel) Si vous déployez un conteneur depuis Azure Container Registry, attribuez également le acrpull rôle à l'identité gérée :

IDENTITY_PRINCIPAL=$(az identity show --name myGitHubDeployIdentity --resource-group <RESOURCE_GROUP> --query 'principalId' -o tsv)
az role assignment create --assignee $IDENTITY_PRINCIPAL --role acrpull \
    --scope /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.ContainerRegistry/registries/<REGISTRY_NAME>

Remplacez <SUBSCRIPTION_ID>, <RESOURCE_GROUP> et <REGISTRY_NAME> par vos valeurs.

Ajouter des identifiants à GitHub

Utilisez les valeurs que vous avez copiées lors de la création de l’identité gérée.

Dans GitHub, accédez à votre dépôt.
Va dans Paramètres>Secrets et variables>Actions.
Dans l’onglet Secrets , sélectionnez Nouveau secret de dépôt.

Créez chacun des secrets suivants :

Nom	Value
`AZURE_CLIENT_ID`	Le `clientId` de l’identité managée
`AZURE_TENANT_ID`	La `tenantId` de l’identité gérée
`AZURE_SUBSCRIPTION_ID`	L’ID d’abonnement contenant votre application fonctionnelle

Pour les déploiements de conteneurs depuis un registre privé, il faut aussi des secrets spécifiques à chaque registre. Pour plus d’informations, voir Action de connexion Docker.

Créer le flux de travail à partir d’un modèle

La meilleure façon de créer manuellement une configuration de flux de travail consiste à commencer à partir du modèle officiellement pris en charge.

Choisissez Windows ou Linux pour vous assurer que vous obtenez le modèle pour le système d’exploitation approprié.
- Windows
- Linux
Les déploiements sur Windows utilisent runs-on: windows-latest. Les déploiements conteneurisés nécessitent Linux.

Les déploiements sur Linux utilisent runs-on: ubuntu-latest. Utilisez Linux pour les déploiements conteneurisés.

Utilisez le modèle de workflow OIDC spécifique à chaque langage issu du dépôt d’actions Azure Functions. Copiez le contenu complet du fichier dans un nouveau fichier nommé .github/workflows/deploy-function-app.yml dans votre dépôt :

name: Build and deploy .NET project to Azure Function App using OIDC

on:
  push:
    branches: [ main ]
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_NAME: 'APP_NAME'         # Set this to your function app name on Azure 
  AZURE_FUNCTIONAPP_PROJECT_PATH: '.'        # Set this to the path to your function app project, defaults to the repository root. The deploy action will package the contents of this path.
  DOTNET_VERSION: '10.0.x'                   # Set this to the .NET version of your project
  BUILD_ARTIFACT_NAME: 'released-package'    # Set this according to your team's naming convention
  
jobs:
  build:
    runs-on: windows-latest # Assumes your target function app is Windows-based
    permissions:
      id-token: write  # Required for OIDC
      contents: read   # Required for actions/checkout
    defaults:
      run:
        shell: bash
        working-directory: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      - name: 'Set up .NET version: ${{ env.DOTNET_VERSION }}'
        uses: actions/setup-dotnet@v5
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }}

      # Perform additional steps such as running tests, if needed

      - name: 'Build and prepare .NET project for deployment'
        run: dotnet publish --configuration Release --output ./output

      - name: Upload artifact for the deployment job
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/output
          include-hidden-files: true  # Required for .NET projects
  
  deploy:
    runs-on: windows-latest # Assumes your target function app is Windows-based
    needs: build
    permissions:
      id-token: write  # Required for OIDC
    steps:
      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v8
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'
     
      - name: 'Log in to Azure with AZ CLI'
        uses: azure/login@v3
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
        
      - name: 'Run the Azure Functions action'
        uses: Azure/functions-action@v1
        id: deploy-to-function-app
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'

name: Build and deploy .NET project to Azure Function App using OIDC

on:
  push:
    branches: [ main ]
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_NAME: 'APP_NAME'         # Set this to your function app name on Azure 
  AZURE_FUNCTIONAPP_PROJECT_PATH: '.'        # Set this to the path to your function app project, defaults to the repository root. The deploy action will package the contents of this path.
  DOTNET_VERSION: '10.0.x'                   # Set this to the .NET version of your project
  BUILD_ARTIFACT_NAME: 'released-package'    # Set this according to your team's naming convention
  
jobs:
  build:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-based
    permissions:
      id-token: write  # Required for OIDC
      contents: read   # Required for actions/checkout
    defaults:
      run:
        shell: bash
        working-directory: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      - name: 'Set up .NET version: ${{ env.DOTNET_VERSION }}'
        uses: actions/setup-dotnet@v5
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }}

      # Perform additional steps such as running tests, if needed

      - name: 'Build and prepare .NET project for deployment'
        run: dotnet publish --configuration Release --output ./output

      - name: Upload artifact for the deployment job
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/output
          include-hidden-files: true  # Required for .NET projects
  
  deploy:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-based
    needs: build
    permissions:
      id-token: write  # Required for OIDC
    steps:
      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v8
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'
     
      - name: 'Log in to Azure with AZ CLI'
        uses: azure/login@v3
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
        
      - name: 'Run the Azure Functions action'
        uses: Azure/functions-action@v1
        id: deploy-to-function-app
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'

name: Build and deploy Java project to Azure Function App using OIDC

on:
  push:
    branches: [ main ]
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_NAME: 'APP_NAME'          # set this to your function app name on Azure. Ensure that `functionAppName` in your pom.xml file matches. 
  POM_XML_DIRECTORY: '.'                      # set this to the directory which contains the pom.xml file. The deploy action will package the contents of this path.
  JAVA_VERSION: '21'                          # set this to the Java version of your project
  BUILD_ARTIFACT_NAME: 'released-package'     # Set this according to your team's naming convention

jobs:
  build:
    runs-on: windows-latest # Assumes your target function app is Windows-based
    permissions:
        id-token: write  # Required to fetch an OIDC token to authenticate with the job
        contents: read # Required for actions/checkout
    defaults:
      run:
        shell: bash
        working-directory: ${{ env.POM_XML_DIRECTORY }}
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      - name: 'Set up Java version: ${{ env.JAVA_VERSION }}'
        uses: actions/setup-java@v4
        with:
          java-version: ${{ env.JAVA_VERSION }}
          distribution: 'microsoft'

      - name: 'Build project with Maven'
        run: mvn clean package -DfunctionAppName=${{ env.AZURE_FUNCTIONAPP_NAME }}

      # Perform additional steps such as running tests, if needed
      
      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.POM_XML_DIRECTORY }}/target/azure-functions/${{ env.AZURE_FUNCTIONAPP_NAME }}

  deploy:
    runs-on: windows-latest # Assumes your target function app is Windows-based
    needs: build
    permissions:
      id-token: write  # Required to fetch an OIDC token to authenticate with the job
    steps:
      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v8
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: '${{ env.POM_XML_DIRECTORY }}/downloaded-artifact'
      
      - name: 'Log in to Azure with AZ CLI'
        uses: azure/login@v3
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

      - name: 'Run the Azure Functions action'
        uses: Azure/functions-action@v1
        id: deploy-to-function-app
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: '${{ env.POM_XML_DIRECTORY }}/downloaded-artifact'
          respect-pom-xml: false # Set to `true` if the build artifact path is ${{ env.POM_XML_DIRECTORY }}

name: Build and deploy Java project to Azure Function App using OIDC

on:
  push:
    branches: [ main ]
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_NAME: 'APP_NAME'          # set this to your function app name on Azure. Ensure that `functionAppName` in your pom.xml file matches. 
  POM_XML_DIRECTORY: '.'                      # set this to the directory which contains the pom.xml file. The deploy action will package the contents of this path.
  JAVA_VERSION: '21'                          # set this to the Java version of your project
  BUILD_ARTIFACT_NAME: 'released-package'     # Set this according to your team's naming convention

jobs:
  build:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-based
    permissions:
        id-token: write  # Required to fetch an OIDC token to authenticate with the job
        contents: read # Required for actions/checkout
    defaults:
      run:
        shell: bash
        working-directory: ${{ env.POM_XML_DIRECTORY }}
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      - name: 'Set up Java version: ${{ env.JAVA_VERSION }}'
        uses: actions/setup-java@v4
        with:
          java-version: ${{ env.JAVA_VERSION }}
          distribution: 'microsoft'

      - name: 'Build project with Maven'
        run: mvn clean package -DfunctionAppName=${{ env.AZURE_FUNCTIONAPP_NAME }}

      # Perform additional steps such as running tests, if needed
      
      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.POM_XML_DIRECTORY }}/target/azure-functions/${{ env.AZURE_FUNCTIONAPP_NAME }}

  deploy:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-based
    needs: build
    permissions:
      id-token: write  # Required to fetch an OIDC token to authenticate with the job
    steps:
      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v8
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: '${{ env.POM_XML_DIRECTORY }}/downloaded-artifact'
      
      - name: 'Log in to Azure with AZ CLI'
        uses: azure/login@v3
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

      - name: 'Run the Azure Functions action'
        uses: Azure/functions-action@v1
        id: deploy-to-function-app
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: '${{ env.POM_XML_DIRECTORY }}/downloaded-artifact'
          respect-pom-xml: false # Set to `true` if the build artifact path is ${{ env.POM_XML_DIRECTORY }}

name: Build and deploy Node.js project to Azure Function App using OIDC

on:
  push:
    branches: [ main ]
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_NAME: 'APP_NAME'        # Set this to your function app name on Azure 
  AZURE_FUNCTIONAPP_PROJECT_PATH: '.'       # Set this to the path to your function app project, defaults to the repository root. The deploy action will package the contents of this path.
  NODE_VERSION: '22'                        # Set this to the Node version of your project
  BUILD_ARTIFACT_NAME: 'released-package'   # Set this according to your team's naming convention
  
jobs:
  build:
    runs-on: windows-latest # Assumes your target function app is Windows-based
    permissions:
      id-token: write  # Required for OIDC
      contents: read   # Required for actions/checkout
    defaults:
      run:
        shell: bash
        working-directory: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      - name: 'Set up Node version: ${{ env.NODE_VERSION }}'
        uses: actions/setup-node@v6
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: 'Install project dependencies'
        run: npm install # Use `npm ci` if you have a package-lock.json file and want to ensure a clean install
      
      - name: 'Build project'
        run: npm run build --if-present
      
      - name: 'Run tests'
        run: npm run test --if-present
      
      - name: 'Prune development dependencies'
        run: npm prune --production
      
      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
  
  deploy:
    runs-on: windows-latest # Assumes your target function app is Windows-based
    needs: build
    permissions:
      id-token: write  # Required for OIDC
    steps:
      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v8
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'
     
      - name: 'Log in to Azure with AZ CLI'
        uses: azure/login@v3
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
        
      - name: 'Run the Azure Functions action'
        uses: Azure/functions-action@v1
        id: deploy-to-function-app
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'

name: Build and deploy Node.js project to Azure Function App using OIDC

on:
  push:
    branches: [ main ]
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_NAME: 'APP_NAME'        # Set this to your function app name on Azure 
  AZURE_FUNCTIONAPP_PROJECT_PATH: '.'       # Set this to the path to your function app project, defaults to the repository root. The deploy action will package the contents of this path.
  NODE_VERSION: '22'                        # Set this to the Node version of your project
  BUILD_ARTIFACT_NAME: 'released-package'   # Set this according to your team's naming convention
  
jobs:
  build:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-based
    permissions:
      id-token: write  # Required for OIDC
      contents: read   # Required for actions/checkout
    defaults:
      run:
        shell: bash
        working-directory: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      - name: 'Set up Node version: ${{ env.NODE_VERSION }}'
        uses: actions/setup-node@v6
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: 'Install project dependencies'
        run: npm install # Use `npm ci` if you have a package-lock.json file and want to ensure a clean install
      
      - name: 'Build project'
        run: npm run build --if-present
      
      - name: 'Run tests'
        run: npm run test --if-present
      
      - name: 'Prune development dependencies'
        run: npm prune --production
      
      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
  
  deploy:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-based
    needs: build
    permissions:
      id-token: write  # Required for OIDC
    steps:
      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v8
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'
     
      - name: 'Log in to Azure with AZ CLI'
        uses: azure/login@v3
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
        
      - name: 'Run the Azure Functions action'
        uses: Azure/functions-action@v1
        id: deploy-to-function-app
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'

name: Build and deploy Python project to Azure Function App using OIDC

on:
  push:
    branches: [ main ]
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_NAME: 'APP_NAME'        # Set this to your function app name on Azure 
  AZURE_FUNCTIONAPP_PROJECT_PATH: '.'       # Set this to the path to your function app project, defaults to the repository root. The deploy action will package the contents of this path.
  PYTHON_VERSION: '3.13.x'                  # Set this to the Python version of your project
  BUILD_ARTIFACT_NAME: 'released-package'   # Set this according to your team's naming convention
  
jobs:
  build:
    runs-on: ubuntu-latest # Python function apps are Linux-based
    permissions:
      id-token: write  # Required for OIDC
      contents: read   # Required for actions/checkout
    defaults:
      run:
        shell: bash
        working-directory: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      - name: 'Set up Python version: ${{ env.PYTHON_VERSION }}'
        uses: actions/setup-python@v6
        with:
          python-version: ${{ env.PYTHON_VERSION }}

      - name: 'Install project dependencies'
        run: pip install -r requirements.txt --target ".python_packages/lib/site-packages"  # Ensure requirements.txt contains all dependencies
      
      # Perform additional steps such as running tests, if needed

      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
  
  deploy:
    runs-on: ubuntu-latest # Python function apps are Linux-based
    needs: build
    permissions:
      id-token: write  # Required for OIDC
    steps:
      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v8
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'
     
      - name: 'Log in to Azure with AZ CLI'
        uses: azure/login@v3
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
        
      - name: 'Run the Azure Functions action'
        uses: Azure/functions-action@v1
        id: deploy-to-function-app
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'

name: Deploy PowerShell project to Azure Function App using OIDC

on:
  push:
    branches: [ main ]
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_NAME: 'APP_NAME'       # Set this to your function app name on Azure 
  AZURE_FUNCTIONAPP_PROJECT_PATH: '.'        # Set this to the path to your function app project, defaults to the repository root. The deploy action will package the contents of this path.
  
jobs:
  # PowerShell projects do not require a build step
  deploy:
    runs-on: windows-latest # For PowerShell projects, the OS of the runner does not affect deployment. You may use either ubuntu-latest or windows-latest.
    permissions:
      id-token: write  # Required for OIDC
      contents: read   # Required for actions/checkout
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      # Perform additional steps such as running tests, if needed
     
      - name: 'Log in to Azure with AZ CLI'
        uses: azure/login@v3
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
        
      - name: 'Run the Azure Functions action'
        uses: Azure/functions-action@v1
        id: deploy-to-function-app
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}

# Action Requires
# 1. Setup the AZURE_CREDENTIALS secrets in your GitHub Repository
name: Linux_Container_Workflow

on:
  push:
    branches:
    - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment: dev
    steps:
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@v3

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

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

    - name: 'Compose Customized Docker Image'
      shell: bash
      run: |
        # If your function app project is not located in your repository's root
        # Please change the path to your directory for docker build
        docker build . -t REGISTRY/NAMESPACE/IMAGE:TAG
        docker push REGISTRY/NAMESPACE/IMAGE:TAG

    - name: 'Run Azure Functions Container Action'
      uses: Azure/functions-container-action@v1
      id: fa
      with:
        app-name: PLEASE_REPLACE_THIS_WITH_YOUR_FUNCTION_APP_NAME
        image: REGISTRY/NAMESPACE/IMAGE:TAG

    #- name: 'use the published functionapp url in upcoming steps'
    #  run: |
    #    echo "${{ steps.fa.outputs.app-url }}"

    - name: Azure logout
      run: |
        az logout

Important

Pour les nouveaux déploiements d’applications de fonctions basées sur des conteneurs, utilisez le modèle natif d’hébergement Azure Container Apps. Voir Déployer sur Azure Container Apps avec GitHub Actions. Le Azure/functions-container-action présenté ici déploie des images de conteneur dans des ressources existantes d’application de fonction dans Azure.

Avant d’utiliser ce fichier YAML, suivez les étapes suivantes :

Mettez à jour les valeurs de REGISTRY, NAMESPACE, IMAGE, et TAG en fonction de votre registre de conteneurs.
Mettez à jour les identifiants du dépôt du conteneur dans l’action docker/login-action .

Dans le modèle, mettez à jour les env: variables de votre projet. Chaque modèle nécessite AZURE_FUNCTIONAPP_NAME. Les autres variables dépendent de votre langage :

Variable	Obligatoire	Description
`AZURE_FUNCTIONAPP_NAME`	Oui	Votre nom d’application de fonction dans Azure
`DOTNET_VERSION`	Oui	La version .NET de votre projet (par exemple, `10.0.x`)
`AZURE_FUNCTIONAPP_PROJECT_PATH`	No	Chemin vers le dossier de votre projet. Par défaut : `.` (racine du dépôt)

Variable	Obligatoire	Description
`AZURE_FUNCTIONAPP_NAME`	Oui	Votre nom d’application de fonction dans Azure. Doit correspondre à `functionAppName` dans le fichier pom.xml.
`JAVA_VERSION`	Oui	La version Java de votre projet (par exemple, `21`)
`POM_XML_DIRECTORY`	No	Chemin vers le répertoire contenant pom.xml. Par défaut : `.` (racine du dépôt)

Variable	Obligatoire	Description
`AZURE_FUNCTIONAPP_NAME`	Oui	Votre nom d’application de fonction dans Azure
`NODE_VERSION`	Oui	La version Node.js de votre projet (par exemple, `22`)
`AZURE_FUNCTIONAPP_PROJECT_PATH`	No	Chemin vers le dossier de votre projet. Par défaut : `.` (racine du dépôt)

Variable	Obligatoire	Description
`AZURE_FUNCTIONAPP_NAME`	Oui	Votre nom d’application de fonction dans Azure
`PYTHON_VERSION`	Oui	La version Python de votre projet (par exemple, `3.13.x`)
`AZURE_FUNCTIONAPP_PROJECT_PATH`	No	Chemin vers le dossier de votre projet. Par défaut : `.` (racine du dépôt)

Variable	Obligatoire	Description
`AZURE_FUNCTIONAPP_NAME`	Oui	Votre nom d’application de fonction dans Azure
`AZURE_FUNCTIONAPP_PROJECT_PATH`	No	Chemin vers le dossier de votre projet. Par défaut : `.` (racine du dépôt)

Variable	Obligatoire	Description
`AZURE_FUNCTIONAPP_NAME`	Oui	Votre nom d’application de fonction dans Azure
`REGISTRY`	Oui	Votre serveur de connexion du registre de conteneurs (par exemple, `contoso.azurecr.io`)
`NAMESPACE`	Oui	L’espace de noms/dépôt dans votre registre
`IMAGE`	Oui	Le nom de l’image du conteneur
`TAG`	Oui	La balise image (par exemple, `${{ github.sha }}`)

Les modèles OIDC incluent déjà l’étape azure/login de l’authentification OIDC. Vérifiez que les références secrets.AZURE_CLIENT_ID, secrets.AZURE_TENANT_ID, et secrets.AZURE_SUBSCRIPTION_IDcorrespondent aux secrets du dépôt que vous avez créés.
Ajoutez ce nouveau fichier YAML dans le chemin d’accès /.github/workflows/ de votre référentiel.

Créer la configuration du flux de travail dans le portail

Lorsque vous utilisez le portail pour activer GitHub Actions, Fonctions gère toute la configuration automatiquement. Vous n’avez pas besoin de créer manuellement une identité gérée, de configurer des identifiants ou d’écrire un fichier de workflow. Fonctions effectue les tâches suivantes pour vous :

Dans votre abonnement Azure :

Crée une identité managée attribuée par l’utilisateur et lui attribue le rôle de Contributeur du site web dans votre application de fonction.
Ajoute une accréditation fédérée à l’identité gérée pour l’authentification OIDC GitHub.

Dans votre dépôt GitHub :

Ajoute les valeurs de l’ID client, de l’ID d’abonnement et de l’ID de locataire comme secrets GitHub Actions.
Crée un fichier de flux de travail basé sur votre pile applicative et effectue un commit dans .github/workflows.

Pendant la création d’application de fonction

Vous pouvez commencer rapidement avec GitHub Actions via l’onglet Déploiement lorsque vous créez une fonction dans Azure portail. Pour ajouter un flux de travail GitHub Actions lorsque vous créez une application de fonction :

Dans le portail Azure, sélectionnez Déploiement dans le flux Create Function App.
Activez Déploiement continu si vous souhaitez que chaque mise à jour de code déclenche une transmission push de code vers Azure portail.
Dans les paramètres GitHub, sélectionnez Autoriser la connexion de votre compte GitHub. Connectez-vous avec le compte GitHub qui dispose des droits d’écriture sur votre dépôt.
Entrez votre GitHub organisation, référentiel et branche.
Optionnellement, sélectionnez Fichier Aperçu pour voir à quoi ressemble le fichier de workflow avant qu’il ne soit généré et ajouté à votre dépôt.
Terminez la configuration de votre application de fonction. Votre dépôt GitHub inclut désormais un nouveau fichier de flux de travail dans /.github/workflows/.

Pour une application de fonction existante

Pour ajouter un flux de travail GitHub Actions à une application de fonction existante :

Accédez à votre application de fonction dans le portail Azure et sélectionnez Déploiement>Centre de déploiement.
Sélectionnez Déploiement continu (CI/CD). Pour Source, sélectionnez GitHub. Si vous ne voyez pas le message par défaut Créer avec GitHub Actions, sélectionnez Modifier le fournisseur, choisissez GitHub Actions, puis sélectionnez OK.
Si vous n'avez pas déjà autorisé l'accès à GitHub, sélectionnez Autoriser. Fournissez vos informations d’identification GitHub et sélectionnez Sign in. Pour autoriser un autre compte GitHub, sélectionnez Change Account et connectez-vous avec un autre compte.
Sélectionnez votre GitHub Organization, Repository et Branch. Pour déployer en utilisant GitHub Actions, vous devez avoir un accès d’écriture à ce dépôt.
Pour l’option Workflow, sélectionnez Ajouter un workflow. Cette option crée un nouveau fichier de workflow dans /.github/workflows/. Pour utiliser un flux de travail existant, sélectionnez Utiliser le flux de travail disponible et choisissez votre fichier de flux de travail.
Dans les paramètres d'authentification, choisissez Identité attribuée par l'utilisateur pour utiliser OpenID Connect (OIDC), ce qui est recommandé car il ne nécessite pas de stocker des secrets dans GitHub. Sélectionnez votre abonnement et le nom d’identité (Nouveau ) suggéré. Une nouvelle identité gérée attribuée par l’utilisateur est créée et accorde l’accès au rôle de contributeur du site web . Si vous utilisez une identité existante, vous devez d’abord lui accorder l’accès au rôle de Contributeur du site web .

Important

Lorsque vous sélectionnez Authentification de base, votre profil publié, qui contient des secrets partagés, est stocké dans GitHub Secrets. Vous devez également activer l’authentification SCM de base, ce qui rend votre application moins sécurisée.
Sélectionnez Fichierpreview pour afficher le fichier de flux de travail qui est ajouté à votre dépôt de GitHub dans .github/workflows/.
Sélectionnez Enregistrer pour ajouter le fichier de flux de travail à votre référentiel. Sélectionnez l’onglet Journaux pour consulter l’état des déploiements actuels et précédents.

Créez le fichier de configuration de flux de travail

Vous pouvez créer le fichier de configuration de flux de travail GitHub Actions à partir des modèles Azure Functions directement à partir de votre référentiel GitHub.

Dans GitHub, accédez à votre dépôt.
Sélectionnez Actions et Nouveau flux de travail.
Recherchez des fonctions.
Dans les flux de travail d’application functions affichés créés par Microsoft Azure, recherchez celui qui correspond à votre langage de code et sélectionnez Configure.
Dans le fichier YAML nouvellement créé, mettez à jour le paramètre env.AZURE_FUNCTIONAPP_NAME avec le nom de votre ressource d’application de fonction dans Azure. Vous devrez peut-être aussi mettre à jour le paramètre qui définit la version du langage utilisée par votre application, par exemple DOTNET_VERSION pour C# ou PYTHON_VERSION pour les applications Python.
Les modèles par défaut peuvent utiliser l’authentification de publication du profil au lieu de l’OIDC recommandé. Pour passer à l’OIDC et s’aligner sur les comportements du portail, effectuez les modifications suivantes :
- Supprimez les paramètres publish-profile, scm-do-build-during-deployment et enable-oryx-build de Azure/functions-action.
- Supprimez le paramètre environment du travail (s’il est présent), car le sujet des informations d’identification fédérées doit correspondre au déclencheur de branche.
- Ajoutez une azure/login étape avant l’étape Azure/functions-action :
```
- name: 'Login via OIDC'
  uses: azure/login@v3
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- name: 'Run Azure Functions Action'
  uses: Azure/functions-action@v1
  with:
    app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
    package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
```
- Ajoutez les autorisations suivantes à la tâche :
```
permissions:
  id-token: write
  contents: read
```
Vérifiez que le nouveau fichier de workflow est enregistré avec un nom approprié dans /.github/workflows/ et sélectionnez Commit modifications.

action de Azure Functions

L’action Azure Functions (Azure/functions-action) définit la façon dont votre code est publié dans une application de fonction existante dans Azure, ou dans un emplacement spécifique dans votre application.

Paramètres

Le tableau suivant décrit les paramètres d’entrée pris en charge par Azure/functions-action:

Paramètre	Description
app-name	(Obligatoire) Le nom de votre application de fonctions dans Azure.
paquet	(Obligatoire) Le chemin vers votre projet pour publier. Par défaut : `.` (tous les fichiers du dépôt).
Construction à distance	Définissez la valeur sur `true` pour demander une génération à distance lorsque vous déployez vers une application dans le plan Flex Consumption. La version à distance utilise toujours Oryx. Ne définissez pas non plus scm-do-build-during-deployment ou enable-oryx-build. Valeur par défaut : `false`.
scm-do-build-during-deployment	Permettre au site Kudu d’effectuer des opérations préalables au déploiement, telles que des compilations à distance. Réglez pour `true` que Kudu construise votre projet pendant le déploiement. Valeur par défaut : `false`. Pour plus d’informations, consultez `SCM_DO_BUILD_DURING_DEPLOYMENT`.
enable-oryx-build	Permettre à Kudu de résoudre les dépendances de projet en utilisant Oryx. Réglez ce paramètre ainsi que scm-do-build-during-deployment sur `true` pour utiliser Oryx au lieu du flux de travail. Valeur par défaut : `false`. Linux uniquement.
slot-name	Le slot de déploiement dans lequel effectuer le déploiement. Par défaut : emplacement de production.
publier-le-profil	Nom du secret GitHub qui contient votre profil de publication. Ce n’est pas nécessaire avec l’authentification OIDC recommandée.
sku	Définissez sur `flexconsumption` lors de l’authentification avec publish-profile sur un plan Consommation flexible. Ce n’est pas nécessaire avec l’authentification OIDC ou d’autres plans d’hébergement.
respect-pom-xml	(Java uniquement) Définissez sur `true` pour dériver l’artefact de déploiement à partir de pom.xml. Lorsque `true`, définissez package sur `.`. Valeur par défaut : `false`.
respect-funcignore	Définissez la valeur sur `true` afin de respecter votre fichier .funcignore et d’exclure les chemins répertoriés. Valeur par défaut : `false`.

Le tableau suivant montre quels paramètres sont pris en charge pour chaque plan d’hébergement :

Paramètre	Flex Consumption	Elastic Premium	Dedicated	Consumption
app-name	Obligatoire	Obligatoire	Obligatoire	Obligatoire
paquet	Obligatoire	Obligatoire	Obligatoire	Obligatoire
Construction à distance	Optional	—	—	—
scm-do-build-during-deployment	—	Optional	Optional	Optional
enable-oryx-build	—	Optionnel (Linux)	Optionnel (Linux)	Optionnel (Linux)
slot-name	Non pris en charge	Optional	Optional	Optional
publier-le-profil	Non recommandé	Non recommandé	Non recommandé	Non recommandé
sku	Publication de profil uniquement	—	—	—
respect-pom-xml	Optionnel (Java)	Optionnel (Java)	Optionnel (Java)	Optionnel (Java)
respect-funcignore	Optional	Optional	Optional	Optional

Méthodes de déploiement

Lorsque vous utilisez GitHub Actions, la méthode de déploiement dépend de votre plan d’hébergement :

Plan d’hébergement	Méthode de déploiement
Consommation flexible	Déploiement de package
Elastic Premium	Déploiement ZIP
Dédié (App Service)	Déploiement ZIP
Consommation	Windows : déploiement ZIP Linux : URL de package externe^*

* La possibilité d'exécuter vos applications sur Linux dans le cadre d'un plan de consommation est prévue pour être abandonnée. Pour plus d’informations, consultez Hébergement du plan de consommation Azure Functions.

Pour plus d’informations, consultez Technologies de déploiement dans Azure Functions.

Étapes suivantes

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-08-28