| Missing SVN Update on materialized plugins [message #1132800] |
Fri, 11 October 2013 07:53  |
Eclipse User |
|
|
|
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.
Found several posts about this, but none clearly stated how to solve this (the advisorNode technique does not seem to work for us either)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=286284
(Bucky Book does not document the above feature, AFAIK)
http://www.eclipse.org/forums/index.php?t=msg&th=202459&start=0&S=7ca5960ff6869b921d186b4c8ef28222
My workaround used to be deleting buckminster.output, but that makes the next build take much longer, as everything needs to be materialised again.
Now I created a script that executes "svn update" over plugins resolved through SVN.
cd %Workspace%\plugins
for /d /r %%i in (*com.opencanarias*) do @svn up %%i
cd %Workspace%\features
for /d /r %%i in (*com.opencanarias*) do @svn up %%i
Is there any way to tell bucky that it should update plugins resolved through svn before building?
I'm using the 4.2 bucky release
Thank you!
Víctor Roldán
|
|
|
|
|
| Re: Missing SVN Update on materialized plugins [message #1225704 is a reply to message #1132800] |
Mon, 30 December 2013 09:53  |
| Eclipse User |
|
|
|
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)
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=286284
> (Bucky Book does not document the above feature, AFAIK)
>
> http://www.eclipse.org/forums/index.php?t=msg&th=202459&start=0&S=7ca5960ff6869b921d186b4c8ef28222
>
>
> 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.
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
|
|
|
Powered by
FUDForum. Page generated in 0.26768 seconds
Home
Hope someone from the bucky team can clarify this.