[JIRA] [core] (JENKINS-32444) Proposal: Move build logs off of Jenkins master
Title: Message Title Larry Bordowitz commented on JENKINS-32444 Re: Proposal: Move build logs off of Jenkins master This is not a permanent change that affects everybody. I wanted to use a feature flag so that people can turn it on or off as needed. Log annotators aren't a hard requirement for everyone, and if I want zero log annotators, I should have that choice. I want this to be an optional feature. Anybody who doesn't opt in will see Jenkins run the same as always. Folks can keep their absolutely necessary, unsparkly Mask Passwords Plugin. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-32444) Proposal: Move build logs off of Jenkins master
Title: Message Title Larry Bordowitz created an issue Jenkins / JENKINS-32444 Proposal: Move build logs off of Jenkins master Issue Type: Improvement Assignee: Unassigned Components: core Created: 14/Jan/16 1:13 AM Labels: 2.0 Priority: Major Reporter: Larry Bordowitz Since the output stream of the log is wrapped by a remote proxy in StreamBuildListener, every log message on the slave gets transferred to the master. That's a lot of throughput, and it requires a lot of storage for verbose builds. This slows down our builds. There are workarounds, but they address the core scalability issue. I propose that, just like with abstract artifacts (see VirtualFile, ArtifactManager), task/build listeners be made extensible, so that users can choose something other than a StreamBuildListener in a build. Further, the log should no longer be file-based; the Listener provides the input and output stream. This should be easy to serialize in the "remote logging service" perspective: just provide the service configuration, and an API call can be made from the slave to publish to the log, and any authorized user of the log can subscribe. The master can either directly subscribe and pipe the log through the UI, or another service which is authorized to subscribe to the logging service can provide the UI
[JIRA] [core] (JENKINS-32444) Proposal: Move build logs off of Jenkins master
Title: Message Title Larry Bordowitz updated an issue Jenkins / JENKINS-32444 Proposal: Move build logs off of Jenkins master Change By: Larry Bordowitz Since the output stream of the log is wrapped by a remote proxy in StreamBuildListener, every log message on the slave gets transferred to the master. That's a lot of throughput, and it requires a lot of storage for verbose builds. This slows down our builds. There are workarounds, but they don't address the core scalability issue.I propose that, just like with abstract artifacts (see VirtualFile, ArtifactManager), task/build listeners be made extensible, so that users can choose something other than a StreamBuildListener in a build. Further, the log should no longer be file-based; the Listener provides the input and output stream. This should be easy to serialize in the "remote logging service" perspective: just provide the service configuration, and an API call can be made from the slave to publish to the log, and any authorized user of the log can subscribe. The master can either directly subscribe and pipe the log through the UI, or another service which is authorized to subscribe to the logging service can provide the UI externally.One of the tougher things about this change is that it will not be compatible with any BuildWrapper and ConsoleLogFilter plugins. Those plugins decorate the OutputStream on master referred to by the slave's proxy stream. Since the plugins are on the master, it forces the slave to send all log lines to the master for decoration. This pattern tightly couples the logging concept with a master-based file. In order to maintain compatibility for those users for whom this is not an issue, I recommend a "high availability mode" feature flag. This flag will enable certain features that improve availability and scalability, and disable those extension points (BuildWrapper, ConsoleLogFilter) which are incompatible with this new flow. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [labeled-test-groups-publisher-plugin] (JENKINS-30711) TAP Parser comes up as default test result format while loading job config UI
Title: Message Title Larry Bordowitz resolved as Fixed Please verify that this works for you. Jenkins / JENKINS-30711 TAP Parser comes up as default test result format while loading job config UI Change By: Larry Bordowitz Status: Open Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [labeled-test-groups-publisher-plugin] (JENKINS-30711) TAP Parser comes up as default test result format while loading job config UI
Title: Message Title Larry Bordowitz assigned an issue to Larry Bordowitz Jenkins / JENKINS-30711 TAP Parser comes up as default test result format while loading job config UI Change By: Larry Bordowitz Assignee: Larry Bordowitz Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [labeled-test-groups-publisher-plugin] (JENKINS-13376) Ability to add in new groups of test types
Larry Bordowitz resolved JENKINS-13376 as Fixed Ability to add in new groups of test types Let me know if this works alright. The fix should provide backwards compatibility, so it shouldn't interfere with previous versions if you upgrade it. Change By: Larry Bordowitz (05/Jan/15 6:11 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [labeled-test-groups-publisher-plugin] (JENKINS-13376) Ability to add in new groups of test types
Larry Bordowitz assigned JENKINS-13376 to Larry Bordowitz Ability to add in new groups of test types Change By: Larry Bordowitz (05/Jan/15 5:53 PM) Assignee: LaurenceBordowitz This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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.
