Where do I put my files? In the jenkins project workspace?
Orchid1
unit tests all in the jenkins workspace folder? /var/usr/jenkins/
PROJECT_NAME ??
I am confused. Please help :(
Jesse Farinacci
It is best if you put your source code into a source control system,
like git. Then create a new Jenkins job, and have Jenkins poll that
SCM url for changes, building your project as required; typically via
Apache Maven or Apache Ant.
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
Orchid1
So OK I will have Jenkins poll subversion
but I guess the issue I am having still is what does Jenkins mean by
"Specify the name of the Clover xml file generated relative to the
workspace root."
my clover file is way outside of where the Jenkins works space is
and it doesn't look like Jenkins is running my PHING build file
because I use a absolute path instead of a relative path
I use this as the value to the Clover file
/home/orchid-linux/Sites/sequoia/stats/clover.xml
I must be doing something very dumb here
I am also getting this weird error in Jenkins when I try to define my
JUnit file
'/home/orchid-linux/Sites/sequoia/docs/junit/junit.xml' doesn't match
anything: '' exists but not '/home/orchid-linux/Sites/sequoia/docs/
junit/junit.xml'
here's a screenshot of the configurations
http://i301.photobucket.com/albums/nn51/noahryanmart/Selection_003.png
thanks
Jesse Farinacci
On Thu, Jan 26, 2012 at 2:13 AM, Orchid1 <orchidon...@gmail.com> wrote:
> So OK I will have Jenkins poll subversion
> but I guess the issue I am having still is what does Jenkins mean by
> "Specify the name of the Clover xml file generated relative to the
> workspace root."
I'm not specifically familiar with clover plugin, but this generally
means if freestyle build, or maven build with oddball location of
generated clover.xml file, that you need to specify the location of
the generated clover output file.
> my clover file is way outside of where the Jenkins works space is
> and it doesn't look like Jenkins is running my PHING build file
> because I use a absolute path instead of a relative path
> I use this as the value to the Clover file
> /home/orchid-linux/Sites/sequoia/stats/clover.xml
I think this is kind of weird. Generally, you will have Jenkins build
the project and generate the <test/coverage file>. You don't commit it
to your SCM. It's a generated file, and generally should not be put
under source control.
> I am also getting this weird error in Jenkins when I try to define my
> JUnit file
> '/home/orchid-linux/Sites/sequoia/docs/junit/junit.xml' doesn't match
> anything: '' exists but not '/home/orchid-linux/Sites/sequoia/docs/
> junit/junit.xml'
Same as above. The JUnit XML report file is a generated file. And in
Jenkins, you will generate it through normal build processes. It is
unusual, to say the least, to commit this to SCM and then have Jenkins
check out that SCM and simply put a report up for that output..... I
get the feeling that you're trying to use Jenkins as a UI for these
clover.xml and junit.xml, which isn't impossible given how flexible
and awesome Jenkins is, but is totally strange... sorry.
The general idea is that you have your SOURCE code at some well
defined location. You have Jenkins check that SCM location out, build
the project, which includes running tests and coverage, then you
inform Jenkins about the location of those outputs, and it presents
the outputs in the Jenkins UI.
If you're deviating from this model, you're pretty much on your own. Good luck,
Orchid1
explaining it correctly
Jenkins is installed on my machine as are my project files, however
the project files are not located in the same work-space
I think I know what you mean though
what I am going to do is develop my project commit to SVN
then Ill have Jenkins poll the subversion server
I assume the procedure is that i include the build.xml file in the
subversion repo so that when jenkins downloads me repo from subversion
it also downloads the build.xml
then I assume I tell Jenkins to use the build.xml file in the repo to
generate generate the code coverage file and to also to read the new
junit file.
Ill post back after I try this and make a video tutorial.
I am new to CI even though I have been programming for 4 years and
have worked with phing and phpdocumentor. anyways I will post back
thanks
Orchid1
the issue. I guess I just didnt understand the workflow of Jenkins.
Basically the workflow is like this
-Poll VCS (NOTE in this step the files are downloaded to work-space
folder, also note that connecting to a remove VCS is complicated at
best on linux and windows)
-Run this build once as it will download the files and store them int
he work-space
-Step 3 now that the files are int the work-space you can configure
the build a bit more such as configure the ant plugin or phing plugin
to work on the downloaded files that are now int he work-space.
It is critical that the files be downloaded to the work-space. This
was my error as I thought I could get Jenkins to just use the files
fromt he folder where I was working on my source code. (dohh!)
Took me a while to wrap my head around the work-flow paradigm for
Jenkins I think I will have to create a video tutorial on this step
because I know I will not be the only person that makes this mistake.
Anyways thank you. Your comments helped me decipher the process.
PS I am really liking Jenkins now
Jesse Farinacci
On Sun, Jan 29, 2012 at 10:08 AM, Orchid1 <orchidon...@gmail.com> wrote:
> OK so I admit I am a total newbie on Jenkins (argh) anyways I solved
> the issue. I guess I just didnt understand the workflow of Jenkins.
Everyone starts somewhere, we all learn by doing. :-)
> Took me a while to wrap my head around the work-flow paradigm for
> Jenkins I think I will have to create a video tutorial on this step
> because I know I will not be the only person that makes this mistake.
While I am very happy that Jenkins is now doing something you want it
to do, in my years of using Hudson/Jenkins, I don't think I've ever
seen anyone use it in this fashion... so congratulations on breaking
that new ground! And while I also admire your enthusiasm, I'm not sure
the workflow is one to be recommended.
Les Mikesell
> OK so I admit I am a total newbie on Jenkins (argh) anyways I solved
> the issue. I guess I just didnt understand the workflow of Jenkins.
> Basically the workflow is like this
> -Poll VCS (NOTE in this step the files are downloaded to work-space
> folder, also note that connecting to a remove VCS is complicated at
> best on linux and windows)
"Connecting" to a remote VCS is normally trivial - the client is
generally designed for that. Setting up a VCS as a network server may
be somewhat complicated the first time you try it. But most people
would probably have already been using a networked VCS for storage
before using jenkins for automation.
> -Run this build once as it will download the files and store them int
> he work-space
> -Step 3 now that the files are int the work-space you can configure
> the build a bit more such as configure the ant plugin or phing plugin
> to work on the downloaded files that are now int he work-space.
Don't work 'in' the jenkins working copy. The normal workflow is
that you have your own checked out working copy, make sure everything
builds there, commit all changes to the VCS, and have jenkins
configured to use the same build command that you did. If you are
working in a group, you'll probably continue to run test builds after
changes to minimize the changes of breaking the build for the others.
If you are the only one working on the project you can just commit
subsequent changes and jenkins will do the grunge work, collating the
results.
> It is critical that the files be downloaded to the work-space. This
> was my error as I thought I could get Jenkins to just use the files
> fromt he folder where I was working on my source code. (dohh!)
If you do things right, the only critical component will be the VCS
copy of the work. You should be able replace anything else (your own
working copy, the jenkins install, the jenkins build node, etc.) or
add more developers or more build nodes perhaps with different
environments, and keep on going.
--
Les Mikesell
lesmi...@gmail.com
Orchid1
So I have been exploring more of Jenkins and I found a few other
things I could have done
Apparently there is a custom work-space option in Jenkins
configuration which I should have tried (but then again i didn't
understand the general innerworking of Jenkins to begin with
so ...well whatever, now I know and this is another option for people,
personally not going to try it I am happy the way I have things
working)
On another note I had been doing unit tests for a while but had not
automated them outside of a PHING task( PHING is a PHP port of Apache
Ant) and although my projects source code is pretty well decoupled my
Unit test includes are not that decoupled so when I moved them to the
Jenkins everything was failing (this was actually an imporvement from
everything not running LOL)
So there is another bit of food for thought
Keep your Unit tests decoupled so you can run them on other machines
using a bootstrap file
@Les Mikesell
I just swithced to mercurial which saved me the nightmare of trying to
figure out the permissions issue with connecting to a remote
Repository, I was using Subversion on a remote server and I originaly
tried that but it was just not working for me and after what seemed
like 10,000 hours (likely just 10 hair pulling ones) I just gave up
and used mercurial sine it is better anyways (my opinion).
But I will try to figure it all out. I meant to write a whole more
code this weekend but instead I learned about Jenkins and there is
plenty more to learn but things are going smooth now.
Thanks for all your help and feedback
@Jesse I agree my first workflow probably isn't one I would recommend
for others but it is working for me right now and I will likely change
it up as I learn more and my project includes more people. Also I am
hoping to get a few of my friends using this and I think with their
help i think we can get some other projects off to a better start
Thanks again.
I will look at your suggestions a bit more. Right now I am goign to
try to get some code down before the weekend is over and the monday
grind begins
Cheers
Edgar
Les Mikesell
>
> @Les Mikesell
> I just swithced to mercurial which saved me the nightmare of trying to
> figure out the permissions issue with connecting to a remote
> Repository, I was using Subversion on a remote server and I originaly
> tried that but it was just not working for me and after what seemed
> like 10,000 hours (likely just 10 hair pulling ones) I just gave up
> and used mercurial sine it is better anyways (my opinion).
Subversion works, with a choice of 3 different styles of remote
access. Others are equally good, but normally you should make that
choice based on their relative strengths and whether you care about
distributed or centralized organization, not just which one you get
working first. Subversion has its own active mail list if you need to
ask for help. One thing that is easy with subversion that may take
some extra work with other VCs is that you can have top level projects
that use svn's 'external' feature to pull in components that can
either float with the trunk or be pinned to specific revisions or
tags, allowing you to decouple the component versioning from the
applications that use them - without having to do anything extra in
the upper level tools like jenkins.
--
Les Mikesell
lesmi...@gmail.com