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
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
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
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
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
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
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,
> 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
(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.
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
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
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
> 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
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
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
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
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
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
>
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
19 matches
Mail list logo