Jenkins will not recognize inter-dependencies of multiple jiras and try to pull in dependent patches. You'd need to wait for the dependent patch to get reviewed and committed first, and then trigger the Jenkins run for the second patch.
Sometimes people like to get a "preview" Jenkins run to see an early health check instead of waiting for the commit. You can do that by uploading a consolidated patch file to the second jira that includes all of the changes and applies cleanly to trunk. After the first patch gets committed, you would once again upload a new patch file on the second jira containing just the second set of changes. (The final Jenkins run should be done on what is actually getting committed within the scope of that second jira.) Thanks for the patches, Martin! --Chris Nauroth On 7/22/15, 6:29 AM, "Martin Walsh" <martin.wa...@oracle.com> wrote: >I am working on the following two bugs: > >https://issues.apache.org/jira/browse/HADOOP-12184 >https://issues.apache.org/jira/browse/HADOOP-7824 > >HADOOP-12184 is in the "Patch Available" state and is marked as a >requirement for HADOOP-7824. When I submit the patch for HADOOP-7824 it >will touch the same section of code that HADOOP-12184 has done. >Therefore my patch will only apply cleanly if HADOOP-12184 patch is >applied first. Is Jenkins smart enough to pull in required patches as >detailed in the JIRA and apply them first, or does the dependency need >to be committed back to the repository? > >Thanks, > >Martin >
