CI/CD

Table of Contents

• CI/CD
  • Table of Contents
  • Overview
  • Workflows
    • Checks on Pull Requests
    • Regular Checks
    • Release
    • Manual Dispatch
      • Release bdist wheel
      • Dispatch Example Test
      • Compatibility Test
    • User Friendliness
  • Configuration
  • Progress Log

Overview

Automation makes our development more efficient as the machine automatically run the pre-defined tasks for the contributors. This saves a lot of manual work and allow the developer to fully focus on the features and bug fixes. In Colossal-AI, we use GitHub Actions to automate a wide range of workflows to ensure the robustness of the software. In the section below, we will dive into the details of different workflows available.

Workflows

Checks on Pull Requests

Workflow Name	File name	Description
Build	build.yml	This workflow is triggered when the label Run build and Test is assigned to a PR. It will run all the unit tests in the repository with 4 GPUs.
Pre-commit	pre_commit.yml	This workflow runs pre-commit checks for code style consistency.
Report pre-commit failure	report_precommit_failure.yml	This PR will put up a comment in the PR to explain the precommit failure and remedy. This is executed when Pre-commit is done
Report test coverage	report_test_coverage.yml	This PR will put up a comment to report the test coverage results. This is executed when Build is completed.
Test example	auto_example_check.yml	The example will be automatically tested if its files are changed in the PR

Regular Checks

Workflow Name	File name	Description
Test example	auto_example_check.yml	This workflow will test all examples every Sunday
Compatibility Test	auto_compatibility_test.yml	This workflow will check the compatiblity of Colossal-AI against PyTorch and CUDA every Sunday. The PyTorch and CUDA versions are specified in .compatibility.
Build on 8 GPUs	build_gpu_8.yml	This workflow will run the unit tests everyday with 8 GPUs.
Synchronize submodule	submodule.yml	This workflow will check if any git submodule is updated. If so, it will create a PR to update the submodule pointers.
Close inactive issues	close_inactive.yml	This workflow will close issues which are stale for 14 days.

Release

Workflow Name	File name	Description
Draft GitHub Release Post	draft_github_release_post.yml	Compose a GitHub release post draft based on the commit history. Triggered when the change of version.txt is merged.
Release to PyPI	release_pypi.yml	Build and release the wheel to PyPI. Triggered when the change of version.txt is merged.
Release Nightly to PyPI	release_nightly.yml	Build and release the nightly wheel to PyPI as colossalai-nightly. Automatically executed every Sunday.
Release Docker	release_docker.yml	Build and release the Docker image to DockerHub. Triggered when the change of version.txt is merged.
Release bdist wheel	release_bdist.yml	Build binary wheels with pre-built PyTorch extensions. Manually dispatched. See more details in the next section.
Auto Release bdist wheel	auto_release_bdist.yml	Build binary wheels with pre-built PyTorch extensions.Triggered when the change of version.txt is merged. Build specificatons are stored in .bdist.json
Auto Compatibility Test	auto_compatibility_test.yml	Check Colossal-AI's compatiblity against the PyTorch and CUDA version specified in .compatibility. Triggered when version.txt is changed in a PR.

Manual Dispatch

Workflow Name	File name	Description
Release bdist wheel	release_bdist.yml	Build binary wheels with pre-built PyTorch extensions.
Dispatch Example Test	dispatch_example_check.yml	Manually test a specified example.
Dispatch Compatiblity Test	dispatch_compatiblity_test.yml	Test PyTorch and Python Compatibility.

Refer to this documentation on how to manually trigger a workflow. I will provide the details of each workflow below.

Release bdist wheel

Parameters:

• torch version:torch version to test against, multiple versions are supported but must be separated by comma. The default is value is all, which will test all available torch versions listed in this repository which is regularly updated.
• cuda version: cuda versions to test against, multiple versions are supported but must be separated by comma. The CUDA versions must be present in our DockerHub repository.
• ref: input the branch or tag name to build the wheel for this ref.

Dispatch Example Test

parameters:

• example_directory: the example directory to test. Multiple directories are supported and must be separated by comma. For example, language/gpt, images/vit. Simply input language or simply gpt does not work.

Compatibility Test

Parameters:

• torch version:torch version to test against, multiple versions are supported but must be separated by comma. The default is value is all, which will test all available torch versions listed in this repository.
• cuda version: cuda versions to test against, multiple versions are supported but must be separated by comma. The CUDA versions must be present in our DockerHub repository.

It only test the compatiblity of the main branch

User Friendliness

Workflow Name	File name	Description
issue-translate	translate_comment.yml	This workflow is triggered when a new issue comment is created. The comment will be translated into English if not written in English.

Configuration

This section lists the files used to configure the workflow.

1. .compatibility

This .compatibility file is to tell GitHub Actions which PyTorch and CUDA versions to test against. Each line in the file is in the format ${torch-version}-${cuda-version}, which is a tag for Docker image. Thus, this tag must be present in the docker registry so as to perform the test.

2. .bdist.json

This file controls what pytorch/cuda compatible pre-built releases will be built and published. You can add a new entry according to the json schema below if there is a new wheel that needs to be built with AOT compilation of PyTorch extensions.

{
  "build": [
    {
      "torch_version": "",
      "cuda_image": ""
    },
  ]
}

Progress Log

• unit testing
  • test on PR
  • report test coverage
  • regular test
• release
  • official release
  • nightly build
  • binary build
  • docker build
  • draft release post
• pre-commit
  • check on PR
  • report failure
• example check
  • check on PR
  • regular check
  • manual dispatch
• compatiblity check
  • manual dispatch
  • auto test when release
• helpers
  • comment translation
  • submodule update
  • close inactive issue