[FIXED] How do I clear my Jenkins/Hudson build history?

Issue

I recently updated the configuration of one of my hudson builds. The build history is out of sync. Is there a way to clear my build history?

Please and thank you

Solution

If you click Manage Hudson / Reload Configuration From Disk, Hudson will reload all the build history data.

If the data on disk is messed up, you'll need to go to your %HUDSON_HOME%\jobs\<projectname> directory and restore the build directories as they're supposed to be. Then reload config data.

If you're simply asking how to remove all build history, you can just delete the builds one by one via the UI if there are just a few, or go to the %HUDSON_HOME%\jobs\<projectname> directory and delete all the subdirectories there -- they correspond to the builds. Afterwards restart the service for the changes to take effect.

Answered By - William Leara

Answer Checked By - Terry (PHPFixing Volunteer)

Read More

[FIXED] How to configure Jenkins to run on port 80

Issue

I'm running Ubuntu 11.10 and have run sudo apt-get install jenkins to install Jenkins on this system.

I've seen some tutorials on how to setup a reverse proxy (Apache, Nginx, etc), however this is a VM dedicated for just jenkins and I'd like keep it as lean as possible while having jenkins running on port 80.

I've found the upstart config in /etc/init/jenkins.conf and modified the port to 80 env HTTP_PORT=80

When I start jenkins via service jenkins start, ps reveals that it runs for a few seconds then terminates.

Is this because jenkins is running as the jenkins user on a privileged port? If so, how do I fix this? Any other ideas a welcome.

Here is the upstart config:

description "jenkins: Jenkins Continuous Integration Server"
author "James Page <james.page@ubuntu.com>"

start on (local-filesystems and net-device-up IFACE!=lo)
stop on runlevel [!2345]

env USER="jenkins"
env GROUP="jenkins"
env JENKINS_LOG="/var/log/jenkins"
env JENKINS_ROOT="/usr/share/jenkins"
env JENKINS_HOME="/var/lib/jenkins"
env JENKINS_RUN="/var/run/jenkins"
env HTTP_PORT=80
env AJP_PORT=-1
env JAVA_OPTS=""
env JAVA_HOME="/usr/lib/jvm/default-java"

limit nofile 8192 8192

pre-start script
    test -f $JENKINS_ROOT/jenkins.war || { stop ; exit 0; }
    $JENKINS_ROOT/bin/maintain-plugins.sh   
    mkdir $JENKINS_RUN > /dev/null 2>&1  || true
    chown -R $USER:$GROUP $JENKINS_RUN || true
end script

script
    JENKINS_ARGS="--webroot=$JENKINS_RUN/war --httpPort=$HTTP_PORT --ajp13Port=$AJP_PORT"
    exec daemon --name=jenkins --inherit --output=$JENKINS_LOG/jenkins.log --user=$USER \
        -- $JAVA_HOME/bin/java $JAVA_OPTS -jar $JENKINS_ROOT/jenkins.war $JENKINS_ARGS \
        --preferredClassLoader=java.net.URLClassLoader
end script

Solution

Give a try to 'authbind':

sudo apt-get install authbind
sudo touch /etc/authbind/byport/80
sudo chmod 500 /etc/authbind/byport/80 
sudo chown jenkins /etc/authbind/byport/80

Then modify the script above to have (add authbind before the $JAVA_HOME/bin/java part):

exec daemon --name=jenkins --inherit --output=$JENKINS_LOG/jenkins.log \
--user=$USER -- authbind $JAVA_HOME/bin/java $JAVA_OPTS \
-jar $JENKINS_ROOT/jenkins.war $JENKINS_ARGS \
--preferredClassLoader=java.net.URLClassLoader

For newer Jenkins installations (1.598) on newer Ubuntu installations (14.04) edit /etc/init.d/jenkins and add authbind before $JAVA

$SU -l $JENKINS_USER --shell=/bin/bash -c "$DAEMON $DAEMON_ARGS -- authbind $JAVA $JAVA_ARGS -jar $JENKINS_WAR $JENKINS_ARGS" || return 2

