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 trigger is selected? And as the BuildStep does nothing when run 
(only the prebuild part does something), is it then hidden from the build 
step list on the job configuration page?

Last how are BuildStep.prebuild() execution evaluated? I guess all selected 
BuildStep's prebuild methods of a job are executed before the first 
BuildStep.perform() are executed, is this correct?

/Bjarke F.

On Wednesday, April 4, 2012 10:38:02 AM UTC+2, Emanuele Zattin wrote:
>
> 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" <[email protected]> 
> wrote:
>
>> 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.
>>
>

Reply via email to