Skip to content

Commit 42c6f78

Browse files
authored
docs: add docs for CI/CD (#795)
1 parent 722fe69 commit 42c6f78

File tree

4 files changed

+78
-0
lines changed

4 files changed

+78
-0
lines changed

docs/advanced/cicd.md

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
# CI/CD Configurations
2+
3+
The CI/CD (Continuous Integration and Continuous Delivery) workflows automate various development tasks to ensure project maintainability with minimal human effort. The configuration files are located at `.github/workflows/*.yml` for GitHub and `.gitlab/workflows/*.yml` for GitLab.
4+
5+
## `ci.yml`
6+
7+
The `ci` workflow is the most frequently used workflow, running on all pull/merge requests and changes to the default `main` branch. It performs linting, testing, and builds for the documentation and the package across all supported operation systems and Python versions to ensure everything works as expected.
8+
9+
## `commitlint.yml`
10+
11+
The `commitlint` workflow checks whether the pull/merge request title comply with the <project:/development/commit.md>. This ensures consistent commit history and enable the possibility of automated release pipeline.
12+
13+
## `delete-untagged-packages.yml`
14+
15+
The `delete-untagged-packages` workflow removes untagged packages since GitHub will still keep the package when overridden with the same tag. It helps keep the GitHub Packages clean and tidy.
16+
17+
## `devcontainer.yml`
18+
19+
The `devcontainer` workflow will be triggered by container related changes. It builds and tests the development and production containers and push the development container except during pull/merge requests, ensuring seamless containerized environments.
20+
21+
## `readthedocs-preview.yml`
22+
23+
The `readthedocs-preview` workflow leverage the [readthedocs/actions/preview](https://github.com/readthedocs/actions/tree/v1/preview) to add Read the Docs preview links to the related pull requests. These links make it easy to review documentation changes.
24+
25+
## `release.yml`
26+
27+
The `release` workflow manages the entire publish process, including publishing the documentation, containers and packages. It is triggered by a new release or a release tag. It also ensures all the builds and tests are succeed before completing the release.
28+
29+
## `renovate.yml`
30+
31+
The `renovate` workflow automates the <project:/management/update.md>. It is scheduled to run weekly and will create pull/merges request when there are new versions of the scaffold template, Python packages, GitHub Runners, GitHub Actions, docker images and etc. It keeps the project secure and ensures compatibility with the latest versions.
32+
33+
## `semantic-release.yml`
34+
35+
The `semantic-release` workflow automate the versioning and release process by publishing new releases or new release tags when certain changes are pushed to the default `main` branch. It simplifies the release management while maintaining consistency.

docs/advanced/index.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,4 +5,5 @@ This section provides recommended best practices for enhancing your development
55
```{toctree}
66
dev-containers
77
partial-dev-env
8+
cicd
89
```

template/docs/advanced/cicd.md.jinja

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
# CI/CD Configurations
2+
3+
The CI/CD (Continuous Integration and Continuous Delivery) workflows automate various development tasks to ensure project maintainability with minimal human effort. The configuration files are located at `.github/workflows/*.yml` for GitHub and `.gitlab/workflows/*.yml` for GitLab.
4+
5+
## `ci.yml`
6+
7+
The `ci` workflow is the most frequently used workflow, running on all pull/merge requests and changes to the default `main` branch. It performs linting, testing, and builds for the documentation and the package across all supported operation systems and Python versions to ensure everything works as expected.
8+
9+
## `commitlint.yml`
10+
11+
The `commitlint` workflow checks whether the pull/merge request title comply with the <project:/development/commit.md>. This ensures consistent commit history and enable the possibility of automated release pipeline.
12+
13+
[% if repo_platform == 'github' -%]
14+
## `delete-untagged-packages.yml`
15+
16+
The `delete-untagged-packages` workflow removes untagged packages since GitHub will still keep the package when overridden with the same tag. It helps keep the GitHub Packages clean and tidy.
17+
18+
[% endif -%]
19+
20+
## `devcontainer.yml`
21+
22+
The `devcontainer` workflow will be triggered by container related changes. It builds and tests the development and production containers and push the development container except during pull/merge requests, ensuring seamless containerized environments.
23+
24+
[% if repo_platform == 'github' -%]
25+
## `readthedocs-preview.yml`
26+
27+
The `readthedocs-preview` workflow leverage the [readthedocs/actions/preview](https://github.com/readthedocs/actions/tree/v1/preview) to add Read the Docs preview links to the related pull requests. These links make it easy to review documentation changes.
28+
29+
[% endif -%]
30+
31+
## `release.yml`
32+
33+
The `release` workflow manages the entire publish process, including publishing the documentation, containers and packages. It is triggered by a new release or a release tag. It also ensures all the builds and tests are succeed before completing the release.
34+
35+
## `renovate.yml`
36+
37+
The `renovate` workflow automates the <project:/management/update.md>. It is scheduled to run weekly and will create pull/merges request when there are new versions of the scaffold template, Python packages, GitHub Runners, GitHub Actions, docker images and etc. It keeps the project secure and ensures compatibility with the latest versions.
38+
39+
## `semantic-release.yml`
40+
41+
The `semantic-release` workflow automate the versioning and release process by publishing new releases or new release tags when certain changes are pushed to the default `main` branch. It simplifies the release management while maintaining consistency.

template/docs/advanced/index.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,4 +5,5 @@ This section provides recommended best practices for enhancing your development
55
```{toctree}
66
dev-containers
77
partial-dev-env
8+
cicd
89
```

0 commit comments

Comments
 (0)