GitLab Search
Description
gitlabsearch is not an scm you clone from - it is a generator. Before anything else runs, Updatecli lists the projects of the configured GitLab group, lists the branches of each of them, keeps the branches matching branch, and turns each surviving project/branch pair into a regular gitlab scm.
Your manifest is then duplicated once per pair, each copy pinned to one project and one branch. Ten matches mean ten pipelines, ten working branches, and (if the manifest declares a gitlab/mergerequest action) ten merge requests. Everything the gitlab documentation says about cloning, working branches, commits, and signing applies unchanged to each copy.
Its behavior depends on the stage referencing it:
- source and condition
Each discovered project is cloned and the resource works on the files from the matched branch. Nothing is pushed.
- target
Updatecli creates a working branch in each discovered project, commits the changes there, and pushes it.
Important | Like the gitlab scm, this plugin does not open merge requests (that is the job of an actions block of kind gitlab/mergerequest, documented on the "GitLab Merge Request" page). |
Parameters
| Name | Type | Description | Required |
|---|---|---|---|
| branch | string | “branch” defines the git branch to work on. compatible:
default: ^main$ remark: The branch value is a regular expression used to match branches across the discovered repositories. 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 a 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:
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 passphrase used for commit signing compatible:
| |
| 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 | |
| group | string | “group” defines the GitLab group (or subgroup) to search repositories in. compatible:
remark: Supports nested groups using slash notation, e.g. “myorg/myteam”. | |
| includesubgroups | boolean | “includeSubgroups” defines whether projects from subgroups should be included in the search results. compatible:
default: true | |
| limit | integer | Limit defines the maximum number of repositories to return. compatible:
default: 10 remark: If limit is set to 0, all repositories matching the query will be returned. | |
| search | string | “search” filters the repository list by name. compatible:
remark: When omitted, all projects in the group are returned. | |
| submodules | boolean | “submodules” defines if Updatecli should checkout submodules. compatible:
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: “_” |
group is the only mandatory parameter; without it the run aborts with GitLab group is required for gitlabsearch SCM.
Apart from group, search, includeSubgroups, branch, and limit, every parameter is passed through untouched to each generated gitlab scm; see the "GitLab" page for what they do. One consequence is worth spelling out: directory is copied verbatim, so every discovered project would be cloned into the same path. Leave it unset and let Updatecli derive one path per project.
Selecting projects
groupThe group path. Nested groups use slash notation:
group: "myorg/myteam"includeSubgroupsDefaults to
true, so projects of nested subgroups are discovered too. Set it tofalseto stay in the group itself.searchAn optional GitLab project-name filter, passed to the API as-is. Omitted, every project of the group is returned. It is a substring search, not a regular expression, unlike
branch.
Each discovered project’s full path is split at the last slash: myorg/myteam/myproject becomes owner: myorg/myteam and repository: myproject on the generated scm.
Branch selection
branch is a regular expression matched against every branch name of every discovered project, not a branch name. It defaults to ^main$.
branch: "^main$" # main only (default)
branch: "^main$|^v2$" # main or v2
branch: "^release/" # every release branchAnchors matter. An unanchored expression such as main also matches maintenance, and . matches every branch in the project.
Limit
limit caps the number of generated pipelines, that is project/branch pairs - not the number of projects. It defaults to 10; 0 means no cap.
A project with three matching branches therefore consumes three slots, and can exhaust the limit before the second project is reached. Projects and branches are consumed in the order the API returns them, so a limit that truncates the set gives you an arbitrary subset rather than a chosen one. Tighten branch and search instead of relying on limit to keep a run small.
Authentication
url defaults to gitlab.com; for a self-managed instance, give its hostname with or without a scheme. token authenticates both the API calls used for discovery and the git operations on each discovered project, together with username.
# url: gitlab.example.com # defaults to gitlab.com
username: '{{ requiredEnv "GITLAB_USERNAME" }}'
token: '{{ requiredEnv "GITLAB_TOKEN" }}'The token must be able to list the group’s projects, on top of the permissions each project needs. As with the gitlab scm, a group or project access token has no user identity of its own (set user and email accordingly, or the merge requests can stay stuck in the "Your merge request is almost ready!" state).
Working branch and commit message
Both work exactly as on the "GitLab" page: a working branch named <workingBranchPrefix><separator><branch><separator><pipelineID>, force defaulting to true with its "better safe than sorry" safeguard, and conventional commit messages driven by commitMessage.
The pipelineID component is derived from the manifest, not from the project, so all copies share it and every discovered project ends up with an identically named working branch (convenient when you later need to find or clean up the branches a group-wide run created).
Note | commitMessage.title is deprecated and ignored. The commit title comes from the target name. |
Example
This manifest bumps the Golang version across the projects of the myorg/myteam group. Each discovered project/branch pair gets its own working branch, its own squashed commit, and its own merge request.
# updatecli.yaml
name: "Updatecli Golang - GitLab group"
pipelineid: "golang/version"
scms:
default:
kind: gitlabsearch
spec:
# url defaults to gitlab.com
# url: gitlab.example.com
group: "myorg/myteam"
# optional project name filter, every project of the group otherwise
search: "service"
# discover projects of nested subgroups too, true by default
includesubgroups: true
# maximum number of project/branch pairs to process
limit: 3
# "branch" is a regular expression matched against every branch name
branch: "^main$"
username: '{{ requiredEnv "GITLAB_USERNAME" }}'
token: '{{ requiredEnv "GITLAB_TOKEN" }}'
# a group or project access token has no identity of its own,
# name the bot user explicitly so GitLab can attribute the commits
user: updatecli-bot
email: updatecli-bot@updatecli.io
commitmessage:
squash: true
type: chore
scope: deps
actions:
default:
kind: gitlab/mergerequest
scmid: default
spec:
title: 'deps(golang): Bump Golang version'
labels:
- dependencies
sources:
golang:
name: Get the latest Golang version
kind: golang
spec:
versionfilter:
kind: semver
pattern: "1.24.x"
targets:
gitlab-ci:
# the commit title is generated from this name
name: 'deps(golang): Bump Golang version to {{ source "golang" }}'
kind: yaml
scmid: default
spec:
file: .gitlab-ci.yml
key: $.variables.GOLANG_VERSION