A simplified way to provision and manage networks for EKS on AWS.
This repository that brings together all the network resources needed to provision and maintain an EKS on AWS.
To use this module, you will need to make a link to this repo, and will use the resources like we did make in the example path.
Just create a branch from the main branch and open a Pull Request. When your code was committed, a new release will be created by the pipeline, based on the commit message.
semantic-release uses the commit messages to determine the consumer impact of changes in the codebase. Following formalized conventions for commit messages, semantic-release automatically determines the next semantic version number, generates a changelog and publishes the release.
By default, semantic-release uses Angular Commit Message Conventions.
The commit message format can be changed with the preset
or config
options of the @semantic-release/commit-analyzer and @semantic-release/release-notes-generator plugins.
Tools such as commitizen or commitlint can be used to help contributors and enforce valid commit messages.
The table below shows which commit message gets you which release type when semantic-release
runs (using the default configuration):
Commit message | Release type |
---|---|
fix(pencil): stop graphite breaking when too much pressure applied |
|
feat(pencil): add 'graphiteWidth' option |
|
perf(pencil): remove graphiteWidth option BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons. |
(Note that the BREAKING CHANGE: token must be in the footer of the commit) |