| `mvn-semrel-release-disabled` / `MVN_SEMREL_RELEASE_DISABLED` | Set to `true` to disable [semantic-release integration](#semantic-release-integration) | _none_ (disabled) |
| `GIT_USER_NAME` | Git user name to use when committing (global TBC variable) | `$GITLAB_USER_NAME` |
| `GIT_USER_EMAIL` | Git user email to use when committing (global TBC variable) | `$GITLAB_USER_EMAIL` |
| :lock: `GIT_SIGNING_KEY_GPG` | Git GPG signing key to use for commit signing (global TBC variable) | _none_ (disabled) |
| :lock: `GIT_SIGNING_KEY_SSH` | Git SSH signing key to use for commit signing (global TBC variable) | _none_ (disabled) |
More info:
@@ -426,6 +430,8 @@ We recommend you to use a [project deploy key](https://docs.gitlab.com/user/proj
The key should not have a passphrase (see [how to generate a new SSH key pair](https://docs.gitlab.com/user/ssh/#generate-an-ssh-key-pair)).
Note: It is strongly recommended to use a Service Account user (GitLab Premium feature), rather than a human user, to create the deploy key. This helps avoid the risks and limitations outlined in the [Security implications](https://docs.gitlab.com/user/project/deploy_keys/#security-implications) section.
Specify :lock: `$GIT_PRIVATE_KEY` as protected project variable with the private part of the deploy key.
```PEM
@@ -448,7 +454,7 @@ The template handles both classic variable and file variable.
##### Using Git user authentication
Simply specify :lock: `$GIT_USERNAME` and :lock: `$GIT_PASSWORD` as protected project variables and they will be dynamically
Simply specify :lock: `$GIT_USER_NAME` and :lock: `$GIT_PASSWORD` as protected project variables, and they will be dynamically
evaluated and appended to the Maven release arguments.
Note that the password should be an access token with `write_repository` scope and `Maintainer` role.
@@ -463,6 +469,44 @@ Note that the password should be an access token with `write_repository` scope a
</scm>
```
#### Working around Push Rules
A Maven release involves some Git commit and push operations, which might fail in projects where one or more [push rules](https://docs.gitlab.com/user/project/repository/push_rules/) have been activated.
##### "Reject unverified users" and "Reject inconsistent user name" push rules
With these rules enabled, the Git push will fail unless the commit author name and committer email match the name and email of the user that _authenticated the push_.
* If an **SSH key** is used, this will be the user associated with that SSH key.
* If a **deploy key** is used, this will be the user that created the deploy key.
* If a **deploy token** is used, this will be the deploy token bot user.
During a Maven release, however, the Git user name and email will be derived from the user that _triggered the release job_ instead, which may or may not be the same user.
To work around this, you can explicitly set the `$GIT_USER_NAME` and `$GIT_USER_EMAIL` variables to the appropriate user's name and email.
##### "Reject unsigned commits" push rule
With this rule enabled, the Git push will fail unless all commits are signed.
While GitLab supports commit signing via GPG, SSH, and X.509, the Maven template currently only supports GPG and SSH.
###### Automatic commit signing using GPG
To enable automatic commit signing using GPG, you must generate a GPG keypair, add its public key to the appropriate user, and configure its private key as the :lock: `$GIT_SIGNING_KEY_GPG` protected project variable.
###### Automatic commit signing using SSH
To enable automatic commit signing using SSH, you must generate an SSH keypair, add its public key to the appropriate user (with usage type `Signing`), and configure its private key as the :lock: `$GIT_SIGNING_KEY_SSH` protected project variable.
:warning: SSH commit signing requires Git version 2.34 or higher in your build image.
Note: If you are already using SSH key authentication using `$GIT_PRIVATE_KEY`, the same SSH key can be used for commit signing, provided its usage type was set to `Authentication & Signing`. You can configure this as follows: