Skip to content
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

Closed
wants to merge 13 commits into from
Closed

Conversation

or-shachar
Copy link
Contributor

@or-shachar or-shachar commented Mar 1, 2017

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:

  1. All runs must share the same repository cache, and there must be one rule that will run before tests and download the libraries once (otherwise all tests would try to download the libraries in parallel to the same path). Currently you get consistent behavior and test time only from second run
  2. The targets that run java fail because they cannot find java executable - I need your advise about how to make java available in sh_test env
  3. I added .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.

- moved to use bazel sh_test
- separated each test to different target
@bazel-io
Copy link
Member

bazel-io commented Mar 1, 2017

Can one of the admins verify this patch?

@googlebot
Copy link

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. I signed it!) and we'll verify. Thanks.


  • If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
  • If you signed the CLA as a corporation, please let us know the company's name.

@googlebot
Copy link

CLAs look good, thanks!

@googlebot googlebot added cla: yes and removed cla: no labels Mar 1, 2017
Copy link
Contributor

@damienmg damienmg left a 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 = []
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is additions for?

Copy link
Contributor Author

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,
Copy link
Contributor

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

Copy link
Contributor Author

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...

Copy link
Contributor

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:

  1. to set --javabase and --host_javabase like it is done in testenv in Bazel
  2. 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"
@damienmg
Copy link
Contributor

damienmg commented Mar 2, 2017

Trigger bazel ci: test this please

@or-shachar
Copy link
Contributor Author

or-shachar commented Mar 2, 2017

@damienmg - I don't think that you run the test_sh script in Jenkins...
If I understand right the only thing you run there is bazel test test:...

@damienmg
Copy link
Contributor

damienmg commented Mar 2, 2017

Right, we do bazel test //test/..., can you add a test_suite there that execute the sh_test?

@or-shachar
Copy link
Contributor Author

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.

@damienmg
Copy link
Contributor

damienmg commented Mar 2, 2017

sure it just implies another change to ci.bazel.io, so it's easier to do it that way right now.

@or-shachar
Copy link
Contributor Author

Ok... I added another folder under test called integration-tests and put all tests there. You can trigger bazel ci: test again. Thanks

@damienmg
Copy link
Contributor

damienmg commented Mar 2, 2017

test this please


script:
- bash test_run.sh
- bazel test test/integration-tests/...
Copy link
Member

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/...?

Copy link
Contributor Author

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/...

@or-shachar
Copy link
Contributor Author

@damienmg you were right. Under platform darwin-x86_64 all tests fail because it cannot find bazel.

@or-shachar
Copy link
Contributor Author

So we are left with several problems:

  1. For some reason the run_java rules cannot load the main class. (with error message - Could not find or load main class *). Note that adding the --host_javabase... --javabase... to the inner bazel run did not make any difference on my local.
  2. bazel is missing in some platforms and must be imported.
  3. run_scalaBinary is possibly flaky (failed on timeout on Linux platform only on Jenkins).
  4. test_disappearing_classes is failing because it tries to change the content of files in the workspace and when running inside bazel test - the file is in read only mode.

or-shachar referenced this pull request in bazelbuild/bazel Mar 6, 2017
…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
@ittaiz
Copy link
Member

ittaiz commented May 30, 2017

just had a talk with @dslomov which proposed using sh_binary on the downloaded http_archive and having the sh_test depend on the sh_binary target to get it into the sandbox.
WDYT?

@bazel-io
Copy link
Member

Can one of the admins verify this patch?

@ittaiz
Copy link
Member

ittaiz commented Jan 18, 2018

obviously we won't resurrect this. If we'll want concepts we'll take a look at the branch.

@ittaiz ittaiz closed this Jan 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants