adop-docker-compose icon indicating copy to clipboard operation
adop-docker-compose copied to clipboard

Error in job Setup_Pluggable_Library on upgrade

Open deors opened this issue 5 years ago • 2 comments

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.

deors avatar Nov 11 '18 09:11 deors

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.

RobertNorthard avatar Nov 11 '18 11:11 RobertNorthard

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

deors avatar Nov 11 '18 11:11 deors