Azure DevOps YAML 管道手动干预作业与其他作业并行运行

Question

我希望作业一个接一个地进行，第一个作业应该控制下一个作业的执行。

由于 YAML 管道中当前没有可用于 Kubernetes 外部部署的批准，因此我使用手动干预来停止作业的运行。但显然，它并没有停止之前的工作，而是停止了即将到来的阶段。我做错了什么？我希望收到一些有关干预的通知，但它会立即失败，并且根本不会停止下一项工作。

这是部署 STG 阶段的代码部分，其中parameters.interventionEnabled设置为true

jobs:
- job: RunOnServer
  displayName: 'Reject or resume'
  pool: server
  continueOnError: false
  steps:
  - task: ManualIntervention@8
    displayName: 'Manual Intervention'
    timeoutInMinutes: 0
    inputs:
      instructions: 'reject or resume'
    enabled: ${{ parameters.interventionEnabled }}

- job: Deploy
  displayName: ${{ parameters.name }}
  pool:
    name: ${{ parameters.agentPoolName }}
  steps:
  - checkout: none # skip checking out the default repository resource

  - task: DownloadPipelineArtifact@2
    displayName: Download NPM build artifact
    inputs:
      artifact: ${{ parameters.artifactName }}
      buildType: 'current'
      targetPath: ${{ parameters.artifactPath }}

Answer 1

嘿，ManualIntervention@8YAML 不支持 Andree。它是2020 年第二季度的路线图。

我认为您想要走的路线是使用通用环境类型的批准。

因此，您可以像这样在 yaml 中定义部署作业和环境

- deployment: DeploymentHosted Context
  displayName: Runs in Hosted Pool
  pool:
    vmImage: 'Ubuntu-16.04'
  # creates an environment if it doesn't exist
  environment: 'Dev'
  strategy:
    runOnce:
      deploy:
        steps:
        - bash: |
            echo This multiline script always runs in Bash.
            echo Even on Windows machines!

您可以使用 GUI 来保护环境。

• 导航到Pipelines -> Environments。
• 选择环境（您可以预先创建它们）。

• 然后添加并批准

  

与经典的发布定义和能够手动触发阶段相比，存在一些缺点。您可能不希望每个工件都成为每个阶段的候选者，如果您不批准环境，它最终会超时并报告失败。其他好的讨论请参见这里的评论。

Answer 2

现在可用： https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-validation ?view=azure-devops&tabs=yaml

- task: ManualValidation@0
  timeoutInMinutes: 1440 # task times out in 1 day
  inputs:
    notifyUsers: |
      test@test.com
      example@example.com
    instructions: 'Please validate the build configuration and resume'
    onTimeout: 'resume'