For now I'll do the work in the scripts to add branch-1 as an option in
the same way other branches work now. Once we get that in place we can
start working on fancier stuff. I'm guessing someone with access rights
to cloudera's instance on ec2 needs to configure the new build. I don't
seem to have permission for that as there's no new build button on my page.
Alan.
Thejas Nair <mailto:thejas.n...@gmail.com>
June 3, 2015 at 15:24
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 <
Vinod Kumar Vavilapalli <mailto:vino...@hortonworks.com>
June 3, 2015 at 12:17
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
<mailto:alanfga...@gmail.com>> wrote:
Alan Gates <mailto:alanfga...@gmail.com>
June 3, 2015 at 9:16
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
