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 {hierarchy|collection|flat}] [--dataset DATASET] [-r] [-R LEVELS] [-s NAME] [--existing {skip|error|reconfigure}] [--access {http|ssh|ssh+http}] [--publish-depends SIBLINGNAME] [--description DESCRIPTION] [--dryrun] [PATH ...]
An existing GitLab project, or a project created via the GitLab web interface can be configured as a sibling with the siblings command. Alternativly, this command can create a GitLab project at any location/path a given user has appropriate permissions for. This is particulary 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.html#configuration 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 three different project layouts (see --layout):
"hierarchy" Each dataset is placed into its own group, and the actual GitLab project for a dataset is put in a project named "_repo_" inside this group. Using this layout, arbitrarily deep hierarchies of nested datasets can be represented, while the hierarchical structure is reflected in the project path. This is the default layout, if no project path is specified. "flat" All datasets are placed in the same group. The name of a project is its relative path within the root dataset, with all path separator characters replaced by '--'. "collection" This is a hybrid layout, where the root dataset is placed in a "_repo_" project inside a group, and all nested subdatasets are represented inside the group using a "flat" layout.
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.
All configuration switches and options for GitLab sibling creation can be provided 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.
datalad is developed by The DataLad Team and Contributors <team@datalad.org>.
2021-02-04 | datalad create-sibling-gitlab 0.14.0 |