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.
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.
- In UX-100 only some job types may support the "re-run" action
UX-208multi-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: