Differences between revisions 51 and 135 (spanning 84 versions)
Revision 51 as of 2018-02-02 12:14:17
Size: 12370
Editor: ?formorer
Comment:
Revision 135 as of 2020-07-09 18:31:24
Size: 11160
Editor: ?JakubWilk
Comment: s/URLS/URLs/
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
= Users: Login and Registration =
 * [[DebianDeveloper|Debian Developers]] can login with their Debian email address
  * you need to use your official Debian email address in order to gain specific permissions for Debian Developers
  * Use password recovery on https://salsa.debian.org/users/sign_in to get a password for your account. Please don't use your Debian password. Salsa has its own password database.
= Support =
<<Include(Salsa/support)>>
Line 11: Line 9:
 * everyone else can register an account with an implicitly added suffix {{{-guest}}}. There is a a self service webfrontend for doing so at https://signup.salsa.debian.org/ = Users =
Line 13: Line 11:
= Namespace concepts (Users, Teams) = Register an account at https://salsa.debian.org/users/sign_in#register-pane
Line 15: Line 13:
== Debian Developers == == Unused accounts for DD before May 2020 ==
Line 17: Line 15:
Debian Developers get synced every 6 hours from LDAP and retain their Debian login as salsa username. Before May 2020 all Debian Developers had accounts created for them using their Debian user name.
Accounts that had never been used and never had a password set are deactivated.
Those accounts can only be used after being activated properly.
Please use any of the [[Salsa/Doc#Support|support channels]].
After being reactivated a new password can be set via the [[https://salsa.debian.org/users/password/new|password reset]].
Line 19: Line 21:
== External Users ==

To avoid clash with the Debian LDAP Usernames, external users get a suffix of -guest to their username.

== Groups ==
= Groups =
Line 29: Line 27:
= Projects and Repositories = == Collaborative Maintenance: "Debian" group ==
Line 31: Line 29:
A project = a repository. The `debian` group is for CollaborativeMaintenance (the old `collab-maint` on [[Alioth]]). The group is accessible to all Debian developers by default, who are automatically added with `Maintainer` access levels.
Direct commits to repositories in the Debian group by any Debian developer are implicitly welcome. No pre-commit coordination (e.g. merge-request or mail) is expected.
Line 33: Line 32:
You can create several projects in the same namespace (user or group). External users (non-Debian Developers) need to request write access to repositories inside `debian` group from a Debian developer they know, or their sponsor. Access should be granted to single projects and not the whole Debian group.
Line 35: Line 34:
Debian Developers are able to create projects in the Debian/ Namespace. It's the Salsa equivalent of 'collab-maint' on Alioth, and non-DDs (DMs or external contributors) need to be explicitly granted commit privileges for single projects. Projects under `debian` group cannot be transferred or deleted by anyone except Salsa administrators. In case you need to delete a project or have it transferred out into other namespaces, please contact Salsa administrators via support channel. See [[#Support]] section for contact information.
Line 37: Line 36:
= Email notifications =

Every project owner can enable "email on push".
To do so, go the project settings → integrations → project services → email on push and configure the list of recipients you want to send emails to.

In particular, to forward emails to tracker.debian.org, you should add `dispatch@tracker.debian.org` to the recipients (or, if for some not good reason the project name is not the name of the source package, `dispatch+${package}_vcs@tracker.debian.org` (where `${package}` is the source package name)).

= IRC notifications =
== Irker ==
Alexander Wirt is sponsoring an Irker instance. It can be enabled with the irker integration available under Settings/Integrations/Irker. Please use the following settings:

 * Server host: ruprecht.snow-crash.org
 * Server port: 6659
 * Default IRC URI: irc://irc.oftc.net:6667/

Under recipients add a newline separated list of recipients/channels. If your channel is protected by a key, use the syntax `channel-name?key=whatever` omitting the leading `#` sign (failing to omit the `#` sign will result in Irker joining a channel literally named `#channel-name?key=whatever` and doing so making your channel key public as it is visible in the bot's `/whois`.<<BR>>
Currently only Push events are supported.

== KGB ==
KGB webhook support is being worked on.

= Dealing with Debian BTS from commit messages =
We run a webhook receiver that can modify the Debian BTS based on
commit messages. If you want to use it, go to your project, "Settings
-> integrations" and add a URL (see below), then click save. No secret
token is needed, and currently it only deals with push events.

Possible URLs:
{{{
https://webhook.salsa.debian.org/close/SOURCENAME
https://webhook.salsa.debian.org/tagpending/SOURCENAME
}}}

Replace SOURCENAME with the name of your sourcepackage and chose
either close or tagpending, depending on the action you want to get.

See the code for more details: https://salsa.debian.org/salsa/webhook.

= Hints for previous users of Alioth =
''Salsa'' provides services which partially replace some features of the former [[Alioth]] service. The following hints may help you to move your packaging collaboration effort from ''Alioth'' to ''Salsa''.

Many [[Alioth]] features are (intentionally) not provided by the ''Salsa'' platform. You may want to take a look at the [[Sprints/2017/Alioth/MeetingMinutes|related discussion during a sprint]] for the detailed reasons for this decision.

{{{#!wiki important
There is significant overlap between this section and the [[Alioth#Deprecation_of_Alioth]] documentation. Those should be merged, somehow. -- TheAnarcat <<DateTime(2017-09-23T18:41:36Z)>>
}}}

== Canonical Repository URLs ==
== Canonical URLs ==
Line 103: Line 55:
== Custom Hooks ==

For security reasons it is not allowed to run arbitrary custom hooks
on repositories. You may want to write yourself a webhook receiver and
put your custom actions into such a one.

Alternatively you may use the common webhook receiver or even enhance
it with new features, see https://salsa.debian.org/salsa/webhook for
details on it.

== Import git repository ==

This is currently done by hand but Christoph Berg's wrote a handy [[http://www.df7cb.de/blog/2017/Salsa_batch_import.html|batch import script]] that you can use to import your projects semi-automatically.

Once a repository is migrated, you may want to archive the repository on Alioth. One way to do this is to add a pre-receive hook that exits with a non-zero status code, for example:
You can also use a shortcut for all Salsa repositories:
Line 120: Line 58:
$ cat /git/collab-maint/magic-wormhole.git/hooks/pre-receive
#!/bin/sh

cat <<EOF
Repository was moved to Salsa.

https://salsa.debian.org/debian/magic-wormhole

Push refused, this repository was archived. Update your remotes to use the following URL instead:

git@salsa.debian.org:debian/magic-wormhole.git

EOF
exit 1
git config --global url."git@salsa.debian.org:".insteadOf salsa:
Line 136: Line 61:
Make sure the file is executable (`chmod +x`) and also update the description similarly so the web interface shows the change as well. You can do this automatically with `~hertzog/bin/disable-repository <path-to-git-repo> <name-of-salsa-group>`. This way you can use a shorter commandline like this:
Line 138: Line 63:
You may also want to add an HTTP redirect from the old repository on Alioth to the new one on Salsa (`git://` and `git+ssh://` cannot be redirected, so you should still make sure to add the pre-receive hook above). You can do this by sending a merge request for [[https://salsa.debian.org/salsa/AliothRewriter|AliothRewriter]]. {{{
git clone salsa:debian/htop
}}}
Line 140: Line 67:
== Import non-git version control repository ==
Only git repositories are supported by the ''Salsa'' platform.
= Projects and Repositories =
Line 143: Line 69:
You may want to take a look at the [[Sprints/2017/Alioth/MeetingMinutes/VCS|reasons for not supporting other version control systems]] within ''Salsa''. In GitLab, a project is one Git repository, and each Git repository needs a project. You can create several projects in the same namespace (user or group).
Line 145: Line 71:
== Import mailing list ==
''Salsa'' does not offer any mailinglist features on its own (see [[Sprints/2017/Alioth/MeetingMinutes/Mailinglists|discussion]]). However, lists previously on alioth can be migrated to a new service retaining the same name @lists.alioth.debian.org; see [[Alioth/MailingListContinuation]] and [[https://lists.debian.org/debian-devel-announce/2018/01/msg00003.html|the announcement]].
= Email notifications =
Line 148: Line 73:
Some mailing lists that were formerly hosted on Alioth may be eligible for being hosted on [[https://lists.debian.org|lists.debian.org]]. The lists eligible for migration must follow the requirements outlined on the [[https://www.debian.org/MailingLists/HOWTO_start_list|"How to ask a mailing list" guide]]. The process is also the same as outlined on the guide. Every project owner can enable "email on push".
To do so, go the project settings → integrations → project services → emails on push and configure the list of recipients you want to send emails to.
Line 150: Line 76:
The following kind of lists are probably acceptable for [[https://lists.debian.org|lists.debian.org]]:
 * The list is expected to be useful, to have a purpose and an audience.
 * Public discussion or support lists are probably OK.
 * Commit or bug notifications lists are not OK. You should use the dedicated features of gitlab instead. If you're interested in a package's bug, you're expected to subscribe to it using the [[http://bugs.debian.org/|BTS]] features.
In particular, to forward emails to tracker.debian.org, you should add `dispatch@tracker.debian.org` to the recipients (or, if for some not good reason the project name is not the name of the source package, `dispatch+${package}_vcs@tracker.debian.org` (where `${package}` is the source package name)).
Line 155: Line 78:
Short version: file a bug on the [[https://bugs.debian.org/lists.debian.org|pseudo-package lists.debian.org]] with the severity 'wishlist', with the following information:
 * List Name
 * Rationale (why do you need this list, stating that you had one on Alioth is not enough!)
 * Short Description (for display in list indices)
 * Long Description (targeted to people that need to decide if they want to join)
 * Category
Take into account that the current implementation sends a single mail per push with all commits lumped together, which makes it rather useless for any post-review workflow. This is tracked upstream at https://gitlab.com/gitlab-org/gitlab-ce/issues/19901.
Line 162: Line 80:
Lists migrated from Alioth are expected to be open, that is:
 * Open Subscription Policy (no closed lists)
 * Open Post Policy (anybody can post)
 * Open Archive
= Information on manipulating bugs by email =
Line 167: Line 82:
If you do want the archive and/or the subscribers to be imported into your new mailing list, please:
 * on alioth, using your ssh access, run 'sudo /usr/local/bin/export-list <mailing_list_name>' to get gzipped tar archive (on stdout) containing:
  * mbox file of the archive
 * import the resulting mbox file in your favorite e-mail reader and clean the spam,
 * attach the compressed archive and/or the list of subscribers to your request.
GitLab has quite a lot of [[https://docs.gitlab.com/ee/user/project/quick_actions.html|text commands aka "quick actions"]] which can be used when interacting with GitLab via email. Most things can be done via email by replying to the [[https://docs.gitlab.com/ee/workflow/notifications.html|email notifications]]. There are special email addresses for creating new [[https://docs.gitlab.com/ee/user/project/merge_requests/#create-new-merge-requests-by-email|merge requests]] and [[https://docs.gitlab.com/ee/user/project/issues/create_new_issue.html#new-issue-via-email|issues]] via email.
Line 173: Line 84:
The export only works if the 'Is archive file source for public or private archival?' archive setting is true. = IRC notifications =
== Irker ==
Alexander Wirt is sponsoring an Irker instance. It can be enabled with the irker integration available under Settings/Integrations/Irker. Please use the following settings:
Line 175: Line 88:
Before any migration ensure that there is consense about the migration and that you have permission from the subscribers. For privacy reasons we expect that the migration process is
done by an admin of the list or the alioth project.
 * Server host: ruprecht.snow-crash.org
 * Server port: 6659
 * Default IRC URI: ircs://irc.oftc.net:6697/
Line 178: Line 92:
Also, please understand that the requirements and features for lists on lists.debian.org are not the same as for a mailing list on Alioth, and the listmaster might reject your request. Lists.debian.org is not supposed to replace all mailing lists and aliases on Alioth. Under recipients add a newline separated list of recipients/channels. If your channel is protected by a key, use the syntax `channel-name?key=whatever` omitting the leading `#` sign (failing to omit the `#` sign will result in Irker joining a channel literally named `#channel-name?key=whatever` and doing so making your channel key public as it is visible in the bot's `/whois`.<<BR>>
Currently only Push events are supported.
Line 180: Line 95:
== KGB ==
Line 181: Line 97:
== Import members of a team ==
It is not possible to transfer the members of an Alioth team to ''Salsa''. You will need to ask the members of your team to join your team on ''Salsa'' individually.
KGB supports gitlab webhooks. To use the kgb instances provided by dam, tincho, and gregoa from salsa, set a webhook in your project:
Line 184: Line 99:
== Host project web pages ==
Gitlab offer the "Gitlab Pages" feature, and it is enabled on Salsa both as '''`https://pages.debian.net/<namespace>/<project>`''' or '''`http://<namespace>.pages.debian.net/<project>`'''
{{{http://kgb.debian.net:9418/webhook/?channel=<irc-channel-name-without-#>}}}

For details, additional parameters, and helper scripts see the KGB documentation at https://salsa.debian.org/kgb-team/kgb/wikis/usage

= Dealing with Debian BTS from commit messages =
We run a webhook receiver that can modify the Debian BTS based on
commit messages. If you want to use it, go to your project, "Settings
→ Webhooks" and add a URL (see below), then click save. No secret
token is needed, and currently it only deals with push events.

Possible URLs:
{{{
https://webhook.salsa.debian.org/close/SOURCENAME
https://webhook.salsa.debian.org/tagpending/SOURCENAME
}}}

Replace SOURCENAME with the name of your source package and chose
either close or tag pending, depending on the action you want to get.

You can ignore a branch or pattern, say wip/*, by providing the
ignored-namespaces parameter. See the README in code for more details.

Code: https://salsa.debian.org/salsa/salsa-webhook.

= Deployment keys =

For automating task FIXME

= Runners =

Salsa provides [[https://docs.gitlab.com/ce/ci/runners/#shared-specific-and-group-runners|shared runners]] for all projects to use.
All jobs without more specific tags run within a privileged Docker container on one-time-use VM.
Outbound connections from the shared runner VMs are limited to http & https.

You may also add group runners for your group or specific runners and configure them for your project.

= Web page hosting =

Gitlab offer the "Gitlab Pages" feature, and it is enabled on Salsa as '''`https://<namespace>.pages.debian.net/<project>`'''
Line 189: Line 141:
See https://docs.gitlab.com/ce/user/project/pages/index.html for a detailed documentation and HOWTOs. See [[https://docs.gitlab.com/ce/user/project/pages/|the official documentation]] for details. Note that hosting pages on arbitrary domains — whilst [[https://docs.gitlab.com/ee/user/project/pages/getting_started_part_three.html|supported by upstream]] — is not supported on Salsa due to lack of bandwidth within [[Teams/DSA|DSA]] to support that feature (see [[https://rt.debian.org/Ticket/Display.html?id=7045|RT #7045]]).
Line 191: Line 143:
 * '''''Note:''' there is no SSL for <namespace>.pages.debian.net, since Let's Encrypt doesn't provide wildcard certificates yet.'' [[ChrisLamb]] has created a number of [[https://lamby.pages.debian.net/salsa-ribbons/||Github-esque "fork me on Salsa" image ribbons]] that you can add to your site.
Line 193: Line 145:
Should you want to access the pages with your own domain name and your own certificate, it is possible via ''''Settings > Pages > New Domain'''' in your project. {{{#!wiki note
https://<namespace>.pages.debian.net should work, thanks to Let's Encrypt new [[https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html|wildcard certificate support]].
}}}
Line 195: Line 149:
=== Quick start === == Quick start ==
Line 197: Line 151:
 1. On your project Home, use '''`Set up CI`''' button  1. On your project Home, use '''`Set up CI/CD`''' button. (If your project is empty, select '''`New file`''' instead.)
Line 201: Line 155:
 1. Wait a few minutes for the job to run. When it's '''`Passed`''' you can see your pages at https://pages.debian.net/<namespace>/project (or http://<namespace>.pages.debian.net/<project>/)  1. Wait a few minutes for the job to run. When it's '''`Passed`''' you can see your pages at https://<namespace>.pages.debian.net/<project>/)
Line 203: Line 157:
  * '''''Note:''' Even though we plan to support simple page generators like Jekyll or Hugo in the future, in most cases, you should content yourself with the `HTML` template, and generate the pages locally to push them afterward, in order to save the resources on the runner. Some templates might require commands not available on the server anyway.''
  * '''''Note 2: We mean that. Really.''' Be nice to the server. At some point in the future we hope to add some dedicated Runners servers - Sponsors welcome! ;).''
{{{#!wiki important
Even though we plan to support simple page generators like Jekyll or Hugo in the future, in most cases, you should content yourself with the `HTML` template, and generate the pages locally to push them afterward, in order to save the resources on the runner. Some templates might require commands not available on the server anyway.
}}}
Line 206: Line 161:
{{{#!wiki important
'''We mean that. Really.''' Be nice to the server. ;)
}}}

'''important''': (at least for static pages deployment) your artifacts must be stored in a directory named `public/`; if they are currently in a different location, use the `script` section in `.gitlab-ci.yml` to create that dir and copy the content there.
Line 209: Line 169:

== Hints for previous users of Alioth ==

See [[Salsa/AliothMigration]].

= API Usage Best practises =

 * if you want to know if a project exists, access the project by name, authenticated, if you get a 404 then it doesn't exists.
 * do not search for getting an id. If you need the id, access the project by name and use path-encoding https://docs.gitlab.com/ee/api/#namespaced-path-encoding
 * do not request all projects in a group unless you really have. If you really have to get the list, for i.e. looping, use simple=true (https://docs.gitlab.com/ee/api/groups.html#list-a-group-s-projects).
 * Implement proper pagination, please do not just requests a few hundreds elements per page
 * set an `User-Agent` header with information about the project; don't make requests with generic user agent headers
 * if you use a lib, ensure the lib does implement the api properly
 * do not run extensive jobs too often
 * please consider to use vcswatch or other data gathering projects
 * do not regularly poll things
 * if in doubt, talk to us before you code and talk to us before you put your code into production

= SSH Host Keys =

When connecting to Salsa to fetch or push a Git repo for the first time, it is essential to verify host's `ssh` keys. The keys for Salsa have been published as SSHFP DNS records as well as in the Debian [[https://db.debian.org/debian_known_hosts|known_hosts]] file. This is a one time operation. From now on ssh will trust the keys in the local `known_hosts` file.

Salsa Documentation

Salsa is a collaborative development platform within Debian.

Support

In case you encounter any problems with Salsa, to get support you may want to join us :

... they may help you.

Users

Register an account at https://salsa.debian.org/users/sign_in#register-pane

Unused accounts for DD before May 2020

Before May 2020 all Debian Developers had accounts created for them using their Debian user name. Accounts that had never been used and never had a password set are deactivated. Those accounts can only be used after being activated properly. Please use any of the support channels. After being reactivated a new password can be set via the password reset.

Groups

Users and Group share the same namespace. To prevent clashes with usernames we enforce groups to a '-team' suffix, with the exception being the 'Debian' group, of which all Debian Developers are members.

To create a group, log in and go to the team registration page. There is also a link to it from the registration page: if you're not logged in yet, you will be asked to do so and be redirected afterwards.

Collaborative Maintenance: "Debian" group

The debian group is for CollaborativeMaintenance (the old collab-maint on Alioth). The group is accessible to all Debian developers by default, who are automatically added with Maintainer access levels. Direct commits to repositories in the Debian group by any Debian developer are implicitly welcome. No pre-commit coordination (e.g. merge-request or mail) is expected.

External users (non-Debian Developers) need to request write access to repositories inside debian group from a Debian developer they know, or their sponsor. Access should be granted to single projects and not the whole Debian group.

Projects under debian group cannot be transferred or deleted by anyone except Salsa administrators. In case you need to delete a project or have it transferred out into other namespaces, please contact Salsa administrators via support channel. See #Support section for contact information.

Canonical URLs

The canonical URLs for use in debian/control are:

Vcs-Browser: https://salsa.debian.org/<user-or-team>/<package>
Vcs-Git: https://salsa.debian.org/<user-or-team>/<package>.git

where <user-or-team> is

  • alice for DD Alice Developer <alice@debian.org>

  • bob-guest for non-DD Bob Coder <bobc@example.com>

  • debian for the Debian/ namespace (the equivalent to collab-maint on alioth)

  • foobar-team for the Foobar Packaging Team

You can instruct git to rewrite URLs into pushable ssh URLs:

git config --global url."git@salsa.debian.org:".pushInsteadOf "https://salsa.debian.org/"

This will work for all salsa repositories checked out via https:// URLs in the present, past or future.

You can also use a shortcut for all Salsa repositories:

git config --global url."git@salsa.debian.org:".insteadOf salsa:

This way you can use a shorter commandline like this:

git clone salsa:debian/htop

Projects and Repositories

In GitLab, a project is one Git repository, and each Git repository needs a project. You can create several projects in the same namespace (user or group).

Email notifications

Every project owner can enable "email on push". To do so, go the project settings → integrations → project services → emails on push and configure the list of recipients you want to send emails to.

In particular, to forward emails to tracker.debian.org, you should add dispatch@tracker.debian.org to the recipients (or, if for some not good reason the project name is not the name of the source package, dispatch+${package}_vcs@tracker.debian.org (where ${package} is the source package name)).

Take into account that the current implementation sends a single mail per push with all commits lumped together, which makes it rather useless for any post-review workflow. This is tracked upstream at https://gitlab.com/gitlab-org/gitlab-ce/issues/19901.

Information on manipulating bugs by email

GitLab has quite a lot of text commands aka "quick actions" which can be used when interacting with GitLab via email. Most things can be done via email by replying to the email notifications. There are special email addresses for creating new merge requests and issues via email.

IRC notifications

Irker

Alexander Wirt is sponsoring an Irker instance. It can be enabled with the irker integration available under Settings/Integrations/Irker. Please use the following settings:

Under recipients add a newline separated list of recipients/channels. If your channel is protected by a key, use the syntax channel-name?key=whatever omitting the leading # sign (failing to omit the # sign will result in Irker joining a channel literally named #channel-name?key=whatever and doing so making your channel key public as it is visible in the bot's /whois.
Currently only Push events are supported.

KGB

KGB supports gitlab webhooks. To use the kgb instances provided by dam, tincho, and gregoa from salsa, set a webhook in your project:

http://kgb.debian.net:9418/webhook/?channel=<irc-channel-name-without-#>

For details, additional parameters, and helper scripts see the KGB documentation at https://salsa.debian.org/kgb-team/kgb/wikis/usage

Dealing with Debian BTS from commit messages

We run a webhook receiver that can modify the Debian BTS based on commit messages. If you want to use it, go to your project, "Settings → Webhooks" and add a URL (see below), then click save. No secret token is needed, and currently it only deals with push events.

Possible URLs:

https://webhook.salsa.debian.org/close/SOURCENAME
https://webhook.salsa.debian.org/tagpending/SOURCENAME

Replace SOURCENAME with the name of your source package and chose either close or tag pending, depending on the action you want to get.

You can ignore a branch or pattern, say wip/*, by providing the ignored-namespaces parameter. See the README in code for more details.

Code: https://salsa.debian.org/salsa/salsa-webhook.

Deployment keys

For automating task FIXME

Runners

Salsa provides shared runners for all projects to use. All jobs without more specific tags run within a privileged Docker container on one-time-use VM. Outbound connections from the shared runner VMs are limited to http & https.

You may also add group runners for your group or specific runners and configure them for your project.

Web page hosting

Gitlab offer the "Gitlab Pages" feature, and it is enabled on Salsa as https://<namespace>.pages.debian.net/<project>

This feature makes use of Gitlab-CI to generate static pages in a public directory, on every push.

See the official documentation for details. Note that hosting pages on arbitrary domains — whilst supported by upstream — is not supported on Salsa due to lack of bandwidth within DSA to support that feature (see RT #7045).

ChrisLamb has created a number of https://lamby.pages.debian.net/salsa-ribbons/ that you can add to your site.

https://<namespace>.pages.debian.net should work, thanks to Let's Encrypt new wildcard certificate support.

Quick start

  1. On your project Home, use Set up CI/CD button. (If your project is empty, select New file instead.)

  2. Choose a Gitlab CI Yaml template (Pages templates are at the end)

  3. Edit the template to suit your needs and save it
  4. Push something to the repository. You will see there is a CI Job pending
  5. Wait a few minutes for the job to run. When it's Passed you can see your pages at https://<namespace>.pages.debian.net/<project>/)

Even though we plan to support simple page generators like Jekyll or Hugo in the future, in most cases, you should content yourself with the HTML template, and generate the pages locally to push them afterward, in order to save the resources on the runner. Some templates might require commands not available on the server anyway.

We mean that. Really. Be nice to the server. ;)

important: (at least for static pages deployment) your artifacts must be stored in a directory named public/; if they are currently in a different location, use the script section in .gitlab-ci.yml to create that dir and copy the content there.

Getting Help

See the Salsa maintenance description.

Hints for previous users of Alioth

See Salsa/AliothMigration.

API Usage Best practises

  • if you want to know if a project exists, access the project by name, authenticated, if you get a 404 then it doesn't exists.
  • do not search for getting an id. If you need the id, access the project by name and use path-encoding https://docs.gitlab.com/ee/api/#namespaced-path-encoding

  • do not request all projects in a group unless you really have. If you really have to get the list, for i.e. looping, use simple=true (https://docs.gitlab.com/ee/api/groups.html#list-a-group-s-projects).

  • Implement proper pagination, please do not just requests a few hundreds elements per page
  • set an User-Agent header with information about the project; don't make requests with generic user agent headers

  • if you use a lib, ensure the lib does implement the api properly
  • do not run extensive jobs too often
  • please consider to use vcswatch or other data gathering projects
  • do not regularly poll things
  • if in doubt, talk to us before you code and talk to us before you put your code into production

SSH Host Keys

When connecting to Salsa to fetch or push a Git repo for the first time, it is essential to verify host's ssh keys. The keys for Salsa have been published as SSHFP DNS records as well as in the Debian known_hosts file. This is a one time operation. From now on ssh will trust the keys in the local known_hosts file.