Skip to content

CI workflow

This project has multiple CI workflows to let developers could do the best at focusing on writing code, doesn't get distracted by other chores. And some CI workflows could guarantee the project code quality, validation of feature could work finely, etc.

Here records all the CI workflows of this project runs.

Pre-Commit CI

pre-commit.ci status

  • CI state

    Here's the state of workflow.

  • Trigger points

    Every git commit. This workflow always runs before each CI workflows.

  • Target doing

    Doing some checking of Python code and YAML format configuration.

PR Bot CI

Bot PR

  • CI state

    Here's the state of workflow.

  • Trigger points

    When anyone developers approve the PR which be tagged by tag dependencies, it would trigger this CI workflow.

  • Target doing

    It would wait for 20 minutes and merge the approved PR with tag dependencies if it still doesn't be merged yet.

Why we need this CI workflow?

Sometimes, it would have multiple PRs about upgrading dependencies in the same time. But before merge later new PR, it needs to wait to do git rebase after previous other PRs be merged. This CI workflow exists for resolving the chores.

Source code by PR bot CI

Bot CI

  • CI state

    Here's the state of workflow.

  • Trigger points

    When any PRs be opened by GitHub dependency bot and also be tagged by tag dependencies, it would trigger this CI workflow.

  • Target doing

    Run all tests includes unit tests, integration tests and system tests to guarantee all the project features work finely with the dependency upgrading.

Only run tests

This CI workflow won't upload test coverage report and also won't trigger SonarQube scan of code quality.

pr bot ci

Source code CI

CI

Quality Gate Status codecov

  • CI state

    Here's the state of workflow.

  • Trigger points

    General PR which be opened in developer branch as naming format develop/** and also ignore some specific files or directories like CI workflow folder, documentation folder, etc. And also the PR doesn't have tag dependencies.

  • Target doing

    It would run all tests (unit test, integration test and system test) and record all test coverage reports of each test with different runtime environment OS and Python version. It would also trigger SonarQube scan to check coding style (this would also be checked in pre-commit CI), security or something details about code quality. And finally, it would try to test to run the command line mock to ensure it should work finely.

source code ci

CD

CD

  • CI state

    Here's the state of workflow.

  • Trigger points

    Only occur version info change in the source code module __pkg_info__.

  • Target doing

    It would create new git tag and git release info. After tag and release building, it would build the source code as Python package and push it to PyPI service.

cd

How to trigger the deployment workflow exactly?

In the Python projects which be builded by Chisanan232, it must have a module about the Python package info. And it has software version info __version__. It has only one way to trigger the deployment workflow: update the version info.

In package info source code:

... # other code

__version__ = "0.2.0"    # update this version info to trigger the CD workflow

... # other code

Docker CI

docker

  • CI state

    Here's the state of workflow.

  • Trigger points

    Same as CI workflow CD.

  • Target doing

    It would build the Docker image and push it to DockerHub.

Documentation CI

documentation pages-build-deployment

  • CI state

    Here's the state of workflows.

  • Trigger points

    • For latest version:

      All relative files about documentation includes CI workflow, document content, etc.

    • For latest stable version:

      Same as CI workflow CD.

  • Target doing

    It would build versioning content and commit it into git branch gh-pages to trigger another CI workflow. And the GitHub Pages CI workflow would deploy the documentation into GitHub pages.

    It has 2 different workflows for different versions:

    • For deployment latest version document:

      About any files which relative documentation be updated, it would deploy the content to documentation. So the content of this version would always be the latest.

    • For deployment latest stable version document:

      Only when software version be updated in package info module would trigger the after-process of this workflow, it would try to get the software version as the version to deploy the content to specific version of documentation.

documentation cd

After version info change, it would trigger these CI/CD workflows

When occur version info change, it would trigger following CI/CD workflows: