Utilisation de stratégies de fusion pour générer des ensembles et spécifier des fichiers

Génération de fichiers par resynthèse

La resynthèse peut fusionner le code source produit par un plan avec le code source précédemment généré par le même plan, ce qui permet de propager les modifications apportées à un plan aux projets existants. Les fusions sont exécutées à partir de la resynth() fonction sur les ensembles de sortie du plan. La resynthèse génère d'abord trois ensembles représentant différents aspects du plan et de l'état du projet. Il peut être exécuté manuellement localement à l'aide de la yarn blueprint:resynth commande, qui créera les bundles s'ils n'existent pas déjà. Travailler manuellement avec les ensembles vous permettra de simuler et de tester le comportement de resynthèse localement. Par défaut, les plans exécutent uniquement la resynthèse dans les référentiels situés sous, src/* car seule cette partie du bundle est généralement contrôlée par le code source.

• existing-bundle- Ce bundle est une représentation de l'état actuel du projet. Ceci est construit artificiellement par le calcul de synthèse pour donner au plan le contexte du contenu du projet dans lequel il est déployé (le cas échéant). Si quelque chose existe déjà à cet endroit lors de l'exécution de la resynthèse localement, il sera réinitialisé et considéré comme une maquette. Dans le cas contraire, il sera réglé sur le contenu duancestor-bundle.

• ancestor-bundle- Il s'agit du bundle qui représente le résultat du plan s'il a été synthétisé avec certaines options et/ou versions précédentes. Si c'est la première fois que ce plan est ajouté à un projet, cela signifie que l'ancêtre n'existe pas. Il est donc défini sur le même contenu que leexisting-bundle. Localement, si ce bundle existe déjà à cet endroit, il sera considéré comme une maquette.

• proposed-bundle- Il s'agit du bundle qui se moque du plan s'il a été synthétisé avec de nouvelles options et/ou versions. Il s'agit du même bundle qui serait produit par la synth() fonction. Localement, ce bundle est toujours remplacé.

Chaque bundle est créé lors d'une phase de resynthèse accessible depuis la classe Blueprint ci-dessous. this.context.resynthesisPhase

• resolved-bundle- Il s'agit du bundle final, qui est une représentation de ce qui est empaqueté et déployé dans un CodeCatalyst projet. Vous pouvez voir quels fichiers et différences sont envoyés aux mécanismes de déploiement. Il s'agit du résultat de la resynth() fonction résolvant les fusions entre les trois autres ensembles.

La fusion à trois voies est appliquée en prenant la différence entre le ancestor-bundle et proposed-bundle et en l'ajoutant au existing-bundle pour générer leresolved-bundle. Toutes les stratégies de fusion résolvent les fichiers au formatresolved-bundle. La resynthèse résout la portée de ces ensembles grâce aux stratégies de fusion du plan pendant le processus resynth() et produit le bundle résolu à partir du résultat.

Utilisation de stratégies de fusion

Vous pouvez utiliser une stratégie de fusion proposée par la bibliothèque de plans. Ces stratégies fournissent des moyens de résoudre les sorties de fichiers et les conflits pour les fichiers mentionnés dans la Génération de fichiers par resynthèse section.

• alwaysUpdate- Une stratégie qui correspond toujours au fichier proposé.

• neverUpdate- Une stratégie qui répond toujours au fichier existant.

• onlyAdd- Une stratégie qui prend en compte le fichier proposé lorsqu'un fichier existant n'existe pas déjà. Dans le cas contraire, il est résolu dans le fichier existant.

• threeWayMerge- Une stratégie qui effectue une fusion à trois voies entre les fichiers d'ancêtres existants, proposés et communs. Le fichier résolu peut contenir des marqueurs de conflit si les fichiers ne peuvent pas être correctement fusionnés. Le contenu des fichiers fournis doit être codé en UTF-8 pour que la stratégie produise un résultat significatif. La stratégie tente de détecter si les fichiers d'entrée sont binaires. Si la stratégie détecte un conflit de fusion dans un fichier binaire, elle renvoie toujours le fichier proposé.

• preferProposed- Une stratégie qui effectue une fusion à trois voies entre les fichiers d'ancêtres existants, proposés et communs. Cette stratégie permet de résoudre les conflits en sélectionnant la version du fichier proposé pour chaque conflit.

• preferExisting- Une stratégie qui effectue une fusion à trois voies entre les fichiers d'ancêtres existants, proposés et communs. Cette stratégie permet de résoudre les conflits en sélectionnant le côté du fichier existant dans chaque conflit.

Pour consulter le code source des stratégies de fusion, consultez le GitHub référentiel open source.

Spécification de fichiers pour les mises à jour de gestion du cycle

Lors de la resynthèse, les plans contrôlent la manière dont les modifications sont fusionnées dans un référentiel source existant. Cependant, il se peut que vous ne souhaitiez pas envoyer des mises à jour à chaque fichier de votre plan. Par exemple, les exemples de code tels que les feuilles de style CSS sont conçus pour être spécifiques au projet. La stratégie de fusion à trois voies est l'option par défaut si vous ne spécifiez aucune autre stratégie. Les plans peuvent spécifier les fichiers qu'ils possèdent et ceux qu'ils ne possèdent pas en spécifiant des stratégies de fusion dans la structure du référentiel elle-même. Les plans peuvent mettre à jour leurs stratégies de fusion, et les dernières stratégies peuvent être utilisées lors de la resynthèse.

const sourceRepo = new SourceRepository(this, {
      title: 'my-repo',
    });
    sourceRepo.setResynthStrategies([
      {
        identifier: 'dont-override-sample-code',
        description: 'This strategy is applied accross all sample code. The blueprint will create sample code, but skip attempting to update it.',
        strategy: MergeStrategies.neverUpdate,
        globs: [
          '**/src/**',
          '**/css/**',
        ],
      },
    ]);

Plusieurs stratégies de fusion peuvent être spécifiées, la dernière étant prioritaire. Les fichiers non couverts sont par défaut three-way-merge similaires à Git. Plusieurs stratégies de fusion sont proposées dans le MergeStrategies build, mais vous pouvez écrire la vôtre. Les stratégies fournies sont conformes au pilote de stratégie git merge.

Rédaction de stratégies de fusion

En plus d'utiliser l'une des stratégies de build merge fournies, vous pouvez également écrire vos propres stratégies. Les stratégies doivent respecter une interface de stratégie standard. Vous devez écrire une fonction de stratégie qui prend les versions d'un fichier à partir du existing-bundleproposed-bundle, etancestor-bundle, et les fusionne en un seul fichier résolu. Par exemple :

type StrategyFunction = (
   /**
   * file from the ancestor bundle (if it exists)
   */
    commonAncestorFile: ContextFile | undefined, 
   /**
   * file from the existing bundle (if it exists)
   */
    existingFile: ContextFile | undefined,
   /**
   * file from the proposed bundle (if it exists)
   */ 
    proposedFile: ContextFile | undefined, 
    options?: {}) 
    /**
    * Return: file you'd like in the resolved bundle
    * passing undefined will delete the file from the resolved bundle
    */ 
=> ContextFile | undefined;

Si les fichiers n'existent pas (ne sont pas définis), ce chemin de fichier n'existe pas dans cet ensemble d'emplacements en particulier.

Exemple :

strategies: [
          {
            identifier: 'dont-override-sample-code',
            description: 'This strategy is applied across all sample code. The blueprint will create sample code, but skip attempting to update it.',
            strategy: (ancestor, existing, proposed) => {
                const resolvedfile = ...
                ...
                // do something
                ...
                return resolvedfile
            },
            globs: [
              '**/src/**',
              '**/css/**',
            ],
          },
        ],