commit type

ci commit template

A commit that changes CI/CD pipeline configuration files and scripts: GitHub Actions, GitLab CI, CircleCI, Dockerfile, or deployment scripts.

format

ci(scope): short imperative description of the pipeline change

- what workflow, job, or step was added or modified (bullet 1)
- what trigger or condition was changed (bullet 2)
- any performance or reliability improvement (bullet 3)

Why the CI change was necessary: new requirement, flaky test fix,
cost reduction, or environment update. Max 72 chars/line.

real examples

ci(github-actions): add release workflow with semantic-release

- add .github/workflows/release.yml triggered on push to main
- configure semantic-release with @semantic-release/github and npm plugins
- add GITHUB_TOKEN and NPM_TOKEN to required workflow secrets

Releases were manual and inconsistent; semantic-release derives the next
version from commit history and publishes automatically on every main push.

ci(test): split unit and integration tests into parallel jobs

- add unit-tests and integration-tests jobs that run concurrently
- move db setup and migrations to integration-tests job only
- reduce total CI time from 8m to 3m on typical PRs

Unit tests were blocked on database setup even though they do not use the
db; parallelising them removes the unnecessary dependency.

ci(docker): switch base image from node:18 to node:20-alpine

- update Dockerfile FROM to node:20-alpine
- pin to node:20.14.0-alpine3.19 for reproducible builds
- remove manual SSL cert update step no longer needed in alpine 3.19

node:18 reaches end of life in April 2025; alpine base reduces the
final image from 1.1GB to 210MB.

ci(dependabot): add weekly dependency update schedule for npm and actions

- add .github/dependabot.yml with package-ecosystem: npm and github-actions
- set schedule to weekly on Monday at 09:00 UTC
- add reviewers and labels for automated triage

Dependencies were only updated manually when a vulnerability was reported;
automated PRs ensure routine updates surface before they accumulate.

when to use

Use ci for changes to pipeline definition files, Dockerfiles, deployment scripts, and CI configuration. If the change also modifies application source code, consider splitting it.

git-agent automatically analyzes your changes and infers the correct commit type.

brew install gitagenthq/brew/git-agent

FAQ

What is the difference between ci and chore for pipeline changes?

ci is specifically for CI/CD pipeline files (.github/workflows/, .gitlab-ci.yml, Jenkinsfile). chore covers other maintenance. Use ci for pipeline changes to make them easy to filter in git log.

Should Dockerfile changes use ci or chore?

Either is acceptable. ci is appropriate when the Dockerfile is part of the CI/CD pipeline definition. chore or build is appropriate when it defines the production runtime image. Be consistent within your project.

Does ci appear in public changelogs?

No. ci commits are internal infrastructure changes with no relevance to users or API consumers, and are excluded from all standard changelog presets.

What are Conventional Commits?chore commit template Conventional changelog