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 <mailto: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 <mailto: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 <mailto: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.
