I maybe got the point:

My build deep inside makes use of a compiler | tee | grep,... and therefore is splitting the output into a file at one point.

Not too far ago I switched from a formerly deprected warnings parser to the warnings next generation plugin and therefore had to insert another | tee - split. I'm not yet 100% sure if this exactly matches the point were buildtimes increased but at least it might be close to. I'll set up a test.

At least my way quicker freestyle build does not make use of the inner  | tee | grep!

On the other hand this | tee provides a list of other problems and I'd like to avoid it at any level - also for warnings next generation. Is there another way to split build output to a file and in the same step keep the return code?

In fact, it is the grep. But that's in there for a longer time. Is there some real relation between a grep (from msys) and some components of jenkins that might explain the significant decrease in the speed?

Second issue I observed with warnings-ng - for my tests I changed the use of recordIssued from:

recordIssues sourceCodeEncoding: 'ISO-8859-1',
         tools: [groovyScript(parserId: 'MSVC-Warning', pattern:'**/build-makedep.log', reportEncoding:'ISO-8859-1'),
                        groovyScript(parserId: 'MSVC-Error', pattern:'**/build-makedep.log', reportEncoding:'ISO-8859-1') ]

to

 recordIssues sourceCodeEncoding: 'ISO-8859-1',
                    tools: [groovyScript(parserId: 'MSVC-Warning', reportEncoding:'ISO-8859-1'),
                        groovyScript(parserId: 'MSVC-Error', reportEncoding:'ISO-8859-1') ]

(note the missing "pattern:") but that does not work as documented (scanning the console output without the need of an intermediate file).

Ecuse me, that's not an issue, that's documented - but ugly!

The problem seems to have disappeared after the latest LTS update to v2.190.1. At least at the first test build after that update.

This jenkins installation is driving me nuts - the slow behaviour came back.

The last quick run was on September, 27th. After that the build failed for some days due to issues with the code and the libraries used. The first completing build after that on Oct. 9th was slow again (same times - ~45min vs 3:40hours).

OK, I noticed, there are failed builds with indicatino of slow behaviour since October, 2nd. The builds before failed after only 6mins.

I implemented every updates in that time as soon as I realised them. There were a number of them in that time frame. Is there a log that shows the plugins updated and the version change? With that I could restore the state of September 27th and apply all the updates step by step until the build gets slower again.

The speed decrease dissappeared again.

Maybe it got lost a little through the history of all the comments:

• the decrease happens only in one step, not distributed over all
• in case it runs slowly, removing a '| grep' from a makefile build rule immediately takes down the speed decrease

I now started tracking all the plugin updates to maybe get a correlation between jenkins updates and speed impact

A new finding:

for a lot of sequential updates I aborted the running job after recognizing the build speed. That caused hanging processes in the back that made cleaning the workplace impossible. To recover from that I rebooted the machine (without having applied an update). After that the build ran slowly again.

In the meantime the build got a little faste, it 'only' takes 5 hours instead of 8 previously. I can't find out the real time since when it happened because I had a number of failing builds in that time.

Arg - this issue doesn't like being chased.

Every time I do a single action like update, reboot or restart behaviour stays the same.

Whenever I do simultaneous actions, something changes.

This time: update of Script security 166->1.67 and restart of jenkins (without reboot) due to hanging job fragments made the build fast again.

Noticeable: I restarted jenkins by starting and stopping the jenkins service this time.

BTW: really no support here? Where else can I get assistance?

After the latest updates I got the problem again. Besides, all my automatic build weren't restartet....

The list of updates:

Jira 3.0.10  -> 3.0.11
Oracle Java SE Development Kit Installer 1.3->1.4
Script Security 1.67->1.68
Warnings Next Generation 7.2.0->7.2.1

Jenkins v2.190.3

It runs quickly again after a service restart.

So I guess, it's an issue of the update procedure or the implementation as a windows service?

Which components do these belong to for a correct assignment of the job?

The issue is still present.

It still is present and restart of the service very reliably and repeatedly solves the issue. Could you please check the update procedure!

I noticed the msBuild warnings parser also does the job for me and thus removed one of the "grep"-layers. Unforunately the problem still persists.