• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • blueocean-plugin
    • None

      I had discussed this with jamesdumay at Jenkins World 2017 so opening this to summarize.

      A few weeks ago, there was the following conversation on IRC that had some popularity(attached). TL;DR it would be cool to have a reactor/dashboard type view for a TV monitor. 

      Two approaches I had thought of was to:

      1. Service Accounts/Users in Jenkins. Right now, the blueocean jobs that are starred are for a particular user. There could be something like a 'tv user' account (which would theoretically be equivalent to a user with read-only permissions as assigned in the permissions matrix, where an organization can login to their 'tv user' account and display that on a screen, rather than someone's actual account. (This requires no real code change, it would just be an advertised use-case)
      2. Widget based drag-and-drop WYSIWYG type of interface. With the new work on Trends that I recently saw on Twitter, it might be useful to not only make these charts specific for a job but rather make it available on a dashboard view. This would look something like the crude cut and paste of the Trend video I attached . What I am trying to display here is a sample dashboard where I have selected a few jobs I care about knowing the status of, and then 3 different time series graphs of jobs/builds I am knowingly trying to optimize as a long term project, or just runtimes I care about for lengthier regression tests. I can call out all these useful pieces of information to look at without having to build the job (if I have Github hooks configured), nor search through builds to check their runtimes and/or trends. 

      Unfortunately, I am not much of a designer so I don't know how clear I am with all of this but I am sure someone on the team could turn this idea into something real. 

        1. BlueOceanReactorChat.jpg
          BlueOceanReactorChat.jpg
          197 kB
        2. dashing.png
          dashing.png
          267 kB
        3. IMG_20170926_114347.jpg
          IMG_20170926_114347.jpg
          3.36 MB
        4. Sample Dash.jpeg
          Sample Dash.jpeg
          123 kB
        5. Screen Shot 2017-09-22 at 3.23.24 pm.png
          Screen Shot 2017-09-22 at 3.23.24 pm.png
          797 kB
        6. testngchart.jpg
          testngchart.jpg
          72 kB

          [JENKINS-46780] Wallboard for Blue Ocean

          Michael Neale added a comment -

          In terms of functionality how close are plugins like: https://wiki.jenkins.io/display/JENKINS/Build+Monitor+Plugin to this - in terms of the end user experience? Want something different building on blue ocean UI elements? (I have more thoughts  on this, but just wanted to point that out for now). 

          Michael Neale added a comment - In terms of functionality how close are plugins like: https://wiki.jenkins.io/display/JENKINS/Build+Monitor+Plugin  to this - in terms of the end user experience? Want something different building on blue ocean UI elements? (I have more thoughts  on this, but just wanted to point that out for now). 

          Alvin Huang added a comment -

          I haven't personally used that plugin like the person who suggested it on IRC. From looking at the screenshots on the plugin page though, it seems to show the latest build, build status (progress bar), and green/red for success/failure. All of this can currently be visualized on the blue ocean dashboard. 

          If dashboards can be built arbitrarily and saved either with a sidebar link or in a view like the Build Monitor Plugin, we have basically replicated the functionality. 

          Currently, the jobs in the blue ocean dashboard are favorited and saved per Jenkins account, right? Would it be useful to add permissions to the matrix based authorization to restrict certain users/roles from seeing dashboards of other user/service accounts? Or would this be unnecessary? I know in our org no one will care that you are looking at their teams dashboard as long as you can't rerun the job or delete it. 

          Another thought would just be to make another tab in the Blue Ocean interface (next to Pipelines and Administration) for 'Dashboard' or 'Wallboard.' Where I can fill out a form similar to how you would create a new pipeline in blue ocean, add a regex of the jobs I care about or pick from a list, and then save it. Then a user can click the Tab and it would drop down:

          Dashboard ▼

          • App1 Dashboard
          • App2 Dashboard
          • Alvin's Dashboard
          • Create a New Dashboard

          Where all the dashboards are read-only and if I have am seeing an issue with App1, I can quickly look at their dashboard to see if their build job recently ran and put a new build in dev, or if their deploy job recently ran because they have pushed something new to prod.

          I don't know how to mock this up but if anyone prefers, I can hop on Hangouts and walk through my ideas.

          Alvin Huang added a comment - I haven't personally used that plugin like the person who suggested it on IRC. From looking at the screenshots on the plugin page though, it seems to show the latest build, build status (progress bar), and green/red for success/failure. All of this can currently be visualized on the blue ocean dashboard.  If dashboards can be built arbitrarily and saved either with a sidebar link or in a view like the Build Monitor Plugin, we have basically replicated the functionality.  Currently, the jobs in the blue ocean dashboard are favorited and saved per Jenkins account, right? Would it be useful to add permissions to the matrix based authorization to restrict certain users/roles from seeing dashboards of other user/service accounts? Or would this be unnecessary? I know in our org no one will care that you are looking at their teams dashboard as long as you can't rerun the job or delete it.  Another thought would just be to make another tab in the Blue Ocean interface (next to Pipelines and Administration) for 'Dashboard' or 'Wallboard.' Where I can fill out a form similar to how you would create a new pipeline in blue ocean, add a regex of the jobs I care about or pick from a list, and then save it. Then a user can click the Tab and it would drop down: Dashboard ▼ App1 Dashboard App2 Dashboard Alvin's Dashboard Create a New Dashboard Where all the dashboards are read-only and if I have am seeing an issue with App1, I can quickly look at their dashboard to see if their build job recently ran and put a new build in dev, or if their deploy job recently ran because they have pushed something new to prod. I don't know how to mock this up but if anyone prefers, I can hop on Hangouts and walk through my ideas.

          Michael Neale added a comment -

          ahuang I think for wallboards, they are often run on an monitor via some shared computer, not a personal login (that can time out). 

          My preference was that the wallboard was a discrete feature, that provides a read only URL you can throw up on a monitor (with some token that grants it read access). So you are thinking that you like the look of the favourite cards? that is the primary visualisation? or woudl there also be a need for the pipeline graph visualisation on a wallboard?

          Michael Neale added a comment - ahuang I think for wallboards, they are often run on an monitor via some shared computer, not a personal login (that can time out).  My preference was that the wallboard was a discrete feature, that provides a read only URL you can throw up on a monitor (with some token that grants it read access). So you are thinking that you like the look of the favourite cards? that is the primary visualisation? or woudl there also be a need for the pipeline graph visualisation on a wallboard?

          Alvin Huang added a comment - - edited

          The read-only URL sounds good to me. I was just thinking it could be quick link on the sidebar for someone to click:

          App1 Status

          App2 Status

          App3 Status

          And quickly see how the builds are doing or when a new deploy job ran across a particular team/app. Or maybe a /wallboard endpoint where all the prebuilt dashboards you have created live and you just pick one.

           

          I don't have a preference for the cards. The primary widget pieces I can think of so far are just the normal job status bar like blueocean shows now, pipeline graphs, or trends/metrics. And a user can either

          • drag and drop (snap to grid) to the dashboard to their desired layout 
          • or you can give them a drop down menu of selectors and blue ocean will decide how to best lay it out with/without the ability to rearrange

          As far as the pipeline graph goes, I think that might be too detailed for a wallboard. If you have parallel stages or many serial stages, that graph can get quite large and may take up too much real estate. Maybe for one or two jobs the pipeline graph is OK but if you have more than that I would prefer the current blue ocean job list. That way, I can quickly scan the 'Status' column and login myself to check the pipeline graph and see more detailed of that particular job/run. 

          Alvin Huang added a comment - - edited The read-only URL sounds good to me. I was just thinking it could be quick link on the sidebar for someone to click: App1 Status App2 Status App3 Status And quickly see how the builds are doing or when a new deploy job ran across a particular team/app. Or maybe a /wallboard endpoint where all the prebuilt dashboards you have created live and you just pick one.   I don't have a preference for the cards. The primary widget pieces I can think of so far are just the normal job status bar like blueocean shows now, pipeline graphs, or trends/metrics. And a user can either drag and drop (snap to grid) to the dashboard to their desired layout  or you can give them a drop down menu of selectors and blue ocean will decide how to best lay it out with/without the ability to rearrange As far as the pipeline graph goes, I think that might be too detailed for a wallboard. If you have parallel stages or many serial stages, that graph can get quite large and may take up too much real estate. Maybe for one or two jobs the pipeline graph is OK but if you have more than that I would prefer the current blue ocean job list. That way, I can quickly scan the 'Status' column and login myself to check the pipeline graph and see more detailed of that particular job/run. 

          Michael Neale added a comment -

          ahuang that is a good point about a graph being too detailed, that simplifies it somewhat in that case. 

          I suppose next step is to copy/paste some things into a draft design

          Michael Neale added a comment - ahuang that is a good point about a graph being too detailed, that simplifies it somewhat in that case.  I suppose next step is to copy/paste some things into a draft design

          Alvin Huang added a comment -

          Yes, my belief is that the wallboard will show a very high level of health but show enough for me to say 'oh shoot I need to go take a look at that'

          Another interesting tidbit may be to possibly 'widgetize' all the different reporting graphs from the various testing tools (cobertura, junit, testng, etc.) I have attached the testng results from one of our jobs as reference. Then if I care about the test results for AppX on TeamY's Dashboard, I can pull in this results graph and snap it to my dashboard. Not sure how hard this would be or what the LOE is. 

          Let me know what I can do to help on my end. I can try to find a UI mockup tool and build up what I envision (if you have any recommendations of FOSS tools to do this that would be great). Or if it would be helpful, I can jump on Hangouts. 

          Alvin Huang added a comment - Yes, my belief is that the wallboard will show a very high level of health but show enough for me to say 'oh shoot I need to go take a look at that' Another interesting tidbit may be to possibly 'widgetize' all the different reporting graphs from the various testing tools (cobertura, junit, testng, etc.) I have attached the testng results from one of our jobs as reference. Then if I care about the test results for AppX on TeamY's Dashboard, I can pull in this results graph and snap it to my dashboard. Not sure how hard this would be or what the LOE is.  Let me know what I can do to help on my end. I can try to find a UI mockup tool and build up what I envision (if you have any recommendations of FOSS tools to do this that would be great). Or if it would be helpful, I can jump on Hangouts. 

          Michael Neale added a comment -

          hey ahuang yeah a hangout may help - what is your TZ? 

          For tools, not sure about OSS ones but we use Sketch, but we don't need to go that far yet. 

          Based on your comments above, what about something like this: 

          Very simple. The top half are the same fav. cards we have now, just made 3 columns wide, and responsive. They do no more or less than now. You can specity what pipelines/branches (via a pattern) appear up there. 

          The bottom 3rd is charts - whcih are any charts, as you say, that other tools produce. Maybe time spent in a stage, or test trends. Once again, this is existing widgets (mostly) just assembled together, no new data - just existing data brought together. This can then be stored, possibly in a simple URI form so you can bookmark it, and access from anywhere. I guess the discussion points are around access control etc... but I am interested if building on existing widgets alone as a starting point. For example - with 1.3 (master) if you put ?features=trends on the URL, you can access this feature flagged thing: https://github.com/jenkinsci/blueocean-plugin/pull/1373

          This likely has some basic but useful trends (and it is a new extension point that backend code can implement to provide nice snappy charts). 

           

          so you end up with a URI like: 

          /wallboard?pipelines=<pipeline1/branch expression,anotherpipeline>&trends=<similar pattern>

          The patterns can uniquely idenitfy what you want to show (if they match multiple, it will try to squeeze them in). Some work to define what those patterns are etc

           

          How does that kind of thing sound? 

          The trick will be the /wallboard endpoint exposing data safely (or we make tokens) or something so we can get out of the personalization business for the purpose of this. 

          Michael Neale added a comment - hey ahuang yeah a hangout may help - what is your TZ?  For tools, not sure about OSS ones but we use Sketch, but we don't need to go that far yet.  Based on your comments above, what about something like this:  Very simple. The top half are the same fav. cards we have now, just made 3 columns wide, and responsive. They do no more or less than now. You can specity what pipelines/branches (via a pattern) appear up there.  The bottom 3rd is charts - whcih are any charts, as you say, that other tools produce. Maybe time spent in a stage, or test trends. Once again, this is existing widgets (mostly) just assembled together, no new data - just existing data brought together. This can then be stored, possibly in a simple URI form so you can bookmark it, and access from anywhere. I guess the discussion points are around access control etc... but I am interested if building on existing widgets alone as a starting point. For example - with 1.3 (master) if you put ?features=trends on the URL, you can access this feature flagged thing: https://github.com/jenkinsci/blueocean-plugin/pull/1373 This likely has some basic but useful trends (and it is a new extension point that backend code can implement to provide nice snappy charts).    so you end up with a URI like:  /wallboard?pipelines=<pipeline1/branch expression,anotherpipeline>&trends=<similar pattern> The patterns can uniquely idenitfy what you want to show (if they match multiple, it will try to squeeze them in). Some work to define what those patterns are etc   How does that kind of thing sound?  The trick will be the /wallboard endpoint exposing data safely (or we make tokens) or something so we can get out of the personalization business for the purpose of this. 

          Alvin Huang added a comment -

          I am in EST and I think you are in Australia right? I don't mind hopping on in the evening when I get home and catch you in the morning your time. 

          By fav cards did you mean the 'starred' jobs that Blue Ocean has or the cards on the Build Monitor Plugin? I'd vote for the Blue Ocean table since its organized, easier to read, and no new coding has to be done to create 'cards' like the Build Monitor Plugin. 

          The URI sounds like a great idea I agree with you that that should be the way to go. 'Saving' a dashboard should really just be saving the link to that URI as a quick link after it is built.

           

          I have uploaded a drawing of my thoughts as well. The things I added were:

          • Dashboard tab with drop down to select your saved dashboards
          • Normal blue ocean table with a '+' button where I can search by pattern or string (similar to the 'Search pipelines...' at the top of the normal blue ocean homepage). After adding a job it will add a new row to the table.
          • Sample trends/graphs of current charts from reporting plugins as we have discussed. Maybe some other sort of visualization like Github Org Health or Jenkins System Metrics of some sort (What I envision with this is setting a threshold of WARNING/ERROR based on how many jobs have failed/passed, or a counter of average runtimes). Just a integer/decimal widget for some sort of GREEN/YELLOW/RED threshold based metric. 
          • An 'add a graph/widget' button. I'm not sure the best way to design this. Whether having a list of widgets on the side and dragging-and-dropping is better, or using this 'add' button and dropping into some sort of widget configuration. 

          Alvin Huang added a comment - I am in EST and I think you are in Australia right? I don't mind hopping on in the evening when I get home and catch you in the morning your time.  By fav cards did you mean the 'starred' jobs that Blue Ocean has or the cards on the Build Monitor Plugin? I'd vote for the Blue Ocean table since its organized, easier to read, and no new coding has to be done to create 'cards' like the Build Monitor Plugin.  The URI sounds like a great idea I agree with you that that should be the way to go. 'Saving' a dashboard should really just be saving the link to that URI as a quick link after it is built.   I have uploaded a drawing of my thoughts as well. The things I added were: Dashboard tab with drop down to select your saved dashboards Normal blue ocean table with a '+' button where I can search by pattern or string (similar to the 'Search pipelines...' at the top of the normal blue ocean homepage). After adding a job it will add a new row to the table. Sample trends/graphs of current charts from reporting plugins as we have discussed. Maybe some other sort of visualization like Github Org Health or Jenkins System Metrics of some sort (What I envision with this is setting a threshold of WARNING/ERROR based on how many jobs have failed/passed, or a counter of average runtimes). Just a integer/decimal widget for some sort of GREEN/YELLOW/RED threshold based metric.  An 'add a graph/widget' button. I'm not sure the best way to design this. Whether having a list of widgets on the side and dragging-and-dropping is better, or using this 'add' button and dropping into some sort of widget configuration. 

          Javier Delgado added a comment - - edited

          I would like to hijack this issue to propose another (additional) alternative:

          Since more than a year, Im using a custom dashing dashboard and I belive its feedback could fit into blueocean.

          The dashboard left side shows the currently running jobs, unfiltered, showing its full foder paths (AI/EOSNightly), the run id (#60) and the elapsed time (51 minutes, 49 seconds). Additional info such as agents connected to the master and number of containers in our swarm cluster are shown at the bottom.
          The dashboard right side shows the last ten executions (again, unfiltered), showing the same fields as before (path, id, duration) and adding the run result in a colored way. The bottom number (12514) is the amount of not shown runs

          I believe that polishing some elements, adding a filtering functionality (so that you can see one project activity) and maybe some testing related info (as you were commenting) would be cool

          Edit: I must say that blueocean aready shows the wun/running information, but not in an aggregated way (you can't watch several jobs activities on the same view) and thats what the dashing board allows for me.

          Edit2: that said, maybe this comment would fit at a different ticket, as a RFE.

          Javier Delgado added a comment - - edited I would like to hijack this issue to propose another (additional) alternative: Since more than a year, Im using a custom dashing dashboard and I belive its feedback could fit into blueocean. The dashboard left side shows the currently running jobs, unfiltered, showing its full foder paths (AI/EOSNightly), the run id (#60) and the elapsed time (51 minutes, 49 seconds). Additional info such as agents connected to the master and number of containers in our swarm cluster are shown at the bottom. The dashboard right side shows the last ten executions (again, unfiltered), showing the same fields as before (path, id, duration) and adding the run result in a colored way. The bottom number (12514) is the amount of not shown runs I believe that polishing some elements, adding a filtering functionality (so that you can see one project activity) and maybe some testing related info (as you were commenting) would be cool Edit: I must say that blueocean aready shows the wun/running information, but not in an aggregated way (you can't watch several jobs activities on the same view) and thats what the dashing board allows for me. Edit2: that said, maybe this comment would fit at a different ticket, as a RFE.

            Unassigned Unassigned
            ahuang Alvin Huang
            Votes:
            7 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: