From 3ec555ed013e006862238b76d29ba21a1b7987d9 Mon Sep 17 00:00:00 2001
From: Pierre Smeyers <pierre.smeyers@gmail.com>
Date: Thu, 23 May 2024 12:11:27 +0200
Subject: [PATCH] docs: enhance semantic-release with other TBC templates
chapter
---
README.md | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/README.md b/README.md
index a1f77fd..a00a0c1 100644
--- a/README.md
+++ b/README.md
@@ -213,7 +213,7 @@ There are actually 2 questions that will determine the required configuration:
* _Application Deployment_ mode should trigger the release directly from your production branch (`main` or `master` by default),
* _Software Distribution_ mode should trigger the release through a tag pipeline.
2. does the release involve **changing files in your repository** (and therefore creating a Git commit)?
- * that will be the case if you use plugins such as [@semantic-release/changelog](https://github.com/semantic-release/changelog) or the [semantic-release-replace](https://github.com/jpoehnelt/semantic-release-replace-plugin)
+ * that will be the case if you use plugins such as [@semantic-release/changelog](https://github.com/semantic-release/changelog) or [semantic-release-replace](https://github.com/jpoehnelt/semantic-release-replace-plugin)
### Case 1: _Application Deployment_ mode
@@ -221,9 +221,11 @@ As said previously, if you're using the _Application Deployment_ delivery mode i
In that case you'll need to:
-1. enable the [semantic-release info job](#semantic-release-info-job),
+1. enable the [semantic-release info job](#semantic-release-info-job),<br/>
+ _this is the job that will provide next release information to the other template(s)_
* by setting `info-on` / `SEMREL_INFO_ON` to `prod` (or any suitable non-empty value)
2. disable the [semantic-release job](#semantic-release-job),
+ _the release will be handled by other template(s) directly from the production branch_
* by setting `release-disabled` / `SEMREL_RELEASE_DISABLED` to `true`
3. make sure the other template(s) provide a semantic-release integration to perform the release from the semantic-release info job.
Templates supporting it:
@@ -251,8 +253,8 @@ In that case, when semantic-release determines a release is required, it will:
* create a Git tag with the next release version,
* push the commit + the tag.
-Problem: by default, semantic-release creates a Git commit with comment `chore(release): release ${nextRelease.version} [skip ci]`.
-The `[skip ci]` part prevents GitLab from triggering the tag pipeline, therefore preventing other to-be-continuous templates from publishing their versioned packages.
+Problem: by default, semantic-release creates a Git commit with comment `chore(release): release ${nextRelease.version} [skip ci]`.\
+:information_source: The `[skip ci]` part is problematic as it prevents GitLab from triggering the tag pipeline, therefore preventing other to-be-continuous templates from publishing their versioned packages.
To fix this, you'll have to override the default semantic-release Git commit comment in order not to prevent the tag pipeline from being triggered.
With this done:
@@ -262,7 +264,10 @@ With this done:
#### How to override the Git commit comment
-In most cases it is recommended to use `chore(release): release ${nextRelease.version} [skip ci on prod]` (the `[skip ci on prod]` part prevents GitLab from triggering the pipeline on your production branch only, **but not the tag pipeline**).
+In most cases it is recommended to use `chore(release): release ${nextRelease.version} [skip ci on prod]` as message template.\
+:information_source: the `[skip ci on prod]` part prevents GitLab from triggering the pipeline on your production branch only, **but not the tag pipeline**.
+
+#### Using a configuration file
If you're configuring semantic-release with a configuration file in your repository, then the Git commit message has to be configured in the [@semantic-release/git](https://github.com/semantic-release/git#message) plugin section.
@@ -298,7 +303,9 @@ branches:
tagFormat: '${version}'
```
-If you're not configuring semantic-release with a configuration file (but using default configuration provided by the template), then the Git commit message can be configured with the `commit-message` / `SEMREL_COMMIT_MESSAGE` input / variable:
+#### Using implicit configuration
+
+If you're not configuring semantic-release with a configuration file (but using implicit configuration provided by the template), then the Git commit message can be configured with the `commit-message` / `SEMREL_COMMIT_MESSAGE` input / variable:
```yaml
variables:
--
GitLab