* Update ruby version
* Update checksum
* Update Jruby version
* Update rubocop version
* Update MODULE.bazel
* Update Ruby and correct check sums
* Update all the places that used 9.4.8.0
* Add missing comma
Notably, it now allows to read version from `.ruby-version` file and use
a more convenient `run_binary()` rule instead of a `genrule()`.
The commit also bumps supported Ruby versions on CI.
* [java] require Java 11
* [java] remove netty http client and use native java client by default
* [java] updated the list of exports
* [java] use the default http client in tests
* [java] removed --remote-allow-origins=* for the netty client
* [java] removed the asynchttpclient and htmlunit-driver dependencies
---------
Co-authored-by: Jörg Sautter <joerg.sautter@gmx.net>
* Add macos coverage to Ruby CI (#12397)
* guard is not present in before all hook so do not set driver
* after hook still executes even when guard disposition of the test is skip so explicitly skip it too
---------
Co-authored-by: Titus Fortner <titusfortner@users.noreply.github.com>
Co-authored-by: titusfortner <titus.fortner@gmail.com>
This commit introduces few major changes to the Selenium CI, overhauling
the current implementation to make it a bit more usable and maintainable.
1. Introduces high-level orchestrating "CI" workflow that is run on
every push to the main branch, every 12 hours, every pull request,
and manually. This workflow checks which bindings are affected by the
pushed changes and calls individual CI workflows, presenting all of
the results on a single page -
https://github.com/SeleniumHQ/selenium/actions/workflows/ci.yml.
2. Reworks every "CI - <Bindings>" workflow to be callable from other
workflows or run manually. The former is important for the "CI" workflow,
the latter is matter of convenience so that individual bindings CI
workflow can be run.
3. Individual bindings CI workflow are also implemented in a similar
manner with the following pipeline:
Build -> Documentation / Lint / Unit Tests -> Integration Tests
This allows to better balance the load across the CI runners queue,
preventing an immediate burst of queued runs.
4. Almost every CI pipeline step is implemented via a callable
bazel.yml workflow. It is responsible for setting up the whole
environment (browsers, Bazel caches) and greatly simplifies the
individual bindings workflow. The only exceptions not using it are
few JavaScript/Python tasks not migrated to Bazel and Rust pipeline.
6. Removes unnecessary installation of JDK because it's already taken
care of by Bazel.
7. Allows to start interacting SSH session inside CI upon failure. This
can be done by re-running a failed build with "Enable debug logging"
on.
8. Allows to force-run CI on pull requests if the title includes
[<bindings>] text. We could also fetch commits on this PR, but it
needs extra code and can be done later.
This fits more into Bazel approach because smaller packages with a
proper dependency tree would allow to use Bazel caching more
efficiently. For example, only few tests would be re-run considering
you ran all integration tests for Chrome before and only changed code
in `chrome/driver.rb`. This is because just a few tests depend on
`chrome/driver.rb`. Per-test file packages also allow us to use Bazel
flaky retry flags efficiently - previously it would re-run all the tests
when one of them fails.
This commit also moves certain files around to make Ruby codebase more
reasonable:
* CDP client code generator lives in the `rb/lib/selenium/devtools`
* Nightly version generator lives in a new `rb/lib/selenium/support`
Since now integration tests are being in parallel by default, few
changes had to be done to make support code more concurrency-safe.
Notably, Grid and Rack servers are being started on randomized ports.
Some other tests were adapted/guarded to work better when run in
parallel.
The test configuration is now controlled by a combination of
`--define <name>=<value>` flags, supporting `browser/remote/headless` as
names. See README.md changes for more details.
It provides cross-platform configuration of Bazel and fine-grained
caching for bazelisk, disk_cache, repository_cache and external
repositories resulting in faster CI builds.
This commit lands a support for public read-only remote Bazel cache
stored on Google Cloud Storage at
https://storage.googleapis.com/seleniumhq-bazel-remote-cache. The
storage bucket is public so anyone on the internet can use it to speed
up building Selenium locally.
The cache is written on the trunk CI builds by specifying
--remote_upload_local_results=true in CI .bazelrc. Likewise, Selenium
committers can write to the cache by getting the JSON key and adding
the following to the .bazelrc.local:
build --remote_upload_local_results=true --google_credentials=<path-to-json-key>
For now, the bucket is stored in @p0deje personal Google cloud and we
should eventually move it SeleniumHQ account if/once we have it.
Refactores shared Bazel GitHub action to work both on Windows and Unix
operating systems. It also introduces a new action to share cache
between the workflow runs that works in both OSes too - though Windows
implementation is far less performant.
