Manually triggered stages in Azure Devops YAML Pipelines

Question

I'd like to recreate a pipeline that looks something like this in YAML.

I have successfully recreated the first line (A) pipeline. A combination of dependsOn, environmentName, and environment approvals handles that. However, there doesn't seem to be a way to create the B and C pipelines in YAML.

I've seen several similar questions, but most were not quite what I was looking for or were very old had no solution. I suspect this isn't possible right now but wanted to ask to be sure.

Nies

Not get your response for several days, would you please share your latest information about this issue? If you have any concern, feel free to share it here. – Richman

@HughLin-MSFT, I haven't made any progress on this. – Nies

Answer 1

Put an approval in front of the first environment. It won't trigger until it's approved. That's as close as you're going to get right now.

Pokey

So then it is either always running or failed. There is no way to have a successful pipeline that doesn't run every stage. – Nies

Answer 2

You could control it per to the parameters, for example:

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"

The parameter is stageTest and you could set the value (check or uncheck) when queue pipepeline.

On the other hand, you also could skip stage when run pipeline: Skipping stages in a YAML pipeline

Sohn

That would remove the CI part of the pipeline and require me to know in advance which stages should be executed. – Nies

@Nies I am not clear what you mean. Which CI part is removed? On the other hand, what's the result if you skip some stages when run pipeline? – Sohn

it removes the initial trigger requiring me to manually run builds after every commit. – Nies

@Nies You can change trigger value to enable CI part, but it uses default parameter value. – Sohn

yes you can, but that effectively removes the ability to control what executes putting me back at square one. – Nies

It seems that there isn't the better way to do it. – Sohn

Answer 3

you could either set-up a mandatory environment approval or add an additional stage with an ManualValidation@0 task like so:

- stage: approval
  displayName: 'Approval'
  dependsOn: ci
  jobs:
  - deployment: approval
    displayName: Approve
    timeoutInMinutes: 4320 # job times out in 3 days
    pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job
    environment:
      name: ProdSA
      resourceType: VirtualMachine
    strategy: 
      runOnce:
        deploy:
          steps:
          - task: ManualValidation@0
            inputs:
              instructions: 'Approval required'
            timeoutInMinutes: 1440 # task times out in 1 day

result

note 1: the task will not work if you do not specify the pool: server, so I was not able to include the task inside of the actual dependent stage that executes on the remote agent. So in the setup like mine, you will need a separate stage for the approval.

note 2: you need the ManualValidation@0 specifically, not the ManualIntervention@8 task. I have been getting weird errors with the later

note 3: don't forget to set dependsOn: approval for the stages that follow next after approval stage.

Particolored

Answer 4

I am afraid that it is currently impossible to implement the manually triggered stage like the UI of release pipeline in YAML pipeline.

At present, the function of specifying the stage to run is provided in yaml, but this only applies to manually triggered pipelines and cannot deploy the manual stage at any time as in the release pipleine.

According to your flow chart, you want your pipeline start with CI and keep the independence of manual stages will not affect the running of the pipeline. Splitting stages into multiple yaml pipelines should not be what you want, so you can follow the uservoice and vote for this ticket to look forward to the release of new features.

Richman

That's what I had found as well. I had already voted on that but it's been over a year and no word on that. I'm just hoping someone has a clever workaround or that something else had been done that wasn't listed there. – Nies