6

This happened after I updated some plugins and added 'blue ocean' to our Jenkins.

Every job we have is using a JenkinsFile to build and package our applications.

But we are loading some groovy files within our git from the workspace@script folder, so this is what I did :

script {
    slack = load WORKSPACE + "@script/jenkins/libs/toto.groovy"
}

But now I have to do this to have the right folder :

script {
    // Locate the jenkins folder
    // This is done because there is a new sub-folder (like : 17a4ba1ed1ce777b18c5...)
    // that appeared out of nowhere (update -> security ??)
    git_jenkins_folder = sh (
        script: "find " + WORKSPACE + "@script -type d -name 'jenkins' -printf '%T@ %Tc %p\n' | sort -rn | head -1 | cut -d' ' -f9",
        returnStdout: true
    ).trim()
    // Load the groovy methods in groovy files
    slack = load git_jenkins_folder + "/libs/toto.groovy"
}

And of course, I had to remove previously checked out code from the workspace@script folder for this to work.

Why did this happened all of a sudden ? I was thinking of a security update maybe ?

What if this number changes in the future and a new folder appear ??

This is really weird IMHO but maybe I missed something. If someone out there has the answer I'll gladly read it :)

EDIT :

Thanks to @1141514admin, this was done to address those issues with the 'Pipeline: Groovy' plugin :

EDIT 2 :

Added retrieval of the last modified folder in case this folder name changes in the future.

WannaGetHigh
  • 3,826
  • 4
  • 23
  • 31
  • If you just want to load Groovy methods to make them available in your pipeline, then why not use global variable methods from a shared library instead? – Matthew Schuchard Feb 16 '22 at 16:36
  • Ah, this is not something that I know of, could you elaborate on how to achieve this ? As far as I am concerned, I would prefer having everything on git so we keep track of changes that are made to our library. But maybe your solution involves this :) – WannaGetHigh Feb 17 '22 at 09:48
  • 1
    "find " + WORKSPACE + "@script is not 100% correct since WORKSPACE can end with @2, @3, etc. if you have multiple Jenkins executors. See a better approach here: https://stackoverflow.com/questions/37800195/how-do-you-load-a-groovy-file-and-execute-it/46045382#comment98211190_38108449 – Carlos Quintero Mar 04 '22 at 12:14
  • Thanks @CarlosQuintero I used `readTrusted` from an answer you linked to, this was for a **Pipeline script from SCM**, after previously depending on the directory name being `workspace@script` which is no longer the case. The Pipeline script used `readTrusted` to read/parse a JSON config file from the same project checked out from the SCM. – ptha Nov 17 '22 at 15:05

3 Answers3

3

I just noticed this new behavior in my builds today as well. I had updated some plugins earlier. I found that on my server it's the 'Pipeline: Groovy' plugin, version 2656.vf7a_e7b_75a_457 that's causing these new subfolders with lengthy randomized names which contained the cloned repo files. The problem for me was it was resulting in builds failing, causing file paths to exceed 260 characters which is a default limit in Windows. I downgraded the 'Pipeline: Groovy' plugin to version 2648.va9433432b33c and after restarting the Jenkins service I was no longer seeing these new random-named subfolders in the workspace build folders.

Sounds like this is a permanent change.

https://www.jenkins.io/security/advisory/2022-02-15/

Pipeline: Groovy Plugin 2656.vf7a_e7b_75a_457 uses distinct checkout directories per SCM when reading the script file (typically Jenkinsfile) for Pipelines.

1141514admin
  • 46
  • 2
  • All right I so this is the one that seems to be causing the "issue", but what if this behaviour is the new one and won't change ? I mean I can't be stuck with an old version of this plugin, for all time. Anyway I downgraded and will wait for the next update, I just hope that future upgrades doesn't change this behaviour again. – WannaGetHigh Feb 17 '22 at 09:40
  • Same problem with version 3673.v5b_dd74276262 – FishingIsLife Jun 01 '23 at 09:22
0

I have the same problem and for me it seams to be a bug produced by these security fixes. There is also an issue fieled: https://issues.jenkins.io/browse/JENKINS-67857

Why should the script from the jenkinsfile not be able to access other files from the own checkout (if the "Lightweight checkout" is not enabled)?

Your script above is a workaround for the problem at the moment, but it doesn't solve the problem permanently if the developers decide to move the checkout else where or to restrict access to this "other" workspace.

So I think the solution is, that the plugin provides an official way to access the checkout.

BMaehr
  • 41
  • 5
0

I just ran into the same issue today.

We are using Mercurial (hg), and the main issue associated with this feature is the impossibility to checkout the jenkinsfile because some files path inside the repository now exceeded the windows 255 characters limit.

Our fix was to setup Win32LongFileNamesExtension to mercurial on the jenkins node.

Documentation: https://www.mercurial-scm.org/wiki/Win32LongFileNamesExtension

Source file: https://foss.heptapod.net/mercurial/win32lfn/-/blob/branch/default/src/win32lfn.py

Hope this can help anyone :)

Laurent GROSBOIS
  • 61
  • 5