I am having issues with Jenkins that I am unable to resolve, and all the solutions I've found online I've used in the past, but are not helping.
I am on windows 2008r2, utilizing svn, jenkins version 1.407.
Initially the service failed, and was not resolved with past methods. In the past I have successfully troubleshoot Jenkins by killing hung processes, restoring the war file, ect.
I have attempted a new install with bringing over the files in the jobs folder. The end result was a partially functioning Jenkins would attempt a build it would report no change and not update.
What I'm trying to determine is a list of files/folders beyond the jobs folder that I need to move to the new install. The initial install predates me and was Hudson. The folder has a number of obviously obsolete files and folders (both a jenkins.war and a hudson.war)
Go to Jenkins home folder and collect:
all ./*.xml files in - these are configuration files for plugins and jenkins itself
users/* in case you have security enabled
subversion-credentials/** and secrets/** for any kind of keys provided in jenkins to access svn or other resources
plugins/*.*pi folder for all plugins - you don't need to have the unpacked folders
jobs/*/config.xml - to retrieve all job configurations; jobs/*/nextBuildNumber if you care to continue build numbers
plugins may create additional folders which you may want to use
with that you should recreate Jenkins as it was. Pay especially attention to config.xml file in root folder - this holds main jenkins configuration. If your issue reproduces on new system most likely a plugin is cause for problems - in that case review log files most likely you will find out which plugin causes trouble.
You didn't indicate if you tried new setup with same version of Jenkins or newer one; if you are using newest version it may be that ssh key handling / svn authentication for each job needs to be updated as somewhen in last few months authentication / security handling changed. Best is to look into Jenkins release log.
I'm using Jenkins 1.55x on CentOS installed as RPM; given that it is a webapp I assume Windows 1.4x setup is similar.
Related
I installed Jenkins on to 2 new machines no-problemo!
But, when attempting to integrate Maven, I am having "command not found" in my Jenkins log, yet I can run mvn no problem in the command line.
So, I thought it was a PATH issue - so I added the /bin and also the / (of the location where Maven is extracted to), yet I'm still getting the error.
I tried adding the PATH to my ~/.bash_profile as well, so my current PATH is:
$PATH:/usr/local/bin:/Users/jenkins/apache-maven-3.5.2/bin:/Users/jenkins/apache-maven-3.5.2
Still, Jenkins will not find Maven. I do NOT want to globally install Maven, as it may affect the other 5 build servers we have that are working with Maven correctly (not sure how it's working).
The issue was resolved by simply re-connecting the Jenkins Slave. Thanks for your feedback!
I have a teamcity installation running on a windows server
I have a build process, that is building a .net application. As part of the build process it is running a gulp task, and is installing various node modules to build all the sass and js files.
Within my teamcity solution i have my clean up rules for "Everything" to be older that the 4th-th successful build
However teamcity does not appear to be cleaning everything up, because my artifacts folder is massive ( and caused the server to run out of disk space )
Now I believe that the issue is because one of the gulp task and all the node_modules being installed. Because of how nested node installs everything.
On windows machines, in most instances you cannot just delete a node_modules folder as you get the path longer than 256 char warning, and you have to use the robocopy trick of copying across an empty folder to delete the node_modules folder
What have others done to resolve this problem of artifacts not being correctly cleaned up ?
I was thinking about another step that would delete the node_modules folder from the artifact folder after the step to process the gulp tasks, but I cannot see in the list of teamcity parameters once that points to the artifact folder for the current build.
If the builds should be deleted by the server clean-up, but you still see the builds in TeamCity UI and they are not pinned, the most common reason for that is having other builds snapshot- or artifact-depending on the builds in question. Check build's Dependencies tab and related TeamCity settings.
I'm new to this repository, I already installed it and it is working fine on Ubuntu 14.04. Now I want to personalize it and I've found everywhere that to avoid losing your customizations, you should place them in [dspace-source]/dspace/modules/xmlui/src/main/webapp/themes (I'm choosing xmlui since that is the interface I'm using and themes because that is the only customizations I want to do for now) and then you should do a mvn package from [dspace-source]/dspace for it to apply the changes to the installation directory ([dspace]). I have done this but the new theme I created doesn't appear in the installation directory. Should I do an ant update after the mvn package? Am I missing something for the documentation?
Thanks for the help!
You are correct. mvn package will build the code in dspace-source/target. ant update will copy the code from dspace-source/target to your installation directory. The maven build is generic and does not know your configuration settings. The ant task will read your configuration settings (which contain the install path).
After running ant update, you should restart tomcat.
Because the maven/ant cycles can take some time, I will occasionally make changes to uncompiled files (xsl, js, css) on the source branch and then copy them directly to the install branch.
Beware of making changes directly in the install branch since it is easy to overwrite with the ant command.
The cocoon layer of XMLUI does cache some files. If you make a change and it does not seem to take effect, sign in with an admin login and go to Administrative->Java Console->Clear Cache to force a change to be reloaded.
I am in process of moving configuration parameters out of Java application. I discover that the best approach is to extend your classpath and use .properties files (leave ZooKeeper alone for another requirement).
So my WAR file no longer have any hosts/IPs/URLs, users/passwords.
DevOps distribute configs manually across test, stage, stable installations.
Now time for Jenkins to run tests. But they fail as there are no required .propeties files in classpath.
How can I load this config files to Jenkins and how to make in available in test classpath?
maven-surefire-plugin allow extending classpath and passing system-properties.
So only question how to get separate directory in Jenkins hosting server and load files to this directory and create alias/placeholder/envvar per build job to refer to this path in build config.
This job can be done with SSH access, but I think that this is "wrong way". I expect that this can be done via Jenkins UI (any manager can upload file in WEB browser).
UPDATE I have no requirements for distributed slave/master builds but it whould nice to have solution that migrate configuration files to slaves automatically...
In this way sshing to host or ftp/scp - bad thing.
I read most of Jenkins docs, ask at mail list and IRC. Yea - Jenkins community is silent. At docs I found link to Config File Provider Plugin, after that I visit http://builder.evil.com/jenkins/pluginManager/available page and look for config keyword.
There are a lot related plug-ins with various usefulness to my subject (most useless first):
https://wiki.jenkins-ci.org/display/JENKINS/Envfile+Plugin - This plugin enables you to set environment variables via a file.
https://wiki.jenkins-ci.org/display/JENKINS/Credentials+Binding+Plugin - Allows credentials to be bound to environment variables for use from miscellaneous build steps.
https://wiki.jenkins-ci.org/display/JENKINS/Environment+Script+Plugin - Allows you to run a script before each build that generates environment variables for it.
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin - This plugin makes it possible to have an isolated environment for your jobs.
https://wiki.jenkins-ci.org/display/JENKINS/Copy+Data+To+Workspace+Plugin - Copies data to workspace directory for each project build.
https://wiki.jenkins-ci.org/display/JENKINS/Copy+To+Slave+Plugin - This plugin allows to copy a set of files, from a location somewhere on the master node, to jobs' workspaces. It also allows to copy files back from the workspaces of jobs located on a slave node to their workspaces on the master one.
https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin - Adds the ability to provide configuration files (i.e., settings.xml for maven, XML, groovy, custom files, etc.) loaded through the Jenkins UI which will be copied to the job's workspace.
Only last plug-in - Config File Provider Plugin allow editing configs via Jenkins WEB interface. And it have brother - Managed Script Plugin - for uploading/managing/editing custom scripts. No question now I use Config File Provider Plugin!
You should keep the configs required for the tests together with the rest of source code, so that after compilation, your unit tests can run.
After deploying the .war, the DevOps team should overwrite the in-war configs with whatever per-environment configs that they have.
For now I have a batch file with commands for update projects using svn and calling maven 'clean install'. How to create some job in Jenkins for similar actions?
Should I write it to ant file (sorry if it's stupid idea, I've just heard about it but I don't know what is it exactly and what can I do with this) or there is other way?
Thanks
Like arghtype suggested, you need to be using Jenkin's own Source Code Management by configuring SVN as SCM source and supplying credentials as part of Maven build job.
If you have to use your own local working copy, you are organizing it wrong, you will lose on all the benefits of having Jenkins manage SVN changes, and in the end, this organization will give you more unsolvable problems in the future. Think about the advice people are giving here and come with up a reason why you need to have a local workspace outside of Jenkins management on a Jenkins build machine. My only guess is: your Jenkins and Development machine are the same. That again is not how it should be organized. Jenkins is a CI-server, not a personal build "automator".
Regardless, if you still want to do what you say.
What you think you want
Create a new Freestyle job
Under Build Steps, click Add build step
Select Execute Windows batch command
Write your batch execute command in there. Your working directory will be Jenkins's $WORKSPACE, so change your path accordingly to where you want to run it.
But with the above configuration, you might have as well put the batch file under windows scheduler... You are not really using Jenkins with the above.
What you should do instead
Create a new maven2/3 build job
Under Source Code Management, select Subversion
Under Repository URL enter the remote SVN repo (i.e. http://your.svnsever.com/path/to/project)
Under Build, enter your Root POM location (this will be relative to the location of your SVN checkout, so if your POM is under http://your.svnserver.com/path/to/project/maven/pom.xml, then enter maven/pom.xml.
Under Goals and options, enter clean install
Click Save
The Source Code Management section will take care of setting up a local workspace and checkout the repository into that workspace. By default, every time a new build is triggered, it will run svn update on that workspace for you.
The Maven Build step will take care of running your Maven, however note that it is configured to use default ~/.m2/repository location. If your local maven repo needs to be different, change this under Jenkins Global Configuration
Create a new job.
In Source Management choose Subversion, specify your repo and credentials.
Add a new build step - maven build, specify your maven goals ('clean install').
Jenkins is a CI(contiounus integration) server. It can be used to generate scheduled builds of ant or maven based projects. It can also start building projects by some triggering event such as a commit to SCM (git, svn, mercurial,...)connected to it. You really have to read its documentation to get a better understanding. It has nice tutorials.