Utilisation de plusieurs référentiels Git source working-with-multiple-source-git-repos

Au lieu de travailler directement avec le référentiel Git Cloud Manager, découvrez comment utiliser votre propre référentiel Git ou plusieurs référentiels Git.

Synchronisation des référentiels Git gérés par les clients syncing-customer-managed-git-repositories

Pour mettre à jour le référentiel Git Cloud Manager, configurez un processus de synchronisation automatisée si vous utilisez votre propre référentiel ou référentiel.

Selon l’emplacement d’hébergement de votre référentiel Git, une action GitHub ou une solution d’intégration continue telle que Jenkins peut être utilisée pour configurer l’automatisation. Une fois une automatisation en place, chaque notification push vers votre propre référentiel peut être automatiquement transférée vers le référentiel Git Cloud Manager.

Bien qu’une telle automatisation pour un seul référentiel Git détenu par le client soit simple, la configuration pour plusieurs référentiels nécessite une configuration initiale plus impliquée. Le contenu de plusieurs référentiels Git doit être mappé à différents répertoires au sein d’un seul référentiel Git Cloud Manager. Le référentiel Git de Cloud Manager doit être configuré avec un Maven racine pom.xml, répertoriant les différents sous-projets dans la section modules.

Vous trouverez ci-dessous un exemple pom.xml pour deux référentiels Git détenus par le client. Le premier projet est placé dans le répertoire project-a et le second dans le répertoire project-b.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>customer.group.id</groupId>
    <artifactId>customer-reactor</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>pom</packaging>

    <modules>
        <module>project-a</module>
        <module>project-b</module>
    </modules>

</project>

Une telle racine pom.xml est transmise à une branche dans le référentiel Git Cloud Manager. Ensuite, les deux projets doivent être configurés pour transférer automatiquement les modifications vers le référentiel Git de Cloud Manager.

Par exemple, une notification push vers une branche du projet A peut déclencher une action GitHub. L’action extrait le projet A et le référentiel Cloud Manager Git. Il copie tous les contenus du projet A dans le répertoire project-a du référentiel Git Cloud Manager. Ensuite, il valide et envoie le changement.

Par exemple, une modification de la branche main du projet A est automatiquement envoyée à la branche main du référentiel Git Cloud Manager. Bien sûr, il peut y avoir un mappage entre les branches, par exemple une transmission de type push vers une branche nommée dev dans le projet A, qui est envoyée vers une branche nommée development dans le référentiel Git Cloud Manager. Des étapes similaires sont nécessaires pour le projet B.

Selon la stratégie et les workflows d’embranchement, il est possible de configurer la synchronisation pour différentes branches. Si le référentiel Git utilisé ne fournit pas de concept similaire aux actions GitHub, une intégration par le biais de Jenkins (ou similaire) est également possible. Dans ce cas, un webhook déclenche une tâche Jenkins qui effectue la tâche.

Procédez comme suit pour ajouter une nouvelle source ou un nouveau référentiel (troisième) :

Exemple d’action GitHub sample-github-action

Une notification push vers la branche main déclenche cet exemple d’action GitHub, qui est ensuite placée dans un sous-répertoire du référentiel Git de Cloud Manager. Les actions GitHub doivent comporter deux secrets, MAIN_USER et MAIN_PASSWORD, pour se connecter et effectuer des transmissions de type push vers le référentiel Git de Cloud Manager.

name: SYNC
env:
  # Username/email used to commit to Cloud Manager's Git repository
  USER_NAME: <NAME>
  USER_EMAIL: <EMAIL>
  # Directory within the Cloud Manager Git repository
  PROJECT_DIR: project-a
  # Cloud Manager's Git repository
  MAIN_REPOSITORY: https://$MAIN_USER:$MAIN_PASSWORD@git.cloudmanager.adobe.com/<PATH>
  # The branch in Cloud Manager's Git repository to push to
  MAIN_BRANCH : <BRANCH_NAME>

# Only run on a push to this branch
on:
  push:
     branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # Checkout this project into a sub folder
      - uses: actions/checkout@v2
        with:
          path: sub
      # Cleanup sub project
      - name: Clean project
        run: |
          git -C sub log --format="%an : %s" -n 1 > commit.txt
          rm -rf sub/.git
          rm -rf sub/.github
      # Set global git configuration
      - name: Set git config
        run: |
          git config --global credential.helper cache
          git config --global user.email ${USER_EMAIL}
          git config --global user.name ${USER_NAME}
      # Checkout the main project
      - name: Checkout main project
        run:
          git clone -b ${MAIN_BRANCH} https://${{ secrets.PAT }}@github.com/${MAIN_REPOSITORY}.git main
      # Move sub project
      - name: Move project to main project
        run: |
          rm -rf main/${PROJECT_DIR}
          mv sub main/${PROJECT_DIR}
      - name: Commit Changes
        run: |
          git -C main add -f ${PROJECT_DIR}
          git -C main commit -F ../commit.txt
          git -C main push

Comme illustré ci-dessus, l’utilisation d’une action GitHub est flexible. Il est possible d’effectuer n’importe quel mappage entre les branches des référentiels Git et n’importe quel mappage des projets Git distincts dans la disposition des répertoires du projet principal.

Exemple de traitement Jenkins sample-jenkins-job

Ce script est un exemple qui peut être utilisé dans une tâche Jenkins ou une tâche similaire. Une modification dans un référentiel Git la déclenche. Le traitement Jenkins extrait l’état le plus récent de ce projet ou de cette branche, puis déclenche ce script.

Ce script extrait ensuite le référentiel Git de Cloud Manager et valide le code du projet dans un sous-répertoire.

Le traitement Jenkins doit comporter deux secrets, MAIN_USER et MAIN_PASSWORD, pour pouvoir se connecter et effectuer des transferts (push) vers le référentiel Git de Cloud Manager.

# Username/email used to commit to Cloud Manager's Git repository
export USER_NAME=<NAME>
export USER_EMAIL=<EMAIL>
# Directory within the Cloud Manager Git repository
export PROJECT_DIR=project-a
# Cloud Manager's Git repository
export MAIN_REPOSITORY=https://$MAIN_USER:$MAIN_PASSWORD@git.cloudmanager.adobe.com/<PATH>
# The branch in Cloud Manager's Git repository to push to
export MAIN_BRANCH=<BRANCH_NAME>

# clean up and init
rm -rf target
mkdir target

# mv project to sub folder
mkdir target/sub
for f in .* *
do
    if [ "$f" != "." -a "$f" != ".." -a "$f" != "target" ]
    then
        mv "$f" target/sub
    fi
done
cd target

# capture log and remove git info
cd sub
git log --format="%an : %s" -n 1 > ../commit.txt
rm -rf .git
rm -rf .github
cd ..

# checkout main repository
git clone -b $MAIN_BRANCH $MAIN_REPOSITORY main
cd main

# configure main repository
git config credential.helper cache
git config user.email $USER_EMAIL
git config user.name $USER_NAME

# update project in main
rm -rf $PROJECT_DIR
mv ../sub $PROJECT_DIR

# commit changes to main
git add -f $PROJECT_DIR
git commit -F ../commit.txt
git push

Comme indiqué ci-dessus, l’utilisation d’un traitement Jenkins est très flexible. Il est possible d’effectuer n’importe quel mappage entre les branches des référentiels Git et n’importe quel mappage des projets Git distincts dans la disposition des répertoires du projet principal.