Jenkins Build connected to RTC using JenkinsFile creates two build results when polled from Jenkins

Richard Good (57●4●27) | asked Jul 10, 5:49 a.m.

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:-

https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=453681

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

Comments

Sridevi Sangaiah commented Jul 10, 6:58 a.m.

JAZZ DEVELOPER

Hi Richard,

There are three approaches mentioned in the work item, for the workaround. Can you clarify which one of them is being used in your scenario.

Richard Good commented Jul 10, 7:02 a.m. | edited Jul 10, 7:05 a.m.

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.

Note that the issue does not occur when I use an equivalent pipeline stored in Jenkins.

Richard Good commented Jul 15, 4:20 a.m.

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.

Lakshmi Narasimhan T V commented Jul 15, 5:02 a.m. | edited Jul 15, 5:03 a.m.

JAZZ DEVELOPER

Could you check whether your Jenkins File does not include any checkout step for the build definition again? I tried this scenario locally, here is my JenkinsFile

node {
checkout([$class: 'RTCScm', buildType: [buildSnapshot: "${env.team_scm_snapshotUUID}", loadDirectory: 'C:\\Temp\\Test', value: 'buildSnapshot'], timeout: 480])
}

This loads the content in the Test directory and doesn't end up creating another build result. The only build result created is from the Pipeline checkout step for JenkinsFile.

2 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Richard Good (57●4●27) | answered Jul 15, 5:09 a.m.
edited Jul 15, 5:10 a.m.

Hi Lakshmi,

Thanks for your reply

Not enough characters to add this as a comment

Note that in order to recreate this problem the build must be initiated from Jenkins, it only generates one build result when initiated from RTC, the following is the relevant part of my jenkins file. The polling for changes to achieve continuous integration must be setup in Jenkins, doesn't work properly from RTC.

//The following is a workaround for light checkout not working in RTC

//what we do here is define a load rule in our build definition that just returns the filse in the build folder

//then checkout the snapshot made of all components in the cas of a regular build

def checkOutVars

if ("${env.personalBuild}" == "true") { // This is true when a personal build is started from RTC.

echo "Checking out the build definition in node"

checkOutVars = checkout([$class: 'RTCScm', avoidUsingToolkit: false, buildTool: 'RTC 6.0.4', buildType: [buildDefinition: 'Experimental PCU-TSS build', customizedSnapshotName: '', value: 'buildDefinition'], credentialsId: '01c78c54-715c-4302-b68c-cfb7fb51f91a', overrideGlobal: true, serverURI: 'server', timeout: 480])

}

else { // Otherwise we checkout the snapshot created by the Pipeline Script from SCM's checkout.

echo "Checking out a snapshot in node"

checkOutVars = checkout([$class: 'RTCScm', avoidUsingToolkit: false, buildTool: 'RTC 6.0.4', buildType: [buildSnapshot: "${env.team_scm_snapshotUUID}", buildSnapshotContext: [snapshotOwnerType: 'none'], currentSnapshotOwnerType: 'none', loadDirectory: '.', value: 'buildSnapshot'], credentialsId: '01c78c54-715c-4302-b68c-cfb7fb51f91a', overrideGlobal: true, serverURI: 'server', timeout: 480])

}

Comments

Lakshmi Narasimhan T V commented Jul 15, 5:51 a.m.

JAZZ DEVELOPER

To clarify, the problem happens only if the build is triggered from Jenkins (either manually or through polling).

I was not able to reproduce the issue by triggering the build from Jenkins. I have switched on polling and checking.

Could you check whether you have a Jenkins Job parameter called "personalBuild"?

Lakshmi Narasimhan T V commented Jul 15, 8:42 p.m.

JAZZ DEVELOPER

I couldn't reproduce the issue with polling enabled either.

Richard Good commented Jul 16, 2:23 a.m.

That's interesting, note that I do return things on the build result with AMT:-

withCredentials([usernamePassword(credentialsId: '01c78c54-715c-4302-b68c-cfb7fb51f91a', passwordVariable: 'password', usernameVariable: 'userId')]) {

//If this build was ran from RTC then use ANT to store results

withAnt(installation: 'ANT-DEFAULT', jdk: 'IBMJDK') {

//Return information to RTC should work if initiated from Jenkins or RTC

bat label: '', script: 'ant -f returnFilesAndLogs.xml -DrepositoryAddress=%repositoryAddress% -DbuildResultUUID=' + bResult + ' -DdeployResultsZip=' + deployZipFile + ' -DdeployTermResultsZip=' + deployTermZipFile + ' -DuserId=%userId% -Dpassword=%password% -lib C:\IBM\TeamConcert_6.0.4\TeamConcertBuild_6.0.4\buildsystem\buildtoolkit'

Richard Good commented Jul 16, 2:28 a.m.

Thanks for your help It could possibly be something to do with a bit of latency in our network/ RTC, been a bit weird the last few weeks? It seems that if I fire a build from RTC it can sometimes take 15 minutes before it starts to run (the particular Jenkins instance is not doing anything, it is my test area), but if I run it from Jenkins it runs straight away.. I'm pretty sure the personal build clause is not running because I get the "Checking out snapshot in node message" in the console log. Using the skipDefaultCheckout option seems to cure my issue, I do prefer your solution to mine though.

permanent link

Richard Good (57●4●27) | answered Jul 15, 5:20 a.m.

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

Richard Good commented Jul 16, 11:03 a.m.

I begin to think this is a better option than option 3

Lakshmi Narasimhan T V commented Jul 16, 12:06 p.m. | edited Jul 16, 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!

Richard Good commented Jul 17, 2:30 a.m.

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

Lakshmi Narasimhan T V commented Jul 17, 3:15 a.m.

JAZZ DEVELOPER

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

Richard Good commented Sep 30, 3:20 a.m.

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

It's all about the answers!

Related questions

Jenkins Build connected to RTC using JenkinsFile creates two build results when polled from Jenkins

2 answers

Your answer