Bug/jenkins 36273 pipeline search api organization support #307
Conversation
Also adds support to exclude jenkins item from flattening.
|
@cliffmeyers pipeline search api with organization support as well as param to exclude flattening of certain types (folder/multi-branch etc.). Please review. |
|
This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation. |
|
🐝 - this doesn't fix things fully, but moves it a bit closer. |
| @@ -23,7 +23,7 @@ export class PipelineRecord extends Record({ | |||
| weatherScore: 0, | |||
| }) { | |||
| isFolder() { | |||
| return this.numberOfFolders !== null; | |||
| return this._class === 'io.jenkins.blueocean.service.embedded.rest.PipelineFolderImpl'; | |||
There was a problem hiding this comment.
@michaelneale this works, but maybe we should simply keep code something like, this.numberOfFolders !== null && totalNumberOfBranches == null with TODO to say replace by class/capability, because this discovery of whats what needs to be dealt with in a common way, for example sometimes it needs to go and call /classes API to discover what other classes it knows or what other capabilities it might have. I think Keith was playing with this thing for JUnit report stuff.
There was a problem hiding this comment.
as discussed, lets use _class for now (other logic is hard to get right, surprisingly).
There was a problem hiding this comment.
Using _class is way more explicit than the num/folders/branches stuff which I always felt was a little too loose, so 🐝 - long term maybe referring to some kind of capability array with fixed values is a fine idea too.
There was a problem hiding this comment.
@cliffmeyers @michaelneale This is fine as quick solution. However for UI to show any multi-branch, I mean a developer has its own implementation of multi-branch, how does that show up in the UI? For that, UI should really be checking against interface, in this case: io.jenkins.blueocean.rest.model.BlueMultiBranchPipeline. That is UI core knows about well known interfaces it supports and on receiving a _class, it should call a common utility class that calls /rest/classes/:classId API to get list of other supported classes/capabilities. Something like: supportsCapability(givenClass, expectedClass), returns boolean. See Class of resource discovery
So a TODO should be marked or perhaps a ticket to track this.
There was a problem hiding this comment.
@vivek at the moment this is explicitly for filtering out what we know is vanilla folders, vs positively identifying things based on capabilities, so I think it will be ok for this as it won't stop new types showing up, just identify them by folders.
I believe we have some tickets open for capabilities, if not, we should open them for sure.
Related to issue # .
Summary of this pull request:
.
.
.
@reviewbybees