Project settings (FREE)

The Settings page in GitLab provides a centralized home for your project configuration options. To access it, go to your project's homepage and, in the left navigation menu, select Settings. To reduce complexity, settings are grouped by topic into sections. To display all settings in a section, select Expand.

In GitLab versions 13.10 and later, GitLab displays a search box to help you find the settings you want to view.

NOTE: Only users who have the Maintainer role for the project and administrators can access project settings.

General settings

Under a project's general settings, you can find everything concerning the functionality of a project.

General project settings

Adjust your project's name, description, avatar, default branch, and topics:

The project description also partially supports standard Markdown. You can use emphasis, links, and line-breaks to add more context to the project description.

Topics

Use topics to categorize projects and find similar new projects.

To assign topics to a project:

1. On the top bar, select Menu > Projects and find your project.
2. On the left sidebar, select Settings > General.
3. Under Topics, enter the project topics. Existing popular topics are suggested as you type.
4. Select Save changes.

For GitLab.com, explore popular topics on the Explore topics page. When you select a topic, you can see relevant projects.

NOTE: The assigned topics are visible only to everyone with access to the project, but everyone can see which topics exist at all on the GitLab instance. Do not include sensitive information in the name of a topic.

If you're an instance administrator, see also Administering topics.

Compliance frameworks (PREMIUM)

• Introduced in GitLab 13.9.
• Feature flag removed in GitLab 13.12.

You can create a compliance framework label to identify that your project has certain compliance requirements or needs additional oversight. The label can optionally apply compliance pipeline configuration.

Group owners can create, edit, and delete compliance frameworks:

1. On the top bar, select Menu > Groups and find your group.
2. On the left sidebar, select Settings > General.
3. Expand the Compliance frameworks section.

Compliance frameworks created can then be assigned to projects within the group using:

• The GitLab UI, using the project settings page.
• In GitLab 14.2 and later, using the GraphQL API.

NOTE: Creating compliance frameworks on subgroups with GraphQL causes the framework to be created on the root ancestor if the user has the correct permissions. The GitLab UI presents a read-only view to discourage this behavior.

Compliance pipeline configuration (ULTIMATE)

• Introduced in GitLab 13.9, disabled behind ff_evaluate_group_level_compliance_pipeline feature flag.
• Enabled by default in GitLab 13.11.
• Feature flag removed in GitLab 14.2.

Group owners can use compliance pipeline configuration to add additional pipeline configuration to projects to define compliance requirements such as scans or tests.

Compliance frameworks allow group owners to specify the location of compliance pipeline configuration stored and managed in dedicated projects, separate from regular projects.

When you set up the compliance framework, use the Compliance pipeline configuration box to link the compliance framework to specific CI/CD configuration. Use the path/file.y[a]ml@group-name/project-name format. For example:

• .compliance-ci.yml@gitlab-org/gitlab.
• .compliance-ci.yaml@gitlab-org/gitlab.

This configuration is inherited by projects where the compliance framework label is applied. The result forces projects with the label to run the compliance CI/CD configuration in addition to the project's own CI/CD configuration. When a project with a compliance framework label executes a pipeline, it evaluates configuration in the following order:

1. Compliance pipeline configuration.
2. Project-specific pipeline configuration.

The user running the pipeline in the project must at least have the Reporter role on the compliance project.

Example .compliance-gitlab-ci.yml:

# Allows compliance team to control the ordering and interweaving of stages/jobs.
# Stages without jobs defined will remain hidden.
stages:
  - pre-compliance
  - build
  - test
  - pre-deploy-compliance
  - deploy
  - post-compliance

variables:  # Can be overridden by setting a job-specific variable in project's local .gitlab-ci.yml
  FOO: sast

sast:  # None of these attributes can be overridden by a project's local .gitlab-ci.yml
  variables:
    FOO: sast
  image: ruby:2.6
  stage: pre-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # or when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

sanity check:
  image: ruby:2.6
  stage: pre-deploy-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # or when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

audit trail:
  image: ruby:2.6
  stage: post-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # or when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

include:  # Execute individual project's configuration (if project contains .gitlab-ci.yml)
  project: '$CI_PROJECT_PATH'
  file: '$CI_CONFIG_PATH'
  ref: '$CI_COMMIT_REF_NAME' # Must be defined or MR pipelines always use the use default branch
  rules:
    - exists: '$CI_CONFIG_PATH'

Ensure compliance jobs are always run

Compliance pipelines use GitLab CI/CD to give you an incredible amount of flexibility for defining any sort of compliance jobs you like. Depending on your goals, these jobs can be configured to be:

• Modified by users.
• Non-modifiable.

