GitLab
Description
The gitlab scm plugin clones a repository hosted on GitLab (gitlab.com or a self-managed instance) and pushes changes back to it. It is referenced by a resource through its scmid, as described on the "SCM" page.
Its behavior depends on the stage referencing it:
- source and condition
The repository is cloned and the resource works on the files from the branch defined by
branch. Nothing is pushed.- target
Updatecli creates a working branch based on
branch, commits the changes to it, and pushes that branch. Thebranchvalue itself is left untouched.
Important | This plugin does not open merge requests. Pushing a working branch and opening a merge request are two distinct steps: the merge request comes from an actions block of kind gitlab/mergerequest, documented on the "GitLab Merge Request" page. Without such an action, the branch is pushed and nothing else happens. |
Parameters
| Name | Type | Description | Required |
|---|---|---|---|
| branch | string | “branch” defines the git branch to work on. compatible:
default: main remark: depending on which resource references the GitLab scm, the behavior will be different. If the scm is linked to a source or a condition (using scmid), the branch will be used to retrieve file(s) from that branch. If the scm is linked to target then Updatecli creates a new “working branch” based on the branch value.
The working branch created by Updatecli looks like “updatecli_ | |
| commitmessage | object | “commitMessage” is used to generate the final commit message. compatible:
remark: it’s worth mentioning that the commit message settings is applied to all targets linked to the same scm. | |
| body | string | body defines the commit body of the commit message as defined by the conventional commit specification. More information on -> https://www.conventionalcommits.org/en/ default: none | |
| deprecatedtitle | string | DeprecatedTitle is deprecated and will be ignored. The commit title is now always generated from the target name or description. | |
| footers | string | footers defines the footer of the commit message as defined by the conventional commit specification. More information on -> https://www.conventionalcommits.org/en/ default: none | |
| hidecredit | boolean | hideCredit defines if updatecli credits should be displayed inside commit message body please consider sponsoring the Updatecli project if you want to disable credits. -> https://github.com/updatecli/updatecli default: false | |
| scope | string | scope defines the scope of the commit message as defined by the conventional commit specification. More information on -> https://www.conventionalcommits.org/en/ default: none | |
| squash | boolean | squash defines if the commit should be squashed default: false important: if squash is set to true, then it’s highly recommended to set the commit body to a meaningful value as all other commit information will be lost during the squash operation. if body is not set, then the commit title/message will be generated based on the most recent commit message of the squashed commits. The commit title is always generated from the target name or description. | |
| title | string | Title is the parsed commit message title (not configurable via YAML). The title is automatically generated from the target name or description. | |
| type | string | type defines the type of commit message such as “chore”, “fix”, “feat”, etc. as defined by the conventional commit specification. More information on -> https://www.conventionalcommits.org/en/ default:
| |
| depth | integer | Depth defines the depth used when cloning the git repository. Default: disabled (full clone) Remark: When using a shallow clone (depth greater than 0), Updatecli is not able to retrieve the full git history. This may cause some issues when Updatecli tries to push changes to the remote repository. In that case, you may need to set the force option to true to force push changes to the remote repository. | |
| directory | string | “directory” defines the local path where the git repository is cloned. compatible: * scm remark: Unless you know what you are doing, it is recommended to use the default value. The reason is that Updatecli may automatically clean up the directory after a pipeline execution. default:
The default value is based on your local temporary directory like: (on Linux)
/tmp/updatecli/gitlab/ | |
| string | “email” defines the email used to commit changes. compatible:
default: default set to your global git configuration | ||
| force | boolean | “force” is used during the git push phase to run compatible:
default: true remark: When force is set to true, Updatecli also recreates the working branches that diverged from their base branch. | |
| gpg | object | “gpg” specifies the GPG key and passphrased used for commit signing. compatible: * scm | |
| passphrase | string | passphrase defines the gpg passphrase used to sign the commit message | |
| signingkey | string | signingKey defines the gpg key used to sign the commit message default: none | |
| owner | string | “owner” defines the owner of a repository. compatible:
| |
| repository | string | repository specifies the name of a repository for a specific owner. compatible:
| |
| submodules | boolean | “submodules” defines if Updatecli should checkout submodules. compatible: * scm default: true | |
| token | string | “token” defines the credential used to authenticate with GitLab remark: A token is a sensitive information, it’s recommended to not set this value directly in the configuration file but to use an environment variable or a SOPS file. The value can be set to For more information, about a SOPS file, please refer to the following documentation: https://github.com/getsops/sops | |
| url | string | “url” defines the GitLab url to interact with default: “gitlab.com” | |
| user | string | “user” specifies the user associated with new git commit messages created by Updatecli. compatible:
| |
| username | string | “username” defines the username used to authenticate with GitLab | |
| workingbranch | boolean | “workingBranch” defines if Updatecli should use a temporary branch to work on.
If set to compatible:
default: true | |
| workingbranchprefix | string | WorkingBranchPrefix defines the prefix used to create a working branch. compatible:
default: updatecli remark: A working branch is composed of three components:
If WorkingBranchPrefix is set to ‘’, then
the working branch will look like “ | |
| workingbranchseparator | string | WorkingBranchSeparator defines the separator used to create a working branch. compatible:
default: “_” |
owner and repository are mandatory, a missing one aborts the run with wrong gitlab configuration. For a project nested in subgroups, owner carries the full group path:
owner: "mygroup/mysubgroup"
repository: "myproject"Note | The table is generated from the Updatecli JSON schema, refreshed by a bot after each release. A recently added parameter (currently singleBranch, which restricts clone and fetch to the configured branch) may work in the binary before it appears there. |
Authentication
url defaults to gitlab.com. For a self-managed instance, give its hostname with or without a scheme; https:// is assumed when none is given.
token is used both for the GitLab API and, together with username, as the HTTP credentials for git operations. Keep it out of the manifest:
# url: gitlab.example.com # defaults to gitlab.com
username: '{{ requiredEnv "GITLAB_USERNAME" }}'
token: '{{ requiredEnv "GITLAB_TOKEN" }}'The token needs read access for a source or a condition, and write access to the repository for a target. Reading from a public repository works without any credential.
Personal vs group or project access tokens
A personal access token carries the identity of the user it belongs to, so GitLab attributes the commits to that account.
Group and project access tokens do not. Combined with the default commit identity (updatecli-bot <updatecli-bot@updatecli.io>, which matches no GitLab account), the commits end up attributed to nobody, and the merge request Updatecli opens can remain stuck in the "Your merge request is almost ready!" state. Set user and email to the identity the token acts as:
user: "<the bot user name shown by GitLab for that token>"
email: "<the bot user email shown by GitLab for that token>"Working branch
For a target, the working branch is derived from three components joined by a separator:
<workingBranchPrefix><workingBranchSeparator><branch><workingBranchSeparator><pipelineID>With the defaults (updatecli and ), a pipeline based on main produces updatecli_main<pipelineID>, where pipelineID is a hash derived from the manifest - so the same pipeline reuses the same branch instead of piling up new ones. Characters git refuses in a ref are stripped, and the name is truncated to 255 characters. Setting workingBranchPrefix: "" gives <branch>_<pipelineID>.
branch defaults to main, with a warning in the logs when it is left unset.
Disabling the working branch
workingBranch: false makes Updatecli commit and push straight to branch. Since force defaults to true (meaning git push --force), that combination is refused unless force is also set explicitly:
Better safe than sorry.
Updatecli may be pushing unwanted changes to the branch "main".Set force: false to push without forcing, or force: true to acknowledge the force push. When force is true, Updatecli also recreates working branches that diverged from their base branch.
Tip | updatecli apply --clean-git-branches deletes, at the end of a run, the working branches that ended up identical to their base branch (those left behind by pipelines that had nothing to change). |
Commit message
Updatecli generates conventional commits. The commitMessage parameters (type, scope, body, footers, hideCredit, squash) shape the result.
The commit title always comes from the target’s name, or from its description when name is unset. It is capped at 72 characters minus the room taken by type and scope; the overflow moves into the body. With the default type chore:
Author: updatecli-bot <updatecli-bot@updatecli.io>
Date: Tue May 4 15:41:44 2021 +0200
chore: Update key "dependencies[0].version" from file "charts/jenkins/r...
... equirements.yaml"
Made with ❤️️ by updatecliSetting body replaces the generated body entirely, including that overflow. hideCredit: true drops the credit line. squash: true collapses the commits of the working branch into one (set body when you use it, since the individual messages are lost).
Warning |
|
Note | commitMessage applies to every target linked to the same scm. |
Commit signing
gpg.signingkey takes an armored private GPG key and gpg.passphrase its passphrase. Both are secrets:
gpg:
signingkey: '{{ requiredEnv "GPG_SIGNING_KEY" }}'
passphrase: '{{ requiredEnv "GPG_PASSPHRASE" }}'Clone behavior
Left unset, directory defaults to <tmp>/updatecli/gitlab/<owner>/<repository> - /tmp/updatecli/gitlab/olblak/updatecli on Linux. Overriding it is rarely useful, as Updatecli may clean that directory up after a run.
submodulesDefaults to
true; set it tofalseto skip submodule checkout.depthNumber of commits to fetch. Unset means a full clone. A shallow clone leaves an incomplete history, which can break pushes;
force: trueis often needed alongside.singleBranchDefaults to
false, meaning every branch, tag, and ref is fetched.truefetches onlybranch(much faster on repositories with many refs, at the cost of Updatecli sometimes failing to notice an already published working branch and opening a duplicate merge request).
Tip | To run the same manifest against every project of a group instead of a single repository, use the gitlabsearch scm. |
Example
# updatecli.yaml
---
name: Show Gitlab scm
scms:
gitlab:
kind: gitlab
spec:
# By default url is set to gitlab.com
# url: gitlab.com
owner: "olblak"
repository: "updatecli"
branch: main
sources:
license:
name: Retrieve license file content
kind: file
scmid: gitlab
spec:
file: LICENSE