The trick is to not run the jenkins slave on the VM. If you run the jenkins
slave on the VM, then when it reverts the TCP connection between master and
slave dies, and jenkins get's very unhappy.
What we do is for each VM we run the slave on a "vm controller". The
controller then does something
So, perhaps you can do it within jenkins.
- Method 1: Use two jobs. The first one is triggered by a git post commit
hook. It looks at the git log and exits if the author or message matches a
pattern. Otherwise it triggers the second real build job.
- Method 2: Not sure if this will work. a) use
Looks like one of your tomcat6-maven plugin is out of date. Of course,
since you can't start jenkins you need to fix that outside of jenkins.
- Shut down jenkins
- cd $JENKINS_FOLDER/plugins
- mkdir ../plugins-save
- mv $PLUGIN ../plugins-save/
- mv $PLUGIN.hpi ../plugins-save
- Start jenkins
You can use vars generated with a shell script. What we do is write them to
a file, then use the "Inject environment variables" plugin.
In your post commit hook, filter out commits that are either authored by
the build user, or whose commit message matches some regex.
Not sure how to do that in git. It works for me with hg.
Copy the serial output to a file (kermit, pyserial, screen, whatever).
Write a program that reads that file and chops it up into individual "test
case" results. Keep the test case results in memory or on disk, as
appropriate.
Write a junit/testng test. Each test function will read one of the ab
You may be able to use a job parameter to control whether to do a complete
or incremental build. You can look at the parameter from shell file build
step, and I think you can look at it using the conditional build step to
determine whether to run other build steps.
We use the multi-scm plug in with Mercurial. I'd suggest giving it a try.
Either it works or it doesn't. If it doesn't, there's a good chance you can
work around it.
On Sunday, July 1, 2012 12:04:45 PM UTC-7, Jon Schewe wrote:
>
>
> On Sat, Jun 30, 2012 at 8:05 AM, Chris Withers wrote:
>
>> Hi
Yes, you can run master(s) and slave(s) on the same machine.
As Mark says though: there are few reasons to do so. I do it so I can
control a VM from the slave, including taking snapshots, reverting to
snapshots, and doing reboots.
Based on what you say later (5 webapps each of which binds to a
I have some tests that require multiple nodes. For example, one node
is client, one server, one server replica.
Right now, I set up little vm clusters, with one node acting as a
jenkins slave and representing the group. But that is terribly
inefficient. Am really looking for a way to say that a jo
rties
echo "TEST_RUN_NUMBER=${TEST_RUN.number}" >>jop.properties
- Add an "Inject environment variables" step:
Properties File Path: job.properties
With luck, you can now access your variables as ${TEST_RUN_JOBNAME}
and ${TEST_RUN_NUMBER}
giuliano
On May 30, 8:03 pm, OSUBeav
Use two jobs. The first job polls. It loops and kicks off the second
job for each changelist it finds.
On May 16, 4:50 pm, Andrew Melo wrote:
> On May 16, 2012, at 17:18, Jesse Farinacci wrote:
>
> > Greetings,
>
> > On Wed, May 16, 2012 at 5:55 PM, Andrew Melo wrote:
> >> I'm also interested i
I have to do something like this. I need to revert a vm to a clean
state between tests. I run the jenkins slave on a "controller" box. It
uses ssh to run the test on the test box. And runs commands on the
controller to create snapshots and revert as needed.
You may be able to do something similar,
Anyone have any insights on getting parameters to work with the
notification plugin?
On Apr 25, 12:18 pm, giuliano wrote:
> I’m using thenotificationplugin. Mostly works great. Except that I’m
> getting no job parameters. And my job does have parameters. Any
> thoughts on why not and w
I’m using the notification plugin. Mostly works great. Except that I’m
getting no job parameters. And my job does have parameters. Any
thoughts on why not and what I can do to get them sent in the
notification message?
Some bits and pieces I’ve found that may (or may not) help:
Looking at the plu
15 matches
Mail list logo