[jira] [Updated] (HADOOP-12233) if CHANGED_FILES is corrupt, find_changed_modules never returns
[ https://issues.apache.org/jira/browse/HADOOP-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HADOOP-12233: - Issue Type: Bug (was: Sub-task) Parent: (was: HADOOP-12111) > if CHANGED_FILES is corrupt, find_changed_modules never returns > --- > > Key: HADOOP-12233 > URL: https://issues.apache.org/jira/browse/HADOOP-12233 > Project: Hadoop Common > Issue Type: Bug > Components: yetus >Affects Versions: HADOOP-12111 >Reporter: Allen Wittenauer >Assignee: Kengo Seki > Fix For: HADOOP-12111 > > Attachments: HADOOP-12233.HADOOP-12111.00.patch, > HADOOP-12233.HADOOP-12111.01.patch, HADOOP-12233.HADOOP-12111.02.patch > > > In building some unit tests, did a negative tests and hit this condition. We > should put a limit on how many times we loop in the find_x_dirs code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12233) if CHANGED_FILES is corrupt, find_changed_modules never returns
[ https://issues.apache.org/jira/browse/HADOOP-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kengo Seki updated HADOOP-12233: Attachment: HADOOP-12233.HADOOP-12111.02.patch We maybe overthought it. Is the 02.patch enough to solve this problem? > if CHANGED_FILES is corrupt, find_changed_modules never returns > --- > > Key: HADOOP-12233 > URL: https://issues.apache.org/jira/browse/HADOOP-12233 > Project: Hadoop Common > Issue Type: Sub-task > Components: yetus >Affects Versions: HADOOP-12111 >Reporter: Allen Wittenauer >Assignee: Kengo Seki > Fix For: HADOOP-12111 > > Attachments: HADOOP-12233.HADOOP-12111.00.patch, > HADOOP-12233.HADOOP-12111.01.patch, HADOOP-12233.HADOOP-12111.02.patch > > > In building some unit tests, did a negative tests and hit this condition. We > should put a limit on how many times we loop in the find_x_dirs code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12233) if CHANGED_FILES is corrupt, find_changed_modules never returns
[ https://issues.apache.org/jira/browse/HADOOP-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kengo Seki updated HADOOP-12233: Status: Patch Available (was: Reopened) > if CHANGED_FILES is corrupt, find_changed_modules never returns > --- > > Key: HADOOP-12233 > URL: https://issues.apache.org/jira/browse/HADOOP-12233 > Project: Hadoop Common > Issue Type: Sub-task > Components: yetus >Affects Versions: HADOOP-12111 >Reporter: Allen Wittenauer >Assignee: Kengo Seki > Fix For: HADOOP-12111 > > Attachments: HADOOP-12233.HADOOP-12111.00.patch, > HADOOP-12233.HADOOP-12111.01.patch, HADOOP-12233.HADOOP-12111.02.patch > > > In building some unit tests, did a negative tests and hit this condition. We > should put a limit on how many times we loop in the find_x_dirs code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12233) if CHANGED_FILES is corrupt, find_changed_modules never returns
[ https://issues.apache.org/jira/browse/HADOOP-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer updated HADOOP-12233: -- Resolution: Fixed Fix Version/s: HADOOP-12111 Status: Resolved (was: Patch Available) ha. i forgot about relative_dir. Good call! +1 committing if CHANGED_FILES is corrupt, find_changed_modules never returns --- Key: HADOOP-12233 URL: https://issues.apache.org/jira/browse/HADOOP-12233 Project: Hadoop Common Issue Type: Sub-task Components: yetus Affects Versions: HADOOP-12111 Reporter: Allen Wittenauer Assignee: Kengo Seki Fix For: HADOOP-12111 Attachments: HADOOP-12233.HADOOP-12111.00.patch, HADOOP-12233.HADOOP-12111.01.patch In building some unit tests, did a negative tests and hit this condition. We should put a limit on how many times we loop in the find_x_dirs code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12233) if CHANGED_FILES is corrupt, find_changed_modules never returns
[
https://issues.apache.org/jira/browse/HADOOP-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kengo Seki updated HADOOP-12233:
Attachment: HADOOP-12233.HADOOP-12111.01.patch
bq. Would something simple like verifying that we're still inside $\{BASEDIR}
be sufficient?
It sounds better because it's not unnatural and we can remove magic numbers
from the source.
Attaching a revised patch. If a changed file is not in $\{BASEDIR}, test-patch
will fail as follows:
{code}
[sekikn@mobile hadoop]$ cat /tmp/test.patch
diff --git /a/dev-support/releasedocmaker.py b/dev-support/releasedocmaker.py
index 3c398be..05aa347 100755
--- a/dev-support/releasedocmaker.py
+++ b/dev-support/releasedocmaker.py
@@ -581,3 +581,4 @@ def main():
if __name__ == __main__:
main()
+
[sekikn@mobile hadoop]$ dev-support/test-patch.sh --basedir=../dev/hadoop
--project=hadoop /tmp/test.patch --debug
(snip)
[Sat Aug 22 13:55:42 JST 2015 DEBUG]: Find pom.xml dir for: /a/dev-support
dev-support/test-patch.sh: line 1123: cd: /a: No such file or directory
[Sat Aug 22 13:55:42 JST 2015 DEBUG]: ERROR: /a/dev-support is not in
/Users/sekikn/dev/hadoop.
ERROR: pom.xml is not found. Make sure the target is a maven-based project.
-1 overall
{code}
Valid patches still pass:
{code}
[sekikn@mobile hadoop]$ cat /tmp/test.patch
diff --git a/dev-support/releasedocmaker.py b/dev-support/releasedocmaker.py
index 3c398be..05aa347 100755
--- a/dev-support/releasedocmaker.py
+++ b/dev-support/releasedocmaker.py
@@ -581,3 +581,4 @@ def main():
if __name__ == __main__:
main()
+
[sekikn@mobile hadoop]$ dev-support/test-patch.sh --basedir=../dev/hadoop
--project=hadoop /tmp/test.patch
(snip)
+1 overall
{code}
if CHANGED_FILES is corrupt, find_changed_modules never returns
---
Key: HADOOP-12233
URL: https://issues.apache.org/jira/browse/HADOOP-12233
Project: Hadoop Common
Issue Type: Sub-task
Components: yetus
Affects Versions: HADOOP-12111
Reporter: Allen Wittenauer
Assignee: Kengo Seki
Attachments: HADOOP-12233.HADOOP-12111.00.patch,
HADOOP-12233.HADOOP-12111.01.patch
In building some unit tests, did a negative tests and hit this condition. We
should put a limit on how many times we loop in the find_x_dirs code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HADOOP-12233) if CHANGED_FILES is corrupt, find_changed_modules never returns
[
https://issues.apache.org/jira/browse/HADOOP-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kengo Seki updated HADOOP-12233:
Attachment: HADOOP-12233.HADOOP-12111.00.patch
-00:
* put a limit on the loops in find_buildfile_dir and module_skipdir in the same
way as find_changed_modules
I confirmed that both of them stop against some artificial patch (without going
into detail so that a malicious patch starving jenkins is not submitted easily)
with the following message:
{code}
ERROR: pom.xml is not found. Make sure the target is a maven-based project.
{code}
if CHANGED_FILES is corrupt, find_changed_modules never returns
---
Key: HADOOP-12233
URL: https://issues.apache.org/jira/browse/HADOOP-12233
Project: Hadoop Common
Issue Type: Sub-task
Components: yetus
Affects Versions: HADOOP-12111
Reporter: Allen Wittenauer
Attachments: HADOOP-12233.HADOOP-12111.00.patch
In building some unit tests, did a negative tests and hit this condition. We
should put a limit on how many times we loop in the find_x_dirs code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HADOOP-12233) if CHANGED_FILES is corrupt, find_changed_modules never returns
[ https://issues.apache.org/jira/browse/HADOOP-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kengo Seki updated HADOOP-12233: Assignee: Kengo Seki Status: Patch Available (was: Open) if CHANGED_FILES is corrupt, find_changed_modules never returns --- Key: HADOOP-12233 URL: https://issues.apache.org/jira/browse/HADOOP-12233 Project: Hadoop Common Issue Type: Sub-task Components: yetus Affects Versions: HADOOP-12111 Reporter: Allen Wittenauer Assignee: Kengo Seki Attachments: HADOOP-12233.HADOOP-12111.00.patch In building some unit tests, did a negative tests and hit this condition. We should put a limit on how many times we loop in the find_x_dirs code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
