Uploaded image for project: 'Jenkins Website'
  1. Jenkins Website
  2. WEBSITE-88

Figure out styles re-use between plugin-site and jenkins.io site

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      There's going to be some overlap in the styles between these two applications that we should share in some form or another.

      The site generation is using awestruct in the jenkins.io repository, and the plugin site is a different application entirely that we should be hosting under plugins.jenkins.io.

      The simplest/dumbest approach would be to copy and paste styles between the two applications, but that isn't great.

      Here are some things to consider:

      • Packaging shared styles in a npm module or some other referencable artifact that both applications can pull down at build time
      • Handling the top nav bar content, i.e. ensuring the links listed in the top navigation bar are consistent between the two sites

      We already use bower to install some node packages in the jenkins.io generation process so that might work, but I'm not familiar enough to make a decision on which direction to go here

        Attachments

          Issue Links

            Activity

            Hide
            gusreiber gus reiber added a comment -

            Some Sass infrastructure shared between a number of sites including the product, will make sense, but I don't view this as a ship requirement.

            Show
            gusreiber gus reiber added a comment - Some Sass infrastructure shared between a number of sites including the product, will make sense, but I don't view this as a ship requirement.
            Hide
            gusreiber gus reiber added a comment -

            Sass compiler will be the mechanism for this sharing.

            Show
            gusreiber gus reiber added a comment - Sass compiler will be the mechanism for this sharing.
            Hide
            rtyler R. Tyler Croy added a comment -

            gus reiber this is pretty important to me as copy/pasted styles between projects is not going to be manageable when others start contributing to these projects independently of one another.

            From my discussion IRL with Thorsten Scherler this doesn't seem like it's going to be a significant amount of work, but definitely has a pre-requisite (AFAICT) on WEBSITE-96 which is on my docket for this week

            Show
            rtyler R. Tyler Croy added a comment - gus reiber this is pretty important to me as copy/pasted styles between projects is not going to be manageable when others start contributing to these projects independently of one another. From my discussion IRL with Thorsten Scherler this doesn't seem like it's going to be a significant amount of work, but definitely has a pre-requisite (AFAICT) on WEBSITE-96 which is on my docket for this week
            Hide
            tscherler Thorsten Scherler added a comment -

            Actually the plugin site does not use Sass yet, but that can be adopted. As for now I do not thing there is much sharing, but maybe extracting a common.css for the website makes sense and using a central url to get it from. However we can adopt that quickly as soon we have it in place, so I think we should postpone this ticket.

            Show
            tscherler Thorsten Scherler added a comment - Actually the plugin site does not use Sass yet, but that can be adopted. As for now I do not thing there is much sharing, but maybe extracting a common.css for the website makes sense and using a central url to get it from. However we can adopt that quickly as soon we have it in place, so I think we should postpone this ticket.
            Hide
            gusreiber gus reiber added a comment -

            Daniel Beckham, and I discussed this a bit more at today's meeting. Since the plugin site is inheriting for .io and not the other way around, the .io site will really need to be the one surfacing the resources for the plugin site to consume. The easiest way we can think of to do that, is for the plugin site to scrape the top of the plugin site DOM at build time (or whatever index generating schedule) and dump that HTML atop the plugin's index.html page. Whatever CSS files it finds there from jenkins.io, it will apply.

            If we want to do something fancier with Sass or the menu bar, the .io site would need to produce those artifacts. To my knowledge, the .io site doesn't include any sass files, so there is nothing for the plugin site to share.

            ...I still think going the reverse direction, attaching the plugin site scripts directly to jenkins.io is the correct way to go, but for now, we are looking at serving both front and back of the plugin site from its own subdomain. Thus we need to pull shared resources from you, rather than push ourselves to you where we could just inherit shared resources as normal. Daniel, correct me if I am wrong. I will ping Michael as well, so he can correct me.

            Show
            gusreiber gus reiber added a comment - Daniel Beckham , and I discussed this a bit more at today's meeting. Since the plugin site is inheriting for .io and not the other way around, the .io site will really need to be the one surfacing the resources for the plugin site to consume. The easiest way we can think of to do that, is for the plugin site to scrape the top of the plugin site DOM at build time (or whatever index generating schedule) and dump that HTML atop the plugin's index.html page. Whatever CSS files it finds there from jenkins.io, it will apply. If we want to do something fancier with Sass or the menu bar, the .io site would need to produce those artifacts. To my knowledge, the .io site doesn't include any sass files, so there is nothing for the plugin site to share. ...I still think going the reverse direction, attaching the plugin site scripts directly to jenkins.io is the correct way to go, but for now, we are looking at serving both front and back of the plugin site from its own subdomain. Thus we need to pull shared resources from you, rather than push ourselves to you where we could just inherit shared resources as normal. Daniel, correct me if I am wrong. I will ping Michael as well, so he can correct me.
            Hide
            mmccaskill Michael McCaskill added a comment -

            As I've taken over development from Thorsten he is correct that the plugin site still doesn't use Sass but it can be adopted to use it.

            Show
            mmccaskill Michael McCaskill added a comment - As I've taken over development from Thorsten he is correct that the plugin site still doesn't use Sass but it can be adopted to use it.
            Hide
            danielbeck Daniel Beck added a comment -

            R. Tyler Croy Is the current approach to inheriting the style of the site okay with you, or does it need to be reworked?

            Show
            danielbeck Daniel Beck added a comment - R. Tyler Croy Is the current approach to inheriting the style of the site okay with you, or does it need to be reworked?
            Hide
            rtyler R. Tyler Croy added a comment - - edited

            Daniel Beck, it's not my favorite, but it works! So meh I guess

            Show
            rtyler R. Tyler Croy added a comment - - edited Daniel Beck , it's not my favorite, but it works! So meh I guess

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              rtyler R. Tyler Croy
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: