Table of Contents generated with DocToc
The CI jobs are notoriously difficult to test, because you can only
really see results of it when you run them in CI environment, and the
environment in which they run depend on who runs them (they might be
either run in our Self-Hosted runners (with 64 GB RAM 8 CPUs) or in the
GitHub Public runners (6 GB of RAM, 2 CPUs) and the results will vastly
differ depending on which environment is used. We are utilizing
parallelism to make use of all the available CPU/Memory but sometimes
you need to enable debugging and force certain environments. Additional
difficulty is that Build Images
workflow is pull-request-target
type, which means that it will always run using the main
version - no
matter what is in your Pull Request.
There are several ways how you can debug the CI jobs and modify their behaviour when you are maintainer.
When you create the PR you can set one of the labels below, also in some cases, you need to run the PR as coming from the "apache" repository rather than from your fork.
You can also apply the label later and rebase the PR or close/reopen the PR to apply the label to the PR.
Action to perform | Label to set | PR from "apache" repo |
---|---|---|
Run the build with all combinations of all python, backends, kubernetes etc on PR, and run all types of tests for all test groups. |
full tests needed | |
Force to use public runners for the build | use public runners | |
Debug resources used during the build for parallel jobs |
debug ci resources | |
Force running PR on latest versions of python, backends, kubernetes etc. when you want to save resources and test only latest versions |
latest versions only | |
Force running PR on minimal (default) versions of python, backends, kubernetes etc. in order to save resources and run tests only for minimum versions |
default versions only | |
Make sure to clean dependency cache usually when removing dependencies You also need to increase DEPENDENCIES_EPOCH_NUMBER in Dockerfile.ci |
disable image cache | |
Change build images workflows, breeze code or scripts that are used during image build so that the scripts can be modified by PR |
Yes | |
Treat your build as "canary" build - including updating constraints and pushing "main" documentation. |
Yes | |
Remove any behaviour specific for the committers such as using different runners by default. |
non committer build |
Read next about Running CI locally