Commit 8b148e9b authored by Hordur Freyr Yngvason's avatar Hordur Freyr Yngvason
Browse files

Merge branch 'jarv/add-semantic-release' into 'master'

feat: Add support for semantic-release

Closes #15

See merge request gitlab-org/cluster-integration/auto-deploy-image!24
parents 9b2c7349 b5f54f5f
Loading
Loading
Loading
Loading
+42 −8
Original line number Diff line number Diff line
@@ -152,6 +152,24 @@ test-initialize-tiller:
    - auto-deploy create_secret
    - kubectl get secret gitlab-registry -n $KUBE_NAMESPACE

# This template is used for the publish jobs, which do the following:
#   * Check to see if there is a version bump based on
#     [Conventional Commits (v1.0.0-beta.2)](https://www.conventionalcommits.org/en/v1.0.0-beta.2/)
#     See README.md for more information
#   * If there is a new release it will tag the repository with the new release as the `ops-gitlab-net`
#     user

.semantic-release:
  image: node:12
  stage: release
  before_script:
    - npm install -g semantic-release @semantic-release/gitlab
  script:
    - semantic-release $DRY_RUN_OPT -b $CI_COMMIT_REF_NAME
  only:
    variables:
      - $CI_API_V4_URL == "https://gitlab.com/api/v4"

test-create-secret-public-project:
  <<: *test-job
  variables:
@@ -216,17 +234,19 @@ test-create-application-secret:
release-tag:
  stage: release
  image: docker:stable
  variables:
    # e.g. auto-deploy-image:v1.0.0
    RELEASE_IMAGE_NAME: "$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME"
  services:
    - docker:stable-dind
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - docker pull "$BUILD_IMAGE_NAME"
    - docker tag "$BUILD_IMAGE_NAME" "$RELEASE_IMAGE_NAME"
    - docker push "$RELEASE_IMAGE_NAME"
    - 'echo ${CI_JOB_TOKEN} | docker login --password-stdin -u $CI_REGISTRY_USER $CI_REGISTRY'
    - export ci_image="${CI_REGISTRY_IMAGE}"
    - export ci_image_tag=${CI_COMMIT_TAG:-$CI_COMMIT_SHORT_SHA}
    - echo "Using tag $ci_image_tag for image"
    - docker build --cache-from ${ci_image}:latest
      --tag ${ci_image}:$ci_image_tag
      --tag ${ci_image}:latest
      -f Dockerfile-ci .
    - docker push $ci_image:latest
    - docker push $ci_image:$ci_image_tag
  only:
    - tags

@@ -257,3 +277,17 @@ before_script:
      export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
      kubectl version
    }

publish:
  extends: .semantic-release
  only:
    refs:
      - master

public-dryrun:
  extends: .semantic-release
  variables:
    DRY_RUN_OPT: '-d'
  only:
    refs:
      - branches

.releaserc.yml

0 → 100644
+10 −0
Original line number Diff line number Diff line
---

verifyConditions:
  - "@semantic-release/gitlab"
prepare: false
publish:
  - "@semantic-release/gitlab"
success: false
fail: false
npmPublish: false
+33 −1
Original line number Diff line number Diff line
@@ -24,3 +24,35 @@ template will use the Docker image generated from this project. Changes from pre
* `install_dependencies` is removed as it is now part of the Docker image.
*  All the other commands should be prepended with `auto-deploy`.
   For example, `check_kube_domain` now becomes `auto-deploy check_kube_domain`.

# Generating a new auto-deploy image

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

## Git Commit Guidelines

This project uses [Semantic Versioning](https://semver.org). We use commit
messages to automatically determine the version bumps, so they should adhere to
the conventions of [Conventional Commits (v1.0.0-beta.2)](https://www.conventionalcommits.org/en/v1.0.0-beta.2/).

### TL;DR

- Commit messages starting with `fix: ` trigger a patch version bump
- Commit messages starting with `feat: ` trigger a minor version bump
- Commit messages starting with `BREAKING CHANGE: ` trigger a major version bump.

## Automatic versioning

Each push to `master` triggers a [`semantic-release`](https://semantic-release.gitbook.io/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>'
```