My team uses Bazel and what I'd like to do is bazel test and have Bazel automatically detect dependencies of modified files, and run all impacted tests. I feel like this should be possible due to the way dependencies are well defined in build and test rules but haven't been able to find anything on the topic.
Is this currently possible?
Bazel indeed provides the declarative dependency infrastructure to do such test selection, but it does not have a full end-to-end solution. Instead, there are thirdparty projects like https://github.com/Tinder/bazel-diff.
Related
Is it possible to integrate Fastlane with Bazel (or vice versa)? The non-mobile part of our org uses Bazel for build, and I'd like to be consistent on mobile. However Fastlane provides a lot of stuff aimed at mobile that Bazellane does not. Bazel is for built + test, whereas Fastlane also provides solutions for release/deployment.
Is it possible (or advisable) to call Bazel build from within Fastlane? Or perhaps call Fastlane from within Bazel for deployment?
Bazel is like an interpreter for a language, which allows you to define rules - functions which may have a set of inputs, an action, and a set of outputs.
I am not familiar with Fastlane, but it is surely possible to write a rule which will produce you an artifact. The only requirement is that your set of outputs must be clearly defined (hardcoded in a rule) - in other words, you can not write a rule which will "unzip whatever is in this archive to this folder", because you have to define a set of outputs.
Rules doc page is the best place to start.
I am preparing for making a minor bug fix to bazel java code. Am working on a Linux distribution.
Following the instructions in https://bazel.build/contributing.html but I encounter problems with two of the test instructions:
In the section about "Compiling bazel" the third parapgraph state: "In addition to the Bazel binary, you might want to build the various tools Bazel uses. They are located in //src/java_tools/..., //src/objc_tools/... and //src/tools/... and their directories contain README files describing their respective utility." If I follow this the //src/tools/... fail because there is no xcrun command in the Linux environment I am using. I suppose this is MacOS platform specific tests?
The next paragraph instructs you to build a distribution package, that you then unpack in a new directory, and then do: "bazel test //src/... //third_party/ijar/...". I now get an error that windows.h is missing, which I suppose is Windows platform specific tests.
Some questions:
So is there an easy way to run tests only for the current platform?
Is the instructions good enough?
If the instructions should be updated, what is the best way to notify the ones managing that documentation page?
Thanks for your interest in contributing to Bazel! The bazel-dev mailing list is a better avenue for these questions.
The tests that you want to run largely depend on the changes you make, but when you make a pull request, the Bazel CI will run all of Bazel's tests to make sure that nothing breaks.
So is there an easy way to run tests only for the current platform?
It depends, and this is still a work in progress where we want to make Bazel more aware of platforms and toolchains without specifying additional flags.
In general, you don't need to modify or worry about the //src/*_tools packages unless you're making direct changes to them.
Is the instructions good enough?
The instructions will never be perfect, and we're always looking for ways to make it clearer and more concise.
If the instructions should be updated, what is the best way to notify the ones managing that documentation page?
Please file an issue on the GitHub repository or email the bazel-dev mailing list for further discussion.
Long story short,
I was wondering if anyone ever felt the need for (and knows of any implementation of) the possibility of "instantiating" (OO terminology) a parametrized build.
What I mean is treating a parametrized build as a template, from which many "instances" can be generated.
Each instance is supposed to define a different combination of values for the parameters.
The final goal is twofold:
DRY (which is given simply by the parametrized build concept)
having separate build histories / test reports for each instance (otherwise it would be a mess)
the instances would be schedulable directly in jenkins UI (while a parametrized build is not)
The template would then be used only for:
manual builds
changing the config for all of the instances at once
Now, time for some context, as I may be missing something in my overall approach.
You are welcome to point me in the right direction :)
I have a maven project with a suite of selenium tests that I want jenkins to run.
The suite is parametrized: browser, OS, test environment.
So, I can run it e.g. with mvn test -Dbrowser=chrome -Dplatform=win [..].
I want a separate test report for each combination of my parameters.
As a newbie, my first solution was "Copy existing job".
Quick and dirty. But effective.
As you will know, problems arise when you need to make a change to the configuration of the job, and you want to keep in sync all of these copy&pasted jobs.
Then I found the parametrized build feature.
It's very cool (code reuse/maintainability++), but the test report and the build history is shared among all of the actual builds, therefore I can not rely on them for a tidy reporting like "this test is always failing on IE; but it isn't on chrome", and so on.
Thank you very much in advance
I think what you are describing is the matrix project
There are also selenium plugins, I put one together to work with matrix jobs https://wiki.jenkins-ci.org/display/JENKINS/Selenium+Axis+Plugin
One lack I can see: you can't build a single combination, as the build btn is present only at the "top level".
Have you tried the Matrix Combination plugin
https://wiki.jenkins-ci.org/display/JENKINS/Matrix+Combinations+Plugin
I'm looking for a jenkins plugin that would allow selection of file(s)/folder(s) for a parameterized build.
The purpose is to be able to select different tests to execute, each test being defined as a .xml file in a svn repo.
eg of repo structure:
tests/business/cars/buy.xml
tests/business/cars/sell.xml
tests/system/core/stuff.xml
I'm not sure if these quite get at what you're looking for, but I found the following two possibilities:
Test In Progress which, based on their GitHub information, should allow you to run tests based on pattern matching and view the progress as they run.
RQM is an IBM tool made to allow you to run specific test cases in a test plan that have a custom property that you configured and provide at test execution time.
edit:
I just found Multi Module Test Publisher, which may be a little closer to what you're looking for. It acts as a replacement for the normal junit plugin and allows you to group junit tests into suites and view statistics on each separately.
When running unit tests, Gradle can execute multiple tests in parallel without any changes to the tests themselves (i.e. special annotations, test runners, etc.). I'd like to achieve the same thing with ant, but I'm not sure how.
I've seen this question but none of the answers really appeal to me. They either involve hacks with ant-contrib, special runners set up with the #RunWith annotation, some other special annotations, etc. I'm also aware of TestNG, but I can't make the Eclipse plug-in migrate our tests - and we have around 10,000 of them so I'm not doing it by hand!
Gradle doesn't need any of this stuff, so how do I do it in ant? I guess Gradle uses a special runner, but if so, it's set up as part of the JUnit setup, and not mentioned on every single test. If that's the case, then that's fine. I just don't really want to go and modify c. 10,000 unit tests!
Gradle doesn't use a special JUnit runner in the strict sense of the word. It "simply" has a sophisticated test task that knows how to spin up multiple JVMs, run a subset of test classes in each of them (by invoking JUnit), and report back the results to the JVM that executes the build. There the results get aggregated to make it look like a single-JVM, single-threaded test execution. This even works for builds that define their own test listeners.
To get parallel test execution in Ant, you would need an Ant task that supports this feature (not sure if one exists). An alternative is to import your Ant build into Gradle (ant.importBuild "build.xml") and add a test task on the Gradle side.