| `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.
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.
# 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
