| Re: [buckminster-dev] tips on headless buckminster in CI environment? [message #9623] |
Sat, 15 March 2008 10:56 |
|
Todd_Lee@amis.com wrote:
> Many thanks to the community at large (especially Thomas & Adrian) whose
> help has got us to the point of resolving a workspace headlessly :D
> As you can probably tell from the deluge of posts to this forum, we're
> currently on our way from 0 to 60 in getting an autobuild system up and
> running, so thanks in advance for your patience!
>
> I'm wondering at this point if anyone would have any tips as to best
> practices using buckminster for headless builds? Looking to those who've
> successfully implemented similar systems, I guess I'm asking, "what do you
> wish someone told you when you were starting out that would have saved some
> bruising on your forehead..."?
>
> We're building an eclipse IDE based product which uses alot of external
> stuff. We're automating using a Pulse CI build server and looking to
> buckminster to solve our 'middleware' issues (resolving/materializing
> workspaces and dependencies). The current build is PDE based.
>
> Specific questions:
> 1) what's the best entry point for buckminster in a real-world build setup
> - standalone or ant integration?
>
In my opinion, you have two entry-points. One that is configuring your
build system and one that executes tasks in that build system.
Configuring:
The Buckminster product is a very thin headless Eclipse Runtime
executable. It cannot do much more then configure itself. The intention
is that an organization maintains a pre-configured Buckminster that is
suitable for their needs, i.e. if you work with OSGi bundles and uses
SVN repositories, you would configure your Buckminster with the pde and
svn support.
The first entry-point in my opinion, is the script that configures this
Buckminster runtime and publishes it at some shared place where everyone
that needs it can find it. You only need to rebuild this configuration
when you need a new version of some feature in Buckminster. This
build-tool would also contain an ant-script with the Buckminster macro.
Executing:
This entry-point is an ant-script that uses the configured Buckminster.
The typical flow is to first a CQUERY and then perform a series of
perform commands on the resulting workspace.
> 2) once the workspace is materialized, is buckminster's role finished? ie -
> is it best to just hand off to ant from there and execute the build or is
> it better to use buckminster's 'perform' command to execute actions to
> accomplish build tasks?
>
Buckminsters role is to orchestrate the build. After a materialization
Buckminster knows where all components reside and how they fit together.
Many of the ant-tasks that are provided with Buckminster are tailor made
to make use of the environment that the Buckminster ant actor propagates
to them.
> 3) artifacts/cacheing - cleaning vs. retention - given the large amount of
> caching that buckminster seems to use, is there any concern about clean up
> post-build? Do people clear caches or just let them accumulate. And related
> to products of buckminster, is there anything that you'd really suggest
> keeping for posterity (obviously the bomfile comes to mind...)
>
In a headless scenario, I think that a complete clean of the
"${buckminster.output.root}" is the preferred way. Although Buckminster
keeps track of what to rebuild, it cannot know about artifacts that used
to be there but has since been removed (if you remove a project for
instance, old builds of that project may remain).
> 4) specifically to those using pde builds - any tips/pitfalls with
> buckminster?
>
>
Make sure you define the ${buckminster.output.root}. The default folder
is probably not what you want.
Use OSGi manifests in all plug-ins
Make sure all bundles have a build.properties with correctly defined
src/bin and bin.includes
Using SVN, the revision number is great to use in the version qualifier.
Using CVS, a timestamp isn't half bad. Buckminster is able to compute
the feature qualifier based on included features and plug-ins. You can
use one of two settings:
for SVN
qualifier.replacement.*=generator:lastRevision
generator.lastRevision.format=r{0,number,00000}
for CVS
qualifier.replacement.*=generator:lastModified
generator.lastModified.format='v'yyyyMMdd-HHmm
> Any suggestions are certainly appreciated!
>
> Also, as an aside - any plans to include tutorials on this subject on the
> wiki? Seems like a good candidate for a walk through. The documentation is
> a big help and I know for me, it would be great to see buckminster at work
> in the context of a sample build from beginning to end to demonstrate full
> scope.
>
>
Yes. We have plans to do this. In my opinion, the task of providing such
content it's way overdue. Any help in making it happen is greatly
appreciated.
Regards,
Thomas Hallgren
|
|
|
Powered by
FUDForum. Page generated in 0.01529 seconds
] 
Search
Help
Register
Login
Home
