-
Notifications
You must be signed in to change notification settings - Fork 284
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
WIP: issue-76 #156
WIP: issue-76 #156
Conversation
- moved to use bazel sh_test - separated each test to different target
Can one of the admins verify this patch? |
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
CLAs look good, thanks! |
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.
Sorry for taking so long, a bit of a rush here
BUILD
Outdated
"//tut_rule:sources", | ||
"//twitter_scrooge:sources"] | ||
|
||
additions = [] |
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.
What is additions for?
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.
Bad naming... and currently redundant. At first I used this mechanism to only run tests that run bazel, the "additions" allowed me to define bazel arguments / flags that will be added to each execution. Later on I saw that shipping .bazelrc is much more effective because some other tests call bash function with inner calls to bazel.
BUILD
Outdated
sh_test( | ||
name = "build_targets_under_tests_package", | ||
size = "large", | ||
data = repo, |
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.
If you want the toolchain to be shiped in the test you need to pass "@local_jdk//:jdk", in the data dependency. You will also need bazel itself as a dependency and specify it to the --javabase option of bazel.
See https://github.com/bazelbuild/bazel/blob/master/src/test/shell/testenv.sh#L246
and https://github.com/bazelbuild/bazel/blob/master/src/test/shell/testenv.sh#L87
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.
Adding the local_jdk://jdk
was easy and we made some progress (It fails on another thing right now which is - it claims that it cannot load the main class JavaBinary... (look in travis).
As for "bazel itself as dependency with --javabase" - I tried to adjust Bazel's testenv.sh to our repository but it seems to have some dependencies on other packages that I couldn't find. I tried to simply add the --javabase <path>
to the .bashrc
but it did not make any different in the result...
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.
So let me rephrase, you need:
- to set --javabase and --host_javabase like it is done in testenv in Bazel
- You will need to have "bazel" as a dependency to run inside the sandbox. Might not be important if it's on the PATH and installed outside of the workspace but I think it will fails on ci.bazel.io.
removed redundant "addition"
Trigger bazel ci: test this please |
@damienmg - I don't think that you run the test_sh script in Jenkins... |
Right, we do bazel test //test/..., can you add a test_suite there that execute the sh_test? |
Sure! But I think that once it's working it should be moved to a different location... like "intergration-tests" or something of a kind. |
sure it just implies another change to ci.bazel.io, so it's easier to do it that way right now. |
Ok... I added another folder under |
test this please |
|
||
script: | ||
- bash test_run.sh | ||
- bazel test test/integration-tests/... |
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.
why not bazel test test/...
?
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.
In previous solution it would only run the test_sh.sh which is the integration tests.
Inside the integration tests in runs the bazel test test/...
@damienmg you were right. Under platform |
So we are left with several problems:
|
…on tests. Currently a call to "bazel" in an integration test means calling a (quite hidden) function in test-setup.sh which actually calls "$bazel" defined in "shell/bazel/testenv.sh" which is equal to "$(rlocation io_bazel/src/bazel)". This is extremely confusing and error prone. The new mechanism is to add a wrapper script to shell/bin called bazel and export this directory to the PATH. Moreover, not every test loads the same test environment, for instance consider how bazel_query_test loads the test environment: - Load shell/integration/testenv.sh which loads, - shell/bazel/test-setup.sh which loads, - shell/bazel/testenv.sh which loads, - shell/unittest.bash which loads, - shell/testenv.sh Again this is error prone and specially hard to understand, in fact each test writer needs to decide which of these testenv to load. This change fixes all of this by having only one testenv.sh and summarizing the test setup in integration_test_setup.sh. Namely, for any new integration test, the developer needs to load integration_test_setup to get the environment set up including the unittest framework (also it helps to attract contributions). This change also allows to open sourcing client_sigint_test: Since bazel was a function client_sigint_test was using a wrong process id to interrupt the build. The problem is that $! returns bash's id instead of the id of the process running in the background when using a function instead of an executable. A few tests needed to be adapted to the new infrastructure. -- MOS_MIGRATED_REVID=136470360
just had a talk with @dslomov which proposed using |
Can one of the admins verify this patch? |
obviously we won't resurrect this. If we'll want concepts we'll take a look at the branch. |
working on #76
Instead of running tests using bash, it will use sh_tests.
To run this you can run
bazel test :all
Known issues that I need to find solution for:
.bashrc
that define some rules for persistent worker and shared repository cache. Not sure how this will behave in CI, or if it's allowed.@damienmg @johnynek - Of course this PR is mainly for your review and advise, and not for merge yet.