| Conditionally using a local Git clone [message #1008078] |
Fri, 08 February 2013 19:18  |
 Terran Gilman
Messages: 67
Registered: July 2009 |
Member |
|
|
I use Buckminster for both workspace generation within the IDE as well as automated builds using Hudson. I'm in the process of migrating from SVN to Git. I'd like to be able to set up a local clone of a Git repository prior to workspace generation and then use that repo for the materialization process, but during automated builds I'd like buckminster to handle the cloning and repo management for me. Any suggestions on how to set this up?
To clarify: what I want is to be able to have separate locations for the local repository depending on which configuration is being used. Clone is external to workspace for IDE while located in the workspace root under Hudson.
[Updated on: Fri, 08 February 2013 20:55] Report message to a moderator |
|
|
| Re: Conditionally using a local Git clone [message #1008113 is a reply to message #1008078] |
Sat, 09 February 2013 08:00  |
|
On 02/08/2013 08:18 PM, Terran Gilman wrote:
> I use Buckminster for both workspace generation within the IDE as well
> as automated builds using Hudson. I'm in the process of migrating from
> SVN to Git. I'd like to be able to set up a local clone of a Git
> repository prior to workspace generation and then use that repo for the
> materialization process, but during automated builds I'd like
> buckminster to handle the cloning and repo management for me. Any
> suggestions on how to set this up?
Did you mean
'I'd like Hudson to handle the cloning and repo management for me.' ?
^^^^^^
If you mean that in hudson you do not want to clone the repository
(because hudson job already does that), I could suggest two alternative
strategies (at least they work for me):
1. when using the git provider you should use a property for the path
where the repository is cloned, with a default value, e.g.,
<rm:property key="git.clone.dir" value="${user.home}/git/myrepo" />
in the hudson job, you should override that by passing an explicit value
for that property specifying the path of the already cloned repository,
which usually is $WORKSPACE
2. in the search path for local sources you put two providers: the first
one is readerType="local" thus it reads from the local filesystem, the
second one is readerType="git". Since the first one is tried first, if
it succeeds it won't perform any git operations. For instance, (taken
from
http://sourceforge.net/p/buckyexamples/bucky-mail-rcp/ci/master/tree/org.eclipse.buckminster.examples.rcp.mail.releng/build.rmap
)
<rm:searchPath name="localsources">
<rm:provider componentTypes="eclipse.feature,osgi.bundle,buckminster"
readerType="local" mutable="false">
<rm:uri format="{0}/{1}">
<bc:propertyRef key="projects.location" />
<bc:propertyRef key="buckminster.component" />
</rm:uri>
</rm:provider>
<rm:provider componentTypes="osgi.bundle,eclipse.feature,buckminster"
readerType="git">
<rm:property key="git.remote.uri"
value="git://git.code.sf.net/p/buckyexamples/bucky-mail-rcp" />
<rm:property key="git.auto.fetch" value="true" />
<rm:uri format="{0},{1}">
<bc:propertyRef key="git.clone.dir" />
<bc:propertyRef key="buckminster.component" />
</rm:uri>
</rm:provider>
</rm:searchPath>
also in this case you should use a property for the destination of the
git clone so that you can still override that property both in IDE
materializations and in headless builds...
hope this helps
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
Powered by
FUDForum. Page generated in 0.02545 seconds
] 
Search
Help
Register
Login
Home
