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 and build" button seemed like a good start as any. /Bjarke F. On Wednesday, April 4, 2012 12:16:19 PM UTC+2, domi wrote: > > 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 guess I would more check into the direction of implementing a new > trigger. I would do this: > - Implement a new hudson.triggers.Trigger > - implement a new hudson.model.listeners.RunListener > The listener gets notified about every build triggered and it should be > able to react on the cause of the trigger and then clean the workspace only > if it is a build triggered by the required trigger. > This means at the end you only need to enable an additional trigger on > your project if you want to have this feature… > /imod > > On 04.04.2012, at 11:56, Bjarke Freund-Hansen wrote: > > 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 every night" (or something like that.) Nothing else > should be shown, if that is possible. And everything else should be handled > internally by the plugin. (I.e. scheduling of the nightly clean build apart > from other nightly clean builds, the actual cleaning of the workspace that > is only performed when this trigger is activated, etc.) I think that is > reasonable requirements to a plugin. > > The reason for hiding/locking the BuildStep is not because I do not trust > the user (this is not a permission problem, which would be the wrong way to > handle it anyway.) It is simply because the BuildStep does not make sense > as anything but the very first build step, and it does not make sense to > *not* have it when the trigger *is* used, and it does *not* make sense to > have it when the trigger *is not* used. I.e. the BuildStep configuration is > tightly dependent on the build trigger, and would only confuse the user if > it can be moved, removed or added manually. > > Does this make sense to you? > > /Bjarke F. > > On Wednesday, April 4, 2012 10:56:57 AM UTC+2, swiest wrote: >> >> Hi Bjarke, >> >> I think a conditional build step could meet much of your requirements >> (see >> https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin >> and https://wiki.jenkins-ci.org/display/JENKINS/Run+Condition+Plugin). >> >> Why is it important to hide/lock such a build step from the access of >> your users? If you grant them access to your job configuration page, >> shouldn't they be trusted enough to use that power properly? Like in >> "With great power comes great responsibility" (Spiderman, 2002)... :O) >> >> Cheers, >> Simon. >> -- >> Bjarke Freund-Hansen (04.04.2012 10:11): >> > 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 build-step being unremovable and unmoveable? And also >> > remove the build-step when the build trigger is disabled again? >> > >> > Could that build-step perhaps be hidden from the user? >> > >> > I think this would be a better design, do you agree? >> > >> > Specifically I want a build trigger saying "Wipe workspace and trigger a >> > clean build every night". >> > When this is activated, a build-step is also inserted, which will >> > perform the wipe only when the build is triggered by the above trigger, >> > otherwise it just does nothing. As such this build-step does not have to >> > be visible to the user at all. >> > >> > The actual wipe action could be specified by the user (i.e. just delete >> > the workspace, or e.g. a "git clean -fxd"). Perhaps this could even be >> > defined depending on the SCM type used for the job? >> > >> > Any input please? :) >> > >> > /Bjarke F. >> >> >> >
