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

Allow plugins to override aspects of the Blue Ocean theme

    • Blue Ocean 1.2-beta3

      Problem

      It's currently difficult to make changes to the Blue Ocean CSS because it is compiled by the plugin when a release is prepared. Right now this makes the Blue Ocean CSS difficult to modify for theming purposes. Another plugin should be able to override any of the colors defined in `variables.less` to create a new "Theme" for Blue Ocean. It would also be nice if Blue Ocean made it easy to replace the logo with a custom logo.

      Solution

      • Make it easy to build the CSS based on of a primary brand color or two. Less allows you to define colors that have a relationship to with another. For example, the primary theme could define one color for the header (blue) and define the selection color to be a tint of the header (light blue). A derived theme could then specify it’s own header color (green) and the selection color would be automatically adjust to a tint of the header (light green). If colors are defined to have a relationship with each other it makes it easy for a theme to declare slight adjustments to the main theme without specifying all of the color values (which is harder to maintain as the base theme changes).
      • Make it easy to replace the logo with a custom logo. The theme should be able to provide one image for the entire logo, or a logo mark and text (for example, CJE has a 24x24 pixel logo mark with the text “CloudBees Jenkins Enterprise”). The provided logo (or logo mark) could be a gif, PNG, SVG.

      Example

      I've attached an example theme showing how CloudBees Jenkins Enterprise modifies the Blue Ocean theme to make the header dark teal. The goal of this story is to make it easy for the a plugin to supply:

      • A Logo mark
      • Logo text (In this example: “CloudBees Jenkins Enterprise”)
      • A header background color (In this example: #4e7c91)

      And everything is adjusted automatically, including the buttons and the selection colors.

      Our current approach for CJE accomplishes this by adding an additional stylesheet that adds rules to override the generated Blue Ocean CSS (bad approach). This is problematic because the CSS in the upstream Blue Ocean package can change without warning and we run the risk of having to re-theme components to get them to use the CloudBees theme.

      It would be much easier if we could supply our own “variables.less” and the Blue Ocean CSS would be generated based on our own variables.

      Technical Notes

      • JDL and other plugins export the less rather than compiled CSS
      • Blue Ocean compiles and serves less at runtime

       

          [JENKINS-44466] Allow plugins to override aspects of the Blue Ocean theme

          Thorsten Scherler created issue -
          Thorsten Scherler made changes -
          Description Original: When using JDL as standard design source forces to use the defined color scheme in JDL .

          Currently I as plugin dev has to declare css to override the colors:

          {codecss}
          .BasicHeader--default {
              background-color: #4E7C91;
          // ...
          }
          {code}

          The danger you have here by overriding the CSS is that the JDL styles can and will change without notice and will break your theme

          In https://issues.jenkins-ci.org/browse/JENKINS-42385 we are talking to centralize the usages/definition of color variables ( e.g. color.less). This allows to quickly see what colors are used.

          In a ideal solution I as a plugin dev can place my personalised color.less file in a determine location and it gets picked up and used to override the colours provided by jdl. Alternative we could define those color codes in a JS file which then can be override/read from.

          I will start a mail thread to discuss alternative solutions.
          New: When using JDL as standard design source forces to use the defined color scheme in JDL .

          Currently I as plugin dev has to declare css to override the colors:

          {code:css}
          .BasicHeader--default {
              background-color: #4E7C91;
          // ...
          }
          {code}

          The danger you have here by overriding the CSS is that the JDL styles can and will change without notice and will break your theme

          In https://issues.jenkins-ci.org/browse/JENKINS-42385 we are talking to centralize the usages/definition of color variables ( e.g. color.less). This allows to quickly see what colors are used.

          In a ideal solution I as a plugin dev can place my personalised color.less file in a determine location and it gets picked up and used to override the colours provided by jdl. Alternative we could define those color codes in a JS file which then can be override/read from.

          I will start a mail thread to discuss alternative solutions.
          Thorsten Scherler made changes -
          Description Original: When using JDL as standard design source forces to use the defined color scheme in JDL .

          Currently I as plugin dev has to declare css to override the colors:

          {code:css}
          .BasicHeader--default {
              background-color: #4E7C91;
          // ...
          }
          {code}

          The danger you have here by overriding the CSS is that the JDL styles can and will change without notice and will break your theme

          In https://issues.jenkins-ci.org/browse/JENKINS-42385 we are talking to centralize the usages/definition of color variables ( e.g. color.less). This allows to quickly see what colors are used.

          In a ideal solution I as a plugin dev can place my personalised color.less file in a determine location and it gets picked up and used to override the colours provided by jdl. Alternative we could define those color codes in a JS file which then can be override/read from.

          I will start a mail thread to discuss alternative solutions.
          New: When using JDL as standard design source forces to use the defined color scheme in JDL .

          Currently I as plugin dev has to declare css to override the colors:

          {code}
          .BasicHeader--default {
              background-color: #4E7C91;
          // ...
          }
          {code}

          The danger you have here by overriding the CSS is that the JDL styles can and will change without notice and will break your theme

          In https://issues.jenkins-ci.org/browse/JENKINS-42385 we are talking to centralize the usages/definition of color variables ( e.g. color.less). This allows to quickly see what colors are used.

          In a ideal solution I as a plugin dev can place my personalised color.less file in a determine location and it gets picked up and used to override the colours provided by jdl. Alternative we could define those color codes in a JS file which then can be override/read from.

          I will start a mail thread to discuss alternative solutions.
          Ryan Campbell made changes -
          Labels New: cloudbees-internal-steel
          Ryan Campbell made changes -
          Priority Original: Minor [ 4 ] New: Critical [ 2 ]
          James Dumay made changes -
          Epic Link New: JENKINS-43955 [ 181487 ]
          James Dumay made changes -
          Description Original: When using JDL as standard design source forces to use the defined color scheme in JDL .

          Currently I as plugin dev has to declare css to override the colors:

          {code}
          .BasicHeader--default {
              background-color: #4E7C91;
          // ...
          }
          {code}

          The danger you have here by overriding the CSS is that the JDL styles can and will change without notice and will break your theme

          In https://issues.jenkins-ci.org/browse/JENKINS-42385 we are talking to centralize the usages/definition of color variables ( e.g. color.less). This allows to quickly see what colors are used.

          In a ideal solution I as a plugin dev can place my personalised color.less file in a determine location and it gets picked up and used to override the colours provided by jdl. Alternative we could define those color codes in a JS file which then can be override/read from.

          I will start a mail thread to discuss alternative solutions.
          New: *Scope*
          * JDL and other plugins export the less rather than compiled CSS
          * Blue Ocean compiles and serves less at runtime

          *Problem*
          When using JDL as standard design source forces to use the defined color scheme in JDL .

          Currently I as plugin dev has to declare css to override the colors:

          {code}
          .BasicHeader--default {
              background-color: #4E7C91;
          // ...
          }
          {code}

          The danger you have here by overriding the CSS is that the JDL styles can and will change without notice and will break your theme

          In https://issues.jenkins-ci.org/browse/JENKINS-42385 we are talking to centralize the usages/definition of color variables ( e.g. color.less). This allows to quickly see what colors are used.

          In a ideal solution I as a plugin dev can place my personalised color.less file in a determine location and it gets picked up and used to override the colours provided by jdl. Alternative we could define those color codes in a JS file which then can be override/read from.

          I will start a mail thread to discuss alternative solutions.
          James Dumay made changes -
          Assignee New: Josh McDonald [ sophistifunk ]
          James Dumay made changes -
          Priority Original: Critical [ 2 ] New: Major [ 3 ]
          James Dumay made changes -
          Sprint New: Blue Ocean 1.2-beta3 [ 346 ]
          James Dumay made changes -
          Rank New: Ranked lower

            kzantow Keith Zantow
            tscherler Thorsten Scherler
            Votes:
            10 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated: