Payton Doud
opened 1 month ago
-
The image field can not load variable from file as it is determined at start of the job. To work around this issue, use docker in docker:
- Enable the mount docker sock option for the job executor in privilege section
- Instead of using the run docker container step, create a command step with image set to
docker, and execute command such asdocker run <your docker image>:@file:_DOCKER_TAG.txt@
-
Please upgrade to build OD-6835 (13.1.3), which supports to read variable from workspace file for various run container step settings.
-
Previous Value Current Value Open
Closed
-
Thank you, the docker-in-docker method will work nicely. Sorry for not responding over the weekend, I got caught up with some other things going on.
I also tried upgrading the OneDev instance to 13.1.3 with:
helm repo update onedev helm upgrade onedev onedev/onedev -n onedev --reuse-valuesAfter this, the upgrade wrapper is failing with the following log:
# /app/logs/upgrade.log INFO - Launching application from '/app'... INFO - Starting application... INFO - Upgrading /opt/onedev... INFO - >>> INFO - Launching application from '/opt/onedev'... INFO - >>> INFO - Cleaning temp directory... INFO - >>> INFO - Starting application... ERROR - >>> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/wicket/util/io/IClusterable ERROR - >>> at java.base/java.lang.ClassLoader.defineClass1(Native Method) ERROR - >>> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) ERROR - >>> at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150) ERROR - >>> at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524) ERROR - >>> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427) ERROR - >>> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421) ERROR - >>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:712) ERROR - >>> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420) ERROR - >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:592) ERROR - >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525) ERROR - >>> at java.base/java.lang.Class.forName0(Native Method) ERROR - >>> at java.base/java.lang.Class.forName(Class.java:377) ERROR - >>> at io.onedev.commons.loader.AppLoader.loadPluginModules(AppLoader.java:147) ERROR - >>> at io.onedev.commons.loader.AppLoader.start(AppLoader.java:63) ERROR - >>> at io.onedev.commons.bootstrap.Bootstrap.main(Bootstrap.java:200) ERROR - >>> Caused by: java.lang.ClassNotFoundException: org.apache.wicket.util.io.IClusterable ERROR - >>> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445) ERROR - >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:592) ERROR - >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525) ERROR - >>> ... 15 more INFO - >>> INFO - Stopping application... ERROR - Unable to upgrade specified installation due to above error INFO - *** After solving the problem, please restart container with correct image ***I am not certain if it is the version in particular that has an issue, or likely some misconfiguration on my end possibly? This seems like an odd error to be thrown. The container image does seem to be correct (
docker.io/1dev/server:13.1.3), but I cannot seem to figure out why this is happening. The upgrade wrapper is being invoked with/usr/lib/jvm/java-17-openjdk-amd64/bin/java -Djava.awt.headless=true -Djdk.io.File.allowDeleteReadOnlyFiles=true --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED --add-modules=java.se --add-exports=java.base/jdk.internal.ref=ALL-UNNAMED --add-opens=java.management/sun.management=ALL-UNNAMED --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED --add-opens=java.base/sun.nio.fs=ALL-UNNAMED -XX:MaxRAMPercentage=50 -Xss1024k -Djava.library.path=. -classpath ch.qos.logback.logback-classic-1.4.14.jar:ch.qos.logback.logback-core-1.4.14.jar:io.onedev.commons-bootstrap-3.1.1.jar:org.slf4j.jul-to-slf4j-2.0.9.jar:org.slf4j.log4j-over-slf4j-2.0.9.jar:org.slf4j.slf4j-api-2.0.9.jar:wrapper.jar -Dwrapper.key=<this looks sensitive?> -Dwrapper.port=32001 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.disable_console_input=TRUE -Dwrapper.pid=3 -Dwrapper.version=3.5.51-st -Dwrapper.native_library=wrapper -Dwrapper.arch=x86 -Dwrapper.cpu.timeout=3600 -Dwrapper.jvmid=1 -Dwrapper.lang.domain=wrapper -Dwrapper.lang.folder=../lang org.tanukisoftware.wrapper.WrapperSimpleApp io.onedev.commons.bootstrap.Bootstrap upgrade /opt/onedev -
Previous Value Current Value Closed
Open
-
Just created a new k8s cluster and tested upgrading from 13.1.2 to 13.1.3 and it works fine. Not sure if image downloaded is corrupted at your side, please remove cached image and try upgrade again.
-
Hello, thank you for trying on your end, good to know its something with our deployment in particular at least. After going into the nodes and deleting the image:
k scale -n onedev statefulset onedev --replicas 0 #for each node crictl rmi docker.io/1dev/server:13.1.3 k scale -n onedev statefulset onedev --replicas 1After that I am still getting the same error unfortunately.
I rolled back to 13.1.2 and still am receiving the same error, so its definitely not a 13.1.3 issue. There's some larger issue with our deployment. Probably somewhere in the /opt/onedev folder?
-
(Testing on 13.1.2 from now on) I'm not certain if this is intended to be missing or not, but I checked the /opt/onedev/lib folder, and noticed that there was no wicket-utils.jar in the folder so I grabbed a jar from here, and dropped it in the folder and named it
org.apache.wicket.wicket-utils-7.18.0.jar, which yielded the following new error:Launching a JVM... WrapperManager: Initializing... 18:02:03 INFO i.onedev.commons.bootstrap.Bootstrap - Launching application from '/opt/onedev'... 18:02:03 INFO i.onedev.commons.bootstrap.Bootstrap - Cleaning temp directory... 18:02:04 INFO io.onedev.commons.loader.AppLoader - Starting application... 18:02:04 ERROR i.onedev.commons.bootstrap.Bootstrap - Error booting application java.lang.RuntimeException: Unable to process dependencies: [io.onedev.server-plugin-report-pylint, io.onedev.server-plugin-executor-remotedocker, io.onedev.server-plugin-report-junit, io.onedev.server-plugin-report-cpd, io.onedev.server-product, io.onedev.server-plugin-buildspec-dotnet, io.onedev.server-plugin-buildspec-gradle, io.onedev.server-plugin-report-cppcheck, io.onedev.server-plugin-report-ruff, io.onedev.server-plugin-report-pmd, io.onedev.server-plugin-buildspec-cmake, io.onedev.server-plugin-report-gtest, io.onedev.server-plugin-report-checkstyle, io.onedev.server-plugin-buildspec-python, io.onedev.server-plugin-buildspec-maven, io.onedev.server-plugin-report-clippy, io.onedev.server-plugin-report-mypy, io.onedev.server-plugin-report-roslynator]. This is either because circular exists in these dependencies, or because some of these dependencies depends on non-existent dependencies. at io.onedev.commons.utils.DependencyUtils.sortDependencies(DependencyUtils.java:85) at io.onedev.commons.loader.AppLoader.start(AppLoader.java:64) at io.onedev.commons.bootstrap.Bootstrap.main(Bootstrap.java:200) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:569) at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimpleApp.java:349) at java.base/java.lang.Thread.run(Thread.java:840) 18:02:04 INFO io.onedev.commons.loader.AppLoader - Stopping application... <-- Wrapper StoppedIt almost feels like our /opt/onedev folder got a bunch of random files deleted if there's a missing plugin, or some upgrade didn't complete properly and replace dependencies as it should have?
Is there a way to essentially "reset" our dependencies or reinstall them without nuking the whole /opt/onedev folder? Would it work to "reset" the whole instance if I just copy some data out of the /opt/onedev folder, backup from the interface, nuke the whole thing, reinstall and drop the data back in? If so what folders would I need to copy out of /opt/onedev? I assume
siteat the very least. -
I also feel that something gets corrupted inside /opt/onedev/lib. You may copy out /opt/onedev/site, and /opt/onedev/internaldb (only necessary if you are using internal database). Then start a new OneDev instance of 13.1.2, then copy back /opt/onedev/site and optionally /opt/onedev/internaldb
-
Cool, that must have been the case. I deleted the entire instance after copying
siteout (using Postgres, so nointernaldb), reinstalled 13.1.3, and ran a restore and everything worked nicely. Not sure what would have happened, I did do an upgrade before this which jumped many versions at once(12.0.4 -> 13.1.2), so maybe something went wrong there. Maybe I missed some upgrade instructions. :PThank you for your help! The @file@ syntax worked great for the test step, and the pipeline is running nicely now.
-
Previous Value Current Value Open
Closed
-
OneDev allows to upgrade between arbitrary versions. So 12.0.4 to 13.1.2 should be fine.
-
Odd, I'm gonna chalk it up to a one time fluke, and not worry about it lol. Thank you for all your help!
-
| Type |
Question
|
| Priority |
Normal
|
| Assignee | |
| Labels |
No labels
|
Hello, I am probably doing something wrong here, but I am trying to set up a CI pipeline in our hosted OneDev instance, and am running into an issue with trying to run a docker container. I have my buildspec set up to build the image in one job, then in another I want it to test the image separately.
My issue arises with trying to pass the built docker image's tag to the
testjob. Mybuildpipeline publishes the docker tag(including registry url) through an artifact file_DOCKER_TAG.txt, and I wanted the test step to read from that file, but using@file:_DOCKER_TAG.txt@in theimagefield of the "Run Docker Container" step yields the following error:Adding a command step that just has
echo _DOCKER_TAG.txtcorrectly outputs the tag, so the artifact is being loaded properly. I didn't dig too much into the code, but briefly looking through it seems that some placeholders aren't being replaced? Not sure if this is intentional or not, but if it is, how would you recommend passing a tag from thebuildstep to theteststep? A parameter would work fine, but I could not figure out how to use an artifact's contents as a job parameter.I could make the
teststep generate the tag itself, but that would require adding a code checkout step (slowing it down, albeit not much), and duplicating the version tag generating logic to a second step, which I would rather avoid. Not to mention the possible issues later, if I add a new build format a new tag.OneDev Server Version: 13.1.2 Hosted on K8S through helm Using a Docker Executor, with a 1dev/agent image that has a custom CA cert added to it.