Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

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

Questions
Tags
Users
Badges
Richard Good
(87●28●61) Jul 10 '19, 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:-

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

0 votes

Comments
Sridevi Sangaiah
JAZZ DEVELOPER Jul 10 '19, 6:58 a.m.
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
Jul 10 '19, 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
Jul 15 '19, 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
JAZZ DEVELOPER Jul 15 '19, 5:03 a.m.
Hi

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
4,226 views
0 votes

2 answers

Permanent link
Richard Good
(87●28●61) edited
Jul 15 '19, 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])
}

0 votes

Comments
Lakshmi Narasimhan T V
JAZZ DEVELOPER Jul 15 '19, 5:51 a.m.
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
JAZZ DEVELOPER Jul 15 '19, 8:42 p.m.

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

Richard Good
Jul 16 '19, 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
Jul 16 '19, 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
(87●28●61) Jul 15 '19, 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() 
}

0 votes

Comments
Richard Good
Jul 16 '19, 11:03 a.m.

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

Lakshmi Narasimhan T V
JAZZ DEVELOPER Jul 16 '19, 12:59 p.m.

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
Jul 17 '19, 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
JAZZ DEVELOPER Jul 17 '19, 3:15 a.m.
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
Sep 30 '19, 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 

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,019
× 562
× 151

Question asked: Jul 10 '19, 5:49 a.m.

Question was seen: 4,226 times

Last updated: Sep 30 '19, 3:20 a.m.

Confirmation Cancel Confirm