[dash-dev] Automated Tagging & Releasing of weekly changes to map(s) (wa

[Nick Boldt <nickboldt@xxxxxxxxx>]

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 <nickboldt@xxxxxxxxx <mailto:nickboldt@xxxxxxxxx>>
>
>         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