How to make gitlab project public

Setting repository visibility

In this article

You can choose who can view your repository.

About repository visibility changes

Organization owners can restrict the ability to change repository visibility to organization owners only. For more information, see «Restricting repository visibility changes in your organization.»

We recommend reviewing the following caveats before you change the visibility of a repository.

Making a repository private

Making a repository public

For information about improving repository security, see «Securing your repository.»

Changing a repository’s visibility

On GitHub.com, navigate to the main page of the repository.

Under your repository name, click

Settings.

Under «Danger Zone», to the right of to «Change repository visibility», click Change visibility.

Select a visibility.

To verify that you’re changing the correct repository’s visibility, type the name of the repository you want to change the visibility of.

Click I understand, change repository visibility.

Project and group visibility

These visibility levels affect who can see the project in the public access directory ( /public for your GitLab instance). For example, https://gitlab.com/public. You can control the visibility of individual features with project feature settings.

Public projects and groups

Public projects can be cloned without any authentication over HTTPS.

They are listed in the public access directory ( /public ) for all users.

Any signed-in user has the Guest role on the repository.

Internal projects and groups

Internal projects can be cloned by any signed-in user except external users.

They are also listed in the public access directory ( /public ), but only for signed-in users.

Any signed-in users except external users have the Guest role on the repository.

Private projects and groups

Private projects can only be cloned and viewed by project members (except for guests).

They appear in the public access directory ( /public ) for project members only.

Change project visibility

Change group visibility

Restrict use of public or internal projects

You can restrict the use of visibility levels for users when they create a project or a snippet. This is useful to prevent users from publicly exposing their repositories by accident. The restricted visibility settings do not apply to administrators.

Control access and visibility

GitLab enables users with administrator access to enforce specific controls on branches, projects, snippets, groups, and more.

Define which roles can create projects

Restrict project deletion to administrators

User interface changed in GitLab 15.1.

Deletion protection

Instance-level protection against accidental deletion of groups and projects.

Retention period

Groups and projects will remain restorable within a defined retention period. By default this is 7 days but it can be changed. Setting the retention period to 0 means that groups and project are removed immediately and cannot be restored.

Delayed project deletion

User interface changed in GitLab 15.1.

Administrators can enable delayed project deletion by default for newly-created groups. Group owners can choose to disable this and existing groups will retain their existing setting. When enabled deleted groups will remain restorable within a retention period.

Deletion protection is not available for projects only (without being also being enabled for groups).

In GitLab 15.1, and later this setting is enforced on groups when disabled and it cannot be overridden.

Delayed group deletion

User interface introduced in GitLab 15.1.

Groups will remain restorable if the retention period is 1 or more days.

In GitLab 15.1 and later, delayed group deletion can be enabled by setting Deletion projection to Keep deleted.

Override defaults and delete immediately

Configure project visibility defaults

Configure snippet visibility defaults

For more details on snippet visibility, read Project visibility.

Configure group visibility defaults

For more details on group visibility, see Group visibility.

Restrict visibility levels

For more details on project visibility, see Project visibility.

Configure allowed import sources

Enable project export

Configure enabled Git access protocols

With GitLab access restrictions, you can select the protocols users can use to communicate with GitLab. Disabling an access protocol does not block port access to the server itself. The ports used for the protocol, SSH or HTTP(S), are still accessible. The GitLab restrictions apply at the application level.

GitLab shows a tooltip when you hover over the URL’s protocol, if user action (such as adding a SSH key or setting a password) is required:

GitLab only allows Git actions for the protocols you select.

Customize Git clone URL for HTTP(S)

You can customize project Git clone URLs for HTTP(S), which affects the clone panel:

Configure defaults for RSA, DSA, ECDSA, ED25519, ECDSA_SK, ED25519_SK SSH keys

These options specify the permitted types and lengths for SSH keys.

Enable project mirroring

This option is enabled by default. By disabling it, both pull mirroring and push mirroring no longer work in every repository. They can only be re-enabled by an administrator user on a per-project basis.

Configure globally-allowed IP address ranges

