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? :)
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.
On Apr 4, 2012 10:11 AM, "Bjarke Freund-Hansen" <[hidden email]> wrote:
In reply to this post by Bjarke Freund-Hansen
I think a conditional build step could meet much of your requirements
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)
Bjarke Freund-Hansen (04.04.2012 10:11):
> 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.
In reply to this post by Emanuele Zattin
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?
On Wednesday, April 4, 2012 10:38:02 AM UTC+2, Emanuele Zattin wrote:
In reply to this post by Simon Wiest
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?
On Wednesday, April 4, 2012 10:56:57 AM UTC+2, swiest 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…
On 04.04.2012, at 11:56, Bjarke Freund-Hansen wrote:
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.
On Wednesday, April 4, 2012 12:16:19 PM UTC+2, domi wrote:
In reply to this post by Dominik Bartholdi
Hi again domi
I have run into another issue that you might be able to help with.
The RunListener has a onStarted() method, which is too late as this is run after the SCM has done it's job, and it has setUpEnvironment() which is before the SCM, but also before a workspace has been allocated (and decided) for the build. (build.getWorkspace() returns null, and the source for AbstractBuild.run() confirms this).
This indicates that I should probably use a BuildWrapper, however the BuildWrapper clearly states that:
"BuildWrapper requires an user consent (in terms of a checkbox) to work. If this is not desirable, see Environment for other ways to inject Environments to builds."
So that does not seem to be the solution either.
The FileSystemProvisioner.prepareWorkspace() could be an option, as it is run after deciding the workspace but before doing SCM checkout. However that class carries a big warning: "STILL A WORK IN PROGRESS. SUBJECT TO CHANGE! DO NOT EXTEND.".
What is your take on this? Any suggestions to what I can do?
On Wednesday, April 4, 2012 12:16:19 PM UTC+2, domi wrote:
seems that I did not know all the details about the RunListener - it just sounded to good :)
But I think the idea (different mail) with the WorkSpace-Cleanup plugin and the RunCondition Plugin in combination would be a really good option:
copy from other mail:
Actually this is a good idea too!
If the ws-clean-plugin could be configured to take a cause or even use the run-condition plugin: https://wiki.jenkins-ci.org/display/JENKINS/Run+Condition+Plugin
we would even get more possibilities - currently the run-condition plugin does not have a cause condition yet, but thats very easy to implement and would make it
very flexible too!
On 04.04.2012, at 14:44, Bjarke Freund-Hansen wrote:
Hi again domi
|Powered by Nabble||Edit this page|