Error in job Setup_Pluggable_Library on upgrade

[deors]

When performing an upgrade from 0.6.0 to 0.7.0, the job Setup_Pluggable_Library which is exec by Load_Platform ends in failure.

Expected:
The Load_Platform job finish successfully, upgrading ADOP internals (libraries, cartridges) as needed, too.

Observed:
The Setup_Pluggable_Library job ends in failure, with the following stacktrace:

• echo 'Extracting Pluggable library to additonal classpath location: /var/jenkins_home/userContent/job_dsl_additional_classpath/'
  Extracting Pluggable library to additonal classpath location: /var/jenkins_home/userContent/job_dsl_additional_classpath/
• cp -r src/main/groovy/pluggable/ /var/jenkins_home/userContent/job_dsl_additional_classpath/
• echo '******************'

---

• echo 'Library contents: '
  Library contents:
• ls /var/jenkins_home/userContent/job_dsl_additional_classpath/pluggable/scm/
  PropertiesSCMProviderDataStore.groovy
  SCMProvider.groovy
  SCMProviderDataStore.groovy
  SCMProviderFactory.groovy
  SCMProviderHandler.groovy
  SCMProviderInfo.groovy
  bitbucket
  gerrit
  gitlab
  helpers
  ERROR: Build step failed with exception
  org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use new jenkins.plugins.git.GitSCMSource java.lang.String java.lang.String java.lang.String java.lang.String java.lang.String boolean
  at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectNew(StaticWhitelist.java:184)
  at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onNewInstance(SandboxInterceptor.java:148)
  at org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:197)
  at org.kohsuke.groovy.sandbox.impl.Checker.checkedConstructor(Checker.java:202)
  at org.kohsuke.groovy.sandbox.impl.Checker$checkedConstructor$0.callStatic(Unknown Source)
  at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
  at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
  at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:214)
  at Script1.run(Script1.groovy:20)
  at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.run(GroovySandbox.java:141)
  at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript.evaluate(SecureGroovyScript.java:333)
  at hudson.plugins.groovy.SystemGroovy.run(SystemGroovy.java:95)
  at hudson.plugins.groovy.SystemGroovy.perform(SystemGroovy.java:59)
  at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
  at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
  at hudson.model.Build$BuildExecution.build(Build.java:206)
  at hudson.model.Build$BuildExecution.doRun(Build.java:163)
  at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
  at hudson.model.Run.execute(Run.java:1727)
  at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
  at hudson.model.ResourceController.execute(ResourceController.java:97)
  at hudson.model.Executor.run(Executor.java:429)
  Build step 'Execute system Groovy script' marked build as failure
  Finished: FAILURE

Note

Although this error was obtained in the context of ugprading ADOP from 0.6.0 to 0.7.0, it does not seem to be related with the upgrade scenario, but could be applicable to a clean installation, too.

[RobertNorthard]

Thanks @deors for raising the issue - this is due to the script security plugin not whitelisting the use of GitSCMSource. However, the ADOP Jenkins image explicitly adds this to script approval (https://github.com/Accenture/adop-jenkins/blob/d35414cb0fe404fd82a469bd56eff74d58bc823e/resources/scriptApproval.xml).

@SachinKSingh28 / @dsingh07 is this a known issue?

On a side note adop-pluggable-scm library requires versioning, similar to the work done with platform management as new adop/c have the Gitlab SCM provider.

[deors]

@RobertNorthard maybe as I'm running this while migrating to 0.7.0, the scriptApproval.xml file is not 'applied'. I cannot remember right now the exact rules of how volumes/files are processed when an image is upgraded to a new version, but I have a sort of deja-vu that it could be an issue.