Some information here - see under Integration in the first section:
http://wiki.eclipse.org/Common_Build_Infrastructure/Build_Types
I also have a shell script for searching CVS (not SVN) for changes,
tagging, and checking in changes to map file(s). It has not been tested
w/ Athena builds (and also not ported over to use Athena &
build.eclipse.org file path conventions) but should be serviceable if
you want to try it.
http://dev.eclipse.org/viewcvs/index.cgi/releng-common/tools/org.eclipse.releng.tools.tagandrelease/?root=Modeling_Project
If it works, let me know. If you change it and make it better, please
don't hesitate to attach it to a Technology > Dash Athena bug.
Thanks!
Nick
Quentin GLINEUR wrote:
Hi Nick,
Thanks a lot for the information. It might look simple but it helps me a
lot.
One remaining question: As the Integration build seem to be commonly
done on a weekly basis, I guess that the tagging is automated. If yes, how?
Regards,
Quentin
2009/10/23 Nick Boldt <nickbo...@gmail.com <mailto:nickbo...@gmail.com>>
1) What is the interest of using a map file for the Integration
build? (I understand the tag for the stable and release builds
but not for the integration.)
Many projects choose to use `-forceContextQualifier -fetchTag HEAD`
to override the tags in the maps for their Nightly (unstable) builds
and override the qualifiers on their features/plugins w/ the build's
timestamp. Why? It's a convenient way of quickly verifying that the
latest in CVS will compile and test OK.
All other builds (I, M, S, R) ought to be built from tagged maps for
reproduceability and stability: only tagged & released code
therefore makes its way into an Integration, Maintenance, Stable or
Release build.
Of course this is just a guideline; you may run your project any way
you see fit provided that you follow the Eclipse.org project rules
and don't violate IP policy. Not everyone likes maps; some prefer to
always build from trunk/HEAD and only tag AFTER a successful build.
As with all things, YMMV. :)
2) In all examples of build.properties I have seen, there are
only dependencies to stable builds but never to snapshot.
Isn't it a common practice or is it usually defined elsewhere or
did I miss them?
Here's one build job that depends on the output of another using
SNAPSHOT URLs from Hudson:
https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-m2t-xpand-0.7/ws/build/org.eclipse.xpand.releng/build.properties
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.m2t/org.eclipse.xpand.releng/build.properties?root=Modeling_Project&view=markup
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.m2t/org.eclipse.xpand.releng/build.properties?root=Modeling_Project&view=markup>
As you can see, that build depends on MWE, and points directly at
its lastSuccessfulBuild:
https://build.eclipse.org/hudson/job/cbi-emft-mwe-0.7/lastSuccessfulBuild/artifact/snapshot/emft-mwe-SDK-incubation-N-Snapshot.zip
Cheers,
--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
