Jump to content

PLASTICSCM_CHANGESET_ID is not set reliably by the Jenkins PlasticSCM plugin

Mikael Kalms

Recommended Posts


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"
                            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.

Link to comment
Share on other sites

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:


Link to comment
Share on other sites


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.





Link to comment
Share on other sites

  • 1 month later...

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?



Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...