Do the hadoop jenkins scripts use some regex match on 'target version' to
identify the branch to be used ?


On Wed, Jun 3, 2015 at 12:17 PM, Vinod Kumar Vavilapalli <
vino...@hortonworks.com> wrote:

>  Hadoop uses a "Target Version" field. Not sure if this was done for all
> projects.
>
>  +Vinod
>
>  On Jun 3, 2015, at 9:16 AM, Alan Gates <alanfga...@gmail.com> wrote:
>
>  I don't think using Affects Version will work because it is used to list
> which versions of Hive the bug affects, unless you're proposing being able
> to parse affected version into branch (ie 1.3.0 => branch-1).
>
> I like the idea of customizing JIRA, though I don't know how hard it is.
>
> We could also use the labels field.  It would run against master by
> default and you could also add a label to run against an additional
> branch.  It would have to find a patch matching that branch in order to run.
>
> Alan.
>
>    Thejas Nair <thejas.n...@gmail.com>
> June 3, 2015 at 7:51
>   Thanks for the insights Sergio!
> Using 'Affects Version' sounds like a good idea. However, for the case
> where it needs to be executed against both branch-1 and master, I
> think it would be more intuitive to use
> "Affects Version/s: branch-master branch-1 " , as the version
> number in master branch will keep increasing.
>
> We might be able to request for a custom field in jira (say "Test
> branches") for this as well. But we could probably start with the
> 'Affects Version' approach.
>    Sergio Pena <sergio.p...@cloudera.com>
> June 2, 2015 at 15:03
>   Hi Alan,
>
> Currently, the test system executes tests on a specific branch only if
> there is a Jenkins job assigned to it, like trunk or spark. Any other
> branch will not work. We will need to create a job for branch-1, modify the
> jenkins-submit-build.sh to add the new profile, and add a new properties
> file to the Jenkins instance that contains branch information.
>
> This is a little tedious for every branch we create.
>
> Also, I don't think the test system will grab two patches (branch-1 &
> master) to execute the tests on different branches. It will get the latest
> one you uploaded.
>
> What about if we use the 'Affects Version/s' field of the ticket to specify
> which branches the patch needs to be executed? Or as you said, use hints on
> the comments.
>
> For instance:
> - Affects Version/s: branch-1 # Tests on branch-1 only
> - Affects Version/s: 2.0.0 branch-1 # Tests on branch-1 and master
> - Affects Version/s: branch-spark # Tests on branch-spark only
>
> If we use 'branch-xxx' as a naming convention for our branches, then we can
> detect the branch from the ticket details. And if x.x.x version is
> specified, then just execute them from master.
>
> Also, branch-1 would need to be executed with MR1, right? Then the patch
> file would need to be named 'HIVE-XXXX-mr1.patch' so that it uses the MR1
> environment.
>
> Right now the code that parses this info is on process_jira function on
> 'jenkins-common.sh', and it is called by 'jenkins-submit-build.sh'. We can
> parse different branches there, and let jenkins-submit-build.sh call the
> correct job with specific branch details.
>
> Any other ideas?
>
> - Sergio
>
>
>
>    Alan Gates <alanfga...@gmail.com>
> June 1, 2015 at 16:19
>   Based on our discussion and vote last week I'm working on creating
> branch-1.   I plan to make the branch tomorrow.  If anyone has a large
> commit they don't want to have to commit twice and they are close to
> committing it let me know so I can make sure it gets in before I branch.
>
> I'll also be updating
> https://cwiki.apache.org/confluence/display/Hive/HowToContribute to
> clarify how to handle feature and bug fix patches on master and branch-1.
>
> Also, we will need to make sure patches can be tested against master and
> branch-1.  If I understand correctly the test system today will run a patch
> against a branch instead of master if the patch is named with the branch
> name.  There are a couple of issues with this.  One, people will often want
> to submit two versions of patches and have them both tested (one against
> master and one against branch-1) rather than one or the other.  The second
> is we will want a way for one patch to be tested against both when
> appropriate.  The first case could be handled by the system picking up both
> branch-1 and master patches and running them automatically.  The second
> could be handled by hints in the comments so the system needs to run both.
> I'm open to other suggestions as well.  Can someone familiar with the
> testing code point to where I'd look to see what it would take to make this
> work?
>
> Alan.
>
>
>

Reply via email to