As mentioned by Alan (see comment below) if you need IPv6 and your system is lower than Quantal you can instead of using apt-get to install authbind download a higher version. Make sure you have libc6 and libc6-udeb installed. Here is authbind version 2.1.1 from Ubuntu:

• amd64
• i386

Then execute:

sudo dpkg -i authbind_2.1.1_amd64.deb
# or sudo dpkg -i authbind_2.1.1_i386.deb

sudo touch /etc/authbind/byport/80
sudo chmod 500 /etc/authbind/byport/80 
sudo chown jenkins /etc/authbind/byport/80

Answered By - JScoobyCed

Answer Checked By - Marie Seifert (PHPFixing Admin)

Read More

[FIXED] How to implement continuous deployment with Nexus and Jenkins

Issue

I'm trying to implement a continuous deployment system and I seem to not be able to find a good answer for our problem. We use Jenkins to run a maven build to generate our artifacts and deploy them to Nexus. I see a few projects that bundle up everything into a single war or tar file, extract one file per request from Nexus by name and deploy it to an application server, but this requires them to know beforehand what versions they have available. My project has quite a few jars/wars/binaries among other artifacts, which don't get deployed using an application server. What we want to do is be able to do is pull any snapshot or release revision of the software out of nexus and either generate an install package or deliver it directly to a remote server.

Clarification: I want QA or development to be able to select a version from Jenkins; where Jenkins will poll Nexus for the available versions, then perform an automated deploy to a server from Nexus.

Is there an easy nexus/maven way to get software out to a testing system?

So, is there a way to poll nexus to determine what revisions are available through ant/ivy, Jenkins, maven, gradle? I'll write in something else if it helps.

I see that a similar question was asked here: How do I choose an artifact from Nexus in a Hudson / Jenkins job?, but it is as of yet unanswered 9 months later.

Solution

Nexus gives you a standard HTTP browsing capability. You could browse the repository through HTTP and see what is available.

I still don't understand your Use Case though. If you know which versions of the project you want then what is the problem?

The easiest would be to write an installer pom.xml that has in it a ${} placeholder for the version you want for the artifacts then invoke mvn with mvn package -Dproduct.version=1.0.0

If you use a container, PAX has plugins that allow you to specific artifacts like mvn:myGroup/myArtifact/myVersion and it will auto pull from Maven.

Nexus isn't doing any magic. It's all well known paths on a URL of groups/artifactId/versions

Answered By - Andrew T Finnell

Answer Checked By - David Marino (PHPFixing Volunteer)

Read More

[FIXED] How to configure Jenkins for MasterJob to pass git tag to child jobs, which execute in parallel?

Issue

I've seen numerous questions on SO for similar issues, but I haven't found one that answers this question for me.

I'm looking for pretty much the simplest use case for parallel builds. I'd like to do the following:

Job1 (git commit no: abc123)
  |
  +------- SubJob1 (git commit no: abc123)
  |
  +------- SubJob2 (git commit no: abc123)

Both subjobs would be executed in parallel, and Job1 wouldn't complete until all subjobs finished.

Job1 gets executed by a git hook for a commit against any branch. At the moment the subjobs execute other commits instead of the exact one the parent job originally executed against.

Anyway to get this working?

As a bonus question, would it be possible for console output to be rolled up to the master job?

Thanks

Solution

You can achieve this with the MultiJob plugin which allows you to trigger phases of jobs (subjob1 and subjob2) in addition to any standard job building steps you want in the main job (job1)

You can also pass parameters into the subjobs Jenkins using File Parameter with MultiJob Project

---

EDIT the git parameter plugin may help to pass git revisions into jobs

Answered By - KeepCalmAndCarryOn

Answer Checked By - Mildred Charles (PHPFixing Admin)

Read More

[FIXED] How to stop Maven's verify phase rebuilding the artifact?

Issue

Imagine a Java project built using Maven for which I have:

• some fast-running unit tests that:
  • developers should run before committing
  • my CI server (Hudson, FWIW) should run upon detecting a new commit, giving almost instant feedback in case of failures
