Skip to content

Latest commit

 

History

History
159 lines (121 loc) · 10.4 KB

README.md

File metadata and controls

159 lines (121 loc) · 10.4 KB
Raw

CI/CD

Table of Contents

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

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

A PR which changes the version.txt is considered as a release PR in the following coontext.

Code Style Check

Workflow Name File name Description
Pre-commit pre_commit.yml This workflow runs pre-commit checks for code style consistency for PRs.
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 if Pre-commit fails.

Unit Test

Workflow Name File name Description
Build on PR build_on_pr.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.
Build on Schedule build_on_schedule.yml This workflow will run the unit tests everyday with 8 GPUs. The result is sent to Lark.
Report test coverage report_test_coverage.yml This PR will put up a comment to report the test coverage results when Build is done.

Example Test

Workflow Name File name Description
Test example on PR example_check_on_pr.yml The example will be automatically tested if its files are changed in the PR
Test example on Schedule example_check_on_schedule.yml This workflow will test all examples every Sunday. The result is sent to Lark.
Example Test on Dispatch example_check_on_dispatch.yml Manually test a specified example.

Example Test on Dispatch

This workflow is triggered by manually dispatching the workflow. It has the following input parameters:

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

Compatibility Test

Workflow Name File name Description
Compatibility Test on PR compatibility_test_on_pr.yml Check Colossal-AI's compatiblity when version.txt is changed in a PR.
Compatibility Test on Schedule compatibility_test_on_schedule.yml This workflow will check the compatiblity of Colossal-AI against PyTorch specified in .compatibility every Sunday.
Compatiblity Test on Dispatch compatibility_test_on_dispatch.yml Test PyTorch Compatibility manually.

Compatibility Test on Dispatch

This workflow is triggered by manually dispatching the workflow. It has the following input 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

Release

Workflow Name File name Description
Draft GitHub Release Post draft_github_release_post_after_merge.yml Compose a GitHub release post draft based on the commit history when a release PR is merged.
Publish to PyPI release_pypi_after_merge.yml Build and release the wheel to PyPI when a release PR is merged. The result is sent to Lark.
Publish Nightly Version to PyPI release_nightly_on_schedule.yml Build and release the nightly wheel to PyPI as colossalai-nightly every Sunday. The result is sent to Lark.
Publish Docker Image to DockerHub after Merge release_docker_after_merge.yml Build and release the Docker image to DockerHub when a release PR is merged. The result is sent to Lark.
Check CUDA Extension Build Before Merge cuda_ext_check_before_merge.yml Build CUDA extensions with different CUDA versions when a release PR is created.
Publish to Test-PyPI Before Merge release_test_pypi_before_merge.yml Release to test-pypi to simulate user installation when a release PR is created.

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.
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.

Commmunity

Workflow Name File name Description
Generate Community Report and Send to Lark report_leaderboard_to_lark.yml Collect contribution and user engagement stats and share with Lark every Friday.

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.

  1. .cuda_ext.json

This file controls which CUDA versions will be checked against CUDA extenson built. You can add a new entry according to the json schema below to check the AOT build of PyTorch extensions before release.

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

Progress Log

  • Code style check
    • pre-commit check
    • pre-commit failure report
  • unit testing
    • test on PR
    • report test coverage
    • regular test
  • release
    • pypi release
    • test-pypi simulation
    • nightly build
    • docker build
    • draft release post
  • example check
    • check on PR
    • regular check
    • manual dispatch
  • compatiblity check
    • check on PR
    • manual dispatch
    • auto test when release
  • community
    • contribution report
    • user engagement report
  • helpers
    • comment translation
    • submodule update
    • close inactive issue