I have set up a Jenkins job that should run Firefox. Signed in to Ubuntu with the Jenkins user, I can manually launch Firefox without any problem. However, when I run the job in Jenkins, I get :
[EnvInject] - Loading node environment variables.
Building in workspace /var/lib/jenkins/jobs/cbx4-ci/workspace
Fetching changes from the remote Git repository
Fetching upstream changes from git#bitbucket.org:cognibox/cbx4.git
Checking out Revision c90b791227b3788c2e023fd13db74ed1664428d1 (origin/master)
[EnvInject] - Executing scripts and injecting environment variables after the SCM step.
[EnvInject] - Injecting as environment variables the properties content
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
FIREFOX_BIN=/usr/bin/firefox
[EnvInject] - Variables injected successfully.
[workspace] $ /bin/sh -xe /tmp/hudson985724635788604565.sh
+ bash -ex runkarma.sh
+ node_modules/karma/bin/karma start config/karma.conf.js --reporters junit
[32mINFO [karma]: [39mKarma v0.10.9 server started at http://localhost:9876/
[32mINFO [launcher]: [39mStarting browser Firefox
[31mERROR [launcher]: [39mCannot start Firefox
[32mINFO [launcher]: [39mTrying to start Firefox again.
[31mERROR [launcher]: [39mCannot start Firefox
[32mINFO [launcher]: [39mTrying to start Firefox again.
[31mERROR [launcher]: [39mCannot start Firefox
As you can see, I have injected the environment variable to point to Firefox.
Some useful version numbers if this can help:
Jenkins 1.546
NodeJs 0.10.24
Karma 0.10.9
Edit:
It might be good to know that I had to do an operation for the jenkins user to be able to run firefox in the first place. As my main user, I had to enable other users to launch firefox by doing xhost +local:. Without that, the jenkins user kept getting the following error.
No protocol specified
No protocol specified
No protocol specified
No protocol specified
Error: cannot open display: :0
Although this is likely a separate problem I solved, it might have incidence on the question I am asking, so I felt important to add this detail.
Got it. It turns out the problem originated from a misconception on how to run karma in the first place.
The Jenkins task was doing karma start, with autowatch set to true. Instead, I fired up karma with autowatch false in rc.local (script ran on boot) and the Jenkins task executes karma run instead. This solved the problem entirely.
Edit: Installing the xvnc plugin, and activating it for build works for karma start and karma run.
Edit: The problem came back when I upgraded to 14.04. The fix was to make sure the environment variables injected in the build pointed to the X11 versions.
FIREFOX_BIN=/usr/bin/X11/firefox
CHROME_BIN=/usr/bin/X11/google-chrome
Would you mind running karma with --log-level debug and also --no-colors so we can have a better idea of the reason why it fails?
I you also tried with another browser?
I often encounter issues while running a GUI tool within Jenkins.
You might want to try running your test suite with PhantomJS (http://phantomjs.org/) just to see if a headless browser would solve the problem
Related
I'm in the process of migrating Jenkins from one server to another. I've no issues with the migration process.
But sooner I start my new server the scheduled jobs start executing, which is proving to be dangerous. I need to make sure that everything is in place before activating the new server.
Is there any way to deter any of the jobs from executing while the new server is active?
execute an '/script':
Jenkins.instance.getAllItems(org.jenkinsci.plugins.workflow.job.WorkflowJob.class).each {i -> i.setDisabled(true); i.save() }
Jenkins.instance.getAllItems(hudson.model.AbstractProject.class).each {i -> i.setDisabled(true); i.save() }
Not my idea, from jenkins wiki
Setup a post-initialization script that puts Jenkins into quiet mode right after startup.
https://wiki.jenkins.io/display/JENKINS/Post-initialization+script
Try using https://wiki.jenkins.io/display/JENKINS/Exclusive+Execution+Plugin. You can keep jenkins in shutdown or Quiet mode for some time till your new instance is ready to function.
Use the Jenkins CLI
To prevent any jobs from being run, use quiet-down:
java -jar jenkins-cli.jar -s http://localhost:9090 -auth user:token quiet-down
To re-enable job scheduling:
java -jar jenkins-cli.jar -s http://localhost:9090 -auth user:token cancel-quiet-down
Scheduled jobs will be added to the queue during the quiet-down time, and will be run after canceling the quiet-down. If that's not what you want, you may use clear-queue before canceling the quiet-down.
There is a little downside: in the GUI, Jenkins will announce that it is preparing for shutdown, which wouldn't be true in this case. I find that acceptable, because we use it during backup at night when no one will read the announcement anyway. However, another option would be to take nodes offline, then online again using offline-node and online-node.
Quick Setup
Only if you haven't set up Jenkins CLI already:
You can obtain the Jenkins CLI from your Jenkins server by downloading it from <your_jenkins_url>/jnlpJars/jenkins-cli.jar
Instead of using your actual password to authenticate, obtain a token from <your_jenkins_url>/me/configure
For more details, refer to the Jenkins Handbook: Jenkins CLI
Referencie: https://xanderx.com/post/cancel-all-queued-jenkins-jobs/
Run this in Manage Jenkins > Script Console:
Jenkins.instance.queue.clear()
I am very new to Jenkins and Capistrano. I've found existing documentation to be very fragmented when it comes to running Capistrano from within Jenkins. Having said that, I have successfully installed Jenkins and Capistrano. I've created the items and can trigger the scripts. For my initial test I am just running the default deployment script as it is out of the box.
When I run the following via Jenkins trigger:
#!/bin/bash -exl
export PATH=$PATH:/usr/local/bin
cap staging deploy
I get the error (edited for brevity):
+ USER=jenkins
+ LOGNAME=jenkins
Stage not set, please call something such as `cap production deploy`, where production is a stage you have defined.
*Nothing in /capistrano.log
When I run the same commands inside of a script from the command line I get:
+ USER=root
+ LOGNAME=root
*capistrano.log file:
---
INFO START 2016-09-29 16:50:03 +0000 cap staging deploy
INFO ------------------------------------------------------------------------
---
It appears that the jenkins user is not configured correctly and is missing some dependencies but I can't find how to fix this.
Help is appreciated. If anyone knows of a good resource for using Capistrano together with Jenkins that would also be a huge help.
Turns out the issue was a space in my workspace directory name. The directory name was not being interpreted correctly within the Jenkins script for some reason, but was fine in the bash script I ran from the command line. Thanks to my buddy Scott for figuring that one out!
Inside the .travis.yml configuration file what is the practical difference between before_install, install, before_script and script options?
I have found no documentation explaining the differences between these options.
You don't need to use these sections, but if you do, you communicate the intent of what you're doing:
before_install:
# execute all of the commands which need to be executed
# before installing dependencies
- composer self-update
- composer validate
install:
# install all of the dependencies you need here
- composer install --prefer-dist
before_script:
# execute all of the commands which need to be executed
# before running actual tests
- mysql -u root -e 'CREATE DATABASE test'
- bin/doctrine-migrations migrations:migrate
script:
# execute all of the commands which
# should make the build pass or fail
- vendor/bin/phpunit
- vendor/bin/php-cs-fixer fix --verbose --diff --dry-run
See, for example, https://github.com/localheinz/composer-normalize/blob/0.8.0/.travis.yml.
The difference is in the state of the job when something goes wrong.
Git 2.17 (Q2 2018) illustrates that in commit 3c93b82 (08 Jan 2018) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit c710d18, 08 Mar 2018)
That illustrates the practical difference between before_install, install, before_script and script options
travis-ci: build Git during the 'script' phase
Ever since we started building and testing Git on Travis CI (522354d: Add Travis CI support, 2015-11-27, Git v2.7.0-rc0), we build Git in the
'before_script' phase and run the test suite in the 'script' phase
(except in the later introduced 32 bit Linux and Windows build jobs,
where we build in the 'script' phase').
Contrarily, the Travis CI practice is to build and test in the
'script' phase; indeed Travis CI's default build command for the
'script' phase of C/C++ projects is:
./configure && make && make test
The reason why Travis CI does it this way and why it's a better
approach than ours lies in how unsuccessful build jobs are
categorized. After something went wrong in a build job, its state can
be:
'failed', if a command in the 'script' phase returned an error.
This is indicated by a red 'X' on the Travis CI web interface.
'errored', if a command in the 'before_install', 'install', or
'before_script' phase returned an error, or the build job exceeded
the time limit.
This is shown as a red '!' on the web interface.
This makes it easier, both for humans looking at the Travis CI web
interface and for automated tools querying the Travis CI API, to
decide when an unsuccessful build is our responsibility requiring
human attention, i.e. when a build job 'failed' because of a compiler
error or a test failure, and when it's caused by something beyond our
control and might be fixed by restarting the build job, e.g. when a
build job 'errored' because a dependency couldn't be installed due to
a temporary network error or because the OSX build job exceeded its
time limit.
The drawback of building Git in the 'before_script' phase is that one
has to check the trace log of all 'errored' build jobs, too, to see
what caused the error, as it might have been caused by a compiler
error.
This requires additional clicks and page loads on the web interface and additional complexity and API requests in automated tools.
Therefore, move building Git from the 'before_script' phase to the
'script' phase, updating the script's name accordingly as well.
'ci/run-builds.sh' now becomes basically empty, remove it.
Several of our build job configurations override our default 'before_script' to do nothing; with this change our default 'before_script' won't do
anything, either, so remove those overriding directives as well.
I have a strange behavior by my Jenkins and the ScriptTrigger plugin.
I have Jenkins 1.510 with the latest version of this plugin.
I have the trigger setup with a simple shell script:
#!/bin/bash
echo test
exit 0
The trigger is set to start the build if exit code is 0.
After I restart Jenkins (or just reload configuration), the trigger log shows:
...
The expected script execution code is 0
[ERROR] - SEVERE - Polling error null
No error is in any of the other logs I looked.
No comes the puzzle - if I trigger the job manually, it will make the plugin for this job only start working properly until the next restart...
Has anyone seen this? Does anyone have an idea?
The problem was found to be related to the dependency to xtrigger lib version. I downloaded the sources, updated xtrigger.lib.version to be 0.19 and locally built the plugin (and installed it on my Jenkins). This solved the problem.
Thanks for the help of Gregory Boissinot (the author of the plugin), who helped me find this. He will release a formal release for this plugin soon.
Note - the current version is 0.22.
I hope this helps.
I am trying to do End-to-End automation for an iOS project. My aim is to automate the continuous integration process with attaching UIAutomation scripts as post build action.
So from the time when a user do check his code in SVN and till we get test result of automation, everything will be automated.
Jenkins is installed on my local machine and running on localhost.
Now I have automated build process through jenkins and at other end I have my shell script ready which will run UIAutomation java scripts on build output.
When I use my shell script as post build action then I get error in running instrument command(written inside shell script) but if I run this script manually through terminal then it works fine.
instruments[64703:60f] -[NSAlert alertWithError:] called with nil NSError. A generic error message will be displayed, but the user deserves better.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. Mon Feb 6 13:15:20 inpunml310743 instruments[64703] <Error>: kCGErrorFailure: Set a breakpoint # CGErrorBreakpoint() to catch errors as they are logged. 2012-02-06 13:15:20.179 instruments[64703:60f] Recording cancelled : At least one target failed to launch; aborting run Instruments Trace Error : Failed to start trace. Build step 'Execute shell' marked build as failure Finished: FAILURE
then i tried this command with sudo then I got following error
sudo: no tty present and no askpass program specified
Please let me know how can I run these commands successful, only this step is left in my task.
Jenkins by default installs as a LaunchDaemon, which means it has insufficient permissions to launch WindowsServer.
You’ll need to configure it as a LaunchAgent:
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
sudo mv /Library/LaunchDaemons/org.jenkins-ci.plist /Library/LaunchAgents/org.jenkins-ci.plist
Then login as Jenkins and keep a session open.
If you don't know the Jenkins password you can change it with:
sudo passwd jenkins
Jenkins is running as a daemon and is therefore not allowed to connect to the window server. More info here http://developer.apple.com/library/mac/#technotes/tn2083/_index.html.
Sorry - not got time to put a complete answer now, will update later....
This is possible if you run jenkins as a user app rather than as a deamon -- this might come in handy (https://github.com/stisti/jenkins-app) I haven't tried it but looks like it should work -- I went down another route setting up an always logged in user, that ran jenkins from a login script, it did mean I had to re-install jenkins but managed to get it up and running... word of warning from someone thats been through it, are you using instruments for automated testing? If so, you'll need to do some transformation on the output so it displays in Jenkins.
We have a Jenkins Linux instance that builds to a Mac slave over SSH. One interesting requirement that we noticed with this error is that the build user on the slave must be logged into the console in order for everything to work correctly.
In addition, we had to make the build user an Admin, developer permissions were insufficient.
See more info here:
UIAutomation : Failed to authorize rights with status: -60007