Mise à jour 26-févr.-2020
Dans notre projet, j'ai un pipeline "MyPipeline" qui restaure les packages NuGet, construit les solutions et exécute les tests.
Sur la branche master , j'ai une politique qui fait des choses comme ajouter des réviseurs de code, et elle a une étape de "validation de construction" qui exécute "MyPipeline". Tout va bien.
Cependant, j'ai créé une autre branche de Master appelée NewBranch et je l'ai synchronisée (poussée) vers Azure. Après avoir apporté quelques modifications mineures dans Visual Studio, j'ai effectué une fusion depuis le maître , validée et synchronisée avec Azure.
J'ai été un peu surpris de voir alors "MyPipeline" s'exécuter . Il semble avoir été déclenché lorsque j'ai poussé mes modifications de NewBranch vers Azure. Je n'ai pas de politique de branche sur "NewBranch". Le déclencheur dans le fichier YAML est:
trigger: - master
Qu'est-ce qui a déclenché cela? Je vais bientôt brûler mes minutes d'agent libre si cela continue ...
Mise à jour 26-févr.-2020
Selon les commentaires ci-dessous:
L'historique des commits sur la branche master est:
L'historique de l'exécution du pipeline affiche:
Donc, rien de nouveau n'a été engagé dans la branche Master. Cependant, je pense que je sais ce qui cause cela. Juste que je ne suis pas convaincu du timing ....
Nous avons donc deux branches, master et NewBranch .
Master a une règle qui requiert l'approbation de deux réviseurs de code, et la construction réussit. En raison de cette politique, un développeur ne peut donc pas fusionner directement dans master - il doit générer une Pull Request.
Ainsi, le développeur A crée une Pull Request pour fusionner NewBranch à Master . Il y a ensuite le processus de révision du code plutôt long qui peut nécessiter plusieurs validations supplémentaires pour la Pull Request de "NewBranch" avant qu'elle ne soit jugée acceptable.
Ce qui semble se produire, c'est que chaque fois que l'un de ces nouveaux Commits est synchronisé avec la Pull Request, une compilation est déclenchée. Est-ce une bonne chose? Peut-être peut-être pas. Si la construction ne se déclenche qu'une seule fois, la compilation doit avoir lieu lorsque tout le code de la demande d'extraction a été approuvé, pas avant. Pourquoi déclencher une construction à un stade aussi précoce; la branche master peut être mise à jour par plusieurs autres demandes d'extraction avant qu'elle ne soit prête à être fusionnée. Cependant, avec des ressources illimitées, je suppose qu'il n'y a pas de mal à créer aussi souvent que possible, mais a) ceci peut retarder d'autres builds (ce qui représente un obstacle pour les autres développeurs) et b) cela utilise la limite de temps libre de l'agent.
3 Réponses :
J'ai vu le même comportement aujourd'hui.
Pouvez-vous essayer de réécrire la partie déclencheur de votre pipeline comme ceci:
trigger: - master
Cela vous aide-t-il? Je ne peux pas encore le vérifier moi-même, car j'ai fait ce changement mais le PullRequest n'est pas encore approuvé :)
J'ai aussi un autre dépôt où je ne vois pas ce comportement, mais là, mon déclencheur de pipeline ressemble à ceci:
trigger:
branches:
include:
- master
(Notez les 2 espaces avant - master)
Je pense que vous devez ajouter pr: none à votre définition de pipeline pour désactiver l'exécution automatique.
Si pr n'est pas défini, je pense que la valeur par défaut est exécuté sur chaque PR.
Cela donnerait quelque chose comme ceci:
trigger:
batch: true
branches:
include:
- master
paths:
exclude:
- README.md
pr: none
Je ne pense pas que ce soit la source du problème ici, car les déclencheurs pr ne sont pas pris en charge par Azure DevOps: docs.microsoft.com/en-us/azure/devops/pipelines/build/…
Les informations détaillées que vous partagez en question m'aident beaucoup à comprendre l'ensemble de votre flux de travail.
Bien que vous n'ayez pas exprimé trop clairement, mais, oui, ce que vous devinez est correct. L'action que vous avez affrontée est attendue et conçue. La cause première est que vous utilisez la politique de branche et la Build validation également incluse dans cette politique.
En bref, vous utilisez Déclencheur de demande de traction .
Explication :
Faisons attention à sa définition:
Les déclencheurs de demande d'extraction (PR) entraînent l'exécution d'une compilation chaque fois qu'une demande d'extraction est ouverte avec l'une des branches cibles spécifiées, ou lorsque les modifications sont transmises à une telle demande d'extraction .
En fonction de vos contenus ajoutés, vos développeurs introduisent les modifications (nouveau commit) dans la demande de tirage d'ouverture ( Remarque: Le point clé est que la demande d'extraction est toujours en cours d'ouverture. ) Cela fait partie de la portée de travail du déclencheur PR en raison de la définition ci-dessus. C'est pourquoi la compilation déclenchait toutes les y nouvelles modifications introduites dans la branche NewBranch .
Solution:
Je suis d'accord avec la logique de la réponse de @ devpro. Mais son script n'est pas disponible pour votre scénario. Parce que le pr dans YAML ne fonctionne que pour les dépôts GitHub et Bitbucket Cloud.
Ici, vous utilisez le référentiel VSTS et avez configuré la stratégie pour celui-ci. Ainsi, vous ne pouvez que via la configuration de la politique de branche pour éviter de tels problèmes.
Dans votre panneau de validation de build, vous définissez la stratégie de build avec Automatique , n'est-ce pas?
Veuillez changer le Automatique en Manuel , également conserver la valeur de Exigence de politique comme Obligatoire .
Désormais, le pipeline de build correspondant ne sera pas exécuté automatiquement une fois le nouveau commit poussé, il ne pourra être construit que lorsque quelqu'un l'exécutera manuellement .
Pour le délai de retard que vous avez remarqué et qui vous rend incertain, je suppose que ce serait à cause du conflit.
À titre d'exemple, la requête d'extraction P1 qui fusionne de NewBranch à Master s'ouvre. Je commets un nouveau changement C1 dans NewBranch . MAIS, cela provoque le conflit. À ce stade, la génération ne sera pas exécutée car les modifications ne sont pas réellement transférées dans PR.
Remarque: Le commit est vrai pour NewBranch . MAIS les changements ne sont pas encore acceptés par PR, parce que PR detect là-bas a un conflit ici et vous devez dire à PR les changements que vous souhaitez conserver. Seules les modifications introduites dans PR peuvent fonctionner avec le déclencheur PR.
Seul le conflit résolu, les changements, peut-être que je peux dire «commit», peuvent vraiment être acceptés et poussés dans les relations publiques. Ensuite, la compilation déclenchée a été exécutée.
Ce serait le délai que vous avez remarqué.
avez-vous essayé de le reproduire? et avez-vous vérifié l'histoire du maître?
Il n'a pas pu être reproduit de mon côté. MAIS, c'est câblé. Qu'avez-vous vu dans l'historique de construction? Cela indique-t-il qu'il s'agit du CI individuel du maître? Aussi, d'accord avec ce qui est mentionné dans le commentaire ci-dessus, qu'en est-il de votre histoire principale.
@ MerlinLiang-MSFT - J'ai mis à jour le message d'origine avec des détails supplémentaires. Je pense que je peux voir pourquoi cela se produit, mais je ne suis pas sûr d'être à 100% d'accord avec cela. Soyez intéressé de savoir ce que vous en pensez. Merci