Thanks for your ideas. I think an on-demand script would fit my
organization, but I'll take into account the way that GIT script works.
On Monday, August 5, 2013 4:20:05 AM UTC+3, Mark Waite wrote:
--
*From:* Avihay Eyal aviha...@gmail.com javascript:
*To:*
I don't think that is how the Git plugin does what it does.
I believe the Git plugin monitors multiple repositories and branch names
for changes. If a change is detected in one or more repositories, the
plugin merges those changes into its local branch, and attempts to run the
job steps
Alternatively, if you have a requirement for code passing test/compiling,
etc before checkin and you can't or don't want to use private
repositories/branches, you can look at developing a variation of your build
process that uses the filesystem SCM plugin. Run the build/tests against
the
There is also the github pull request builder which will build the merge of
your pull request every time you commit to the branch in the pull request.
This way you can get the results of the tests, see it failed, fix it, push your
change back to your branch, and the tests will run again. You
I'm using Mercurial, which is a distrusted source control.
So you're suggesting using a script, activated via commits to the developer
local repository?
Once the developer committed changes to it's repository, the script will
build that changes with the latest code, run all the regression
Am Sonntag, 4. August 2013, 11:37:27 schrieb Avihay Eyal:
So you're suggesting using a script, activated via commits to the developer
local repository?
No. I'm suggesting a script that runs on demand, when the developers says he's
ready.
Bye...
Dirk
http://www.recommind.com
--
From: Avihay Eyal avihay.e...@gmail.com
To: jenkinsci-users@googlegroups.com
Cc: dirk.heinri...@recommind.com
Sent: Sunday, August 4, 2013 12:37 PM
Subject: Re: CI usability - isn't there a problem that tests are executed only
after a developer pushed his
Am Donnerstag, 1. August 2013, 20:34:36 schrieb Daniel Beck:
http://www.cloudbees.com/jenkins-enterprise-by-cloudbees-features-validated-
merge-plugin.cb
Developers push to Jenkins' repository, and if that's successful, Jenkins
pushes to your actual repo.
That's what we actually do with
On Thursday, August 1, 2013 1:16:46 AM UTC-6, Avihay Eyal wrote:
I mean, If I'm a developer, I would prefer to somehow run the automated
tests *before* I push to the repository, cause
if an automated test failed and there's a bug in my code, I want to know
that before pushing my change...
Am Freitag, 2. August 2013, 05:14:50 schrieb Mark Waite:
Each developer's private repository could then be added to the job and
would be watched for changes, those changes would be merged, and if the
compile and tests were successful, the merge could be pushed to the
integration
On Friday, August 2, 2013 9:17:44 AM UTC-6, Dirk Heinrichs wrote:
Am Freitag, 2. August 2013, 05:14:50 schrieb Mark Waite:
Each developer's private repository could then be added to the job and
would be watched for changes, those changes would be merged, and if the
compile and
I mean, If I'm a developer, I would prefer to somehow run the automated
tests *before* I push to the repository, cause
if an automated test failed and there's a bug in my code, I want to know
that before pushing my change...
How do you approach this problem?
--
You received this message
Hi Avyhal,
It's a problem with your tools and workflow.
I suggest you look at some tools that enforce some code review as part of your
SCM use, so that the build midst have passed test before it can be in the
mainline.
E.g Gerrit, cloudbees commit validator etc.
Regards
James
--
You
Am Donnerstag, 1. August 2013, 00:16:46 schrieb Avihay Eyal:
I mean, If I'm a developer, I would prefer to somehow run the automated
tests *before* I push to the repository, cause if an automated test failed
and there's a bug in my code, I want to know that before pushing my
change... How
There's a commercial plugin that does this if you're using Git:
http://www.cloudbees.com/jenkins-enterprise-by-cloudbees-features-validated-merge-plugin.cb
Developers push to Jenkins' repository, and if that's successful, Jenkins
pushes to your actual repo.
On 01.08.2013, at 09:16, Avihay Eyal
15 matches
Mail list logo
