PLASTICSCM_CHANGESET_ID is not set reliably by the Jenkins PlasticSCM plugin

[Mikael Kalms]

Hi,

I have recently created two new Jenkins build jobs based off of an existing build job. The existing build job has been working fine for some time, but the two new build jobs fail.

What I find is that with the new build jobs, I get the following error:

groovy.lang.MissingPropertyException: No such property: PLASTICSCM_CHANGESET_ID for class: groovy.lang.Binding

This is strange, and it is causing trouble when we are about to make a major release. I have a workaround, which I will use for the time being -- directly calling `cm status` and using that result instead of he PLASTICSCM_CHANGESET_ID variable. Still, it would be nice if you could find a solution for this long term.

 

 

The entire project exists in a Plastic repo. The Jenkins build job is a Declarative Pipeline job. The Jenkinsfile is configured to be fetched as "Pipeline script from SCM", with a selector like this:

repository "Freedom@FallDamage@Cloud"
  path "/"
    smartbranch "/main"

(Use update is enabled, Lightweight checkout is enabled)

I am not performing any extra checkouts, just relying on what Jenkins automatically does.

 

Now, the step that fails looks like this:

        // Build 64-bit Windows Standalone player, with Steam activated
        // Source project location: ${SOURCE_DIR}
        // Target build location: ${SOURCE_DIR}/SteamBuild/input
        // Target executable name: ${PROJECT_NAME}.exe
        stage('Build') { 
            steps { 
				timeout(time: "${BUILD_STAGE_TIMEOUT_MINUTES}" as int, unit: 'MINUTES') {
                    script {
						failedStage = STAGE_NAME
                        try {
                            bat "if exist ${WORKSPACE}\\UnityEditor.log del ${WORKSPACE}\\UnityEditor.log"
                            bat "START /WAIT \"Unity\" \"${UNITY_INSTALLATION_DIR}/Editor/Unity.exe\"" +
                                    " -quit" +
                                    " -batchmode" +
                                    " -executeMethod CustomBuild.GenerateBuild_CommandLine" +
                                    " -BuildInfo.SourceControl.RepositoryServer \"<org>@Cloud\"" +
                                    " -BuildInfo.SourceControl.Repository \"${SCM_REPOSITORY_NAME}\"" +
                                    " -BuildInfo.SourceControl.ChangeSetId \"${PLASTICSCM_CHANGESET_ID}\"" +
                                    " -BuildInfo.BuildJob.Name \"${JOB_NAME}\"" +
                                    " -BuildInfo.BuildJob.Id \"#${BUILD_ID}\"" +
                                    " -BuildInfo.Configuration \"${CONFIGURATION}\"" +
                                    " -BuildInfo.BuildTimeStamp \"${BUILD_TIMESTAMP}\"" +
                                    " -CustomBuild.OnlineVersion \"${JOB_NAME}.${PLASTICSCM_CHANGESET_ID}\"" +
                                    " -CustomBuild.Configuration \"${CONFIGURATION}\"" +
                                    " -CustomBuild.TargetExecutable \"${SOURCE_DIR}/SteamBuild/input/${PROJECT_NAME}.exe\"" +
                                    " -projectPath \"${SOURCE_DIR}\"" +
                                    " -logFile \"${WORKSPACE}/UnityEditor.log\"" +
									" && IF ERRORLEVEL 1 EXIT /B 1"
                        }
                        finally
                        {
                            bat "type \"${WORKSPACE}\\UnityEditor.log\""
                        }
                    }
                }
            }
        }

It is the ${PLASTICSCM_CHANGESET_ID} variable reference which Jenkins claims is unassigned.

Now, again -- I am using the same exact script, but with 4 environment variables changed, for another build job that is working well.

 

This is what the Stage view looks like. I triggered the build job twice. The first time, the checkout took a long time since it had to pull down the entire repository. The second time, there were no changes to the repo, so checkout was quick.

My wild guess: The PlasticSCM plugin does not publish changes or set some environment variables to Jenkins for a particular build job, until that job has run successfully at least once.

 

Let me know if you want a support ticket with more detailed logs, build scripts & screenshots.

