Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 351740

Summary:	Specify project specific tags/branches with fetchTag
Product:	[Eclipse Project] PDE	Reporter:	Andrew Niefer <aniefer>
Component:	Build	Assignee:	pde-build-inbox <pde-build-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	kim.moir, pwebster
Version:	3.7
Target Milestone:	3.8 M1
Hardware:	PC
OS:	Linux
Whiteboard:

Description Andrew Niefer

2011-07-11 14:14:58 EDT

When running a nightly build from CVS releng will specify
fetchTag=HEAD
to use HEAD instead of the tags recorded in map files.

We also support SCM specific entries when more than one SCM is used:
fetchTag=CVS=HEAD,GIT=master

However, in the case of Git, it may be that some teams want to use some branch other than master for nightly builds and then only promote to master when stable.

Comment 1 Andrew Niefer

2011-07-11 14:29:01 EDT

The best way I can think of to do this is to annotate the "fetchTag" property, with per-project settings:

fetchTag=CVS=HEAD,GIT=master,org.eclipse.pde.build=PDE_BRANCH

This can be achieved within PDE/Build without API changes around the fetch factories.  

The drawback being that teams would need to work with releng to set appropriate values on the fetchTag property.  And that the property value itself can become a bit unwieldy when there are many projects.

Comment 2 Paul Webster

2011-07-11 14:50:37 EDT

I know in our ui.map case, it's over 30 projects that would have to specify R3_development (instead of master).

PW

Comment 3 Andrew Niefer

2011-07-11 15:15:55 EDT

The alternative is to have individual projects specify something in their map files.  This bug would then need to move to egit and be handled by the git fetch factory.


plugin@org.eclipse.foo=GIT,tag=v20110711,unstable=BRANCH

The problem here is how to define the interaction between fetchTag overrides, the normal tag and the unstable branch.

Comment 4 Paul Webster

2011-07-12 13:20:18 EDT

(In reply to comment #2)
> I know in our ui.map case, it's over 30 projects that would have to specify
> R3_development (instead of master).


what about annotating the GIT value?

fetchTag=CVS=HEAD,GIT=master;git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git=R3_development

PW

Comment 5 Andrew Niefer

2011-07-12 14:06:37 EDT

(In reply to comment #4)
> what about annotating the GIT value?
> 
> fetchTag=CVS=HEAD,GIT=master;git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git=R3_development
> 
> PW

I like this better than comment #3, it might be the best way forward.

This would need to be handled in the egit fetch factory.  On the PDE/Build side we know project + SCM provider, here the information is tied to the repository which is not something PDEBuild knows about.

Comment 6 Paul Webster

2011-07-12 19:00:40 EDT

(In reply to comment #5)
> (In reply to comment #4)
> > what about annotating the GIT value?
> > 
> > fetchTag=CVS=HEAD,GIT=master;git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git=R3_development

Which part parses the GIT=... ?  If that could be passed to the git fetch factory when in this override mode it could probably do the right thing

PW

Comment 7 Andrew Niefer

2011-07-13 11:13:24 EDT

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > what about annotating the GIT value?
> > > 
> > > fetchTag=CVS=HEAD,GIT=master;git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git=R3_development
> 
> Which part parses the GIT=... ?  If that could be passed to the git fetch
> factory when in this override mode it could probably do the right thing
> 
> PW

PDE parses the fetchTag, it will have to separate out the annotations so that the fetch factory sees a map:
GIT = master
git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git = R3_development

This way factories that support this new feature can check for a repo specific override, and factories that don't change still work with the old SCM->override format.
Annotations on the SCM value allow the scenario of two different SCMs having overrides for repos that happen to be named the same.  (if say two SCM systems coexisted at the same http address?).  

In general, these annotations will be opaque to PDE/Build and it is up to the fetch factory to check for and interpret them.

Comment 8 Andrew Niefer

2011-07-28 11:39:41 EDT

I have released initial support for this.

The fetchTag format is
fetchTag = REPO-ID=tag[;key=value]* [, REPO-ID=tag[;key=value]* ]*

We associate with each REPO-ID a set of key=value properties.  During fetch script generation, IFetchFactory#parseMapFileEntry receives a Properties object containing the top level REPO-ID=tag pairs as well its repo specific key=value properties.

Example:
fetchTag=CVS=HEAD,GIT=master;platform.ui=development,SVN=trunk;platform.ui=fixes

The property sets seen by each fetch factory are as follows:
  CVS               GIT                         SVN
CVS=HEAD         CVS=HEAD                   CVS=HEAD
GIT=master       GIT=master                 GIT=MASTER
SVN=trunk        SVN=trunk                  SVN=trunk
                 platform.ui=development    platform.ui=fixes

Factories receive the same top level properties they got before this enhancement, plus the additional factory specific annotations.