Description

Discussion
For any job it would be useful for there to be some way for the UI to test what capabilities a particular job has from its REST response.

As more and more operations become optional depending on the underlying job type, inferring what is supported with a job type will become more tricky and how to test with them will become tribal knowledge only.

Why
We do not want a situation where there are two job types that support the same features and implement different UIs to solve the same problem. This the crux of the capabilities model – it declarative way of saying "I support this feature and want to use the blue ocean opinionated way of doing things". This avoids ugliness in the frontend code where we would have to add conditionals for different job types.

For example, if there are two jobs that support branches and pull requests the job can declare in the API that it supports this concept. When it advertises the "supportsBranches" capability, there are parts of the UI (the branches tab) that get shown on this condition. At no point does the Pipeline job and another job type have to implement the same UI (branch tab) nor does the UI have to know what specific plugins support the feature.

Another concrete example is "rerun". The rerun action for a completed run will use the same commits in a new run and users will expect it will work the same way when they see that action. Not all jobs will support this, so there will need to be a capability advertising to the UI to tell it this feature works in the way the user expects.

Examples

In UX-100 only some job types may support the "re-run" action

UX-208 multi-branch pipelines support branches and pull requests. Currently the UI checks for null elements in the response of a job for the "branchNames" sub-element to infer if the tabs should be displayed or not.

This could be as simple as having the following structure in every response for a job:

James Dumay
added a comment - 2016-05-16 16:35 Please include in the scope the capabilities for:
Supporting pipeline graph
Supporting branches
Supporting pull requests
Supporting step level logs
Please have a look around for more. This should have its own section in the REST README.md

Kohsuke Kawaguchi
added a comment - 2016-05-23 06:45 We met just now and agreed on the plan of attack on this.
I'll write it up in the next 24hrs so that we can all sign this off before the implementation work commences.

Vivek Pandey
added a comment - 2016-06-23 00:48 Capability annotation is implemented in separate repo, https://github.com/vivek/capability-annotation . A hosting ticket is opened to move it inside jenkinsci: https://issues.jenkins-ci.org/browse/HOSTING-128 .
Next:
Get this JAR file released to maven
Implement processing of it in blueocean /classes API