|
||||||||
|
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
We have a project with a monolithic repository, and Jenkins CI jobs that use "included paths" to only build when required.
This means that jobs which only build infrequently, due to the included paths, take longer each time a poll is triggered and eventually fail with an out of memory error. I think this then means the job is no longer built.
Would it be more sensible to split the task of identifying changed paths and the changes into two separate calls?
I examined a build that hit this condition this morning (OOM after 20 minutes). I can see that the "git show" invocation takes just under 15 minutes to run from the command line, and generates 196MB of output. if i try "git diff --name-only FROM..TO" I get the result in well under a second, and the output is under 1MB. This path information would be sufficient to know whether to trigger a build.
It would not support the "excludedUsers", but unless I am missing something, when there are multiple commits in the output of "git show", only the oldest one will be used anyway.
This doesn't address the memory usage of getting the change log and parsing it. It might be that for the monolithic repository use case, it should be possible to restrict the change log to specific paths (see
JENKINS-10449).I also tried "git log --full-history --no-abbrev -M --format=raw --raw FROM..TO", and found that it completed much quicker (1.5s) and a much smaller output (4MB). I don't understand the reason for commits being omitted from the latter, but as some of them date from 2009 I don't think it is wrong. Perhaps using "git log" instead of "git show" could be investigated.