[Buildbot-devel] How to suppress "rm -rf" at start of SVN update operation???
Peter Barada
peter.barada at logicpd.com
Sat Jul 2 11:57:52 UTC 2011
On 07/01/2011 05:20 PM, Amber Yust wrote:
> That sounds like for some reason the source step fell back to a
> Clobber-mode update. Is this happening on every build, even after a
> successful one?
Yes it is. And something else bizarre happened. I have two
repositories, call it system_repo and kernel_repo. I setup SVNpollers
for both setting projects to their respective names. Then I setup a
Scheduler using a ChangeFilter(project=[ "system_repo", "kernel_repo"])
to force a build if either the system or kernel repositories changed
(the kernel_repo is checked out as part of building the system_repo),
and on updating kernel_repo, buildbot detected the change, and tried to
check out the kernel_repo in the build directory even though the
factory SVN step explicitly refers to the system_repo.
I'm wondering if my buildbot installation is hosed. How do I
_completely_ wipe out buildbot and reinstall to see if that fixes things...
>
> ~Amber
>
> On Fri, Jul 1, 2011 at 1:58 PM, Peter Barada <peter.barada at logicpd.com
> <mailto:peter.barada at logicpd.com>> wrote:
>
> How do I suppress the "rm -rf build" that is done at the start of a
> job? This wasn't a problem when I ran buildbot-0.8.3p1 (w.o
> ChangeFilters), but when I upgraded to 0.8.4 (Twisted 10.1.0) it
> starst
> off with a "rm -rf .../build" to wipe out the build tree. Here's (a
> snippet of) what I have for master.cfg:
>
> LTIB_REPO_20091102='svn+ssh://LOGIC+peterb@cvs.logicpd.com/cvs/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102
> <http://LOGIC+peterb@cvs.logicpd.com/cvs/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102>'
> svn_poller = SVNPoller(
> svnurl=LTIB_REPO_20091102,
> pollinterval=5*60, # seconds
> histmax=10,
> svnbin='/usr/bin/svn',
> project='repo-ltib-20091102',
> )
> c['schedulers'].append(Scheduler(name="LTIB-20091102",
>
> change_filter=ChangeFilter(project='repo-ltib-20091102'),
> treeStableTimer=2*60,
>
> builderNames=["buildbot-LTIB-20091102"]))
>
> f1 = factory.BuildFactory()
> f1.addStep(SVN(mode='update', baseURL=LTIB_REPO_20091102,
> defaultBranch=''))
> f1.addStep(Compile(command=["./ltib", "-b", "--preconfig",
> "config/platform/omap3logic/defconfig"],
> haltOnFailure=True))
>
> b1 = {'name': "buildbot-LTIB-20091102",
> 'slavename': "example-slave",
> 'builddir': "ltib-20091102",
> 'factory': f1,
> }
> c['builders'] = [b1]
>
> The start of the update log file looks like:
>
> starting svn operation
> rm -rf /home/peter/work/logic/buildbot/ltib-slave/ltib-OMAPPSP/build
> in dir /home/peter/work/logic/buildbot/ltib-slave/ltib-OMAPPSP
> (timeout 1200 secs)
> watching logfiles {}
> argv: ['rm', '-rf',
> '/home/peter/work/logic/buildbot/ltib-slave/ltib-OMAPPSP/build']
> environment:
>
>
> I don't want to remove the ltib-OMAPPSP/build tree since inside of the
> tree is a LInux root filesystem (which "rm -rf" fails due to root
> owned
> files/directories in it) and also it takes a looong time to
> rebuild from
> scratch. I tried adding a "always_purge=False" to the SVN(), but
> it has
> no effect.
>
> Any suggestions are most appreciated!
>
>
> --
> Peter Barada
> peter.barada at logicpd.com <mailto:peter.barada at logicpd.com>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously
> valuable.
> Why? It contains a definitive record of application performance,
> security
> threats, fraudulent activity, and more. Splunk takes this data and
> makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> <mailto:Buildbot-devel at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel
>
>
--
Peter Barada
peter.barada at logicpd.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20110702/c283a61a/attachment.html>
More information about the devel
mailing list