At a high-level, if a value in a compliance job:

• Is set, it cannot be changed or overridden by project-level configurations.
• Is not set, a project-level configuration may set.

Either might be wanted or not depending on your use case.

There are a few best practices for ensuring that these jobs are always run exactly as you define them and that downstream, project-level pipeline configurations cannot change them:

• Add a rules:when:always block to each of your compliance jobs. This ensures they are non-modifiable and are always run.
• Explicitly set any variables the job references. This:
  • Ensures that project-level pipeline configurations do not set them and alter their behavior.
  • Includes any jobs that drive the logic of your job.
• Explicitly set the container image file to run the job in. This ensures that your script steps execute in the correct environment.
• Explicitly set any relevant GitLab pre-defined job keywords. This ensures that your job uses the settings you intend and that they are not overridden by project-level pipelines.

Avoid parent and child pipelines

Compliance pipelines start on the run of every pipeline in a relevant project. This means that if a pipeline in the relevant project triggers a child pipeline, the compliance pipeline runs first. This can trigger the parent pipeline, instead of the child pipeline.

Therefore, in projects with compliance frameworks, we recommend replacing parent-child pipelines with the following:

• Direct include statements that provide the parent pipeline with child pipeline configuration.
• Child pipelines placed in another project that are run using the trigger API rather than the parent-child pipeline feature.

This alternative ensures the compliance pipeline does not re-start the parent pipeline.

Sharing and permissions

For your repository, you can set up features such as public access, repository features, documentation, access permissions, and more. To do so from your project, go to Settings > General, and expand the Visibility, project features, permissions section.

You can now change the Project visibility. If you set Project Visibility to public, you can limit access to some features to Only Project Members. In addition, you can select the option to Allow users to request access.

Use the switches to enable or disable the following features:

Some features depend on others:

• If you disable the Issues option, GitLab also removes the following features:

  • issue boards
  • Service Desk

  NOTE: When the Issues option is disabled, you can still access Milestones from merge requests.

• Additionally, if you disable both Issues and Merge Requests, you cannot access:

  • Labels
  • Milestones

• If you disable Repository functionality, GitLab also disables the following features for your project:

  • Merge Requests
  • CI/CD
  • Container Registry
  • Git Large File Storage
  • Packages

• Metrics dashboard access requires reading both project environments and deployments. Users with access to the metrics dashboard can also access environments and deployments.

Disabling the CVE ID request button (FREE SAAS)

Introduced in GitLab 13.4, only for public projects on GitLab.com.

In applicable environments, a Create CVE ID Request button is present in the issue sidebar. The button may be disabled on a per-project basis by toggling the setting Enable CVE ID requests in the issue sidebar.

Disabling email notifications

Project owners can disable all email notifications related to the project by selecting the Disable email notifications checkbox.

Merge request settings

Set up your project's merge request settings:

• Set up the merge request method (merge commit, fast-forward merge).
• Add merge request description templates.
• Enable merge request approvals.
• Enable status checks.
• Enable merge only if pipeline succeeds.
• Enable merge only when all threads are resolved.
• Enable require an associated issue from Jira.
• Enable delete source branch after merge option by default.
• Configure suggested changes commit messages.
• Configure merge and squash commit message templates.
• Configure the default target project for merge requests coming from forks.

Service Desk

Enable Service Desk for your project to offer customer support.

Export project

Learn how to export a project in GitLab.

Advanced settings

Here you can run housekeeping, archive, rename, transfer, remove a fork relationship, or delete a project.

Archiving a project

Archiving a project makes it read-only for all users and indicates that it's no longer actively maintained. Projects that have been archived can also be unarchived. Only project owners and administrators have the permissions to archive a project.

When a project is archived, the repository, packages, issues, merge requests, and all other features are read-only. Archived projects are also hidden in project listings.

To archive a project:

1. Navigate to your project's Settings > General.
2. Under Advanced, click Expand.
3. In the Archive project section, click the Archive project button.
4. Confirm the action when asked to.

Unarchiving a project

Unarchiving a project removes the read-only restriction on a project, and makes it available in project listings. Only project owners and administrators have the permissions to unarchive a project.

To find an archived project:

1. Sign in to GitLab as the project owner or a user with the Administrator role.
2. If you:
   • Have the project's URL, open the project's page in your browser.
   • Don't have the project's URL:
     1. On the top bar, select Menu > Project.
     2. Select Explore projects.
     3. In the Sort projects dropdown box, select Show archived projects.
     4. In the Filter by name field, provide the project's name.
     5. Click the link to the project to open its Details page.

Next, to unarchive the project:

