feat: semantic release integration (fabf9b9b) · Commits · to be continuous... / Docker

README.md

+20 −0

Original line number	Diff line number	Diff line
		@@ -419,6 +419,7 @@ This job pushes (_promotes_) the built image as the _release_ image [skopeo](htt
		\| `DOCKER_PUBLISH_ARGS` \| Additional [`skopeo copy` arguments](https://github.com/containers/skopeo/blob/master/docs/skopeo-copy.1.md#options) \| _(none)_ \|
		\| `AUTODEPLOY_TO_PROD` \| Set to enable automatic publish (and deploy) on `master` branch \| _none_ (enabled) \|
		\| `PUBLISH_ON_PROD` \| Determines whether this job is enabled on `master` branch \| `true`_ (enabled) \|
		\| `DOCKER_SEMREL_RELEASE_DISABLED` \| Set to `true` to disable [semantic-release integration](#semantic-release-integration) \| _none_ (enabled) \|

		This job produces _output variables_ that are propagated to downstream jobs (using [dotenv artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#artifactsreportsdotenv)):

		@@ -432,6 +433,25 @@ This job produces _output variables_ that are propagated to downstream jobs (usi

		They may be freely used in downstream jobs (for instance to deploy the upstream built Docker image, whatever the branch or tag).

		### `semantic-release` integration

		If you activate the [`semantic-release-info` job from the `semantic-release` template](https://gitlab.com/to-be-continuous/semantic-release/#semantic-release-info-job), the `docker-publish` job will rely on the generated next version info.

		* the release will only be performed if a semantic release is present
		* the tag will be based on `SEMREL_INFO_NEXT_VERSION`, it will override `DOCKER_RELEASE_IMAGE` by simply substituting the tag, or adding a tag when there's none.

		For instance, in both cases:

		```yml
		DOCKER_RELEASE_IMAGE: "registry.gitlab.com/$CI_PROJECT_NAME"
		DOCKER_RELEASE_IMAGE: "registry.gitlab.com/$CI_PROJECT_NAME:$CI_COMMIT_REF_NAME"
		```
		The published Docker image will be `registry.gitlab.com/$CI_PROJECT_NAME:$SEMREL_INFO_NEXT_VERSION` and all subsequent jobs relying on the `docker_image` variable will be provided with this tag.

		:warning: When `semantic-release` detects no release (i.e. either the semantic-release template is misconfigured, or there were simply no `feat`/`fix` commits), the `docker-publish` job will report a warning and no image will be pushed in the release registry. In such a case, the `docker_image` remains unchanged, and will refer to the snapshot image. Any subsequent job that may deploy to production (Kubernetes or Openshift), should thus be configured not to deploy in this situation. Refer to deployment template for more information.

		Finally, the semantic-release integration can be disabled with the `DOCKER_SEMREL_RELEASE_DISABLED` variable.

		## Examples

		### Using the GitLab Docker registry

kicker.json

+5 −0

Original line number	Diff line number	Diff line
		@@ -70,6 +70,11 @@
		"default": "true",
		"type": "boolean"
		},
		{
		"name": "DOCKER_SEMREL_RELEASE_DISABLED",
		"description": "Disable integration with the [semantic release template](https://gitlab.com/to-be-continuous/semantic-release/)",
		"type": "boolean"
		},
		{
		"name": "DOCKER_REGISTRY_MIRROR",
		"description": "URL of a Docker registry mirror to use instead of default `https://index.docker.io`"

templates/gitlab-ci-docker.yml

+19 −7

Original line number	Diff line number	Diff line
		@@ -709,8 +709,9 @@ docker-sbom:
		# ==================================================
		# Stage: publish
		# ==================================================
		# This stage only run when you put a new tag to the git repository (a good tag format would be x.x.x ex: 1.0.2, see https://semver.org/)
		# It will push the release tagged image to the chosen Registry
		# When semantic release is integrated, this stage run on main pipeline
		# When semantic release is not integrated, this stage only run when you put a new tag to the git repository (a good tag format would be x.x.x ex: 1.0.2, see https://semver.org/)
		# In both cases, it will push the release tagged image to the chosen Registry
		docker-publish:
		extends: .docker-base
		image:
		@@ -719,9 +720,20 @@ docker-publish:
		stage: publish
		variables:
		GIT_STRATEGY: none
		dependencies: []
		script:
		- \|
		if [[ "${SEMREL_INFO_ON}" && "${DOCKER_SEMREL_RELEASE_DISABLED}" != "true" ]]
		then
		if [[ -z "${SEMREL_INFO_NEXT_VERSION}" ]]
		then
		log_warn "[semantic-release] no new version to release: skip"
		exit 0
		else
		DOCKER_RELEASE_IMAGE=$(echo "$DOCKER_RELEASE_IMAGE" \| sed "s/$:.*$\{0,1\}$/:$SEMREL_INFO_NEXT_VERSION/")
		log_info "[semantic-release] new Image tag is set: $DOCKER_RELEASE_IMAGE"
		fi
		fi

		if [[ "$DOCKER_SNAPSHOT_IMAGE" == "$DOCKER_RELEASE_IMAGE" ]]
		then
		log_warn "\\e[93mYou should consider distinguishing snapshot and release images as they do not differ. Skipping publish phase as image has already been created by previous job.\\e[0m"
		@@ -742,16 +754,16 @@ docker-publish:
		dotenv:
		- docker.env
		rules:
		# on tag: always
		- if: $CI_COMMIT_TAG
		# on tag: if semrel info not enabled or semrel integration disabled
		- if: '$CI_COMMIT_TAG && ($SEMREL_INFO_ON == null \|\| $SEMREL_INFO_ON == "" \|\| $DOCKER_SEMREL_RELEASE_DISABLED == "true")'
		# exclude non-production branches
		- if: '$CI_COMMIT_REF_NAME !~ $PROD_REF'
		when: never
		# exclude if $PUBLISH_ON_PROD disabled
		- if: '$PUBLISH_ON_PROD != "true"'
		when: never
		# exclude if snapshot is same as release image
		- if: '$DOCKER_SNAPSHOT_IMAGE == $DOCKER_RELEASE_IMAGE'
		# exclude if snapshot is same as release image and semrel info not enabled or semrel integration disabled
		- if: '$DOCKER_SNAPSHOT_IMAGE == $DOCKER_RELEASE_IMAGE && ($SEMREL_INFO_ON == null \|\| $SEMREL_INFO_ON == "" \|\| $DOCKER_SEMREL_RELEASE_DISABLED == "true")'
		when: never
		# if $AUTODEPLOY_TO_PROD: auto
		- if: '$AUTODEPLOY_TO_PROD == "true"'