I've a virtual server running a gitlab runner.
I've now added some GUI unit tests which run nicely on my pc but not on the virtual server.
It always exits with:
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
Any idea how to get this running with gitlab-ci?
Edit:
My virtual server is running centos 7
This im my current .gitlab-ci.yml
image: kaiwinter/docker-java8-maven
#maven:3-jdk-7
before_script:
- "Xvfb :99 &"
- "export DISPLAY=:99"
maven_build:
stage: build
script:
- "mvn clean package"
- "cat target/site/jacoco/index.html"
Now, the headlessexception is gone but basically all unit tests are failing due to awt exceptions like:
Could not initialize class java.awt.image.IndexColorModel
Edit2:
I've added the headless option as suggested:
image: kaiwinter/docker-java8-maven
#maven:3-jdk-7
before_script:
- "Xvfb :99 &"
- "export DISPLAY=:99"
maven_build:
stage: build
script:
- "mvn clean package -Djava.awt.headless=true"
- "cat target/site/jacoco/index.html"
Now I get the headless exceptions again...
You try using xvfb program like in this post http://elementalselenium.com/tips/38-headless.
I have used xvfb to run browser from text terminal. Your case is basically the same.
The problem is that your program expects to be run in window environment, but you are running it from text terminal.
Finally I've found a solution!
I've created a DOCKER image which is prepared for GUI testing (using xvfb, thanks vbuhlev):
https://github.com/thorstenwagner/docker-java8-maven
In the .gitlab-ci.yml I've added the following lines:
before_script:
- "Xvfb :99 &"
- "export DISPLAY=:99"
You need to enable Headless Mode:
maven_build:
stage: build
script:
- "mvn clean package -Djava.awt.headless=true"
Related
My problem is with X11 variable - when Im trying to launch gdx-setup.jar i get output:
Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set,
or no headful library support was found,
but this program performed an operation which requires it,
at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:166)
at java.desktop/java.awt.Window.<init>(Window.java:553)
at java.desktop/java.awt.Frame.<init>(Frame.java:428)
at java.desktop/java.awt.Frame.<init>(Frame.java:393)
at java.desktop/javax.swing.JFrame.<init>(JFrame.java:180)
at com.badlogic.gdx.setup.GdxSetupUI.<init>(GdxSetupUI.java:101)
at com.badlogic.gdx.setup.GdxSetup.main(GdxSetup.java:620)
Im running ubuntu on my local laptop (NO SSH).
System details
I've tried commands:
sudo apt-get update --fix-missing
sudo apt-get update
sudo apt-get clean
sudo apt-get autoremove
sudo dpkg reconfigure -a
sudo apt install -f
It didnt help at all...
When Im running AWT from intellij I can see GUI normally and there's no exception.
Ive followed there instructions while installing libgdx:https://tutorialforlinux.com/2022/11/14/step-by-step-libgdx-ubuntu-22-04-installation-guide/2/
echo $DISPLAY
output:0
Installed: xorg-x11
Double clicking on jar causes with no response... Ive marked jar as executable
You can specify one of many installed java versions when running from intellij. When running from the command line its just a single one.I think your default java probably -actually truly is- headless. Follow this guide here to change your default command line java. I mean the error is specifically that if fails the headless check.
Follow here to switch the default cmd line java version.
https://computingforgeeks.com/how-to-set-default-java-version-on-ubuntu-debian/
Its not unusual to have headless because thats all server side stuff needs.
I'm trying to work with gitlab CI/CD. I'm using Ubuntu server and Spring Boot with Maven. All is fine, runner starts pipeline jobs but it gets lots of errors with pattern "warning: failed to remove target/..." even if i call simple echo 'something' in .yaml pipeline script gitlab-ci.yaml. I found that if i remove /home/gitlab-runner/builds then all starts to work fine until /builds generated again. What am i doing wrong? I already tried to reinstall runner, making gitlab-user, different variations of script^ nothing works until i manually remove builds folder. However, there is also js frontend which is also on gitlab ci/cd and everything works fine there. Help me please!
Here is the error i get trying to get my java spring boot maven pipeline work:
enter image description here
gitlab-ci.yaml code here:
stages:
- test
- package
- deploy
# - sonar
test:
stage: test
only:
- master
- merge_requests
except:
- tags
script:
- echo 'test are running i swear!!!!!!'
- sudo mvn clean
- sudo systemctl stop socnet.service
package:
stage: package
only:
- master
except:
- tags
script:
- sudo mvn package -Dmaven.test.skip=true
deploy_to_server:
stage: deploy
only:
- master
except:
- tags
script:
- sudo systemctl restart socnet.service
Remove sudo from your .gitlab-ci.yml.
Using sudo there will execute mvn package as root user, hence all generated files have root as the owner.
When gitlab-runner picks up a job and proceeds to clean up previously generated files, it is still unprivileged and hence will fail to remove files owned by root.
You might want to add the following variables into your .gitlab-ci.yml file in order to change the location for Maven dependencies cache to inside the project directory:
variables:
MAVEN_OPTS: "-Dhttps.protocols=TLSv1.2 -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"
https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Maven.gitlab-ci.yml
So I have been trying to learn docker for a few days now and set a first goal for me.
I want to run a spigot server inside a docker container and later on the road combine that with a BungeeCord network.
I have run into problem.
My dockerfile runs without problems but once it reaches the point where it starts the minecraft server, the images stops building.
I think this is due to the server continuing to run and not returning a code 0 to show docker to keep on running.
Am I wrong with my idea, and if not, how can I fix the problem?
Here is my Dockerfile:
FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install openjdk-7-jre icedtea-7-plugin -y
RUN apt-get install wget -y
RUN mkdir mc_server && cd mc_server/
RUN wget http://getspigot.org/spigot18/spigot_server.jar
RUN java -Xms1536m -Xmx1536m -Dcom.mojang.eula.agree=true -jar spigot_server.jar nogui
This way the server starts up but docker never finishes building.
I hope I made my problem clear.
Greetings,
Joel
Replace that last RUN with CMD.
RUN / ADD / .. are used to build the static container environment where you want to run your application in. Everything that happens before running the actual application.
CMD and ENTRYPOINT define what's supposed to happen inside the container once you docker run it. This is where the startup script / call goes for the program.
The result of the Dockerfile is similar to a computer that's shut down but has everything installed on the harddrive including a script that autostarts the application. Turn it on and everything starts to run.
PS: https://hub.docker.com/search/?q=spigot&page=1&isAutomated=0&isOfficial=0&starCount=0&pullCount=0 there are several existing images
I'm trying to run some tests on Travis CI that require a server that's, err... Not headless. As you can tell, I know so little about the area I don't even know the right terminology to use.
The tests use LibGDX and LWJGL. They work fine on my desktop (Windows 8 and Ubuntu), but unsurprisingly fail in Travis CI:
Could not initialize class org.lwjgl.Sys
at org.lwjgl.opengl.Display.<clinit>(Display.java:135)
at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.setVSync(LwjglGraphics.java:446)
at com.badlogic.gdx.backends.lwjgl.LwjglApplication$1.run(LwjglApplication.java:118)
Can I do anything with Travis CI to make it think it has a proper display? Even if this is not possible with Travis CI, is there a generic approach that I could perhaps take with another VM I have more control over?
This can be done with xvfb. In your travis.yml, add this:
before_script:
- export DISPLAY=:99.0
- sh -e /etc/init.d/xvfb start
You will have to install xvfb if you don't already have it. You may also have to install the other libs/packages needed by your tests on the VM (for e.g. for web app tests, you would need a browser).
Starting a virtual framebuffer (xvfb) on Travis CI is not enough. If you need OpenGL > 1.4 you also need to install libgl1-mesa-swx11, libgl1-mesa-swx11-dev.
In my travis.yml I setup OpenGL and start xvfb with:
- sudo apt-get install -qq --force-yes mesa-utils libgl1-mesa-swx11 libgl1-mesa-swx11-dev xvfb
- /sbin/start-stop-daemon --start --quiet --pidfile /tmp/custom_xvfb_99.pid --make-pidfile --background --exec /usr/bin/Xvfb -- :99 -screen 0 1400x900x24 -ac +extension GLX +render
the whole file is at:
https://github.com/mwohlf/pluto/blob/master/.travis.yml
I already managed to set up a Jenkins-Slave on a Windows 7(x64) machine. I'm also able to attach Jobs to the slave and they get succesfully executed. But all tasks seem to be running in headless mode!? We have some graphical Swing-Tests that are starting a Swing GUI and executing Macros on it. When executing the corresponding Maven-Command manualy on the slave-node
mvn -B -f C:\Jenkins\workspace\3-Test-Script-GUI-Test\pom.xml clean test
everything works fine, but when triggering this command via Jenkins the Swing-GUI doesn't open and the tests fail.
Are jenkins-jobs by default triggered in headless mode or is there any other configuration that could help me to resolve this problem?
The jenkins-slave.xml looks as follows:
<executable>javaw.exe</executable>
<arguments>-Xrs -jar "%BASE%\slave.jar" -tcp %BASE%\port.txt</arguments>
The manual tests may (appear to) work when run from an X11 session running on the host, as the X server functions as valid peer for AWT components. Some alternatives (VNC, Xvfb) for headless mode are mentioned here.