[Bug] yaml pipelines created through cli need to be run once before CI triggers work

[jkewley]

Describe the bug I have a fairly specific test case which I'm having problems with.

We are generating ARM parameter files and yaml pipeline definitions for applications. At the moment we are testing all of this in a feature branch. These are the trigger bits for a sample yaml definition:

trigger:
  branches:
    include:
    - feature/pipeline-updates
  paths:
    include:
    - app01/app01.sandbox.parameters.json

The Issue

When I use the web interface to create a build definition for a yaml file in the feature/pipeline-updates feature branch the CI triggers work without issue. When I create the pipeline with the cli extension for the exact same file it won't fire until I manually run the pipeline the first time, after which CI triggers work as expected.

Example az call to create the pipeline, leaving out params which aren't related to this issue:

az pipelines create --name 'app01-sandbox' --branch 'refs/heads/master' --yml-path 'app01/app01.pipeline.sandbox.yml' --skip-first-run true

A couple of notes on the branch argument, which I think is the source of this problem

• I originally provided the feature branch where the yaml build definition is found, but that didn't work at all. I think the documentation for this option could use a little love - what does the default branch mean and how is it related to the location of the yaml file?
• I got the idea to use refs/head/master by examining pipeline edit screen > triggers > Yaml for the manually created pipeline. Get Sources showed a default branch of master where the cli-created one showed my feature branch
• this is a small one, but using master instead of refs/head/master appears to work fine, but the pipeline definition isn't normalized to the fully qualified path which is created when using the web interface (verify this with az pipeline show)

When creating via the CLI, the first time you visit the pipeline definition edit screen in the web interface an error is shown saying that it can't find the build definition in master. Switching the dropdown to the feature pipeline fixes that. After the pipeline is executed one time there appears to be a 'last executed on branch' state stored somewhere so returning to the edit screen no longer errors by default. Does the cli need a second parameter to specify which branch the yaml pipeline can be found in?

One last item - az pipeline show reveals that a cli-created pipeline definition has null repository>properties:

...
"repository": {
    ...
    "defaultBranch": "refs/heads/master",
    ...
    "properties": null, <--------------------
    ...
  },

it remains null even after the first run when CI starts to work.

However, the pipeline created in the web interface has this information

  "repository": {
    ...
    "defaultBranch": "refs/heads/master",
    ...
    "properties": {
      "cloneUrl": "redacted",
      "defaultBranch": "refs/heads/master",
      "fullName": "repoNameHere",
      "isFork": "False",
      "reportBuildStatus": "true",
      "safeRepository": "someGuid"
    },
    ...
  },

To Reproduce Azure Cli Version: 2.5.1 Azure-Devops extension version: 0.18.0

Steps to reproduce the behavior:

1. Create a yaml pipeline in a feature branch that triggers off of the same feature branch
2. use az pipeline create to create a pipeline that points to the yaml file. Use the --branch argument noted above
3. Once the pipeline is in place, modify the param file. Notice that the CI trigger doesn't fire
4. Run the pipeline manually using the web interface
5. After it completes, modify the param file again and notice the CI functionality works as expected

Expected behavior CI triggers after first edit to param file, and before the pipeline is executed manually

[jkewley]

Possibly related? #953