andygrove opened a new pull request, #6218:
URL: https://github.com/apache/datafusion-comet/pull/6218
## Which issue does this PR close?
No issue was filed. I found this while checking what CI will cover on
`branch-1.1` before cutting it.
## Rationale for this change
The release process says the release branch "runs the same CI workflows as
`main`". That was written before the CI tiers, and most of what runs for `main`
never runs on a release branch:
- GitHub only fires `schedule` on the default branch, so there is no nightly
run.
- The merge queue ruleset targets `~DEFAULT_BRANCH` only.
- `ci.yml` only runs on push for `main`.
So a pull request to a release branch gets the PR tier alone: the Linux
build, lint, Rust tests, TPC-H/TPC-DS, and the Comet suites on Spark 4.1. The
Spark SQL and Iceberg suites, macOS, the PyArrow UDF tests and the other Spark
profiles never run there unless the pull request is labeled or the workflow is
dispatched. `branch-1.0` avoids this only because its `ci.yml` predates the
tiers and runs the full matrix on every pull request. `branch-1.1` will be the
first release branch cut from the tiered `ci.yml`.
The way to get full coverage is to dispatch `ci.yml` on the release branch,
which runs every job with no path filters. Today that would also overwrite the
website. The dispatch runs the `docs` job, and `docs.yaml` has no ref guard. It
builds the dispatched branch's docs, rsyncs them over `asf-site` with
`--delete`, and pushes, falling back to `git push --force`. Nobody has
dispatched `ci.yml` on `branch-1.0`, so this has not happened yet.
## What changes are included in this PR?
- `ci.yml`: the `docs` job also requires `github.ref == 'refs/heads/main'`,
so a dispatch on any other branch skips the deploy. The check is on the job
rather than in `compute-changes.py`, because `check-ci-config.py` asserts that
a dispatch routes to every job.
- Release process:
- A new "Run the Full CI Suite" step before building the jars. It
dispatches `ci.yml` and `miri.yml` on the release branch and shows how to list
the runs, since a failed dispatch opens no `ci-nightly-failure` issue. Both
runs must be green at the commit being tagged, for every release candidate, and
"Tag the Release Candidate" now says so.
- The protection step now includes a command to confirm the protection
took effect. It also explains that pull requests to the release branch,
backports included, run only the PR tier and should carry `run-*` labels.
- The stale sentence in "Update Maven Version" is corrected. A
`-SNAPSHOT`-only glob in the PyArrow UDF harness would not fail on the version
bump pull request, because that suite is outside the PR tier.
- CI guide: a short "Release branches" section for anyone opening a
backport, linked from the release process.
- Workflows README: the `docs` row now includes a dispatch on `main`.
Not addressed here: `branch-1.0` is unprotected. `gh api
repos/apache/datafusion-comet/branches/branch-1.0 --jq .protected` prints
`false`, because it was never added to `protected_branches` in `.asf.yaml`.
## How are these changes tested?
`python3 dev/ci/check-ci-config.py` and `actionlint --shellcheck=off` pass,
and `prettier --check` passes on the changed Markdown.
Only a dispatch on a branch other than `main` actually exercises the guard.
For every other event it changes nothing:
- On `push` and on a dispatch of `main`, `github.ref` is `refs/heads/main`,
so the deploy behaves as before.
- On a pull request, a merge group, or a schedule, `compute-changes.py`
already returns `docs=false`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
