How do I prevent Workspaces from being automatically deleted.
Locked
How do I prevent Workspaces from being automatically deleted.
 
|
Hi, I’ve searched through the old mailing list messages
(using nabble) and looked on the Wiki and even did a google search or two without
much success. Maybe someone reading this might have a solution. We are using How can I disable this ‘feature’? just for grins here is a test job I created to verify this
was happening. Job settings: Tie this project to a node is set to one a linux based slave
delete old builds with Max # of builds to keep set to 5 scm is set to SVN with a path of http://someRepo/trunk/performance/Automation/tests/genmetadata
and use update is checked no build triggers are active build - execute shell which contains: #!/bin/bash echo running on `hostname –f` echo $WORKSPACE echo the current BUILD_NUMBER is $BUILD_NUMBER echo the current BUILD_ID is $BUILD_ID echo the current JOB_NAME is $JOB_NAME echo the current BUILD_TAG is $BUILD_TAG echo the current WORKSPACE is $WORKSPACE echo the current BUILD_URL is $BUILD_URL echo the current JOB_URL is $JOB_URL echo ============================================================================ env echo ============================================================================ ls –l Thanks in advance, Greg. |
Re: How do I prevent Workspaces from being automatically deleted.
Administrator
|
I'm bit confused here with your use of the term "hudson workspace",
which we normally use to refer to the source code checked out + files produced by the builds, which are often on slaves. I think what you are really saying is that "hudson home" is deleted altogether, which includes things like configurations of jobs and records of past builds, etc. Hudson indeed does some sort of GC-like clean up to workspaces on nodes, but it definitely doesn't wipe out hudson home on its own. Are you sure hudson home isn't in a temporary directory that gets periodically wiped out or something? 2009/12/9 Greg Moore <[hidden email]>: > Hi, > > > > I’ve searched through the old mailing list messages (using nabble) and > looked on the Wiki and even did a google search or two without much success. > Maybe someone reading this might have a solution. > > > > We are using hudson 1.327 and exclusively use slaves. There is a dedicated > master but no jobs are run on the master. The slave, in this case is on > Linux and the job is rather simple. The problem is that if I start a job > before I leave for the evening, The job will run fine but when I come in the > morning EVERYTHING under the hudson workspace directory is gone. the job > directories, checked out file, generated files, job results everything gone… > Before you say it… NO, THERE IS NOTHING in the script that deletes files. > > > > How can I disable this ‘feature’? > > > > just for grins here is a test job I created to verify this was happening. > > > > Job settings: > > Tie this project to a node is set to one a linux based slave > > delete old builds with Max # of builds to keep set to 5 > > scm is set to SVN with a path of > http://someRepo/trunk/performance/Automation/tests/genmetadata and use > update is checked > > no build triggers are active > > build - execute shell which contains: > > > > #!/bin/bash > > echo running on `hostname –f` > > echo $WORKSPACE > > echo the current BUILD_NUMBER is $BUILD_NUMBER > > echo the current BUILD_ID is $BUILD_ID > > echo the current JOB_NAME is $JOB_NAME > > echo the current BUILD_TAG is $BUILD_TAG > > echo the current WORKSPACE is $WORKSPACE > > echo the current BUILD_URL is $BUILD_URL > > echo the current JOB_URL is $JOB_URL > > > > echo > ============================================================================ > > env > > echo > ============================================================================ > > ls –l > > > > > > Thanks in advance, > > Greg. -- Kohsuke Kawaguchi --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: How do I prevent Workspaces from being automatically deleted.
|
|
Thanks for the reply Kohsuke. See below. > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Kohsuke Kawaguchi > Sent: Thursday, December 10, 2009 7:02 AM > To: [hidden email] > Subject: Re: How do I prevent Workspaces from being automatically deleted. > > I'm bit confused here with your use of the term "hudson workspace", > which we normally use to refer to the source code checked out + files > produced by the builds, which are often on slaves. Ok let me clarify some of the term that I use. Workspace is the path defined in the slave configuration line labeled 'Remote FS root'. For *nix machines Remote FS root is set to /var/hudson and for windows machines its set to 'C:\hudsonslave' (minus quotes). What term should I have use to refer to this? The link for http://hudson/job/someJobName/ws/ is labeled Workspace. All the slaves have Sun's Java JDK 1.6 installed on them and JAVA_HOME is set properly. From http://wiki.hudson-ci.org/display/HUDSON/Administering+Hudson "All the settings, build logs, artifact archives are stored under the HUDSON_HOME directory." I am NOT referring to this. This only exists on the master and is not a factor here. hudson_home is however set to /var/hudson > > I think what you are really saying is that "hudson home" is deleted > altogether, which includes things like configurations of jobs and > records of past builds, etc. NO I don't mean the hudson home. I meant what I said! I really do mean EVERYTHING below the 'Remote FS root' aka $WORKSPACE or %WORKSPACE% gets removed completely. There are no odd hudson.log entries only an INFO line stating that a job finished. > > Hudson indeed does some sort of GC-like clean up to workspaces on > nodes, but it definitely doesn't wipe out hudson home on its own. yes IT DOES! I've had complaints from every single member of our team asking why does hudson delete stuff? I believe that this happens sometime after midnight but I'm not completely positive about that. Because during work hours because if I run a job and then go to http://hudson/job/someJobName/ws/ I see what the expected directories and files BUT if I run a job and come back the next morning there is nothing at that URL but: Error: no workspace 1. The project was renamed recently and no build was done under the new name. 2. The slave this project has run on for the last time was removed. 3. The workspace directory (null) is removed outside Hudson. > Are > you sure hudson home isn't in a temporary directory that gets > periodically wiped out or something? [Greg Moore wrote:] No. There are no periodic jobs the go anywhere near /var/hudson or even reference /var > > 2009/12/9 Greg Moore <[hidden email]>: > > Hi, > > > > > > > > I've searched through the old mailing list messages (using nabble) and > > looked on the Wiki and even did a google search or two without much > success. > > Maybe someone reading this might have a solution. > > > > > > > > We are using hudson 1.327 and exclusively use slaves. There is a > dedicated > > master but no jobs are run on the master. The slave, in this case is on > > Linux and the job is rather simple. The problem is that if I start a job > > before I leave for the evening, The job will run fine but when I come in > the > > morning EVERYTHING under the hudson workspace directory is gone. the > job > > directories, checked out file, generated files, job results everything > gone... > > Before you say it... NO, THERE IS NOTHING in the script that deletes > files. > > > > > > > > How can I disable this 'feature'? > > > > > > > > just for grins here is a test job I created to verify this was > happening. > > > > > > > > Job settings: > > > > Tie this project to a node is set to one a linux based slave > > > > delete old builds with Max # of builds to keep set to 5 > > > > scm is set to SVN with a path of > > http://someRepo/trunk/performance/Automation/tests/genmetadata and use > > update is checked > > > > no build triggers are active > > > > build - execute shell which contains: > > > > > > > > #!/bin/bash > > > > echo running on `hostname -f` > > > > echo $WORKSPACE > > > > echo the current BUILD_NUMBER is $BUILD_NUMBER > > > > echo the current BUILD_ID is $BUILD_ID > > > > echo the current JOB_NAME is $JOB_NAME > > > > echo the current BUILD_TAG is $BUILD_TAG > > > > echo the current WORKSPACE is $WORKSPACE > > > > echo the current BUILD_URL is $BUILD_URL > > > > echo the current JOB_URL is $JOB_URL > > > > > > > > echo > > > ========================================================================== > == > > > > env > > > > echo > > > ========================================================================== > == > > > > ls -l > > > > > > > > > > > > Thanks in advance, > > > > Greg. > > > > -- > Kohsuke Kawaguchi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: How do I prevent Workspaces from being automatically deleted.
|
The "Remove FS Root" is distinct from the workspace. That is why Kohsuke has to guess what you really meant after you described the layout of the folder that was wiped out, because what you described was not a workspace directory.
However, since you use the name 'workspace' this way, perhaps someone set a custom workspace for one of their _projects_ on your Hudson instance, and used the remote FS root as the workspace path. That could cause some bad side effects, such as what you are seeing.
-Michael (646) 833-8884 On Thu, Dec 10, 2009 at 3:02 PM, Greg Moore <[hidden email]> wrote:
|
Re: How do I prevent Workspaces from being automatically deleted.
|
|
Wow, that's a bad typo given the context of the thread. I meant to say "Remote FS Root" down there.
-Michael (646) 833-8884 On Thu, Dec 10, 2009 at 4:27 PM, Michael Donohue <[hidden email]> wrote: The "Remove FS Root" is distinct from the workspace. That is why Kohsuke has to guess what you really meant after you described the layout of the folder that was wiped out, because what you described was not a workspace directory. |
RE: How do I prevent Workspaces from being automatically deleted.
|
In reply to this post by Greg Moore-5
Hello,
I have also seen this behaviour in the following use case: I have a Linux master with a Solaris slave (but from what I saw, this is not related). Due to network constraints I have to retrieve the source code before 8PM (after that deadline, the clearcase server is locked for backup, and it is not possible to change that for the time being). In addition I am not allowed to start a nightly production on the solaris server before ~9PM because other builds are prioritary, and some "late developpers" might still be there. So my first try was to split the nightly build in 2 jobs. First, retrieve the source at about 7PM. Then start the production with a delay of 2 hours. I decided to share an external, explicitely-defined workspace between both jobs. The next morning, everything went fine but the workspace was empty. After several nights chasing the culprit, I found that Hudson was doing some cleaning on externally-defined workspace at about 3:20AM. The file "Workspace clean-up.log" logs that activity. So far, I gave up. Now, I retrieve the source code into the default workspace of the first job and point the 2nd job to it, but without "making Hudson aware of that". Not perfect, but enough for my current experiments. Cheers Michel --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: How do I prevent Workspaces from being automatically deleted.
|
|
In reply to this post by Michael Donohue
LOL.. maybe that what it should be really
labled.. Thanks clarification Michael, I hope I
didn’t sound harsh. My apologies that wasn’t my intent. Since no
jobs are ever built on the master I guess we have a different POV as to what a “workspace”
is. As for Custom Workspaces… We had problem
with that but the abusers were flogged (JUST KIDDING) and now we don’t do
that any more because of the bad side effect you mentioned. Since some of these
jobs are my own I know for a fact that a custom workspace is not set and I have
a high level of confidence in stating that none of the jobs on our hudson
server use a custom workspace. Greg. From: Michael Donohue
[mailto:[hidden email]] Wow, that's a bad typo given the context of the thread. I meant
to say "Remote FS Root" down there.
On Thu, Dec 10, 2009 at 4:27 PM, Michael Donohue <[hidden email]>
wrote: The "Remove FS Root" is distinct from the workspace.
That is why Kohsuke has to guess what you really meant after you
described the layout of the folder that was wiped out, because what you
described was not a workspace directory. However, since you use the name 'workspace' this way, perhaps someone
set a custom workspace for one of their _projects_ on your
On Thu, Dec 10, 2009 at 3:02 PM, Greg Moore <[hidden email]>
wrote:
[Greg Moore wrote:]
NO I don't mean the
yes IT DOES! I've had complaints from every single member of our team
asking why does
[Greg Moore wrote:]
|
RE: How do I prevent Workspaces from being automatically deleted.
|
In reply to this post by Michel.DHOOGE
Workspace clean-up can be disabled by setting the system property
hudson.model.WorkspaceCleanupThread.disabled=true (http://wiki.hudson-ci.org/display/HUDSON/Features+controlled+by+system+properties) But AFAIK a workspace is deleted after 30 days since last use. Though there were some weakness in "last use" calculation logic. At least it doesn't work for Matrix type projects and, yes, there were problems with custom workspaces. Michel, to achieve the same result without setting a custom workspace you could to set your 2 jobs as following: 1) 1st job gets the sources and packs them to an archive; then the archive is saved to the job artifacts. 2) 2nd job gets the saved archive from the 1st by URL_SCM (SCM plugin) via permalink (a'la http://hudson/job/FirstJobName/lastSuccessfulBuild/artifact/Archive.tar.gz); unpacks it and builds it. Yes, a notable chunk of disk space is wasted. Also, an operation overhead exists but it won't cause problems for nightly builds. But that works. A similar practice is described in Hudson Wiki (http://wiki.hudson-ci.org/display/HUDSON/Splitting+a+big+job+into+smaller+jobs).
|
RE: How do I prevent Workspaces from being automatically deleted.
|
|
Kirill, Thanks for system property and the URL for the settings. this is a very useful page. Greg. > -----Original Message----- > From: Kirill Evstigneev @spera [mailto:[hidden email]] > Sent: Saturday, December 12, 2009 1:33 AM > To: [hidden email] > Subject: RE: How do I prevent Workspaces from being automatically deleted. > > > Workspace clean-up can be disabled by setting the system property > hudson.model.WorkspaceCleanupThread.disabled=true > (http://wiki.hudson- > ci.org/display/HUDSON/Features+controlled+by+system+properties) > > But AFAIK a workspace is deleted after 30 days since last use. Though > there > were some weakness in "last use" calculation logic. At least it > work > for Matrix type projects and, yes, there were problems with custom > workspaces. > [stuff deleted] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: How do I prevent Workspaces from being automatically deleted.
|
In reply to this post by Greg Moore-5
Is there a way to configure longer keep time for a workspace (job)?
|
Re: How do I prevent Workspaces from being automatically deleted.
|
You can use Discard Old builds in Job Config Page.
There are other interesting Plugins to do the same as Well. For Example, Create Job Advanced Plugin thanks,
Krishna Chaitanya On Thu, Aug 23, 2012 at 10:46 AM, W. Grace Lee <[hidden email]> wrote: Is there a way to configure longer keep time for a workspace (job)? |
| Powered by Nabble | Edit this page |