This setting allows you to set IP address ranges to be combined with group-level IP allowlists. It helps administrators prevent aspects of the GitLab installation from being blocked from working as intended when an IP allowlist is used.

For example, if the GitLab Pages daemon runs on the 10.0.0.0/24 range, specify that range in this field, as otherwise any group-level restrictions that don’t include that range cause the Pages daemon to be unable to fetch artifacts from the pipeline runs.

Help & feedback

Product

Feature availability and product trials

Get Help

If you didn’t find what you were looking for, search the docs.

If you want help with something specific and could use community support, post on the GitLab forum.

For problems setting up or using this feature (depending on your GitLab subscription).

Tutorial: Create a GitLab Pages website from scratch

This tutorial shows you how to create a Pages site from scratch using the Jekyll Static Site Generator (SSG). You start with a blank project and create your own CI/CD configuration file, which gives instructions to a runner. When your CI/CD pipeline runs, the Pages site is created.

This example uses Jekyll, but other SSGs follow similar steps. You do not need to be familiar with Jekyll or SSGs to complete this tutorial.

Prerequisites

You must have a blank project in GitLab.

Create the project files

Create three files in the root (top-level) directory:

.gitlab-ci.yml : A YAML file that contains the commands you want to run. For now, leave the file’s contents blank.

index.html : An HTML file you can populate with whatever HTML content you’d like, for example:

Gemfile : A file that describes dependencies for Ruby programs.

Populate it with this content:

Choose a Docker image

In this example, the runner uses a Docker image to run scripts and deploy the site.

This specific Ruby image is maintained on DockerHub.

Install Jekyll

Specify the public directory for output

Specify the public directory for artifacts

Now that Jekyll has output the files to the public directory, the runner needs to know where to get them. The artifacts are stored in the public directory:

Deploy and view your website

When this pages job completes successfully, a special pages:deploy job appears in the pipeline view. It prepares the content of the website for the GitLab Pages daemon. GitLab runs it in the background and doesn’t use a runner.

Other options for your CI/CD file

The following topics show other examples of other options you can add to your CI/CD file.

Deploy specific branches to a Pages site

You may want to deploy to a Pages site only from specific branches.

First, add a workflow section to force the pipeline to run only when changes are pushed to branches:

Then configure the pipeline to run the job for the default branch (here, main ) only.

Specify a stage to deploy

There are three default stages for GitLab CI/CD: build, test, and deploy.

If you want to test your script and check the built site before deploying to production, you can run the test exactly as it runs when you push to your default branch (here, main ).

To specify a stage for your job to run in, add a stage line to your CI file:

Now add another job to the CI file, telling it to test every push to every branch except the main branch:

When you apply stages to different jobs, every job in the same stage builds in parallel. If your web application needs more than one test before being deployed, you can run all your tests at the same time.

Remove duplicate commands

To avoid duplicating the same scripts in every job, you can add them to a before_script section.

Move these commands to a before_script section:

Build faster with cached dependencies

To build faster, you can cache the installation files for your project’s dependencies by using the cache parameter.

This example caches Jekyll dependencies in a vendor directory when you run bundle install :

In this case, you need to exclude the /vendor directory from the list of folders Jekyll builds. Otherwise, Jekyll tries to build the directory contents along with the site.

In the root directory, create a file called _config.yml and add this content:

Project settings in Gitlab

Part of GitLab Collective

Where now «Project settings» in Gitlab? How delete repository? And change «Visibility Level» repository? And rename project?

3 Answers 3

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Below the «Audit Events» item in the menu you have pulled down in the picture, you should see an option called «Edit Project» that will allow you to do everything you mentioned.

When you rename your project, through its settings page, make sure to not include leading or trailing special character in the new name:

Special characters not permitted in new project names

Project and Group names that have a leading or trailing special character breaks the container registry.

As of this release, you can no longer use special characters as the first or last characters of new project or group names.
You can still use special characters in any other part in the name.

This ensures proper functionality within all stages at GitLab, and enhances the experience of our single platform tool.