[ci] Refresh stale .buildkite/README and remove dead ci_tags_from_change.sh

.buildkite/README.md

@@ -1,30 +1,18 @@
 # Buildkite pipelines
 
-This directory contains buildkite pipelines used to start CI tests.
+This directory contains the Buildkite pipeline definitions for Ray CI, plus the rules that decide which tests run on a given change.
 
-Each step contains a buildkite step that is parsed and executed according to the
-[Buildkite pipeline specification](https://buildkite.com/docs/pipelines).
+## Pipelines
 
-## Conditions
+Pipelines are defined in the `*.rayci.yml` files in this directory and are generated and run by [rayci](https://github.com/ray-project/rayci), Ray's CI orchestration tool. Each file groups the steps for one area (for example, `core.rayci.yml`, `data.rayci.yml`, `doc.rayci.yml`).
 
-An extra optional field `conditions` is defined, which includes conditions under which tests are run.
-The script `ci/pipeline/determine_tests_to_run.py` determines changed files in a PR and only kicks off
-tests that include at least one of the conditions. If no condition is specified, the test is always run.
+## Conditional test selection
 
-A special case is the `NO_WHEELS_REQUIRED` condition. If this is present, it indicates that the test can
-be run with the latest available binaries - in this case the test can be started early, as it will re-use
-the latest branch image and only check out the current code revision in the PR. This early kick off will
-only trigger on PR builds, not on branch builds.
+Which steps run on a given pull request is determined by mapping changed file paths to *tags*. Two rule files drive this:
 
-## Pipelines
+- `test.rules.txt` is the conditional rule set. Rules are evaluated in order and the first match wins. A rule with no `@` tags is a skip rule (it matches but emits nothing), and a trailing `*` catch-all fans unmatched changes out to the full suite.
+- `always.rules.txt` is an always-on overlay applied to every change.
 
-This directory should be considered with respect to the docker images located in `ci/docker`.
+rayci parses these files (its `test-rules` command) and runs the steps whose tags are emitted. See the header comment in each rules file for the full format.
 
-- `pipeline.build.yml` contains jobs that require build dependencies. This includes all tests that re-build
-  Ray (e.g. when switching Python versions). The tests are run on the `build.Dockerfile` image.
-- `pipeline.test.yml` contains jobs that only require an installed Ray and a small subset of dependencies,
-  notably exlcuding ML libraries such as Tensorflow or Torch. The tests are run on the `test.Dockerfile` image.
-- `pipeline.ml.yml` contains jobs that require ML libraries Tensorflow and Torch to be available. The tests
-  are run on the `ml.Dockerfile` image.
-- `pipeline.gpu.yml` contains jobs that require one GPU. The tests are run on the `gpu.Dockerfile` image.
-- `pipeline.gpu.large.yml` contains jobs that require multi-GPUs (currently 4). The tests are run on the `gpu.Dockerfile` image.
+`ci/pipeline/determine_tests_to_run.py` is an in-repo reference implementation of the same rule-file format. It is not the live evaluator; rayci is.