1. Navigate to your project's Settings > General.
2. Under Advanced, click Expand.
3. In the Unarchive project section, click the Unarchive project button.
4. Confirm the action when asked to.

Renaming a repository

NOTE: Only project maintainers and administrators have the permissions to rename a repository. Not to be confused with a project's name where it can also be changed from the general project settings.

A project's repository name defines its URL (the one you use to access the project via a browser) and its place on the file disk where GitLab is installed.

To rename a repository:

1. Navigate to your project's Settings > General.
2. Under Advanced, click Expand.
3. Under Change path, update the repository's path.
4. Click Change path.

Remember that this can have unintended side effects since everyone with the old URL can't push or pull. Read more about what happens with the redirects when renaming repositories.

Transferring an existing project into another namespace

NOTE: Only project owners and administrators have the permissions to transfer a project.

You can transfer an existing project into a group if:

• You have at least Maintainer role in that group.
• You're at least an Owner of the project to be transferred.
• The group to which the project is being transferred to must allow creation of new projects.

To transfer a project:

1. Navigate to your project's Settings > General.
2. Under Advanced, click Expand.
3. Under "Transfer project", choose the namespace you want to transfer the project to.
4. Confirm the transfer by typing the project's path as instructed.

Once done, you are redirected to the new project's namespace. At this point, read what happens with the redirects from the old project to the new one.

NOTE: GitLab administrators can use the administration interface to move any project to any namespace if needed.

Transferring a GitLab.com project to a different subscription tier

When you transfer a project from a namespace that's licensed for GitLab SaaS Premium or Ultimate to Free, some data related to the paid features is deleted.

For example, project access tokens are revoked, and pipeline subscriptions and test cases are deleted.

Delete a project

You can mark a project to be deleted.

Prerequisite:

• You must have at least the Owner role for a project.

To delete a project:

1. On the top bar, select Menu > Projects and find your project.
2. On the left sidebar, select Settings > General.
3. Expand Advanced.
4. In the "Delete project" section, select Delete project.
5. Confirm the action when asked to.

This action deletes a project including all associated resources (issues, merge requests, and so on).

WARNING: The default deletion behavior for projects was changed to delayed project deletion in GitLab 12.6, and then to immediate deletion in GitLab 13.2.

Delayed project deletion (PREMIUM)

Projects in a group (not a personal namespace) can be deleted after a delay period. Multiple settings can affect whether delayed project deletion is enabled for a particular project:

• Self-managed instance settings. You can enable delayed project deletion as the default setting for new groups, and configure the number of days for the delay. For GitLab.com, see the GitLab.com settings.
• Group settings to enabled delayed project deletion for all projects in the group.

Delete a project immediately

Introduced in GitLab 14.1.

If you don't want to wait, you can delete a project immediately.

Prerequisites:

• You must have at least the Owner role for a project.
• You have marked the project for deletion.

To immediately delete a project marked for deletion:

1. On the top bar, select Menu > Projects and find your project.
2. On the left sidebar, select Settings > General.
3. Expand Advanced.
4. In the "Permanently delete project" section, select Delete project.
5. Confirm the action when asked to.

The following are deleted:

• Your project and its repository.
• All related resources including issues and merge requests.

Restore a project (PREMIUM)

Introduced in GitLab 12.6.

To restore a project marked for deletion:

1. Navigate to your project, and select Settings > General > Advanced.
2. In the Restore project section, click the Restore project button.

Removing a fork relationship

Forking is a great way to contribute to a project of which you're not a member. If you want to use the fork for yourself and don't need to send merge requests to the upstream project, you can safely remove the fork relationship.

WARNING: Once removed, the fork relationship cannot be restored. You can't send merge requests to the source, and if anyone has forked your project, their fork also loses the relationship.

To do so:

1. Navigate to your project's Settings > General > Advanced.
2. Under Remove fork relationship, click the likewise-labeled button.
3. Confirm the action by typing the project's path as instructed.

NOTE: Only project owners have the permissions to remove a fork relationship.

Monitor settings

Alerts

Configure alert integrations to triage and manage critical problems in your application as alerts.

Incidents

Alert integration

Automatically create, notify on, and resolve incidents based on GitLab alerts.

PagerDuty integration

Create incidents in GitLab for each PagerDuty incident.

Incident settings

Manage Service Level Agreements for incidents with an SLA countdown timer.

Error Tracking

Configure Error Tracking to discover and view Sentry errors within GitLab.

Jaeger tracing (ULTIMATE)

Add the URL of a Jaeger server to allow your users to easily access the Jaeger UI from within GitLab.

Status Page

Add Storage credentials to enable the syncing of public Issues to a deployed status page.