Skip to content

Latest commit

 

History

History
67 lines (53 loc) · 4.72 KB

07_debugging.md

File metadata and controls

67 lines (53 loc) · 4.72 KB

Table of Contents generated with DocToc

Debugging CI Jobs in Github Actions and changing their behaviour

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