2017-06-28 1 views
0

Mon git a 3 répertoires de haut niveau:Comment conditionner le déclencheur de git-ressource de Concourse basé sur des chemins quand il y a un répertoire de composant partagé?

-\ |- ComponentA |- ComponentB |- SharedLib

je peux utiliser différents git-ressources avec des chemins différents pour déclencher les builds pour le composant A, le composant B et la bibliothèque partagée. Mais SharedLib est une dépendance de construction pour ComponentA et ComponentB et valide parfois les fichiers include dans ComponentA et SharedLib. Ce que je veux, c'est être sûr que les validations qui couvrent ComponentA et sharedlib (et peut-être aussi ComponentB) commencent par construire SharedLib, puis les composants.

Quelle est la meilleure façon de structurer le pipeline dans Concourse pour ce faire? (Je sais que je pourrais tirer le shareLib dans un repo séparé, mais il y a des raisons pour lesquelles cela serait gênant.)

J'ai pensé à étendre la ressource git pour avoir une propriété "unless_path". Mais penser à la manière dont le pipeline gérerait les différentes séquences de validation possibles avec des passages de pipeline qui se chevauchent a fait mal à ma tête.

+0

Pourquoi voulez-vous utiliser des chemins dans ce cas? Je pense que nous pouvons arriver à un pipeline qui n'utilise pas de chemins. – materialdesigner

+0

Ce serait bien. Je préférerais ne pas jouer avec/modifier la ressource git standard (où je pourrais aussi implémenter le comportement). Je ne peux pas facilement voir comment obtenir une configuration où componentA et sharedLib sont "déclenchés" mais ignorer le déclencheur dans le cas d'une validation simultanée des deux. Je suppose que je pourrais vérifier l'ensemble de changement dans la tâche initiale et exécuter le code conditionnellement dans la tâche, mais alors je n'obtiens pas une belle représentation de haut niveau des blocs logiques. – tryggth

+0

Mais y a-t-il une raison spécifique pour laquelle vous voulez des tâches séparées et des ressources séparées? – materialdesigner

Répondre

0

Il me semble que votre désir général est de prendre cette mono-pension et l'utiliser pour construire trois modules, avec SharedLib étant construit avant ComponentA et/ou ComponentB.

Dans ce cas, je dirais qu'il modélise quelque chose comme ceci:

resources: 
- name: repo 
    type: git 
    source: 
    uri: ... 

jobs: 
- name: build 
    plan: 
    - get: repo 
    trigger: true 
    - task: build-shared-lib 
    file: repo/ci/build-shared-lib.yml 
    - aggregate: 
    - task: build-component-a 
     file: repo/ci/build-component-a.yml 
    - task: build-component-b 
     file: repo/ci/build-component-b.yml 
+0

Merci. Je suppose que cela construit la bibliothèque sur tous les commits. Le problème sous-jacent est ce que vous signalez. Utiliser un mono-repo pour construire trois composants. – tryggth