Tag: gitlab

LiteLLM offre un moyen pratique d’intégrer des capacités d’IA à des processus d’automatisation basés sur Git, sans vous enfermer chez un fournisseur de modèles unique.

Pour les équipes utilisant GitHub ou GitLab, l’outil peut servir de passerelle d’IA unifiée pour la révision de code, l’aide à la rédaction de commits, l’analyse des demandes de fusion (merge requests) et les automatisations pilotées par l’intégration continue (CI).

Cela s’avère particulièrement utile lorsque vous recherchez de la flexibilité entre les différents fournisseurs, une gouvernance centralisée et une API cohérente pour vos pipelines.

Pourquoi LiteLLM s’adapte bien aux workflows Git

In git-based environments, the same AI capability often needs to work across different stages: commit time, pull request or merge request review, release preparation, and CI checks.

LiteLLM helps by giving you one OpenAI-compatible endpoint that can route requests to many model providers behind the scenes. That means your automation can stay stable even if you change models, add fallbacks, or move some workloads to self-hosted inference.

For DevOps and DevSecOps teams, this is a strong pattern because it keeps AI usage centralized.

You can add policy controls, logging, model allowlists, and cost tracking at the proxy layer instead of spreading those concerns across many scripts and repositories.

In practice, that makes AI features easier to standardize across GitHub and GitLab estates.

Dans les environnements basés sur Git, une même fonctionnalité d’IA doit souvent opérer à différentes étapes : lors du commit, de la revue de pull request ou de merge request, de la préparation de la mise en production et des vérifications d’intégration continue (CI).

LiteLLM facilite cette tâche en proposant un point de terminaison unique compatible avec l’API OpenAI, capable d’acheminer les requêtes vers divers fournisseurs de modèles en arrière-plan. Ainsi, vos processus automatisés restent stables, même si vous changez de modèle, mettez en place des mécanismes de secours (fallbacks) ou déplacez certaines charges de travail vers une infrastructure d’inférence auto-hébergée.

Pour les équipes DevOps et DevSecOps, cette approche est particulièrement pertinente car elle permet de centraliser l’utilisation de l’IA.

Vous pouvez intégrer des contrôles de politique, la journalisation, des listes blanches de modèles et le suivi des coûts directement au niveau du proxy, plutôt que de disperser ces éléments à travers de multiples scripts et dépôts.

Concrètement, cela simplifie la standardisation des fonctionnalités d’IA au sein de vos écosystèmes GitHub et GitLab.

Cas d’utilisation courants

Voici des moyens pratiques d’utiliser LiteLLM dans des workflows basés sur Git :

1. Revue de pull request ou de merge request.
2. Génération de messages de commit.
3. Vérifications de sécurité et de conformité.
4. Rédaction de notes de version.
5. Aide à la documentation.
6. Enrichissement du pipeline CI.

Exemple de GitHub Actions

Cet exemple illustre un modèle simple dans lequel GitHub Actions fait appel à un proxy LiteLLM lors d’un workflow de pull request. Vous pouvez adapter le prompt pour générer un résumé de la revue, une ébauche de journal des modifications (changelog) ou une liste de contrôle de sécurité.

textname: AI Review with LiteLLM

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Get diff
        run: |
          git fetch origin ${{ github.base_ref }} --depth=1
          git diff origin/${{ github.base_ref }}...HEAD > pr.diff

      - name: Call LiteLLM proxy
        env:
          LITELLM_API_KEY: ${{ secrets.LITELLM_API_KEY }}
        run: |
          PROMPT=$(cat <<'EOF'
          Review the following pull request diff and provide:
          1. A short summary
          2. Potential risks
          3. Suggested improvements

          Diff:
          EOF
          )
          DIFF_CONTENT=$(cat pr.diff)

          curl -s https://litellm.example.com/v1/chat/completions \
            -H "Authorization: Bearer ${LITELLM_API_KEY}" \
            -H "Content-Type: application/json" \
            -d "$(jq -n \
              --arg model 'gpt-4o-mini' \
              --arg system "$PROMPT" \
              --arg user "$DIFF_CONTENT" \
              '{
                model: $model,
                messages: [
                  {role: "system", content: $system},
                  {role: "user", content: $user}
                ]
              }')"

Ce modèle est particulièrement adapté lorsque vous souhaitez intégrer la sortie de l’IA directement dans le flux de travail, plutôt que de passer par une étape distincte de révision manuelle. Vous pouvez également enregistrer la réponse sous forme de commentaire de pull request, d’artefact de build ou de résumé de tâche.

Exemple GitLab CI

Dans GitLab, cette même idée correspond parfaitement à un pipeline de demande de fusion (merge request pipeline). Cet exemple utilise un job qui récupère le diff et l’envoie à un proxy LiteLLM.

textstages:
  - ai_review

ai_review:
  stage: ai_review
  image: alpine:3.20
  variables:
    GIT_DEPTH: "1"
  before_script:
    - apk add --no-cache git curl jq
  script:
    - git fetch origin "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME" --depth=1
    - git diff "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD" > mr.diff
    - |
      PROMPT="Review the following merge request diff and provide:
      1. A short summary
      2. Potential risks
      3. Suggested improvements"
      DIFF_CONTENT="$(cat mr.diff)"

      curl -s https://litellm.example.com/v1/chat/completions \
        -H "Authorization: Bearer ${LITELLM_API_KEY}" \
        -H "Content-Type: application/json" \
        -d "$(jq -n \
          --arg model 'gpt-4o-mini' \
          --arg system "$PROMPT" \
          --arg user "$DIFF_CONTENT" \
          '{
            model: $model,
            messages: [
              {role: "system", content: $system},
              {role: "user", content: $user}
            ]
          }')"
  rules:
    - if: $CI_MERGE_REQUEST_IID

Cela s’intègre parfaitement à GitLab, car les pipelines de demandes de fusion constituent déjà un emplacement tout indiqué pour les vérifications automatisées. Vous pouvez étendre le même job pour publier la réponse en tant qu’artefact, ajouter un commentaire à la demande de fusion ou transmettre le résultat à une étape de contrôle qualité ultérieure.

Conseil de mise en œuvre

Si vous développez cette solution pour un environnement de production, veillez à structurer le format des invites et des réponses.

Par exemple, demandez une sortie JSON afin que votre pipeline puisse analyser correctement la gravité, le résumé et les recommandations.

Il est également judicieux de séparer les modèles publics des dépôts sensibles et d’acheminer les projets protégés uniquement vers des fournisseurs auto-hébergés ou agréés.

Pour les environnements fortement basés sur GitLab, LiteLLM peut également servir de couche de compatibilité devant les systèmes d’IA auto-hébergés ou internes.

Pour les flux de travail centrés sur GitHub, il permet de standardiser le comportement de l’IA entre les dépôts, même si les équipes préfèrent des modèles différents. Dans les deux cas, la véritable valeur ajoutée réside non seulement dans l’accès aux modèles, mais aussi dans le contrôle et la cohérence.

Notre entreprise propose des licences par abonnement, du support et des services gérés pour LiteLLM, git, GitLab et GitHub.
Contactez-nous pour toute question.: litellm@almtoolbox.com
ou appelez-nous : +33 1 84 17 53 28