update rfl ci job policy (#2108)

This commit is contained in:
David Wood 2024-10-31 17:46:24 +00:00 committed by GitHub
parent fd1ce7455f
commit 7ad315771e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 15 additions and 9 deletions

View File

@ -24,19 +24,25 @@ integration.
## What to do in case of failure
Currently, we use the following unofficial policy for handling failures caused
by a change breaking the RfL integration:
If a PR breaks the Rust for Linux CI job, then:
- If the breakage was unintentional, then fix the PR.
- If the breakage was intentional, then let [RFL][rfl-ping] know and discuss
- If the breakage was unintentional and seems spurious, then let [RfL][rfl-ping]
know and retry.
- If the PR is urgent and retrying doesn't fix it, then disable the CI job
temporarily (comment out the `image: x86_64-rust-for-linux` job in
`src/ci/github-actions/jobs.yml`).
- If the breakage was unintentional, then change the PR to resolve the breakage.
- If the breakage was intentional, then let [RfL][rfl-ping] know and discuss
what will the kernel need to change.
- If the PR is urgent, then disable the test temporarily.
- If the PR can wait a few days, then wait for RFL maintainers to provide a
- If the PR is urgent, then disable the CI job temporarily (comment out
the `image: x86_64-rust-for-linux` job in `src/ci/github-actions/jobs.yml`).
- If the PR can wait a few days, then wait for RfL maintainers to provide a
new Linux kernel commit hash with the needed changes done, and apply it to
the PR, which would confirm the changes work.
the PR, which would confirm the changes work (update the `LINUX_VERSION`
environment variable in `src/ci/docker/scripts/rfl-build.sh`).
If something goes wrong with the workflow, you can ping the [Rust for
Linux][rfl-ping] ping group to ask for help.
If you need to contact the RfL developers, you can ping the [Rust for Linux][rfl-ping]
ping group to ask for help:
```text
@rustbot ping rfl