Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-35884

API for testing a entities capabilities for the UI

    Details

    • Epic Link:
    • Sprint:
      1.0-japan-m9, 1.0-m7, 1.0-m10
    • Similar Issues:

      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:

      {
         "displayName":"blueocean-docker-image-build",
         ...
         "capabilities": {
             "supportsMultiBranch": true,
             "supportsPullrequests": true,
             "supportsActionRerun": true,
             "supportsActionSomethingElse": false
           }
         ...
      }
      

        Attachments

          Issue Links

            Activity

            Hide
            michaelneale Michael Neale added a comment -

            I think this makes sense. This probably also ties into plugins - more plugins bring more capability.

            Show
            michaelneale Michael Neale added a comment - I think this makes sense. This probably also ties into plugins - more plugins bring more capability.
            Hide
            jamesdumay James Dumay added a comment -

            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

            Show
            jamesdumay James Dumay added a comment - 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
            Hide
            jamesdumay James Dumay added a comment -

            [~vpandey] as discussed we should be supporting capabilities on all entities

            Show
            jamesdumay James Dumay added a comment - [~vpandey] as discussed we should be supporting capabilities on all entities
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            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.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - 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.
            Hide
            vivek Vivek Pandey added a comment -

            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
            Show
            vivek Vivek Pandey added a comment - 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

              People

              • Assignee:
                vivek Vivek Pandey
                Reporter:
                jamesdumay James Dumay
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: