Connect a New GitLab Repository or Group

This guide explains how to get a new GitLab repository, or repositories in a
different GitLab group, building and deploying through SVIEW.

When you need this

• You have a new application in GitLab and want it deployed to one or more
  Environments.
• You are moving existing projects to a different GitLab group or namespace,
  or copying them into a new one, and want them to keep deploying.
• You want the same pipeline setup you already have in one group to work in a
  second group.

In every case the pipeline connection has to be set up for the new location.
It does not follow a project automatically.

Prerequisites

• GitLab access for CTO2B on the new project or group. Grant the
  cto2bgeneric account Maintainer on each project. If the pipeline will
  use CI/CD variables defined on the group — the usual case when several
  projects share the same registry credentials and SVIEW endpoint — grant
  Owner on that group instead, because GitLab does not let a Maintainer
  read or set group-level variables. See
  GitLab Access for CTO2B for the details.
• A Dockerfile in the repository, so the pipeline can build an image.

What to send in your request

Raise a request in your dedicated Slack channel with:

Use a separate image repository per Environment. Registry retention rules
apply to every image in a repository, so sharing one repository between
development and production lets routine development pushes push a production
image out of retention.

What happens next

flowchart LR
  A[Access granted] --> B[Pipeline and CI/CD variables set up]
  B --> C[Application Component added in SVIEW]
  C --> D[First push builds and deploys]

1. Pipeline setup. We add or adapt the .gitlab-ci.yml so it builds the
   image, scans it, pushes it to the image repository, and tells SVIEW to
   deploy the new version. The CI/CD variables it needs — registry
   credentials, the SVIEW endpoint, and the deploy token — are set on the
   project or on the group.
2. Application Component. Each target Environment gets an application
   Component for the new app, if it does not have one already. See
   Components and Deployments for how Components are organised.
3. First deployment. The first push to the configured branch runs the full
   pipeline and deploys to the matching Environment.

Moving projects between GitLab groups

A GitLab project transfer carries the project's history and its
project-level CI/CD variables, but never the group-level variables of
the group it left. A pipeline that relied on them can keep working for a while
and then start failing with empty or invalid registry credentials, with no
change to the pipeline file.

To avoid that:

1. Tell us before you transfer, and name the destination group.
2. Grant CTO2B the access described above on the destination group.
3. After the transfer, run a pipeline on each moved project and confirm it
   deploys.

A newly created top-level group starts with no group-level variables at all,
so every project moved into it needs the full setup.

If your team signs in to SVIEW with GitLab accounts, mention in the request
whether people are moving to a new group too, since SVIEW access can be tied
to GitLab group membership.

Verify it worked

• The pipeline in GitLab completes all stages, including the deploy stage.
• In SVIEW, the application Component in the target Environment shows the new
  image tag and a healthy status.

If the deploy stage passes but the Component shows Degraded, the problem is
in the application rather than the pipeline — see
Components and Deployments.

Related articles

• GitLab Access for CTO2B — which account and role to grant
• Components and Deployments — Environments, Services and Components
• Environments — what each Environment maps to
• Container Registry Repositories and CI Push Access — the image repository your pipeline pushes to
• Access Requests — short-lived infrastructure access through SVIEW
• Getting Help — how to raise a request