[Mikael Kalms]

I introduced a workaround into my build script, which is a first step that looks like this...

 

First some helper logic:

///////////////////////////////////////////////////////////////////////////////////////////////

def scmChangeSetId = null

///////////////////////////////////////////////////////////////////////////////////////////////

// Return a string on the format "1234" with latest changeset ID

def getSCMChangeSetId()
{
    def cmResult = bat script: "cm status --nochanges ${SOURCE_DIR}", returnStdout: true
    // Result will be a multiline string like this:
    //
	//		<blank line>
    //      C:\Jenkins\workspace\PongSP-Windows>cm status --nochanges C:\Jenkins\workspace\PongSP-Windows/PongSP 
    //      cs:67@rep:PongSP@repserver:FallDamage@Cloud

    // Extract the number '67' from the above multiline string
    def cmResultLines = cmResult.split('\n')
    assert 3 == cmResultLines.size()
	echo "cmResult[2]: " + cmResultLines[2]
    def changeSetId = cmResultLines[2].tokenize(':@')[1]
    
    return changeSetId
}

... and then a build step, before the others:

        stage('RetrieveSCMInfo') {
            steps {
				timeout(time: "${DEFAULT_STAGE_TIMEOUT_MINUTES}" as int, unit: 'MINUTES') {
			
					script {
						scmChangeSetId = getSCMChangeSetId()
					}

					echo "Changeset ID: ${scmChangeSetId}"
				}
            }
        }

... and then I change any remaining build steps to refer to scmChangeSetId instead of PLASTICSCM_CHANGESET_ID.

I trigger a build, and 5 minutes later the build progress display looks like this -  which means it's good and it's doing what it is supposed to:

[Mikael Kalms]

I have attempted to create a minimal repro case, but there I was able to use PLASTICSCM_CHANGESET_ID from the start.

[calbzam]

Hi,

What is your Jenkins plugin version? We recently released some fixes related to the env variables:

Version 2.19

Added support to SCM environment variables for pipelines.

Now, you can check the available ones here: https://<your-jenkins>/env-vars.html

Version 2.17

• The environment variables weren't properly set if the current or previous build checkout failed. Fixed.

 

My wild guess: The PlasticSCM plugin does not publish changes or set some environment variables to Jenkins for a particular build job, until that job has run successfully at least once.

[carlos] I guess this option is not valid anymore as you mentioned that a minimal repro case was properly working?

I'm afraid we would need a way to reproduce it in order to understand and fix the problem. If necessary, we can arrange a meeting to review your setup.

Regards,

Carlos.

 

 

[Mikael Kalms]

I am using Jenkins v2.152, Plastic plugin v2.20.

I'll let you know if I find a repro case sometime in the future.

[calbzam]

Ok, good to know that at least you have a workaround. If we can help you to find the repro case, please let us know.

Regards,

Carlos.

[KrisK]

I am having the same issue. plasticscm_changeset_id does seem to be null. Using latest plastic plugin (2.20).

[calbzam]

Are you using Jenkins pipelines? You may be affected by this bug:

https://issues.jenkins-ci.org/browse/JENKINS-42971

Regards,

Carlos.

[KrisK]

Yes im using pipelines. Will check.

[KrisK]

No this does not help. Even with Light Checkout   echo "Changeset ID: ${env.PLASTICSCM_CHANGESET_ID} will return null

[calbzam]

Please check the last message here: https://github.com/jenkinsci/plasticscm-plugin/issues/8

Is this your first build? If you create a few changesets in the branch, is the issue reproducible?

Regards,

Carlos.

[KrisK]

No we have 8000+ changesets. And this is also not our first build.

  echo bat(returnStdout: true, script: 'set') also shows no plastic variables.

[calbzam]

What is the Jenkins version you are using? It may be broken in the last version and we can run some tests. Otherwise, it is something related to your specific environment. You mentioned that you are working with Pipelines and Jenkins for Linux, right? Maybe also using an external build node?  Could you attach some screenshots of your Jenkins settings and configuration so we can try to reproduce?

Regards,

Carlos.