Details
-
Type:
Task
-
Status: Done (View Workflow)
-
Priority:
Minor
-
Resolution: Fixed
-
Component/s: design, plugin-site
-
Labels:
-
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
- is related to
-
-
- Closed
-
-
-
- Done
-
-
-
- Resolved
-
Activity
Sass compiler will be the mechanism for this sharing.
gus reiber
added a comment - Sass compiler will be the mechanism for this sharing. 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
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.
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.
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. 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.
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. R. Tyler Croy Is the current approach to inheriting the style of the site okay with you, or does it need to be reworked?
Daniel Beck, it's not my favorite, but it works! So meh I guess 
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.