[JIRA] (JENKINS-55359) Add view of Warning Results in Blue Ocean
Title: Message Title Jake Gage commented on JENKINS-55359 Re: Add view of Warning Results in Blue Ocean The two products of Warnings seem to be annotations of files (coverage over the current commit state) summary numbers (a time-series snapshot of the current commit state) which can be differentiated from previous builds (`master`/last passing build) If I'm correct about that, JEP203 wouldn't really be required, would it? It would be possible for Blue Ocean to support two highly broad and valuable views of the build/build trend file annotations (by category, which Warnings NG would have to report correctly) "This line of code reports an annotation produced by a lint tool." ...with the possible addition of a view of annotations produced by the tool, for acceptance and navigating the annotations ...with the possible addition of a view of annotations produced by all tools, for acceptance and navigating the annotations build trends only meaningful in build-trend contexts already a major part of Blue Ocean's interface for an individual build possibly related to a "main" branch build Not a small ask, but I'm not sure it's as broad as "offer an open interface to extend Blue Ocean," which (IMHO) is quite the ask. Add Comment
[JIRA] (JENKINS-46840) Jenkins blueocean plugin - Unable to create pipeline from github
Title: Message Title Jake Gage commented on JENKINS-46840 Re: Jenkins blueocean plugin - Unable to create pipeline from github Sorry to comment on a closed Issue, folks— but I'm a bit confused. JENKINS-45253 doesn't seem to mention "ALPN callback dropped" messages at all. I'm wont to just suppress the messages, but I'd like to know the impact. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53712) Jenkins context initialization should not complete until Jenkins is "ready to work"
Title: Message Title Jake Gage created an issue Jenkins / JENKINS-53712 Jenkins context initialization should not complete until Jenkins is "ready to work" Issue Type: Bug Assignee: Unassigned Components: core Created: 2018-09-21 17:57 Priority: Minor Reporter: Jake Gage Recent changes to Jenkins seem to have made startup times longer, and have acerbated this issue, breaking several automations. However— this issue hopes to address a deeper problem with the startup sequence. The Jenkins initialization reports as completing, then other processes begin to make Jenkins "ready to work...". It's completely okay that these processes will take a while and that the Jenkins application is in-place before it's able to respond to Web service events, say. The problem comes when automations attempt to restart Jenkins, and presume that Jenkins has been restarted when the service reports as restarting. At a deep level, the Jenkins context reports initialization as complete before functionality is available. For the GUI user, we present a nice interface that clearly tells the user to wait. However, for anything relying on Jenkins, there is no cue differentiating Jenkins being "up" and "waiting to come up." Automations can wait for the service to start, but service wrapping report Jenkins as being started— in some cases many minutes before Jenkins is prepared to respond to any events. This issue proposes that this is a bug, and that the init() process should wait for dependent processes, and not return as complete until Jenkins is considered fit-for-use.
