gitlab package registry

Prerequisite: There is a gitlab deployed on an AWS ec2 instance, and you have the relevant permissions to manage this account.

Enable Package Registry and use S3 bucket

################################################################################
## Package repository
##! Docs: https://docs.gitlab.com/ee/administration/packages/
################################################################################

# gitlab_rails['packages_enabled'] = true
# gitlab_rails['packages_storage_path'] = "/var/opt/gitlab/gitlab-rails/shared/packages"
# gitlab_rails['packages_object_store_enabled'] = false
# gitlab_rails['packages_object_store_proxy_download'] = false
# gitlab_rails['packages_object_store_remote_directory'] = "packages"
# gitlab_rails['packages_object_store_connection'] = {
#   'provider' => 'AWS',
#   'region' => 'eu-west-1',
#   'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
#   'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY',
#   # # The below options configure an S3 compatible host instead of AWS
#   # 'host' => 's3.amazonaws.com',
#   # 'aws_signature_version' => 4, # For creation of signed URLs. Set to 2 if provider does not support v4.
#   # 'endpoint' => 'https://s3.amazonaws.com', # default: nil - Useful for S3 compliant services such as DigitalOcean Spaces
#   # 'path_style' => false # Use 'host/bucket_name/object' instead of 'bucket_name.host/object'
# }
gitlab_rails['packages_enabled'] = true
gitlab_rails['packages_object_store_enabled'] = true
gitlab_rails['packages_object_store_remote_directory'] = "your-s3-bucket-name"
gitlab_rails['packages_object_store_connection'] = {
  'provider' => 'AWS',
  'region' => 'ap-east-1',
  'use_iam_profile' => true,
}

gitlab_rails[‘packages_object_store_remote_directory’] is the name of the object store, and there is no need to specify a path, at least not yet.

Use Amazon instance profiles

Use roles to grant permissions to applications running on Amazon EC2 instances.

To set up an instance profile:

1. Create an IAM role with the necessary permissions. The following example is a role for an S3 bucket named test-bucket:

   JSONCopy to clipboard

   {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "s3:PutObject",
                  "s3:GetObject",
                  "s3:DeleteObject"
              ],
              "Resource": "arn:aws:s3:::test-bucket/*"
          },
          {
              "Effect": "Allow",
              "Action": [
                  "s3:ListBucket"
              ],
              "Resource": "arn:aws:s3:::test-bucket"
          }
      ]
   }

2. Attach this role to the EC2 instance hosting your GitLab instance.

3. Set the use_iam_profile GitLab configuration option to true.

Load configuration and restart gitlab

# Load configuration
sudo gitlab-ctl reconfigure

# Restart

Package registry

Gitlab supports independent package management for each repository, but to facilitate package search, create two repositories to manage the corresponding packages according to the maven and npm categories.

1. Create an internal package-registry group

2. Generate a Group Access Token for package publishing

Settings -> Access Token -> Select api in scope -> Generate token and copy

3. Create two repositories, maven-packages and npm-packages, and record the corresponding project ids

maven

settings.xml configuration

<settings>
  <servers>
    <server>
      <id>gitlab-maven</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Private-Token</name>
            <value>REPLACE_WITH_TOKEN</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>
  </servers>
</settings>

Maven uploads jar packages

$ touch your-library-1.0.jar

$ mvn  deploy:deploy-file \
-Dfile=your-library-1.0.jar \
-Dpackaging=jar \
-DgroupId=com.example \
-DartifactId=your-library \
-Dversion=1.0.0 \
-Durl=https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven \
-DrepositoryId=gitlab-maven

Why do we need to configure settings.xml? Because it is not convenient to directly specify the username and password for the mvn deploy command. Otherwise, executing the deploy command will report an exception with status code 401.

In Maven, -DgroupId, -DartifactId, and -Dversion are coordinates used to define Maven projects. These are what you need to define based on your project. Here is the specific meaning of each parameter:

1. -DgroupId: This parameter specifies the group ID of the component, which usually uses the reverse domain name to represent the unique identifier of the organization or project. For example, if your company domain name is example.com, then a common group ID may be com.example.
2. -DartifactId: This parameter specifies the artifact ID of the component, which is usually the name of the project. For example, if your project is called qcsdk, you can use this as the artifactId.
3. -Dversion: This parameter specifies the version number of the component, which helps you manage and distinguish different versions of the project. You can use version number formats such as 1.0.0, 1.0.1, 2.0.0-SNAPSHOT.

pom.xml configuration

<!-- Repository configuration for "Get Package" -->
<repositories>
  <repository>
    <id>gitlab-maven</id>
    <url><your_endpoint_url></url>
  </repository>
</repositories>
<!-- Repository configuration for "Publish Package" -->  
<distributionManagement>
  <repository>
    <id>gitlab-maven</id>
    <url>https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven</url>
  </repository>
  <snapshotRepository>
    <id>gitlab-maven</id>
    <url>https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven</url>
  </snapshotRepository>
</distributionManagement>

• The id is what you defined in settings.xml.
• The <your_endpoint_url> depends on which endpoint you choose.
• Replace gitlab.example.com with your domain name.