TVM's Continuous Integration is responsible for verifying the code in apache/tvm and testing PRs before they merge to inform TVM contributors and committers. These jobs are essential to keeping the TVM project in a healthy state and preventing breakages. CI in TVM is broken into these pieces:

• Lint scripts in tests/lint.
• The tests themselves, all of which live underneath tests.
• Definitions of test suites, with each suite defined as a separate task_ script in tests/scripts.
• Scripts and automation ci/scripts.
• The linux test sequence (in Jenkinsfile), which lints and builds TVM and runs test suites using Docker on Linux.
• The Windows and Mac test sequences (in .github/actions).
• GitHub Actions that support the code review process (in .github/actions).
• Tools to reproduce the CI locally (in tests/scripts).
• Infrastructure-as-Code that configures the cloud services that provide Jenkins for the TVM CI (in the tlc-pack/ci repo).

The CI documentation belongs with the implementation it describes. To make that concrete, the documentation is split like so:

1. An overview of the CI is in this file.
2. User-facing documentation lives in apache/tvm's docs/contribute sub-directory and is served on the TVM docs site.
3. Documentation of the tools that run TVM's various regression tests locally and the test suites are in this sub-directory.
4. Documentation of the cloud services and their configuration lives in the tlc-pack/ci repo.

Jenkins runs all of the Linux-based TVM CI-enabled regression tests. This includes tests against accelerated hardware such as GPUs. It excludes those regression tests that run against hardware not available in the cloud (those tests aren't currently exercised in TVM CI). The tests run by Jenkins represent most of the merge-blocking tests (and passing Jenkins should mostly correlate with passing the remaining Windows/Mac builds).

GitHub Actions is used to run Windows jobs, MacOS jobs, and various on-GitHub automations. These are defined in .github/workflows. These automations include bots to:

• cc people based on subscribed teams/topics
• allow non-committers to merge approved / CI passing PRs
• add cc-ed people as reviewers on GitHub
• ping languishing PRs after no activity for a week (currently opt-in only)
• push a last-successful branch to GitHub with the last main commit that passed CI

https://github.com/apache/tvm/actions has the logs for each of these workflows. Note that when debugging these workflows changes from PRs from forked repositories won't be reflected in the PR. These should be tested in the forked repository first and linked in the PR body.

Each CI job runs most of its work inside a Docker container, built from files in the docker/ folder. These files are built nightly in Jenkins via the docker-images-ci job. The images for these containers are hosted in the tlcpack Docker Hub and referenced in the Jenkinsfile.j2. These can be inspected and run locally via standard Docker commands.

The ci-docker-staging branch is used to test updates to Docker images and Jenkinsfile changes. When running a build for a normal PR from a forked repository, Jenkins uses the code from the PR except for the Jenkinsfile itself, which comes from the base branch. When branches are built, the Jenkinsfile in the branch is used, so a committer with write access must push PRs to a branch in apache/tvm to properly test Jenkinsfile changes. If your PR makes changes to the Jenkinsfile, make sure to @ a committer and ask them to push your PR as a branch to test the changes.

TVM uses Jenkins for running Linux continuous integration (CI) tests on branches and pull requests through a build configuration specified in a Jenkinsfile. Other jobs run in GitHub Actions for Windows and MacOS jobs.

The template files in this directory are used to generate the Jenkinsfile used by Jenkins to run CI jobs for each commit to PRs and branches.

To regenerate the Jenkinsfile, run make in the ci/jenkins dir.