You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Akira Ajisaka (Jira)" <ji...@apache.org> on 2020/02/10 05:17:00 UTC
[jira] [Commented] (HADOOP-13951) Precommit builds do not
adequately protect against test malformed fs permissions.
[ https://issues.apache.org/jira/browse/HADOOP-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033378#comment-17033378 ]
Akira Ajisaka commented on HADOOP-13951:
----------------------------------------
H17 is failing ([https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/1406/console)|https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/1406/console] and ran [https://builds.apache.org/view/H-L/view/Hadoop/job/hadoop-clean-hdfs-workspace/] on the node.
Thanks Sean and Andrew for the work.
> Precommit builds do not adequately protect against test malformed fs permissions.
> ---------------------------------------------------------------------------------
>
> Key: HADOOP-13951
> URL: https://issues.apache.org/jira/browse/HADOOP-13951
> Project: Hadoop Common
> Issue Type: Bug
> Components: test
> Reporter: Sean Busbey
> Priority: Critical
>
> Right now this is expressed as failed Precommit-YARN-build jobs when they run on H5 / H6 (see INFRA-13148), but the problem exists for all of the hadoop related precommit jobs.
> The issue is that we have some tests in Common (and maybe HDFS) that purposefully set permissions within the {{target/}} directory to simulate a failure to interact with underlying fs data. The test sets some subdirectories to have permissions such that we can no longer delete their contents.
> Right now our precommit jobs include a step post-yetus-test-patch that traverses the target directories and ensures that all subdirectories are modifiable:
> {code}
> find ${WORKSPACE} -name target | xargs chmod -R u+w
> {code}
> Unfortunately, if we don't get to that line (say due to an aborted build, or if the call to yetus test-patch exceeds the job timeout), then we are left in a state where there are still subdirectories that can't be modified (including deleted).
> Our builds also currently attempt to run a {{git clean}} at the very start of the build after the repo is updated. If we have one of the aforementioned timeouts that leaves a can't-be-deleted test directory, then all future builds on that machine will fail attempting to run the {{git clean}} command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org