Jenkins Build connected to RTC using JenkinsFile creates two build results when polled from Jenkins
Hello,
I am using the workaround documented here, but it generates two results one with the work items containing the changes and one with all the stuff I return to it. I am using the work around for getting a lightweight checkout when using RTC detailed here:-
This means I run a checkout command twice, but the second command shouldn't generate a build result, it uses the snapshot generated by the lightweight checkout, not sure it is the cause of the issue or simply down to a bug concerning the combination of Jenkins polling and JenkinsFile.
Anyone else had this issue, is there a workaround?
Works OK when the build is initiated from RTC.
Cheers
Richard
|
2 answers
|
Note that before I read your post, I was using the skipDefaultCheckout() option and running the whole thing in the script directory to get around the double checkout issue, might return to that idea, feels like a frig though. Any downside to this other than the ugliness?
pipeline {
agent any
options {
//This is a sort of frig to avoid checking everything out twice
//We want this script to be under change control like everything else
//but when you use the pipeline and get script from scm option in RTC it
//gets absolutely everything into a workspace@script folder you cannot stop that
//you can however stop the secongd checkout to the workspace folder by using the
//skipDefaultCheckout option, this seems to work and just means you run everything
//from the script folder, looks and feels like a frig though
//There is no way of stopping the system checking everything out twice when using
//RTC and the pipeline script from SCM with a build definition other than this way I think
//So the files are loaded into $workspace@script directory and built there
//Also note that a "." should be placed into the load directory in the build definition
//configuration otherwise this JenkinsFile cannot be found, you can reference it relative to the
//root of the jenkins workspace
skipDefaultCheckout()
}
Comments I begin to think this is a better option than option 3 
Lakshmi Narasimhan T V
commented Jul 16 '19, 12:06 p.m.
| edited Jul 16 '19, 12:59 p.m.
JAZZ DEVELOPER
Hi Richard,
Are you using a agent directive in your script? That could explain why a second checkout happens (if skipDefaultCheckout is false) and why a new build result is created when the build is triggered from Jenkins, since the buildResultUUID parameter would be empty in that case and the second default checkout would always create a new build result.
Do note that the second default checkout does perform an accept to the repository workspace and this might not be desired, especially when the source has to be loaded in an agent again (master/slave) with the exact changes that were initially accepted when checking out from the build definition. So the workaround would still be necessary in such situations. I would have to add some details about skipDefaultCheckout to the workaround.
Thanks!
Hi Lakshmi
I'm using declarative syntax, which means I have to, I think, this is a Test Box, so master and slaves are one and the same. This is intended to run on a more complex system so I will need to allocate nodes at some point. Thanks for the information. I have settled on the skipDefaultCheckout workaround for now. I believe people creating a fresh jenkinsFile will mostly want to use declarative syntax.
Cheers
Richard
Hi Richard,
Thanks for the information. I was able to reproduce the issue when using declarative pipeline and saw two build result links. The solution would be to use skipDefaultCheckout(true) in the options as you have pointed out too. I have updated the work item and the Team Concert Plugin wiki with additional information about declarative pipeline and skipDefaultCheckout
The skipDefaultCheckout workaround works fine when you run it on the Master. I recently setup a slave system though and found that the files in the initial checkout to the @script directory did not make it to the Master, only the files in the second checkout made it |
Comments
Approach 3, I believe the other ones are unavailable and under consideration for tool improvement. I am using a build definition and Team not personal build, so using a checkout with load rules to checkout just the directory containing the jenkinsFile and then a checkout of the snapshot created in that step.
Does anyone have a solution to this? The workaround is to not use a JenkinsFile, but that is annoying we want to config control the file itself. Can't see a way to avoid getting the two results.
checkout([$class: 'RTCScm', buildType: [buildSnapshot: "${env.team_scm_snapshotUUID}", loadDirectory: 'C:\\Temp\\Test', value: 'buildSnapshot'], timeout: 480])
}