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. > > >
