I kill jenkins process and started again. After the restart, all the jobs are disappeard. However in my jenkins directory under "jobs" I can see all the job folder still exist.
/app/jenkins
Look like somehow I need to tell the jenkins to pickup all the configuration from existing directory. But not sure how to do.
Any help would be appreciated.
It was a mistake on my part. The reason Jenkins didn't pick up the old jobs is that upon restart, I did not have my JENKINS_HOME environment variable defined. Thus Jenkins didn't pick up the old jobs.
export JENKINS_HOME=/app/jenkins
Related
I've got Eclipse building a Maven project that I just imported. I have Build Automatically checked and Eclipse is constantly building. It builds and waits a few seconds and builds again without me making any changes. I noticed that this only happens when the server is running so I'll include some info on the setup here:
Have a local install of Tomcat.
Eclipse is set up to start Tomcat but points the Tomcat executables to a directory of its own making (Server Location is set to "Use workspace metadata").
Eclipse is set to "Automatically publish when resources change".
As far as I know, Eclipse (or Eclipse's embedded Maven) is building everything into the target directory at the root of my project. Is it possible that Eclipse doesn't realize that the target directory is not supposed to be scanned for changes?
There are zero references checked under the project properties -> Project References.
I'm at a loss as to what this might be. If there are other settings that someone would like me to confirm, please let me know.
This seems to be the same problem but none of the answers seem to apply to me. I'm not sure what the original poster's comment that "added annotation processing to my project which interfere the build process" means.
Does your code generate something in src/main/java or src/main/resources ?
Only then, eclipse scanner can interpret this as 'source change' and then build and deploy continuously.
Any change in 'src' should trigger build
Any change in 'target' should trigger deploy.
If your code is generating data in target (logging for e.g) you would see tomcat deploy happening continuously
I have a Java package which is checked in Git (and code.amazon.com) and I have a Ant job to trigger the package. Within the Ant job, I have created a macrodef for Git and I am performing a git fetch and git reset so that I can get the latest codebase every time I am triggering the Ant job.
When I am triggering the Ant job using Eclipse, it is working. If I am running the Ant job from terminal using ANT –buildfile my_buildfile.xml, it is also working.
Now I have setup Jenkins on my machine and am trying to run the Ant file. Jenkins is not able to trigger the Git job in the Ant file. It is giving following error:
/rhel5pdi/workplace/bangshis/EpubYJConvPerfWorkspace/src/EpubYJConvPerfLinux/Jenkins_Linux_build_Global.xml:81: The following error occurred while executing this line:
/rhel5pdi/workplace/bangshis/EpubYJConvPerfWorkspace/src/EpubYJConvPerfLinux/Jenkins_Linux_build_Global.xml:99: Execute failed: java.io.IOException: Cannot run program "git": error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1047)
at java.lang.Runtime.exec(Runtime.java:617)
at org.apache.tools.ant.taskdefs.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:58)
at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:428)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:442)
at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:628)
at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:669)
at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:495)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
Part of this error might be due to the reason that, my Jenkins is not able to trigger the job as the current user of the host machine.
To solve this problem, I have tried taking the following steps:
Creating a global credential and using password-less account (RSA ID).
Logging into Jenkins using the same username as system.
Installing Git and Git client plugins and setting them up appropriately.
Kindly let me know if I am missing something, and if there is any way out. If my approach is not correct, I would be glad if you can share few other ideas.
I think it's related to the git configuration on your master (or node)
This solution should work to fix your problem:
Jenkins giving error while cloning from gitHub
#Dr.Bokko is correct...and I should thank him for guiding in the right direction. I am trying to give the complete answer. There are three factors based upon which we can do the setup of GIT with JENKINS.
1st Factor: To access GIT repository, if it is a public repository, then user credentials would not be required. But for access restricted GIT repositories, we need to make sure that proper credentials are passed. Git and Git Client plugins need to be installed for Jenkins to understand GIT operations.
2nd Factor: Before running the script, add a build step and export all the libraries needed as a part of the shell script.
3rd Factor: Finally check the System Configuration in Manage Jenkins section and check the environment variables which are considered by Jenkins. If they are not appropriate, then go to the nodes management link, and all the environment variables as KEY-VALUE pairs.
Hopefully, these steps mentioned above would solve the problem.
The following error appears in your stacktrace:
Cannot run program "git": error=2, No such file or directory
What that means is that the git executable is either not installed or not in the command path of the process running ANT.
It's not entirely clear why you're calling GIT from ANT. Normally Jenkins would perform the checkout of the code first (using GIT) and then call ANT. I would highly recommend investigating this alternative workflow, which might require the installation of a GIT plugin for Jenkins (can't remember if this is a default plugin or not).
When I run for the first time there doesn't show any errors and I did double check the code and there is no error, but once again when I build the file again the following error pops up.
Deleting directory C:\Users\Vbabey\Documents\NetBeansProjects\PersistenceMYEX2\build C:\Users\Vbabey\Documents\NetBeansProjects\PersistenceMYEX2\nbproject\build-impl.xml:1054: Unable to delete file C:\Users\Vbabey\Documents\NetBeansProjects\PersistenceMYEX2\build\web\WEB-INF\lib\toplink-essentials-agent.jar
I cannot understand the reason for the above error? Can anybody explain me what it is?
Based on your comments, you are running into the default windows locking behavior. If you have a jar file open to run an application, you can't overwrite it.
You might be building it when the server is on. Some other application is using your files.
Try switching off the server or other applications that may be using the files.
A quick fix can be to export the project and import it with a different name and then you can build it.
Simply stop the tomcat or kill the java.exe process before building again.
Secondly, I believe you're using Clean & Build option, which does create issue, when the project is already running. Instead just use the build option or run option in case you want to run.
I'm working with Eclipse juno on windows7-64bit OS. Due to sudden power problem my system got shutdown, when i restart the Eclipse next start, Eclipse fails to load the workspace. It freezes on startup, or the workspace does not show up. It seems the workspace gets corrupted every time Eclipse is not shut down properly.
One way to fix the startup is
rm -rf ~/workspace/.metadata
After doing this, of course, settings are gone, projects have to be reimported etc. - It's really a pain :( and I don't understand why it has to be this way. Other applications seem to be able to keep their data intact, even if they are killed.
Can you suggest ways to remedy this problem? Are there ways of recovering a corrupted workspace including the settings?
thanks in advance
You can edit your shortcut to eclipse and add behind the line -clean as runtime parameter. It should clean your workspace and it might fix your corruption.
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html
So your shortcut would be something like:
"C:\Program Files(x86)\Eclipse\eclipse.exe" -clean
EDIT: Make sure once you've used this to remove it again after, you don't want to clean your eclipse every time you start it.
from Vissol.ca
create a new workspace
import new (android) project(s) from existing source(s)
good to go...
then you can backup original workspace , delete it and recreate it if desired.
My project install was perfectly fine until yesterday but today my install gets stuck at the following,
Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)
Java version: 1.6.0_20
[INFO] Surefire report directory: C:\Perforce\project-name\target\surefire-reports
Basically after this line the install does not proceed at all. Any thoughts?
I have tried mvn -X and I get the same thing.
I have even upgraded to version 2.6 the latest and still get the same issue
I have ensured that there are no debug options i.e, the JVM is not waiting for any debugger to attach(-Xdebug options)
Make a thread dump of the correct process using jstack and submit an issue
I passed the forkMode=never and now I noticed that one of the tests was not starting up at all. The reason was that it was using a ehcache and stored entries in the "java.io.tmpdir" directory which was my user's temporary directory.
The system also started being slow from today. Then I noticed that my C:/users/../AppData/Local/Temp folder had about 2 million files most of them either p4ticket234234.txt or Visual studio log files.
Once I cleared these log files, my build went successful. A jconsole or some thread dump would have more indicated the same I think.
Surefire waits for all non-daemon threads in your application to finish. It's easy to miss one or another. For example make sure to call the shutdown method on your Executors if you use any. If you do thread handling on your own you basically have to either make them daemon threads or make sure they terminate. A thread dump might help to spot the lingering threads.
Use jps, jstack or jvisualvm tools from JDK to get list of processes and their thread dumps.
I had the same problem. All of a sudden my "mvn test" was hanging seemingly forever and the related org.apache.maven.surefire.booter.ForkedBooter
process was taking 1.7GB! After much investigation it turns out that the problem was that I had deleted a class that was being instantiated by spring-core as a spring bean within the spring XML configuration. Once I removed the element corresponding to the deleted class from the spring XML configuration all was well. This seems like a bug in spring and surefire usage where no reasonable warning or error is produced.