1
votes

Étapes déclenchées manuellement dans Azure Devops YAML Pipelines

J'aimerais recréer un pipeline qui ressemble à ceci dans YAML.

 Release Pipeline

J'ai recréé avec succès le pipeline de première ligne (A). Une combinaison de dependOn , environmentName et d'approbations d'environnement gère cela. Cependant, il ne semble pas y avoir de moyen de créer les pipelines B et C dans YAML.

J'ai vu plusieurs questions similaires , mais la plupart étaient pas tout à fait ce que je cherchais ou étaient très vieux n'avait pas de solution. Je soupçonne que ce n'est pas possible pour le moment, mais je voulais demander pour être sûr.


2 commentaires

Vous n'avez pas reçu de réponse pendant plusieurs jours, pourriez-vous partager vos dernières informations sur ce problème? Si vous avez des inquiétudes, n'hésitez pas à les partager ici.


@ HughLin-MSFT, je n'ai fait aucun progrès à ce sujet.


3 Réponses :


0
votes

Mettez une approbation devant le premier environnement. Cela ne déclenchera pas tant qu'il n'aura pas été approuvé. C'est aussi proche que vous allez l'être maintenant.


1 commentaires

Donc, il est soit toujours en cours d'exécution, soit en échec. Il n'y a aucun moyen d'avoir un pipeline réussi qui n'exécute pas toutes les étapes.



0
votes

J'ai peur qu'il soit actuellement impossible d'implémenter l'étape déclenchée manuellement comme l'interface utilisateur du pipeline de publication dans le pipeline YAML.

À l'heure actuelle, la fonction de spécification de l'étape à exécuter est fournie dans yaml, mais cela ne s'applique qu'aux pipelines déclenchés manuellement et ne peut pas déployer l'étape manuelle à tout moment comme dans la version pipleine.

Selon votre organigramme, vous voulez que votre pipeline démarre avec CI et que l'indépendance des étapes manuelles n'affecte pas le fonctionnement du pipeline. La division des étapes en plusieurs pipelines yaml ne doit pas être ce que vous voulez, vous pouvez donc suivre la uservoice et votez pour ce ticket dans l'attente de la sortie de nouvelles fonctionnalités.


1 commentaires

C'est ce que j'avais trouvé aussi. J'avais déjà voté là-dessus, mais cela faisait plus d'un an et aucun mot à ce sujet. J'espère juste que quelqu'un a une solution de contournement intelligente ou que quelque chose d'autre a été fait qui n'y figurait pas.



1
votes

Vous pouvez le contrôler en fonction des paramètres, par exemple:

parameters:
- name: stageTest
  displayName: Run Stage test
  type: boolean
  default: false

trigger:
  - none

variables:      # pipeline-level
  system.debug: true

stages:
- stage: Build
  jobs:
  - job: Build
    steps:
    - script: echo "hello to my first Build"
- stage: Test
  dependsOn:
    - Build
  jobs:
  - job: Test
    steps:
    - script: echo "test"
- ${{ if eq(parameters.stageTest, true) }}: 
  - stage: B1
    dependsOn: []
    jobs:
    - job: B1
      steps:
      - script: echo "B1"
  - stage: B2
    dependsOn:
    - B1
    jobs:
    - job: B2
      steps:
      - script: echo "B2"

Le paramètre est stageTest et vous pouvez définir la valeur (cocher ou décocher) lors de la file d'attente du pipeline.

 entrez la description de l'image ici

D'autre part, vous pouvez également ignorer l'étape lors de l'exécution du pipeline: Ignorer les étapes d'un pipeline YAML


6 commentaires

Cela supprimerait la partie CI du pipeline et m'obligerait à savoir à l'avance quelles étapes doivent être exécutées.


@ drs9222 Je ne sais pas ce que vous voulez dire. Quelle partie CI est supprimée? D'un autre côté, quel est le résultat si vous sautez certaines étapes lors de l'exécution du pipeline?


il supprime le déclencheur initial qui m'oblige à exécuter manuellement les builds après chaque validation.


@ drs9222 Vous pouvez modifier la valeur de déclenchement pour activer la partie CI, mais elle utilise la valeur de paramètre par défaut.


oui, vous pouvez, mais cela supprime effectivement la capacité de contrôler ce qui s'exécute, me ramenant à la case départ.


Il semble qu'il n'y ait pas de meilleure façon de le faire.