Automate your CI pipeline with ease - you'll find binaries and functions that help you simplify the process.
CI Pilot aims to provide direction and guidance towards setting up the ideal software delivery pipeline as well as fully automating it.
There are plenty of incredible players on the market that aid in production release management and publishing, and CI Pilot doesn't aim to compete with them, rather to bridge the gap and standardise their use in coordination with your Git methodology (focusing on GitHubFlow and GitFlow).
Looking at the most well used release management tools (semantic-release, standard-version, etc.), there's a clear lack of in-depth focus on how to go about producing internal packages during the development life-cycle, pre-production. CI Pilot steps in with out of the box support for the following:
- Feature/Bug-Fix/Hot-Fix branch alpha releases, Git tagging the branch and publishing a package
- For GitFlow adopters, Alpha releases, Git tagging the development branch and publishing a package
npm:
npm i --save-dev ci-pilot
Yarn:
yarn add -D ci-pilot
Supported commands:
publish
release-gh-gf
helper
ci-pilot publish [stage]
ci-pilot publish feature
ci-pilot release-gh-fg [step]
ci-pilot release-gh-gf cut
ci-pilot release-gh-gf stage
ci-pilot release-gh-gf finish
Additional command-line flags:
--auto-bump-change-log
or-a
: This flag when specified will use standard-version under the hood to generate the next release version based on the Conventional Commits preset chosen, bump thepackage.json
version, generate or update the change log, and Git tag the commit with the version.--merge-msg-skip-ci
or-m
: This flag will suffix GitFlow merge commits with[skip ci]
, a common convention used to avoid additional jobs being triggered in your CI pipeline.
ci-pilot release-gh-gf scrap
ci-pilot helper [helper]
ci-pilot helper package-name
ci-pilot helper is-repo-gitflow
Create a file called ci-pilot.config.json
in the root of the repository, and populate it with the following:
Default (fully expanded):
{
"packageManager": "npm",
"gitMethodology": "...",
"branchNames": {
"base": "master",
"feature": "feature",
"hotfix": "hotfix",
"development": "develop",
"bugfix": "bugfix"
},
"release": {
"preset": "angular",
"tagPrefix": "v"
},
"gitBranchSeparator": "/",
"tagSeparator": "#"
}
Alternate example:
{
"gitMethodology": "...",
"branchNames": {
"base": "main",
"feature": "topic",
"gitBranchSeparator": "-",
"tagSeparator": "$"
}
Configuration Options:
packageManager
: Options, npm or yarn, defaults to npmgitMethodology
: Mandatory, GitFlow or GitHubFlowbranchNames.base
: Optional, defaults to masterbranchNames.feature
: Optional, defaults to featurebranchNames.hotfix
: Optional, defaults to hotfixbranchNames.development
: Optional, defaults to developbranchNames.bugfix
: Optional, defaults to bugfixrelease.preset
: Optional, defaults to angularrelease.tagPrefix
: Optional, defaults to vgitBranchSeparator
: Options: / | -, defaults to /tagSeparator
: Options: # | £ | $, defaults to #
Note: CI Pilot uses your package manager of choice under the hood, npm or yarn. Ensuring that your CI pipeline is configured correctly for npm or yarn remains your responsibility and is out of scope for CI Pilot.
We have different recommendations on how to use CI Pilot based on the progress of the code change through your software release pipeline - see details below.
Publish packages on features you're developing by adding the following command as a step in your CI pipeline:
ci-pilot publish feature
Note: We don't recommend committing feature branch versions bumps to Git, as the pre-release alpha versions would eventually be merged into base or development branches which is wrong. Instead we believe that Git tags are sufficient to mark the origin of built packages that are uploaded to your package registries.
Our strategy:
- Version the package(s) in the repository locally
- Publish the packages (containing the
package.json
file for built assets contain the alpha feature version) - Wipe away the version changes in the Git working tree
If you're working in a mono-repo then the above command will detect that and by default publish all workspace packages. If you wish to only publish only one of the packages in the mono-repo then you should include the --package-only
flag otherwise the command will fail, as it's not our recommendation.
Thanks goes to these wonderful people (emoji key):
Colin Agbabiaka 🤔 🚇 💻 |
Jamie Halvorson 🤔 💻 |
This project follows the all-contributors specification. Contributions of any kind welcome!