Add a git repository

From Apertis
Jump to: navigation, search

Contents

Add a git repository

Apertis hosts its own git repositories. These repositories are used to host code which makes up Apertis, but Apertis also makes use of code that is hosted elsewhere.

Only projects of high quality can be added to the Apertis git repositories. To ensure this, the project must fulfil some criteria:

  • The project must be free/open source software
  • It must be part of Apertis
  • You must make a commitment to maintain the project
  • To the best of your knowledge, it must not infringe on patents
  • If it re-uses free/open source code from elsewhere, it must comply with all licenses

New projects are currently assessed for compliance with these rules by the Apertis sysadmins. In future, this will be done by the Technical Steering Committee after it has been formed.

Request the git repository

Most people will need to file a task in Phabricator. You will need to include:

  • The repository name
  • A short repository description
  • Any supporting evidence to prove that your repository satisfies the prerequisites

Create the git repositories

You can only add a git repository if you have permissions to do so. Only proven developers are granted this permissions on a case-by-case basis. Most people will need to make a request for the new repository.

To create a repository, use the New project page. When creating the repository, make sure you select the correct group for it.

For the packaging for third-party software, use the packaging group. Use apertis/master as the default branch instead of master.

Create the project in Phabricator

The project should be added to Phabricator as a tag, mainly for ease of grouping related tasks together easily. Only one Phabricator project should be created for a given codebase.

  1. Open https://phabricator.apertis.org/project/edit/form/default/
  2. Set the project name (same as the git repository name) and description (ending in a full stop).
    • For packaging for third-party software, the project name should match the dpkg source package name, for example gtk+3.0.
  3. Leave the sprint settings unchecked.
  4. Set the icon to ‘Tag’ and the colour to yellow.
  5. Add additional hashtags for other names the project goes by. Do not add the project name as a hashtag, as Phabricator does this automatically.
  6. Leave the visibility, editability and joinability settings as ‘All Users’.

Link the git repository in Phabricator

This exposes the git data to Phabricator, adding context to differential revisions and allowing auto-closing tasks and revisions based on commits.

  1. Open https://phabricator.apertis.org/diffusion/edit/form/default/?vcs=git
    • Name: Whatever
    • Callsign: WHATEVER (you can abbreviate the callsign: if it is named apertis-something, use SOMETHING). For a staging repository, use the STAGING suffix, i.e. WHATEVERSTAGING.
    • Add a description (the same as above, ending in a full stop).
    • Set Projects to include the project from above, plus either ‘Apertis’ or ‘Apertis staging’.
  2. URIs, Add New URI. Fill in git@gitlab.apertis.org:/<group-name>/<repository-name>.git and set I/O type to Observe. Set Credential: SSH Key: K1 (should already be selected)
  3. Go back to the Manage page, click Policies. Set visibility settings:
    • For a public repository: Visible To: Space S3 Public, All Users; Editable By: Collabora; Can push: No one
    • For a staging repository: more restricted; copy from other staging repositories
  4. Go back to the Manage page, click Branches.
    • For a public repository: Edit Branches. Autoclose Only: regexp(/^(?!wip)/)
    • For a public packaging repository: Edit Branches. Default branch: apertis/master; Autoclose Only: regexp(/^apertis/)
    • For a staging repository: Go back to the Manage page, click Actions. Edit Actions. Autoclose: Disable Autoclose
  5. Go back to the Manage page and Activate Repository.

Wire the automation to the repository

  1. For repositories building deb packages, add the Diffusion repository to the Herald rule which triggers the Harbormaster build-snapshot build plan on every Differential submitted: Apertis-originated packages (H2) or packaging (H7)
  2. Add the package name to the appropriate job group in apertis-build-package.yaml(for native packages) or apertis-build-packaging.yaml(for normal quilt packages) to make Jenkins automatically upload source packages generated from git tags(must be apertis/$version) to the OBS :snapshot project (see the Git-based packaging workflow):
    • Pick the job group for the appropriate component (target, development, sdk, hmi)
    • Add the package name to the package: list
    • You may need to apt install jenkins-job-builder package to have the jenkins-jobs command to test and update jenkins job inside the git repository.
    • Configure your ~/.config/jenkins_jobs/jenkins_jobs.ini properly.
    • Run jenkins-jobs test apertis-build-package.yaml or jenkins-jobs test apertis-build-packaging.yaml to check that everything is ok
    • Run jenkins-jobs update apertis-build-package.yaml or jenkins-jobs update apertis-build-packaging.yaml to update the job definitions on Jenkins

The first commit for Apertis-originated software

To speed up things, make sure that the first commit contains only:

  • A README with a description of the purposed of the repository
  • A COPYING file with the text of the license under which the code is released

The repository can then be connected to the Continuous Integration (CI) system.

See also Module setup for further details on what to do in subsequent commits.

The first commits for packaging repositories

For Apertis packaging for software that originated elsewhere, the first few commits should:

Personal tools
Namespaces

Variants
Actions
Navigation
Tools