I am trying to use ssh publisher to publish artifacts to a remote server through jenkins.
<ssh name="ssh-publisher" host="myhost.com" user="dummy" keyFile="/home/dummy/id_rsa">
<ivy pattern="/data/refdata/local0/artifacts[organisation]/[module]/[revision]/ivy-[revision].xml"/>
<artifact pattern="/data/refdata/local0/artifacts/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"/>
</ssh>
However when I tried to publish, I got the following error
impossible to publish artifacts for <my.artifacts>;<my.version>: java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:159)
at java.awt.Window.<init>(Window.java:407)
at java.awt.Frame.<init>(Frame.java:402)
at java.awt.Frame.<init>(Frame.java:367)
at javax.swing.SwingUtilities$SharedOwnerFrame.<init>(SwingUtilities.java:1731)
....
So I set the DISPLAY variable in the bash_profile of the remote user, I tried both
export DISPLAY=:0.0
export DISPLAY=<jenkin.server.ip>:0.0
But none of them works. Could someone shed lights on me how to work this out? Thanks!
I think Ivy is trying to prompt you to enter a password but since Jenkins is running headless, it cannot do so. Check your keyfile.
Related
I want to update Jenkins plugin via Artifactory.
Create a remote repo named Jenkins-update
Create a local repo named jenkins-update-center
Get the update-center.json from repo Jenkins-update to local and modify the URL from 'http://updates.jenkins-ci.org/' to my own URL 'https://artifacts.xxx.com/artifactory/Jenkins-update/' in update-center.json, then put update-center.json into local repo.
#!/bin/sh
curl -L -o /tmp/update-center.json http://localhost:8081/artifactory/Jenkins-update-cache/update-center.json
sed -i 's#http://updates.jenkins-ci.org/#https://artifacts.xxx.com/artifactory/Jenkins-update/#g' /tmp/update-center.json
curl -L -uuser:pass -T /tmp/update-center.json "http://localhost:8081/artifactory/jenkins-update-center/update-center.json"
Change the default update site from 'http://updates.jenkins-ci.org/' to 'https://artifacts.xxx.com/artifactory/jenkins-update-center/update-center.json' in Jenkins
There is an error 'SHA-512 digest mismatch: expected=49a22dc23f739a76623d10128b6803f79e0489de3ded0f1d01f3dfba4557136c7f318baaf4749a7713ec4b3f56633f2ac3afc4703e87d423ede029d68f84c74d in 'update site 'default''' when I click 'check now' button.
What should I do to make Jenkins update plugins from Artifactory?
Tkx
As soon as the content of update-center.json changed you need to re-generate "signature" section of this file.
For that you need to generate your key pair (see more details in How to create a local mirror of public Jenkins update site?)
Also you may use the following proposed approach :
there is probably a better way, by having a sandbox Jenkins on a system that has access to the internet. You update the server using the UI and then you can test that updated Jenkins thoroughly. When done, you just need to copy the war and hpi files over to your 'production' Jenkins. now you have even a nice process and QA in place.
Another way is to setup a transparent https proxy between your Jenkins and Artifactory server - in that case update-center.json will not change and signature verification should work fine.
With best regards,
Dmytro Gorbunov
As of 2023-01-10 there is a problem with making a mirror of the jenkins plugins on artifactory.
Artifactory documentation decribes only how to create a mirror: https://jfrog.com/knowledge-base/how-to-configure-artifactory-as-a-mirror-for-jenkins-plugins/
But this is not a complete solution. Because this leads to the situation when every plugin shall be manually updated. Having plugins with bunch of dependencies it is huge effort.
There is a need to generate a file: update-center.json
There is an internal jenkins tool to do this: https://github.com/jenkins-infra/update-center2, but documentation is poor and contains vague statements like:
With a few modifications it could easily be used to generate your corporate update center as well.
Without clear description, what shall be done.
I tried to follow steps and completely failed. Tool require some special environment variables, which are also not documented and so on.
So as of my experience mirroring jenkins plugins on artifactory is practically not possible. And honestly spoken, I would like to be wrong here.
Background
I have the following Jenkins config.
Ubuntu machine
Jenkins installed using apt-get, and is started as a service (service jenkins start).
To this point I have not made any modifications to Jenkins config.
We have several Ant projects for which I want to publish Javadocs using Jenkins.
After configuring the Javadoc plugin, I quickly hit this issue where only the Javadoc frames are displaying, without any content.
Some reading (here and here) told me that I need to configure Jenkins' Content Security Policy, and that this is done by modifying system properties passed to Jenkins.
However, despite digging around I have not found clear docs on how to pass these system properties to the Jenkins service. How do I do that?
Answering my own question.
To set system properties for the Jenkins service:
Steps
Stop Jenkins (service jenkins stop). You will need root privileges.
Edit the /etc/defaults/jenkins file.
Add an additional line for the JAVA_ARGS that you want to pass.
JAVA_ARGS="-Dhudson.model.DirectoryBrowserSupport.CSP=\"your CSP configuration here\""
Start Jenkins (service jenkins start).
Explanation
Look at /etc/init.d/jenkins for a line similar to:
NAME=jenkins
SCRIPTNAME=/etc/init.d/$NAME
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
These tell us that the Jenkins daemon will look for a file named /etc/default/jenkins. If present, it .s that file.
If you set $JAVA_ARGS in /etc/default/jenkins it will be substituted in the line below, located later in the /etc/init.d/jenkins file:
$SU -l $JENKINS_USER --shell=/bin/bash -c "$DAEMON $DAEMON_ARGS -- $JAVA $JAVA_ARGS -jar $JENKINS_WAR $JENKINS_ARGS" || return 2
Notes
Even after you do the above, the Javadoc may not load properly. Try doing a hard refresh (Ctrl-Shift-R on Chrome).
As detailed in (the Jenkins docs)[https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy] there is a temporary way to do this as well. Read that page and try to understand the implications well.
Changing the Content Security Policy has serious implications especially if your Jenkins is public. It's worth the effort to understand just what policies you are modifying.
I have another project from which I need to copy artifacts.
However the problem I have is that it's from another server. Is there a way to do so with the copy artifact or I'll have to go through code?
You can accomplish by either publishing your artifact and using either file transfer or secure shell.
Here is info to read upon:
Jenkins Secure Shell Plugin
Jenkins FTP Plugin
The only other possibility is to modify the ant or maven project config file.
Here is a More Reference along the same lines.
I used a wget to fetch the file in the end, with fixed paths.
This link can help for someone not used with wget.
Using wget to recursively fetch a directory with arbitrary files in it
For a long time I use this python script to download artifacts from Jenkins. It takes advantage of the JSON API layer available to any Jenkins job. The format of that API call is:
http://_YOUR_BUILD_HOST_/job/_JOBNAME_/lastSuccessfulBuild/api/json
Beware script depends on PyCurl.
Publish over ssh plugin can also be used for copying the files/artifacts from one server (local/linux) to another server. It has retries option also in case there is network issue and no. of retires and timeout also can be configured.
I have a jenkins server running, and for a job I need to download a file which is in the jobs/builds/buildname folder.
How to download that file from jenkins job?
If you would use the workspace as suggested by previous post, you can access it within a Pipeline:
sh "wget http://<servername:port>/job/<jobname>/ws/index.txt"
Or inside a script:
wget http://<servername:port>/job/<jobname>/ws/index.txt
Where index.txt is the file you want to download.
I rock a Unix based development machine and a Unix based Jenkins machine up in the cloud. This means I can use the SCP Command to download the remote file over an ssh connection. This is the anatomy of my scp commands:
scp -i <path/to/ssh.pem/file> <user>#<jenkins.remote.url>:<path/to/remote/file> <local/path/where/download/goes>
This works for directories too, for instance I use this to download backups generated by the ThinBackup Plugin
You had already been given the answer for getting the file from the workspace
http://<servername:port>/job/<jobname>/ws/filename.ext
Obviously replace stuff in <..> with values relevant to your setup, and make sure anonymous user has access to read from workspace, else you may have to login.
The only other files you could access are those that are archived from previous job runs.
http://<servername:port>/job/<jobname>/<buildnumber>/artifact/filename.ext
Where <buildnumber> is the build number you see in job build history, or one of the permalinks provided by Eldad (such as lastStableBuild). But this will only have access to archived artifacts.
You cannot arbitrarily access files from Jenkin's filesystem through the web interface... it wouldn't be very secure if it did let you.
The Jenkins job's build folder is meant for logging and plugins reports. You should not need to access it directly.
If you must, you can access it relative to the workspace: $WORKSPACE/../builds/$BUILD_ID/
You can also replace the $BUILD_ID with one of the links Jenkins creates:
lastFailedBuild
lastStableBuild
lastSuccessfulBuild
lastUnstableBuild
lastUnsuccessfulBuild
I hope this helps.
As others have pointed out this path should work, I like to highlight that the "ws" is a directory in Jenkins:
http://<servername:port>/job/<your job>/ws/<your file>
Download the Package lynx (Command line browser)
$ apt-get install lynx
or
$ yum install lynx
then use the command
# lynx http://<servername:port>/job/<jobname>/ws/file
The App Will Ask you to allow cookies and if there are authentication will direct you to login page like the browser.
My company is trying to automate the creation of a nightly installer with Hudson. Our license to install anywhere is running on a separate server. We have an ANT build script set up to call the InstallAnywhere jar file which creates the installer automatically, and that works great when ran from the command prompt.
However when we try to run it inside of Hudson, Hudson is not able to connect to that license server. InstallAnywhere spits out The evaluation period has expired. Does anyone know what we can do to solve this issue?
I'm assuming it's a Hudson issue since our ANT script works fine when used outside of Hudson.
My best guess is that you need to set up some environment variables required by the InstallAnywhere process; I'm not very familiar with that product, but maybe it needs a home directory for the product, the location of the license file, the license key value, etc.
One easy way to debug this would be to check if Hudson is running under the same user that you are using to run the Ant script from the command line, then check the environment settings for the command line user if they are different.
Since I'm running Hudson as a service I had to use the "Default User" user. The solution was to copy the InstallAnywhere folder tree from "C:\Documents and Settings\MyUser" to "C:\Documents and Settings\Default User"
I just had the same issue, so I thought I would share my solution. You can also register the CI build user so you can continue using the automated user rather than switching it to your own user account: http://www.flexerasoftware.com/downloads/instructions/productlicensing/en/InstallAnywhereProductLicensing.pdf#page=15
Set up a bat file to execute:
<PATH_TO_IA>\build.exe -registerNodeLocked <PATH_TO_IA>\License.lic
Note, the License will be your mac address.lic, and you only have to do this once.
My bat was:
C:\Progra~2\Instal~2\build.exe -registerNodeLocked C:\Progra~2\Instal~2\[MAC].lic
Then I added a bat task to jenkins, and ran the job:
You should see something like:
Trying to checkout IAEE version=12.0
InstallAnywhere is successfully registered.