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

NameTypeDescriptionRequired
branchstring

“branch” defines the git branch to work on.

compatible:

  • scm

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_”. The working branch can be disabled using the “workingBranch” parameter set to false.

commitmessageobject

“commitMessage” is used to generate the final commit message.

compatible:

  • scm

remark: it’s worth mentioning that the commit message settings is applied to all targets linked to the same scm.

    bodystring

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

    deprecatedtitlestringDeprecatedTitle is deprecated and will be ignored. The commit title is now always generated from the target name or description.
    footersstring

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

    hidecreditboolean

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

    scopestring

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

    squashboolean

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.

    titlestringTitle is the parsed commit message title (not configurable via YAML). The title is automatically generated from the target name or description.
    typestring

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:

  • chore
depthinteger

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.

directorystring

“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//

emailstring

“email” defines the email used to commit changes.

compatible:

  • scm

default: default set to your global git configuration

forceboolean

“force” is used during the git push phase to run git push --force.

compatible:

  • scm

default: true

remark: When force is set to true, Updatecli also recreates the working branches that diverged from their base branch.

gpgobject

“gpg” specifies the GPG key and passphrase used for commit signing

compatible:

  • scm
    passphrasestringpassphrase defines the gpg passphrase used to sign the commit message
    signingkeystring

signingKey defines the gpg key used to sign the commit message

default: none

groupstring

“group” defines the GitLab group (or subgroup) to search repositories in.

compatible:

  • scm

remark: Supports nested groups using slash notation, e.g. “myorg/myteam”.

includesubgroupsboolean

“includeSubgroups” defines whether projects from subgroups should be included in the search results.

compatible:

  • scm

default: true

limitinteger

Limit defines the maximum number of repositories to return.

compatible:

  • scm

default: 10

remark: If limit is set to 0, all repositories matching the query will be returned.

searchstring

“search” filters the repository list by name.

compatible:

  • scm

remark: When omitted, all projects in the group are returned.

submodulesboolean

“submodules” defines if Updatecli should checkout submodules.

compatible:

  • scm

default: true

tokenstring

“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 {{ requiredEnv "GITLAB_TOKEN"}} to retrieve the token from the environment variable GITLAB_TOKEN or {{ .gitlab.token }} to retrieve the token from a SOPS file.

For more information, about a SOPS file, please refer to the following documentation: https://github.com/getsops/sops

urlstring

“url” defines the GitLab url to interact with

default: “gitlab.com”

userstring

“user” specifies the user associated with new git commit messages created by Updatecli

compatible:

  • scm
usernamestring“username” defines the username used to authenticate with GitLab
workingbranchboolean

“workingBranch” defines if Updatecli should use a temporary branch to work on. If set to true, Updatecli create a temporary branch to work on, based on the branch value.

compatible:

  • scm

default: true

workingbranchprefixstring

WorkingBranchPrefix defines the prefix used to create a working branch.

compatible:

  • scm

default: updatecli

remark: A working branch is composed of three components:

  1. WorkingBranchPrefix
  2. Target Branch
  3. PipelineID

If WorkingBranchPrefix is set to ‘’, then the working branch will look like “_”.

workingbranchseparatorstring

WorkingBranchSeparator defines the separator used to create a working branch.

compatible:

  • scm

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

group

The group path. Nested groups use slash notation:

group: "myorg/myteam"
includeSubgroups

Defaults to true, so projects of nested subgroups are discovered too. Set it to false to stay in the group itself.

search

An 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 branch

Anchors 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