-
Improvement
-
Resolution: Fixed
-
Minor
-
None
I am using Jenkins 1.475 with the perforce plugin.
I have several jobs using different perforce workspaces and different Jenkins workspaces.
For some reason the build history for each job includes the builds of other jobs. This may be related to JENKINS-11853.
The last failed and last successful builds seem to be determined by build number rather than date.
If you look at the second and third snapshots you can see that Jenkins alternates in its decision over what builds to include in the the history on the left hand side. This may be related or a separate bug.
I have given each job a custom workspace with a unique name to avoid conflicts. Further I have installed the set next build number plugin and given each job a next build number +1000 from the others. This seemed to work until I was forced to restart Jenkins (due to a hardware issue) after which the problem has reoccurred. This scheme would be unviable in general anyway after any one project had more than 1000 builds.
This may be down to a misconfiguration of some kind on my part but it is not at all obvious what is wrong or how to fix it.
A contributing factor could be that some jobs were created by copying existing jobs. Perhaps this caused something to be shared that shouldn't be?
[JENKINS-14583] Improve validation of 'builds dir' global setting
Bruce Adams
created issue -
Missing builds caused by working around this issue cause builder threads to crash in the latest version of Jenkins. See JENKINS-15957
Bruce Adams
added a comment - - edited Missing builds caused by working around this issue cause builder threads to crash in the latest version of Jenkins. See JENKINS-15957 Bruce Adams
added a comment - I am still stuck with builds for different projects and/or configurations which make it look like the job is succeeding when it is failing or failing when it is succeeding because the latest build displayed on for the dashboard is in fact a completely different job.
Can anyone suggest a workaround to this issue?
Bruce Adams
added a comment - I am still stuck with builds for different projects and/or configurations which make it look like the job is succeeding when it is failing or failing when it is succeeding because the latest build displayed on for the dashboard is in fact a completely different job.
Can anyone suggest a workaround to this issue?
Bruce Adams
added a comment - I asked on the mailing list and go a much more rapid response.
For some reason I had a fixed hard-code directory
rather than the default:
${ITEM_ROOTDIR}/builds
I must have tweaked this very early on when I installed and not touched it since.
For extra paranoia I've now changed this to:
${ITEM_ROOTDIR}/builds/${ITEM_FULLNAME}
So far things look promising.
I am therefore re-purposing this issue as a request to make the location of build histories more obvious. Perhaps a link or something in a help bubble could be added to the configuration page for a job in the section containing:
Discard Old Builds
Days to keep builds
Days to keep artifacts
Max # of builds to keep with artifacts
This is where I would expect to see the location of the build history displayed if it were independently configured per job rather than globally (that may make sense but is not a feature I require myself and is possibly a YAGNI).
Bruce Adams
added a comment - I asked on the mailing list and go a much more rapid response.
For some reason I had a fixed hard-code directory
rather than the default:
${ITEM_ROOTDIR}/builds
I must have tweaked this very early on when I installed and not touched it since.
For extra paranoia I've now changed this to:
${ITEM_ROOTDIR}/builds/${ITEM_FULLNAME}
So far things look promising.
I am therefore re-purposing this issue as a request to make the location of build histories more obvious. Perhaps a link or something in a help bubble could be added to the configuration page for a job in the section containing:
Discard Old Builds
Days to keep builds
Days to keep artifacts
Max # of builds to keep with artifacts
This is where I would expect to see the location of the build history displayed if it were independently configured per job rather than globally (that may make sense but is not a feature I require myself and is possibly a YAGNI). Bruce Adams
made changes -
| Issue Type | Original: Bug [ 1 ] | New: Improvement [ 4 ] |
| Priority | Original: Major [ 3 ] | New: Minor [ 4 ] |
| Summary | Original: Build number history is shared by different jobs | New: Make location of build history more obvious |
| Assignee | New: Daniel Beck [ danielbeck ] |
Input validation of global builds dir name does not catch this, but should.
Interpreting this issue as request to improve global config input validation.
| Summary | Original: Make location of build history more obvious | New: Improve validation of 'builds dir' global setting |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
I note that when I create a new job from an existing one the build history remains visible on the right hand side even if a new workspace is defined. Could this be the cause or at least related?