-
Notifications
You must be signed in to change notification settings - Fork 283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add options to run unit tests to TensorFlow EasyBlock #2263
Add options to run unit tests to TensorFlow EasyBlock #2263
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from the mystery removal this lgtm
easybuild/easyblocks/t/tensorflow.py
Outdated
@@ -636,9 +640,6 @@ def configure_step(self): | |||
self.install_base_dir))] | |||
apply_regex_substitutions('configure.py', regex_subs) | |||
|
|||
# Tell Bazel to not use $HOME/.cache/bazel at all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is removed without justification and looks unrelated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I'm currently testing why the tests still fail (they are run at least) and found that we add to many options. Only thing needed seems to be --output_user_root
, TEST_TMPDIR is set internally by Bazel to tell Bazel that a test is being run. Setting that for compilation is hence wrong. I'll double check if output_base and install_base can also be removed and would include that here, or shall I make a second PR where those options are removed? Problem then would be merge conflicts which I'd want to avoid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A second PR would be best indeed.
Perhaps a rebase can avoid merge conflicts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's see. I undid this and if this is merged first I can keep the other changes and likely rebase them
@bartoldeman ping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Going in, thanks @Flamefire! |
(created using
eb --new-pr
)