Inserting an unremovable build-step when a build trigger is activated

2012-04-04 Thread Bjarke Freund-Hansen
Hi In follow up to my post about a wipe-workspace Jenkins plugin, I am reconsidering the design a bit, and would like to know if: Is it possible to have a build trigger, that when activated inserts a build-step (provided by the same plugin) as the first build-step of the job, and have that

Re: Inserting an unremovable build-step when a build trigger is activated

2012-04-04 Thread Emanuele Zattin
Hello. How about a trigger that adds a publisher that does nothing but has a prebuild step? The prebuild part would not be visible by users. Br, Emanuele On Apr 4, 2012 10:11 AM, Bjarke Freund-Hansen bjark...@gmail.com wrote: Hi In follow up to my post about a wipe-workspace Jenkins plugin,

Re: Inserting an unremovable build-step when a build trigger is activated

2012-04-04 Thread Bjarke Freund-Hansen
Hi Emanuele Thanks for the suggestion, just a few questions: The Publisher.prebuild() method is deprecated, so I assume that I should use BuildStep.prebuild(). I.e. make a BuildStep only with a prebuild part? So the question again becomes, can I add that BuildStep automatically when the build

Re: Inserting an unremovable build-step when a build trigger is activated

2012-04-04 Thread Bjarke Freund-Hansen
Hi Simon I have been looking at the Conditional BuildStep Plugin, and yes this is kind of what I want to do, but not quite. :) First I want to make it really really easy for the user. I just want the single button in the build trigger section called: Wipe workspace and trigger a clean build

Re: Inserting an unremovable build-step when a build trigger is activated

2012-04-04 Thread domi
At the end this is nothing else then a new trigger with some added functionality, there is nothing which requires you to have a button. In fact as a user I would question why I would need a button for this - because its a job configuration and not a onetime action I wan a perform on my job. So I

Re: Inserting an unremovable build-step when a build trigger is activated

2012-04-04 Thread Bjarke Freund-Hansen
Hi domi Perfect, a build trigger for activating, and a runlistener for cleaning just before every build triggered from the trigger sound like the right way to do it. Thanks. About the button, I completely agree, it was just my first attempt at doing anything in an eclipse plugin. And a wipe

Re: wipe-workspace-plugin - New plugin that adds a trigger that will wipe and (re)build a job nightly.

2012-04-04 Thread Harry G.
Hi Bjarke, why not add an option to the Workspace cleanup plugin, like clean only when build was triggered automatically or only when triggered by SCM etc. https://wiki.jenkins-ci.org/display/JENKINS/Workspace+Cleanup+Plugin This would do the trick, avoid another plugin and could be useful for

Re: Builder extension code for build step - execute shell?

2012-04-04 Thread Victor Polyansky
Hi David, It is in core, hudson.tasks.Shell среда, 4 апреля 2012 г. 14:57:15 UTC+4 пользователь Chemmo написал: Hey, I'm looking at writing a plugin which executes scala code typed by the user on the box a job is set up to execute on. This should be quite trivial (after looking at the

glassfish repo must die

2012-04-04 Thread nicolas de loof
Hi folks, as you know, glassfish maven repo (aka m.g.o-public) is definitively off, but we depend on it for many plugins dependencies, and this is hardcoded in plugin parent pom (so, to get it fixed, plugin would need to upgrade to a recent jenkins-core dependency). some of you may already

Re: glassfish repo must die

2012-04-04 Thread Bruno P. Kinoshita
Hi nicolas! +1, thanks for working on this. Let me know if you need any help. Cheers   Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com From: nicolas de loof nicolas.del...@gmail.com To: jenkinsci-dev@googlegroups.com Sent: Wednesday, 4 April

Re: glassfish repo must die

2012-04-04 Thread Jeff MAURY
You should rather delete this repo definition as it is not a good Maven practice and may lead to the same problem in the future. Jeff On Wed, Apr 4, 2012 at 8:58 PM, nicolas de loof nicolas.del...@gmail.comwrote: Hi folks, as you know, glassfish maven repo (aka m.g.o-public) is definitively

Re: glassfish repo must die

2012-04-04 Thread nicolas de loof
jenkins-ci.org is under our control so we can point it to whatever we like also, plugin can't build without a repo declaration as jenkins artifacts aren't available on central I don't thing this to be a bad practice. Would you expect all developers to configure settings with adequate repo to

Re: glassfish repo must die

2012-04-04 Thread Jeff MAURY
I think this is a bad Maven design to put repo definition in POM: this is an infrastructure item, it has nothing to do in POM and lead to people building repositories in bad places such a github, googlecode, ... My 0,5cent Jeff On Wed, Apr 4, 2012 at 10:38 PM, nicolas de loof