|
Is it possible for a script to be run before Hudson performs the checkout of a project? I ask because I have come across 2 different instances where it would be useful.
The first is a situation where an ant script moves directory structures around from the way it exists in SVN to the way it needs to be built. When dealing with a gig of data, Move becomes a much cheaper operation than copy. Unfortunately many files have to moved from one directory to another, so it's not just as simple as symlinking a few directories, or using SVN externals. When a build succeeds, the ant script moves the files back into the SVN tree structure. This works great unless a build fails, ant terminates leaving the files in the build structure. Hudson leaves everything the way it is, monitors svn for the next update, but when it happens, has to wipe the entire workspace and download the gig of data all over again because the data does not match the SVN structure. Since Hudson still properly triggers the next build when the files are out of order, if I could run a script to put them back in the SVN order before Hudson tries to check out the next build. The second instance has to do with 2 copies of the svn repository. A local one where the developers commit, and a remote hosted svn at another facility which also happens to be the one which Hudson checks. Every 30 minutes changes at the developer svn are pushed to the remote svn server usually triggering numerous jobs. This works fine in practice, however there are times when it would be nice if a developer could manually build the job if he is a rush and have the server sync script run before Hudson checks out the code. Thanks -Tom |
|
Echoing this request.
My specific issue involves Windows builds. My build requires I create a Windows "junction" point (similar to UNIX symbolic links) to a location containing hundreds of gigs of files, and this "junction" point needs to be inside the workspace directory. The kicker with Windows "junction" points is that, unlike in Unix symbolic links, if you delete the "junction" point, you also delete the ORIGINAL CONTENT. (holy f*ck-a-deeeliac!) I could simply create the "junction" point in an early build step, then remove it in a later build step, but if a build failure occurs, or the system crashes, or whatever, the later build steps are missed, the "junction" point remains in the workspace, and then subsequent build's workspace cleanup script deletes the "junction" point, which deletes the hundreds of gigs of original content. So ideally, there would be an unconditional pre-build step that I could configure to remove any "junction" points before invoking any workspace cleanup steps. No I cannot make this a Maven project and use M2 pre-build steps. No I cannot upgrade to a later version of Windows and use the mklink command. Comments? |
|
You could make a tiny plugin that implements Notifier extension point, that would execute even if the build fails? In this plugin you would remove the junction point. Vincent 2011/1/29 mikeguz <[hidden email]>
|
|
In reply to this post by mikeguz
mikeguz <mikeguz <at> gmail.com> writes:
> So ideally, there would be an unconditional pre-build step that I could > configure to remove any "junction" points before invoking any workspace > cleanup steps. Did you ever solve this problem? We have a similar problem on our build server. Simply cleaning up ALL junctions using "junction -d %1" before deleting the files would be great! Thanks in advance, Søren |
|
Hi Søren,
what about the join plugin and workspace cleaner plugin? You could with join spawn a job that executes "junction -d %1" and then on return to the upstream job configure woekspace cleaner to cleanup the workspace when the job is done. I doubt it but you may eventually have to create a second downstream job to clean the workspace. I don't know if the WS cleaner evaluates a job as done if the join plugin spwans the junction removal as downstream but I assume it should work straight away as the original job is still in the build queue but on hold. Take care Jan Am Freitag, 27. April 2012 14:04:21 UTC+2 schrieb Søren Pingel Dalsgaard: mikeguz <mikeguz <at> gmail.com> writes: |
|
If you just want to remove the junction points between triggering a build and the checkout from SCM, You can use the pre-scm-buildstep plugin[1] which allows you to run most build steps at this point, including windows batch scripts. You could also use the post-build step, which should always run regardless of the result of the build, for more freedom at this point consider using the flexible publish plugin (use the always condition) and anybuildstep plugins to allow buildsteps to be run at this point. [1] https://wiki.jenkins-ci.org/display/JENKINS/pre-scm-buildstep [2] https://wiki.jenkins-ci.org/display/JENKINS/Post+build+task [4] https://wiki.jenkins-ci.org/display/JENKINS/Any+Build+Step+Plugin Chris |
|
pre-scm-buildstep plugin? YAY!
Never heard of that nor seen it before but you have just made my life pretty much easier :) Thanks Chris! Take care Jan Am Montag, 30. April 2012 14:55:16 UTC+2 schrieb cjo:
|
|
In reply to this post by cjo9900
Hi Chris
Would your plugin work for Hudson too ? We tried and it didnt work. Thanks
-- On Monday, April 30, 2012 5:55:16 AM UTC-7, cjo wrote:
You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
I don't think it will work for Hudson as it was created after the split and uses features added after that point.
I cannot add any more than this as I have not used any version of Hudson after the split, or looked for the code. Chris
-- On Monday, 18 February 2013 23:45:29 UTC, zw wrote: Hi Chris You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
| Powered by Nabble | Edit this page |
