Re: [Essentials] (client) Error Telemetry logging: JEP in early draft review

Seems reasonable. The implementation separates JSON records with a newline. This is not apparent from the JEP; it would be nice to mention it, so that readers do not wonder whether you are using some kind of streaming JSON parser (which is unnecessary when each line is a well-formed JSON

Re: Need help designing a fix for JENKINS-50504

On Wed, Apr 4, 2018 at 4:26 AM, Oleg Nenashev wrote: > WorkspaceList#inUse should be reacquired by Pipeline for sure when it > reconnects to a new agent. I would guess it happens even now (or not?) No, currently a lock is acquired only when a `node` (or `ws`) body is

Using available pods in a Kubernetes deployment as slaves via Kubernetes plugin

Hi all, At my company, we use Jenkins to run builds with lots of parallel tasks, where the slaves for each task are provisioned from a private Kubernetes cluster. We have a very specific problem with these provisioned slaves: we'd like to reduce the time overhead of a Kubernetes slave to match

[Essentials] (client) Error Telemetry logging: JEP in early draft review

Hello everyone, So as a followup on the recent discussions around telemetry logging for Essentials, I've drafted a JEP on this matter I would love to get feedback on: https://github.com/batmat/jep/tree/JENKINS-49805/jep/ Thanks! -- Baptiste -- You received this message because you are

[DISCUSS] Change Jenkins default logging format

Hello everyone, Having worked on more things related to Jenkins logging recently, I've had the opportunity to remember my past pain when I was operating a Jenkins instance and sending logs to an ELK cluster. Compared to almost everything else in the infrastructure, the logstash rules for Jenkins

Re: [DISCUSS] Change Jenkins default logging format

Hi Baptiste, Anyone can easily change the logging format in Jenkins by passing custom J.U.L properties file. So it should not be a problem to change logging format even if you do not add a custom logging appender for ELK. Changing a default logging format may cause regressions in existing

Re: Trademark Sublicensing Request: DevOps World - Jenkins World

I will be travelling on April 11th, so I asked Tyler to drive this part of the meeting. My regrets for missing the meeting. As a board member, given that Jenkins World is an approved name, from the technical perspective of approving this trademark request, here is my absentee +1 vote. On Fri,

Re: [DISCUSS] Change Jenkins default logging format

> On 4. Apr 2018, at 18:12, Oleg Nenashev wrote: > > Changing a default logging format may cause regressions in existing > monitoring systems. I would rather be conservative and keep the default > logging format in Jenkins unless there is a strong justification to do

Re: [DISCUSS] Change Jenkins default logging format

(replies inline) On Wed, 04 Apr 2018, Oleg Nenashev wrote: > Hi Baptiste, > > Anyone can easily change the logging format in Jenkins by passing custom > J.U.L properties file. > So it should not be a problem to change logging format even if you do not > add a custom logging appender for ELK.

Re: [DISCUSS] Change Jenkins default logging format

I think I already claimed my hate for this logging format many times. For sure I understand Oleg's concern with the impact of changing the default settings. Like always for such kind of change when we don't really know how it could impact our users I would prefer to introduce the change non

Re: [DISCUSS] Change Jenkins default logging format

I'm +1 to change the format. 2 lines is really annoying On Wed, Apr 4, 2018 at 7:24 PM, R. Tyler Croy wrote: > (replies inline) > > On Wed, 04 Apr 2018, Oleg Nenashev wrote: > > > Hi Baptiste, > > > > Anyone can easily change the logging format in Jenkins by passing custom

Re: [DISCUSS] Change Jenkins default logging format

2018-04-04 18:12 GMT+02:00 Oleg Nenashev : > Hi Baptiste, > > Anyone can easily change the logging format in Jenkins by passing custom > J.U.L properties file. > Yes. But in practice, I'm convinced virtually nobody does this. > So it should not be a problem to change

Re: [DISCUSS] Change Jenkins default logging format

> On 4. Apr 2018, at 21:20, Oleg Nenashev wrote: > > • We enable the new logging format in Essentials + immediately get > benefit from it (e.g. via Logstash/fluentd) > • We offer a feature flag in standard Jenkins. Start from opt-in, then > maybe opt-out at

Re: POTD: Jenkinsfile Runner

Ouch, that's a shame. It looked like an interesting project, I hope my writing to you didn't trigger that. You say "stress builds and also to burn in our build agents" -- can you elaborate on that? It sounds like you are trying to warm up a cache or something, but I'm not sure what that means in

Re: JEP: Modification of "Accepted" JEPs

Hello all, I've attempted to synthesize the key points made here into a PR for JEP 1: https://github.com/jenkinsci/jep/pull/76 The scope of this change expanded a bit, but I think the result is clearer. Please feel free to comment (or even better to commit edits directly). Thanks, Liam On

Re: JEP: Modification of "Accepted" JEPs

Reading the updated JEP 1 sounds like PR 59 for JEP 201 would pass as minor changes which provides clarification. Unless I am misinterpreting the intend of both pull requests  Den onsdag den 4. april 2018 kl. 08.42.21 UTC+2 skrev Liam Newman: > > Hello all, > I've attempted to synthesize the

Re: Install extra Software with plugin installation

Hi Johann, Apparently not enough. Could you please provide some examples? Thanks in advance, Oleg On Wednesday, March 28, 2018 at 9:23:18 AM UTC+2, Johann wrote: > > Hello guys, > > I am wondering if its possible to install external software automatically > while installing a plugin? > > Its

Re: Need help designing a fix for JENKINS-50504

This issue seems to be Pipeline-specific (actually DueableTask-Specific). Standard Freestyle jobs should abort immediately on the agent disconnection, but Pipeline jobs may recover and continue using the workspace. However, it seems ugly to use the new channel in the "in use" map, because >

Fixing bug where git project is built twice when changes are pushed

My project is suffering from a problem where jobs sometimes build the same commit twice. This seems to happen when two or more pushes are made within a short time (by one or more developers). I think the problem matches one or both of these: https://issues.jenkins-ci.org/browse/JENKINS-17346