| datalad create-sibling-gitlab(1) | General Commands Manual | datalad create-sibling-gitlab(1) |
datalad create-sibling-gitlab - create dataset sibling at a GitLab site
datalad create-sibling-gitlab [-h] [--site SITENAME] [--project NAME/LOCATION] [--layout {collection|flat}] [--dataset DATASET] [-r] [-R LEVELS] [-s NAME] [--existing {skip|error|reconfigure}] [--access {http|ssh|ssh+http}] [--publish-depends SIBLINGNAME] [--description DESCRIPTION] [--dryrun] [--dry-run] [--version] [PATH ...]
An existing GitLab project, or a project created via the GitLab web interface can be configured as a sibling with the siblings command. Alternatively, this command can create a GitLab project at any location/path a given user has appropriate permissions for. This is particularly helpful for recursive sibling creation for subdatasets. API access and authentication are implemented via python-gitlab, and all its features are supported. A particular GitLab site must be configured in a named section of a python-gitlab.cfg file (see https://python-gitlab.readthedocs.io/en/stable/cli-usage.html#configuration-file-format for details), such as::
[mygit] url = https://git.example.com api_version = 4 private_token = abcdefghijklmnopqrst
Subsequently, this site is identified by its name ('mygit' in the example above).
(Recursive) sibling creation for all, or a selected subset of subdatasets is supported with two different project layouts (see --layout):
"flat" All datasets are placed as GitLab projects in the same group. The project name of the top-level dataset follows the configured datalad.gitlab-SITENAME-project configuration. The project names of contained subdatasets extend the configured name with the subdatasets' s relative path within the root dataset, with all path separator characters replaced by '-'. This path separator is configurable (see Configuration). "collection" A new group is created for the dataset hierarchy, following the datalad.gitlab-SITENAME-project configuration. The root dataset is placed in a "project" project inside this group, and all nested subdatasets are represented inside the group using a "flat" layout. The root datasets project name is configurable (see Configuration).
GitLab cannot host dataset content. However, in combination with other data sources (and siblings), publishing a dataset to GitLab can facilitate distribution and exchange, while still allowing any dataset consumer to obtain actual data content from alternative sources.
Many configuration switches and options for GitLab sibling creation can be provided as arguments to the command. However, it is also possible to specify a particular setup in a dataset's configuration. This is particularly important when managing large collections of datasets. Configuration options are:
"datalad.gitlab-default-site"
Name of the default GitLab site (see --site)
"datalad.gitlab-SITENAME-siblingname"
Name of the sibling configured for the local dataset that points
to the GitLab instance SITENAME (see --name)
"datalad.gitlab-SITENAME-layout"
Project layout used at the GitLab instance SITENAME (see --layout)
"datalad.gitlab-SITENAME-access"
Access method used for the GitLab instance SITENAME (see --access)
"datalad.gitlab-SITENAME-project"
Project "location/path" used for a datasets at GitLab instance
SITENAME (see --project). Configuring this is useful for deriving
project paths for subdatasets, relative to superdataset.
The root-level group ("location") needs to be created beforehand
via
GitLab's web interface. "datalad.gitlab-default-projectname"
The collection layout publishes (sub)datasets as projects
with a custom name. The default name "project" can be overridden
with
this configuration. "datalad.gitlab-default-pathseparator"
The flat and collection layout represent subdatasets with project names
that correspond to their path within the superdataset, with the regular path
separator replaced
with a "-": superdataset-subdataset. This configuration can be used
to override
this default separator.
This command can be configured with "datalad.create-sibling-ghlike.extra-remote-settings.NETLOC.KEY=VALUE" in order to add any local KEY = VALUE configuration to the created sibling in the local `.git/config` file. NETLOC is the domain of the Gitlab instance to apply the configuration for. This leads to a behavior that is equivalent to calling datalad's ``siblings('configure', ...)``||``siblings configure`` command with the respective KEY-VALUE pair after creating the sibling. The configuration, like any other, could be set at user- or system level, so users do not need to add this configuration to every sibling created with the service at NETLOC themselves.
datalad is developed by The DataLad Team and Contributors <team@datalad.org>.
| 2025-06-15 | datalad create-sibling-gitlab 1.1.5 |