-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
cloudbees-folder: 6.14
The percentage that we see on startup when Jenkins is loading items are not reliable. Here is an example for a real environment:
2020-10-13 01:23:38.402+0000 [id=163] INFO c.c.h.p.folder.AbstractFolder$3#call: Loading job <item1> (116.2%) [...] 2020-10-13 01:24:08.407+0000 [id=163] INFO c.c.h.p.folder.AbstractFolder$3#call: Loading job <item2> (141.2%) [...] 2020-10-13 01:25:38.548+0000 [id=163] INFO c.c.h.p.folder.AbstractFolder$3#call: Loading job <item3> (97.7%) [...] 2020-10-13 01:26:53.732+0000 [id=163] INFO c.c.h.p.folder.AbstractFolder$3#call: Loading job <item4> (73.5%) [...] 2020-10-13 01:32:39.660+0000 [id=163] INFO c.c.h.p.folder.AbstractFolder$3#call: Loading job <item5> (99.7%)
The total number of jobs that the percentage is calculated from is usually wrong because:
- it is calculated by traversing $JENKINS_HOME/jobs and continue recursively when there is a jobs directory. However with Multibranch / Org job and (maybe other kind of item group) the item directory is different.
- it is calculated / incremented asynchronously while items are be loaded
In the same case environment as above, we saw the first messages of AbstractFolder$3#call: Loading job ... at 01:23:38 but the total that is used to calculate the percentage is still incrementing until 01:27:27 (takes about 4 minutes):
2020-10-13 01:27:27.092+0000 [id=172] INFO jenkins.model.Jenkins$5#runTask: Took 246197ms for AbstractFolder.loadJobTotal by pool-9-thread-96
