LINUX.ORG.RU

Jenkins Pipeline + jdbc oracle ... как?

 , , ,


0

1

Всем привет. Прошу сильно не бить тапками, я новенький. Задача: подружить jenkins pipelene с oracle. Установлено: jenkins 2.235.1, oracle client 19.8(настроены ORACLE_HOME,TNS_ADMIN,tnsadmin.ora,), sql plus client


import groovy.sql.Sql
pipeline {
    stages {
        stage ('Oracle') {
            steps {
                script {
					withCredentials([usernamePassword(credentialsId: 'myuser', usernameVariable: 'user', passwordVariable: 'pass')]) {
                    sql = Sql.newInstance("jdbc:oracle:thin:@server:1521", "$user", "$pass","oracle.jdbc.OracleDriver")    
                    try {
                        sql.eachRow('select sysdate from dual'){ row ->
                        println row
                            }
                        } finally {
                        sql.close()
                    }
                    }
                }				
            }
        }
    }
}

приводит к ошибке

java.lang.ClassNotFoundException: oracle.jdbc.OracleDriver
	at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:543)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)
	at groovy.sql.Sql.loadDriver(Sql.java:718)
	at groovy.sql.Sql.newInstance(Sql.java:449)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
	at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrap.invoke(StaticMetaMethodSite.java:133)
	at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:102)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
	at org.kohsuke.groovy.sandbox.impl.Checker$2.call(Checker.java:191)
	at org.kohsuke.groovy.sandbox.GroovyInterceptor.onStaticCall(GroovyInterceptor.java:35)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onStaticCall(SandboxInterceptor.java:186)
	at org.kohsuke.groovy.sandbox.impl.Checker$2.call(Checker.java:189)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedStaticCall(Checker.java:193)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:100)
	at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
	at WorkflowScript.run(WorkflowScript:16)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:86)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:113)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:83)
	at sun.reflect.GeneratedMethodAccessor447.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
	at com.cloudbees.groovy.cps.Next.step(Next.java:83)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
	at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
	at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:186)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:370)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:93)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:282)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:270)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:67)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

это очередные приколы jenkinsa с его обрезанным groovy или у меня руки кривые?


Думаю что это ограничения дженкинсового groovy.

В целом, не надо на groovy писать скрипты. Пайплайн - это запускалка скриптов написанных на нормальных языках, не больше.

https://www.jenkins.io/doc/book/pipeline/pipeline-best-practices/

Use Groovy code to connect a set of actions rather than as the main functionality of your Pipeline.

Так что обращение к базе и т.п, - выноси в какой-то питон-скрипт, а в пайплайне просто дергай его.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

очень бы не хотелось. технически есть плагин SQLPlusRunnerBuilder, который позволяет ходить на базу, но он односторонний - скрипты выполняет, а ответы отдает в лог дженкинса. для тех кому нужна односторонняя связь - выход, кому полноценная - невариант. я с дженкинсом только начинаю дружить, соответственно как организовать питон скрипт - пока для меня высокие материи - если не сложно можете покать как это реализовать?

fez ()

Думаю, лучше накидать плагин для Jenkins и реализовать в нём соответствующий step. Оно и в логах приятнее выглядеть будет, да и полноценную Java (или Groovy) можно использовать.

Тут есть немного документации по поводу того как правильно реализовать step.

com ()
Ответ на: комментарий от fez

Я делаю так:

https://github.com/fedora-ci/eln-build-pipeline/blob/master/Jenkinsfile#L74

То есть Python-скрипт лежит отдельно рядом с Jenkinsfile в той же репе.

Когда пайплайн стартует, то там выгружается содержимое репозитория в workspace, так что этот скрипт становится локально доступен. Соответственно его и вызываем.

alpha ★★★★★ ()
Ответ на: комментарий от com

Тут можно посмотреть примеры реализации. В крайнем случае скопипастить и взять за основу.

Maven умеет одной строчкой запускать полноценный локальный Jenkins с твоим плагином для отладки, так что и отладить по человечески можно будет.

com ()
Ответ на: комментарий от vedowi6419

пардоньте, не в курсе что это. нашел в настройках дженкинса: jna.platform.library.path= /usr/lib64:/lib64:/usr/lib:/lib:/usr/lib64/dyninst:/usr/lib/oracle/19.8/client64/lib:/usr/lib64/mysql:/usr/lib64//bind9-export по логике должен видеть. еслине прав, ткните пожалуйста носом

fez ()
Ответ на: комментарий от fez

простите, вы вообще в курсе, что такое JNA? там лежат системные либы. ты же хочешь втащить в проект JARник, который нужно включать зависимостью в maven gradle или шо там у тебя есть

vedowi6419 ()
Последнее исправление: vedowi6419 (всего исправлений: 1)