Ajouter le runner à votre pipeline CI

L’analyse s’exécute dans le pipeline CI où votre code se trouve déjà - votre code source ne quitte jamais votre infrastructure. Dans les exemples ci-dessous, le runner est invoqué avec le token spécifique au projet.

Note

Définissez APPARCH_TOKEN comme une variable secrète/protégée dans votre CI. Choisissez l’image du runner selon le langage (par ex. collectors/dotnet, collectors/python, collectors/go).

Tous les exemples tirent l’image depuis l’AppArch Hub ; consultez cette page pour l’authentification, la correspondance de langage et les erreurs courantes.

GitHub Actions

.github/workflows/apparch.yml

name: AppArch
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # the target branch is then in the clone: the change's own files and its merge base
      - run: |
          echo "$APPARCH_INSTALLATION_KEY" | docker login hub.apparch.io -u "$APPARCH_INSTALLATION_ID" --password-stdin
          docker run --rm -v "$PWD:/workspace:ro" \
            -e APPARCH_Collector__Token="$APPARCH_TOKEN" \
            -e APPARCH_Collector__ApiUrl="https://api.yourdomain.com" \
            -e GITHUB_EVENT_NAME -e GITHUB_REF -e GITHUB_REPOSITORY \
            -e GITHUB_SERVER_URL -e GITHUB_BASE_REF -e GITHUB_SHA \
            hub.apparch.io/collectors/dotnet:latest /workspace
        env:
          APPARCH_TOKEN: ${{ secrets.APPARCH_TOKEN }}
          APPARCH_INSTALLATION_ID: ${{ secrets.APPARCH_INSTALLATION_ID }}
          APPARCH_INSTALLATION_KEY: ${{ secrets.APPARCH_INSTALLATION_KEY }}

GitLab CI

# Image pulls are authorized with your INSTALLATION credential, not the project token
# (Settings → CI/CD → Variables):
#   DOCKER_AUTH_CONFIG = {"auths":{"hub.apparch.io":{"auth":"base64(<installation-id>:<installation-key>)"}}}
archpilot:
  image: hub.apparch.io/collectors/dotnet:latest
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  variables:
    APPARCH_Collector__Token: "$APPARCH_TOKEN"
    APPARCH_Collector__ApiUrl: "https://api.yourdomain.com"
  script:
    # Optional flags: --modules archpilot,archscan (pin what runs)
    #                 --fail-on critical (fail this step when findings at/above the level exist)
    - apparch "$CI_PROJECT_DIR"

Bitbucket Pipelines

pipelines:
  pull-requests:
    '**':
      - step:
          image:
            name: hub.apparch.io/collectors/dotnet:latest
            username: $APPARCH_INSTALLATION_ID
            password: $APPARCH_INSTALLATION_KEY
            run-as-user: 0   # the clone belongs to root; a PR run fetches the target branch into it
          script:
            - export APPARCH_Collector__Token="$APPARCH_TOKEN"
            - export APPARCH_Collector__ApiUrl="https://api.yourdomain.com"
            - apparch "$BITBUCKET_CLONE_DIR"

Azure DevOps

trigger: none
pr: ['*']
pool: { vmImage: ubuntu-latest }
steps:
  - checkout: self
    fetchDepth: 0   # the target branch is then in the clone: the change's own files and its merge base
  - script: |
      echo "$(APPARCH_INSTALLATION_KEY)" | docker login hub.apparch.io -u "$(APPARCH_INSTALLATION_ID)" --password-stdin
      docker run --rm -v "$(Build.SourcesDirectory):/workspace:ro" \
        -e APPARCH_Collector__Token="$(APPARCH_TOKEN)" \
        -e APPARCH_Collector__ApiUrl="https://api.yourdomain.com" \
        -e SYSTEM_PULLREQUEST_PULLREQUESTID="$(System.PullRequest.PullRequestId)" \
        -e SYSTEM_PULLREQUEST_TARGETBRANCH="$(System.PullRequest.TargetBranch)" \
        -e SYSTEM_TEAMPROJECT="$(System.TeamProject)" \
        -e BUILD_REPOSITORY_NAME="$(Build.Repository.Name)" \
        -e SYSTEM_COLLECTIONURI="$(System.CollectionUri)" \
        -e BUILD_SOURCEVERSION="$(Build.SourceVersion)" \
        hub.apparch.io/collectors/dotnet:latest /workspace

