Home » Archived » Buckminster » How to configure release builds with precompiled components
|
| Re: How to configure release builds with precompiled components [message #550860 is a reply to message #550804] |
Wed, 04 August 2010 13:23   |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
You can do this by:
- having a property that denotes "buildtype" (i.e. something like
'release', 'milestone' 'nightly' etc.) and use this to provide routing
in the RMAP.
- This property should have a default (say 'release') in the RMAP
- Use advisor nodes in the CQUERY to set "buildtype" per component (i.e.
on components where you do not want the default).
This gives you the ability to fully control (in a symbolic fashion) the
location from which each component is resolved.
A scheme like "build from release, fallback to milestone or nightly as
required" is then easily supported. If you want ability to 'cherry-pick'
you need to use the identity of the release/nightly instead of a simple
symbolic name. With a policy on how p2 repositories are
named/structured, it should not be all that difficult (without a
structure and naming policy you end up with a list of every possible
repo in your RMAP which is not very good).
I hope that helps. Fire away with questions if something is unclear....
Regards
- henrik
On 8/4/10 1:55 PM, Peter Kullmann wrote:
> Hi,
> I'm trying to set up our product builds for nightly, maintenance,
> integration and release builds.
>
> Suppose I have two components, say A and B, and B depends on A. I have
> set up nightly builds and release builds for A and I can get the results
> in form of p2 repositories. Something like
> - nightly/A/lastSuccessful/site.p2
> - releases/A/R20100433/site.p2
>
> Now, I want to build B. For B I need some source code which is available
> from a source code repository via a PDE map file. But B also needs A as
> a dependency and I have set up my rmap for B to get A from
> nightly/A/lastSuccessful/site.p2. This works very well.
>
> So here comes the difficult part (for me, anyway): How do I describe and
> build a named release of B? The first step is to fix the source code for
> B which is easy using the PDE map. But how do I specify the version of
> A? I can think of many ways:
>
> 1. Let the rmap of B be one of the source projects that are fetched via
> the map file. And in the map file encode the version of A explicitely,
> like releases/A/R20100433/site.p2.
>
> 2. PDE map files can also reference p2 sites. Theoretically I could
> enter the specific site for A into the map file. But I don't know how to
> redirect to this within the rmap.
>
> 3. Use explicit versions in one of the features that actually pulls A
> and use a composite repository for A's releases so that p2 can get the
> right version. This seems to be difficult because one would have to
> change versions of the included features a lot.
>
> What's the "best" way to proceed here? Any hints or pointers are greatly
> appreciated.
>
> Regards
> Peter
|
|
|
| Re: How to configure release builds with precompiled components [message #550861 is a reply to message #550860] |
Wed, 04 August 2010 14:04 |
Peter Kullmann
Messages: 240
Registered: July 2009 |
Senior Member |
|
|
Hi Henrik,
Thanks for the advice.
I think I want to be able to 'cherry-pick' as you call it. For my
understanding of a named release, every part of the product should be
explicitly identified (as is the case with a bom produced by
buckminster). So, given the name of the release, there must be a way to
identify the exact version of the source code (easy via PDE maps) and to
identify the version of the (binary) pre-requisite(s). I don't see how a
naming policy can help in this case.
For example release XYZ consists of source code for the component B with
tag R_XYZ and of version 1.7.2.R207 of component A. The choice of
1.7.2.R207 may be deliberate, it doesn't necessarily mean that it was
the latest release or the latest in the branch or something like that.
So, I need a place to write this down. But where?
You mention advisor nodes in CQUERYs. This brings me to an idea: One
could use a versioned CQUERY, for instance in the same releng project
where the map file for the source code of B resides, and encode the
exact version of A in an advisor node. This information could then be
translated into a p2 repo URL.
Regards,
Peter
Henrik Lindberg schrieb:
> You can do this by:
> - having a property that denotes "buildtype" (i.e. something like
> 'release', 'milestone' 'nightly' etc.) and use this to provide routing
> in the RMAP.
> - This property should have a default (say 'release') in the RMAP
> - Use advisor nodes in the CQUERY to set "buildtype" per component (i.e.
> on components where you do not want the default).
>
> This gives you the ability to fully control (in a symbolic fashion) the
> location from which each component is resolved.
>
> A scheme like "build from release, fallback to milestone or nightly as
> required" is then easily supported. If you want ability to 'cherry-pick'
> you need to use the identity of the release/nightly instead of a simple
> symbolic name. With a policy on how p2 repositories are
> named/structured, it should not be all that difficult (without a
> structure and naming policy you end up with a list of every possible
> repo in your RMAP which is not very good).
>
> I hope that helps. Fire away with questions if something is unclear....
>
> Regards
> - henrik
>
> On 8/4/10 1:55 PM, Peter Kullmann wrote:
>> Hi,
>> I'm trying to set up our product builds for nightly, maintenance,
>> integration and release builds.
>>
>> Suppose I have two components, say A and B, and B depends on A. I have
>> set up nightly builds and release builds for A and I can get the results
>> in form of p2 repositories. Something like
>> - nightly/A/lastSuccessful/site.p2
>> - releases/A/R20100433/site.p2
>>
>> Now, I want to build B. For B I need some source code which is available
>> from a source code repository via a PDE map file. But B also needs A as
>> a dependency and I have set up my rmap for B to get A from
>> nightly/A/lastSuccessful/site.p2. This works very well.
>>
>> So here comes the difficult part (for me, anyway): How do I describe and
>> build a named release of B? The first step is to fix the source code for
>> B which is easy using the PDE map. But how do I specify the version of
>> A? I can think of many ways:
>>
>> 1. Let the rmap of B be one of the source projects that are fetched via
>> the map file. And in the map file encode the version of A explicitely,
>> like releases/A/R20100433/site.p2.
>>
>> 2. PDE map files can also reference p2 sites. Theoretically I could
>> enter the specific site for A into the map file. But I don't know how to
>> redirect to this within the rmap.
>>
>> 3. Use explicit versions in one of the features that actually pulls A
>> and use a composite repository for A's releases so that p2 can get the
>> right version. This seems to be difficult because one would have to
>> change versions of the included features a lot.
>>
>> What's the "best" way to proceed here? Any hints or pointers are greatly
>> appreciated.
>>
>> Regards
>> Peter
>
|
|
|
| Re: How to configure release builds with precompiled components [message #551140 is a reply to message #550861] |
Thu, 05 August 2010 12:03 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
A naming policy only helps by not having to list every possible repo.
You probably want the possibility to state "give me A of the version
published in latest milestone/release/nightly" as well as being able to
pick a specific version of A when so required.
The query is the place to state this (and do check it in).
The RMAP should be written to support getting everything required by the
queries. When there is a good naming policy one rarely has to touch the
RMAP.
Did that make it clearer?
- henrik
Peter Kullmann <p.kullmann@arenae.ch> wrote:
> Hi Henrik,
> Thanks for the advice.
>
> I think I want to be able to 'cherry-pick' as you call it. For my
> understanding of a named release, every part of the product should be
> explicitly identified (as is the case with a bom produced by
> buckminster). So, given the name of the release, there must be a way
> to identify the exact version of the source code (easy via PDE maps)
> and to identify the version of the (binary) pre-requisite(s). I don't
> see how a naming policy can help in this case.
>
> For example release XYZ consists of source code for the component B
> with tag R_XYZ and of version 1.7.2.R207 of component A. The choice of
> 1.7.2.R207 may be deliberate, it doesn't necessarily mean that it was
> the latest release or the latest in the branch or something like that.
> So, I need a place to write this down. But where?
>
> You mention advisor nodes in CQUERYs. This brings me to an idea: One
> could use a versioned CQUERY, for instance in the same releng project
> where the map file for the source code of B resides, and encode the
> exact version of A in an advisor node. This information could then be
> translated into a p2 repo URL.
>
> Regards,
> Peter
>
> Henrik Lindberg schrieb:
>> You can do this by:
>> - having a property that denotes "buildtype" (i.e. something like >
> > 'release', 'milestone' 'nightly' etc.) and use this to provide
> > routing > in the RMAP.
>> - This property should have a default (say 'release') in the RMAP
>> - Use advisor nodes in the CQUERY to set "buildtype" per component
> > (i.e. > on components where you do not want the default).
>>> This gives you the ability to fully control (in a symbolic fashion)
> > > the > location from which each component is resolved.
>>> A scheme like "build from release, fallback to milestone or nightly
> > > as > required" is then easily supported. If you want ability to
> > > 'cherry-pick' > you need to use the identity of the
> > > release/nightly instead of a simple > symbolic name. With a policy
> > > on how p2 repositories are > named/structured, it should not be
> > > all that difficult (without a > structure and naming policy you
> > > end up with a list of every possible > repo in your RMAP which is
> > > not very good).
>>> I hope that helps. Fire away with questions if something is
> > > unclear....
>>> Regards
>> - henrik
>>> On 8/4/10 1:55 PM, Peter Kullmann wrote:
>>> Hi,
>>> I'm trying to set up our product builds for nightly, maintenance,
>>> integration and release builds.
>>>
>>> Suppose I have two components, say A and B, and B depends on A. I
> > > have
>>> set up nightly builds and release builds for A and I can get the
> > > results
>>> in form of p2 repositories. Something like
>>> - nightly/A/lastSuccessful/site.p2
>>> - releases/A/R20100433/site.p2
>>>
>>> Now, I want to build B. For B I need some source code which is
> > > available
>>> from a source code repository via a PDE map file. But B also needs A
> > > as
>>> a dependency and I have set up my rmap for B to get A from
>>> nightly/A/lastSuccessful/site.p2. This works very well.
>>>
>>> So here comes the difficult part (for me, anyway): How do I describe
> > > and
>>> build a named release of B? The first step is to fix the source code
> > > for
>>> B which is easy using the PDE map. But how do I specify the version
> > > of
>>> A? I can think of many ways:
>>>
>>> 1. Let the rmap of B be one of the source projects that are fetched
> > > via
>>> the map file. And in the map file encode the version of A
> > > explicitely,
>>> like releases/A/R20100433/site.p2.
>>>
>>> 2. PDE map files can also reference p2 sites. Theoretically I could
>>> enter the specific site for A into the map file. But I don't know
> > > how to
>>> redirect to this within the rmap.
>>>
>>> 3. Use explicit versions in one of the features that actually pulls
> > > A
>>> and use a composite repository for A's releases so that p2 can get
> > > the
>>> right version. This seems to be difficult because one would have to
>>> change versions of the included features a lot.
>>>
>>> What's the "best" way to proceed here? Any hints or pointers are
> > > greatly
>>> appreciated.
>>>
>>> Regards
>>> Peter
>>
--
- henrik
|
|
|
Goto Forum:
Current Time: Fri Apr 19 06:32:49 GMT 2024
Powered by FUDForum. Page generated in 0.01859 seconds |
] 
Search
Help
Register
Login
Home
