It would be nice to have this API sooner rather than later so I can spend some more time on these re-entrant flows. Thanks vivek!

cliffmeyers

> For organizations where jenkinsOrganizationPipeline is true, could we add an additional field that indicates whether "auto discover" is enabled?

So auto-discover is false if in model there are no branch filtering specified? that is branch filter is empty then its auto-discover?

> Could we add a field to the repository object that indicates whether a pipeline has already been created for it?

yeah can be done, I guess you want it to be true if there is job for this repo inside this org folder

> So auto-discover is false if in model there are no branch filtering specified? that is branch filter is empty then its auto-discover?

What we call "auto discover" in the UI is the mode where there is no filtering of repositories. You said "branch filtering" but I think perhaps you mean "repository filtering"

> yeah can be done, I guess you want it to be true if there is job for this repo inside this org folder

Yes, that's exactly right.

These fields will allow us to customize the UI appropriately when the user selects a Github organization that already has an org folder created in Jenkins.

vivek I added #2 to this list, related to the HAL href to the Jenkins org folder. Let me know if you think that's doable.

cliffmeyers

> I added #2 to this list, related to the HAL href to the Jenkins org folder. Let me know if you think that's doable.

I would avoid doing it as HAL that is inside _links element. HAL links are HTTP reachable resources, org folder contains repositories and not other way round. This way when you fetch jenkins org folder (/jenkins/scm/github/organizations/cliffmeyers/) you should see HAL link to repositories. Besides if you are accessing /jenkins/scm/github/organizations/cliffmeyers/repositories/ then you already have org folder link that is /jenkins/scm/github/organizations/cliffmeyers/.

I could expose it as separate element, but it should be a collection as there could be more than one jenkins org folder for a given GitHub organization.

cliffmeyers

>> So auto-discover is false if in model there are no branch filtering specified? that is branch filter is empty then its auto-discover?
> What we call "auto discover" in the UI is the mode where there is no filtering of repositories. You said "branch filtering" but I think perhaps you mean "repository filtering"

First of all there could be more than one jenkins org folder for a given GitHub organization. Second there is no definitive way to tell if it was auto-discover. This is UI concept so I can provide an element that can provide list of requested repos when jenkins org folder was created. If its empty you can compute its auto-discover.

So my proposed json element in GitHub organization response could be:

{
...
  "isJenkinsOrganizationPipeline":true,
  "jenkinsOrganizationPipelines":[
    {
      "pipeline":"cloudbeers1",
      "requestedRepos":["PR-7"],
      "_links" : {
        "self" : {
          "_class" : "io.jenkins.blueocean.rest.hal.Link",
          "href" : "/organizations/jenkins/pipelines/cloudbeers1/"
        }
      }
    },
    {
      "pipeline":"cloudbeers2",
      "requestedRepos":[], //will fetch all repos
      "_links" : {
        "self" : {
          "_class" : "io.jenkins.blueocean.rest.hal.Link",
          "href" : "/organizations/jenkins/pipelines/cloudbeers2/"
        }
      }
    }
  ]
...
}

There could be more than one jenkins org folder for a given GitHub org, I am not sure how useful its going to be. I would avoid doing it unless there is UX defined to handle it. Lets chat about it Monday, will be good to have jamesdumay and michaelneale around to get clarification on expected UX.

vivek cliffmeyers yes, returning an empty list or not empty is enough for the UI to decide what should be shown.

The other question is a little more vexing. Lets say we have a github org called "cloudbeers".
In jenkins today you could create as many instances of the cloudbees github org folder as you want - naming them all something creative, but al of the same thing (or with different filter criteria etc). There may be a valid case for this (not terribly likely, but you may apply different PR rules to some named subset of repos - I am fishing for a reason here).

The bottom line is that when you say "github org" - which one of these is the One True github org? In the blue ocean creation flow, you chose "github" and then it enumerate the org (folders?) it knows about, but that implies there is One True github org folder that you will add repos to (or make it auto discovery)? Do we assume the named item is the github orgs name? If things are created through blue ocean we can control this for sure.

michaelneale Well this is a real problem if we can't define a rule or convention to identify these org folders in a consistent manner. Let's discuss in the meeting later today.

cliffmeyers there would be a few ways to solve it that are suitable I am sure.

As discussed in backend meeting, the only change will be made in pipeline API that returns org folder pipeline.

Following tasks are expected:

• Ensure jenkins.branch.OrganizationFolder capability is returned for blueocean organization folder
• Following changes are expected in pipeline JSON response:

  {
    "pipeline":"blueocean-plugin",
    "requestedRepos":["master", "task/JENMINS-123"],
    "pipelines": ["master", "task/JENMINS-123"]
  }
  

• pipelines array is subset of requestedRepos (if not empty) as some of the repos might not have Jenkinsfile

{
  "pipeline":"blueocean-plugin",
  "requestedRepos":["master", "task/JENMINS-123"],
  "pipelines": ["task/JENMINS-123"] //no Jenkinsfile on master
}

• If requestedRepos is empty then consider it as auto-discover

  {
    "pipeline":"blueocean-plugin",
    "requestedRepos":[], //auto-discover
    "pipelines": ["master", "task/JENMINS-123"]
  }
  
  

cliffmeyers michaelneale did I get everything that needs to be done in API for this ticket?

Yes that is right. And the assumption is that the name of the org is the name of the top level org folder item so that the UI knows what to look up to fetch what repos are setup etc.

michaelneale cliffmeyers requestedRepos is saved as pattern using underlying GitHub-branch-source library. If you create org pipeline using BO creation flow there is way to get list of requested repo (BO api saves list of requested repos as properties on the org folder).

However users can create org pipeline using classic and give any kind of regex pattern and its not possible to get meaningful list of repositories. Basically, if its created using classic, this field is going to be empty but that might get interpreted as auto-scanned.

So is it reasonable behavior that "requestedRepos" element is present only if org folder was created using BO GitHub creation flow?

vivek if we can discriminate between if it was created by blue ocean or not* - sure. Perhaps could be another field? I would leave it to cliffmeyers. However, I think it is probably fine to omit it.

What about the case that it was created by blue ocean originally, but a user tweaks the regex after the fact - it would then be invalidated and we would have to know somehow - is this possible?

• Is it necessary to be a property - as if it is a list of patterns, it is pretty clear that it is a list (ie space separated right? or not reasonable to reverse it out of the pattern?)

michaelneale cliffmeyers Actually I don't see how it can work in all cases no matter which way we go. Internally its represented as pattern that user can tweak as well in classic. So there is no guarunteed round trip. I propose to drop requestedRepos property as there doesn't seem a way to provide that in consistent way.

If we drop "requestedRepos" we can't determine whether the user originally picked "autodiscover" or "one repo" and this has a profound implication on what we can do with the re-entrant flow for Github Creation. Seems appropriate to pull jamesdumay into this conversation as he had originally conceived of the feature.

cliffmeyers Ok, so all you need is to determine auto-discover or not. How about backend API returns a boolean - I was trying to avoid that but this seems like most logical solution given challenges listing requested repos. Sounds good to you?

Per discussion, boolean flag is okay as long as the "pipelines" array is preserved. This is important when a user wants to transition from "auto-discover" to "single repo" so that we can call the "update" REST API and provide accurate list for "repoNames": [].concat(pipelines, newRepoName)

cliffmeyers vivek not sure what I should be chiming in here for?

jamesdumay Vivek and I chatted earlier and sorted this out; we're all good for now.