|Re: Missing SVN Update on materialized plugins [message #1225704 is a reply to message #1132800]
||Mon, 30 December 2013 14:53
| Lorenzo Bettini
Registered: July 2009
On 11/10/2013 13:53, Victor Roldan Betancort wrote:|
> Hello all,
> I'm deciding to write on something that's happening on our builds long
> time ago but never managed to fix: Buckminster resolves some plugins
> through SVN (a convenien searchPath is defined in our RMAP). So far so
> good. However, next time we launch a build, Buckminster finds the plugin
> already materialised, but does not consider the fact that there may be
> new commits in SVN affecting that plugin. The Result: we get a build
> with an old version of the plugin.
I guess you're using Jenkins or Hudson, right?
The auto update from svn/git/cvs could be done by the Jenkins job
configuration ("Source Code Management" section); this is
straightforward if you fetch from a single source repository...
> Found several posts about this, but none clearly stated how to solve
> this (the advisorNode technique does not seem to work for us either)
> (Bucky Book does not document the above feature, AFAIK)
> My workaround used to be deleting buckminster.output, but that makes the
> next build take much longer, as everything needs to be materialised again.
does it take longer because a brand new svn checkout is performed, or
because the workspace needs to be materialized from scratch?
In the latter case, I've always thought that it is better to always
perform a brand new workspace materialization in a headless build... at
least that's what I saw in most examples (and it never gave me problems
in all my builds; on the contrary trying to do an incremental workspace
materialization always gave me troubles)... of course you can avoid
materializing the target platform itself over and over again, I was only
referring to materialization of projects in the workspace.
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
Powered by FUDForum
. Page generated in 0.03726 seconds