The Auto-DevOps deploy stage image.
Please see API documentation
Scripts in this repository follow GitLab's
shell scripting guide
and enforces shellcheck and shfmt.
Please see CONTRIBUTING.md
Starting from GitLab 12.2, the Jobs/Deploy.gitlab-ci.yml
template will use the Docker image generated from this project. Changes from previous version of Jobs/Deploy.gitlab-ci.yml include:
sh to bash.install_dependencies is removed as it is now part of the Docker image.auto-deploy.
For example, check_kube_domain now becomes auto-deploy check_kube_domain.Before v1.0.0, auto-deploy-image was downloading a chart from the chart repository, which was then uploaded by the auto-deploy-app project.
Since auto-deploy-image v1.0.0, the auto-deploy-app chart is bundled into the auto-deploy-image docker image as a local asset, and it no longer downloads the chart from the repository.
To generate a new image you must follow the git commit guidelines below, this will trigger a semantic version bump which will then cause a new pipeline that will build and tag the new image
This project uses Semantic Versioning. We use commit messages to automatically determine the version bumps, so they should adhere to the conventions of Conventional Commits (v1.0.0).
fix: trigger a patch version bumpfeat: trigger a minor version bumpBREAKING CHANGE: trigger a major version bump. This can be part of commits of any type.Testing the commit message locally can speed up the iteration cycle. It can be configured as follows:
# install dev dependencies, if necessary
npm install
# usage
npx commitlint --from=master # if targeting latest
npx commitlint --from=1.x # if targeting 1.x stable
To save yourself the manual step of testing the commit message, you can use a commit hook.
At the root of this project, add .git/hooks/commit-msg with the following contents:
#!/bin/sh
npx commitlint --edit
Then, run chmod +x .git/hooks/commit-msg to make it executable.
Each push to master triggers a semantic-release
CI job that determines and pushes a new version tag (if any) based on the
last version tagged and the new commits pushed. Notice that this means that if a
Merge Request contains, for example, several feat: commits, only one minor
version bump will occur on merge. If your Merge Request includes several commits
you may prefer to ignore the prefix on each individual commit and instead add
an empty commit summarizing your changes like so:
git commit --allow-empty -m '[BREAKING CHANGE|feat|fix]: <changelog summary message>'
For backporting a change to a previous release, please follow this recipe.
Here is an example:
Given you have
v2.0.0 tag, which is the latest tag of v2.v1.1.1 tag, which is the latest tag of v1.master branch, which points to v2.0.0.and you want to release a bug fix to both v1 and v2 releases.
You process the following actions:
1.x branch from v1.1.1.1.x branch. semantic-release creates a release with v1.1.2 tag.master branch. semantic-release creates a release with v2.0.1 tag.NOTE: NOTE
Ensure that the maintenance release branch (e.g. 1.x) is protected.
For publishing a pre-release, please follow this recipe.
Here is an example:
Given you have
v1.1.1 tag, which is the latest tag of v1.master branch, which points to v1.1.1.and you want to publish a pre-release.
You process the following actions:
beta branch from the latest master.beta branch. semantic-release creates a release with 2.0.0-beta.1 tag.beta to master. semantic-release creates a release with 2.0.0 tag.beta branch on https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/branchesNOTE: NOTE
Ensure that the pre-release release branch (e.g. beta) is protected.
Content type
Image
Digest
Size
48.4 MB
Last updated
over 5 years ago
docker pull elemenx/auto-deploy-image