• some slow-running automated acceptance tests that:
  • developers can run if they choose, e.g. to reproduce and fix failures
  • my CI server should run after successfully running the unit tests

This seems like a typical scenario. Currently, I'm running:

• the unit tests in the "test" phase
• the acceptance tests in the "verify" phase

There are two CI jobs configured, both pointing to the project's VCS branch:

1. "Commit Stage", which runs "mvn package" (compile and unit test the code, build the artifact), which if successful, triggers:
2. "Automated Acceptance Tests", which runs "mvn verify" (set up, run, and tear down the acceptance tests)

The problem is that job 2 unit tests and builds the artifact-under-test all over again (because the verify phase automatically invokes the package phase). This is undesirable for several reasons (in decreasing importance):

• the artifact created by job 2 might not be identical to that created by job 1 (e.g. if there has been a new commit in the meantime)
• lengthens the feedback loop to the developer who made the commit (i.e. takes longer for them to find out they broke the build)
• wastes resources on the CI server

So my question is, how can I configure job 2 to use the artifact created by job 1?

I realise I could just have one CI job that runs "mvn verify", which would create the artifact only once, but I want to have the separate CI jobs described above in order to implement a Farley-style deployment pipeline.

---

In case it helps anyone, here's the full Maven 2 POM of "project 2" in the accepted answer:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example.cake</groupId>
    <artifactId>cake-acceptance</artifactId>
    <version>1.0</version>
    <packaging>jar</packaging>
    <name>Cake Shop Acceptance Tests</name>
    <description>
        Runs the automated acceptance tests for the Cake Shop web application.
    </description>
    <build>
        <plugins>
            <!-- Compiler -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.1</version>
                <configuration>
                    <source>${java.version}</source>
                    <target>${java.version}</target>
                </configuration>
            </plugin>
            <!-- Suppress the normal "test" phase; there's no unit tests -->
            <plugin>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.5</version>
                <configuration>
                    <skipTests>true</skipTests>
                </configuration>
            </plugin>
            <!-- Cargo (starts and stops the web container) -->
            <plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <version>1.0.5</version>
                <executions>
                    <execution>
                        <id>start-container</id>
                        <phase>pre-integration-test</phase>
                        <goals>
                            <goal>start</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>stop-container</id>
                        <phase>post-integration-test</phase>
                        <goals>
                            <goal>stop</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <!-- Don't wait for CTRL-C after starting the container -->
                    <wait>false</wait>

                    <container>
                        <containerId>jetty7x</containerId>
                        <type>embedded</type>
                        <timeout>20000</timeout>
                    </container>

                    <configuration>
                        <properties>
                            <cargo.servlet.port>${http.port}</cargo.servlet.port>
                        </properties>
                        <deployables>
                            <deployable>
                                <groupId>${project.groupId}</groupId>
                                <artifactId>${target.artifactId}</artifactId>
                                <type>war</type>
                                <properties>
                                    <context>${context.path}</context>
                                </properties>
                            </deployable>
                        </deployables>
                    </configuration>
                </configuration>
            </plugin>
            <!-- Failsafe (runs the acceptance tests) -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
                <version>2.6</version>
                <executions>
                    <execution>
                        <id>integration-test</id>
                        <goals>
                            <goal>integration-test</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>verify</id>
                        <goals>
                            <goal>verify</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <includes>
                        <include>**/*Test.java</include>
                    </includes>
                    <skipTests>false</skipTests>
                </configuration>
            </plugin>
        </plugins>
    </build>
    <dependencies>
            <!-- Add your tests' dependencies here, e.g. Selenium or Sahi,
                with "test" scope -->
        <dependency>
            <!-- The artifact under test -->
            <groupId>${project.groupId}</groupId>
            <artifactId>${target.artifactId}</artifactId>
            <version>${target.version}</version>
            <type>war</type>
        </dependency>
    </dependencies>
    <properties>
        <!-- The artifact under test -->
        <target.artifactId>cake</target.artifactId>
        <target.version>0.1.0-SNAPSHOT</target.version>
        <context.path>${target.artifactId}</context.path>
        <http.port>8081</http.port>
        <java.version>1.6</java.version>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
</project>

Note that even though this "tests" project doesn't create an artifact, it has to use some kind of packaging (I used "jar" here), otherwise no tests are run in the verify phase.

Solution

Try two maven projects. The first one contains the build and unit tests. You install the artifacts in your local repository. The second job runs the second maven project which declares the artifacts of the first project as dependencies and runs the functional tests.

Not sure if the scenario I just described is possible, but I think it is.

For a quick improvement you can bypass the unit test with -Dmaven.test.skip=true. If you pass the revision number of your code in your scm to the second job, you should be able to checkout the same source code.

You can also check into the Clone Workspace SCM plugin. This might offer you some additional options.

Answered By - Peter Schuetze

Answer Checked By - Candace Johnson (PHPFixing Volunteer)

Read More

[FIXED] What backend does Jenkins (Hudson) use for archiving build artifacts?

Issue

I've read about the disadvantages (especially this one) of using SVN to store build artificats (large binary files). Hudson was suggested as an alternative.

How does Hudson handle these files?

Edit: My project is not Java-based.

Solution

Hudson is basically using flat file storage. You can find those files within Hudson in the jobs/builds/ folders. I'm not sure I'd say, "Use Hudson as an alternative to checking in file to source control" but using something as an alternative is a decent idea if it provides:

1. authoritative place to store
2. versioned binaries access control
3. checksums for tamper resistance
4. release meta-data (environment information; approval level)
5. retention periods

I'm not sure how well Hudson scores on those marks, but I think it does at least some of that. SVN is non-terrible as a solution there as well, but really struggles with retention periods (old builds tend to eat disk space like crazy) and isn't terribly well optimized for large binaries - most SCM systems are optimized for smallish text files.

I stole the list above from this presentation: http://www.anthillpro.com/html/resources/webinars/Role_of_Binary_repositories_in_Software_Configuration_Management.html (registration required)

Answered By - EricMinick

Answer Checked By - Cary Denson (PHPFixing Admin)

Read More

[FIXED] Hudson Shellscript for exporting Sourcecode from SVN repository into production folder

Issue

I have one dedicated server which has the whole Lamp-Stack, SVN and Hudson installed. I would like to create a freestyle Hudson job, that gets the latest sourcecode out of my SVN-repository and puts it into my /var/www/myWebApp Folder.

How does the shell script need to look like?

EDIT

When I just use

svn export myRepoURL myWebAppFolder

i get an erro, stating:

Started by user anonymous
Reverting http://myIpAdress/repos
Updating http://myIpAdress/repos
At revision 2
no change for http://myIpAdress/repos since the previous build
[workspace] $ /bin/sh -xe /tmp/hudson7864414135197533508.sh
+ svn export http://myIpAdress/repos/myRepo
/var/www/myWebApp
Authentication realm: <http://myIpAdress> Subversion Repository
Password for 'hudson': Authentication realm: <http://myIpAdress> Subversion Repository
Username: svn: PROPFIND request failed on '/repos/myRepo'
svn: PROPFIND of '/repos/myRepo': authorization failed (http://myIpAdress)
Finished: FAILURE

Solution

It should look something like below

svn export [your svn URL] /var/www/myWebApp

Do let me know if I am missing something here ?

Answered By - Version Control Buddy

Read More

[FIXED] LAMP with Hudson: How to run SQL Statement every hour

Issue

I'm using CentOS 5.5, Apache, MySQL and PHP. I also installed Hudson. Now I would like to run an SQL Statement every hour. What is the easiest way? Should I use Cron or Hudson?

Solution

cron is pluggable as long your box is with crond enable,
use less resource unlike java-based hudson,

As a Java-based web application, Hudson is heavyweight. A low-memory or embedded system is better-off with cron. Even Hudson’s remote job invocation installs and starts a Java-based runtime. You can, however, use the SSH plugin if even one box can run the main Hudson instance.

Cron’s scheduling is more precise if things have to happen exactly at certain time intervals. Hudson’s assumption is that your periodic builds aren’t dependent on when they start within a minute or two.

Answered By - ajreal

Read More