Jenkins

pipeline {
  agent { docker { image 'hub.apparch.io/collectors/dotnet:latest' registryUrl 'https://hub.apparch.io' registryCredentialsId 'apparch-hub' } }
  environment {
    APPARCH_Collector__Token = credentials('APPARCH_TOKEN')
    APPARCH_Collector__ApiUrl = 'https://api.yourdomain.com'
    // PR review (ArchPilot) needs the MR context set explicitly; without these the run is a full scan (ArchScan).
    APPARCH_Collector__Provider__Type = 'gitlab' // gitlab | github | bitbucket | azuredevops
    APPARCH_Collector__Provider__ProjectId = 'group/project'
    APPARCH_Collector__Provider__PullRequestId = "${env.CHANGE_ID}"
  }
  stages {
    stage('AppArch') {
      steps {
        sh 'apparch "$WORKSPACE"'
      }
    }
  }
}

La prochaine fois qu’une PR/MR sera ouverte, ArchPilot laissera des commentaires ligne par ligne. Le runner choisit le mode automatiquement : un pipeline de PR/MR exécute la revue rapide (ArchPilot), un pipeline de push exécute l’analyse complète (ArchScan).

L’utilisateur du conteneur

Les images des collecteurs s’exécutent avec un utilisateur non root (uid 10001) et ne font que lire le checkout, même s’il appartient à un autre utilisateur. Sur une pull request, le collecteur compare la modification avec sa branche cible (les fichiers propres à la modification, sa base de fusion) ; cette branche doit donc se trouver dans le clone :

• GitHub Actions et Azure DevOps : les exemples récupèrent tout l’historique (fetch-depth: 0, fetchDepth: 0) ; la branche cible est alors déjà présente et rien n’est écrit.
• GitLab CI et Jenkins : fonctionnent tels quels (le clone de GitLab est accessible en écriture pour le job, Jenkins lance le conteneur avec son propre utilisateur).
• Bitbucket Pipelines : le clone appartient toujours à root et le collecteur y récupère la branche cible ; l’exemple exécute donc l’étape en root (run-as-user: 0).

Sans cela, l’étape passe quand même, mais elle examine tous les résultats au lieu de ceux de la modification et saute les contrôles qui comparent avec la branche cible (autorisation supprimée, nouveau cycle de dépendances). Si votre runner exige root ailleurs, indiquez-le explicitement : docker run --user 0 ..., securityContext.runAsUser: 0 sous Kubernetes.

Certificats auto-signés ou CA interne

Si votre installation AppArch est servie avec un certificat auquel le runner CI ne fait pas confiance - une CA interne ou un certificat auto-signé -, l’exécution échoue à la récupération du catalogue de règles avec une erreur TLS. Deux issues, par ordre de préférence :

1. Faire confiance à la CA dans l’image du runner. Le certificat est alors vérifié comme tout autre et rien ne change côté collecteur.
2. Désactiver la vérification avec SslVerify :

SslVerify=false                     # ou SSL_VERIFY, ou APPARCH_Collector__SslVerify

false, 0, no et off la désactivent ; toute autre valeur - vide incluse - la laisse active. Le collecteur .NET accepte en plus le flag --no-ssl-verify. Chaque exécution affiche ssl verify on ou ssl verify OFF - server certificate not checked dans son bloc de démarrage.

Attention

Sans vérification, le collecteur ne peut pas distinguer votre Api de n’importe quoi qui répond à cette adresse : le jeton de projet et les résultats partent vers qui écoute. À utiliser quand faire confiance à la CA est impossible, pas par défaut.