Refactor create package services

Context

In Foundation: Prepare application code to read fr... (#548761 - closed) we're refactoring the code to not rely on the package_type column, since it won't be possible after we have multiple database tables.

What does this MR do and why?

Change create package service to use package class instead of package type. Introduce the changes behind the feature flag.

References

Foundation: Prepare application code to read fr... (#548761 - closed)

Screenshots or screen recordings

No.

How to set up and validate locally

Publish Composer package

1. Create a project and composer.json to it:

   composer.json

   {
     "name": "user/madrid",
     "autoload": {
       "psr-4": {
           "User\\Madrid\\": "src/"
       }
     },
     "authors": [
       {
           "name": "User"
       }
     ],
     "require": {}
   }

2. Add a tag. For example 1.0.0

3. Publish a package

   $ curl --fail-with-body --data tag=<tag> "https://__token__:<personal-access-token>@gitlab.example.com/api/v4/projects/<project_id>/packages/composer"

4. Verify that the package was successfully published.

Publish Conan package

1. Build a conan package docs.

   Note: Usually I use cmake_lib as a template: $ conan new Basel/1.0.0 --template=cmake_lib

2. Add the package registry as a remote docs.

3. Publish a package docs.

4. Verify that the package was successfully published.

Publish Generic package

1. Publish a package

   $ touch file.txt
   $ curl --location --header "PRIVATE-TOKEN: <personal_access_token>" \
    --upload-file path/to/file.txt \
    "https://gitlab.example.com/api/v4/projects/<project-id>/packages/generic/my_package/1.0.0/file.txt"

2. Verify that the package was successfully published.

Publish Maven package

1. Build a maven package docs.

2. Authenticate to the package registry docs.

3. Publish a package docs.

4. Verify that the package was successfully published.

Publish Npm package

1. Build a npm package docs.

2. Authenticate to the package registry docs.

3. Publish package docs.

4. Verify that the package was successfully published.

Publish PyPi package

1. Build a PyPi package docs.

2. Authenticate to the package registry and publish package docs.

3. Verify that the package was successfully published.

Publish NuGet

1. Build a NuGet package.

   $ dotnet new classlib -n MyLibrary
   $ cd MyLibrary
   $ dotnet pack

   This will create *.nupkg file in bin/Release

2. Add the package registry as a source for NuGet packages docs.

3. Publish a package docs.

4. Verify that the package was successfully published.

Publish Terraform module

1. Build a module

   $ mkdir simple && cd simple
   $ touch main.tf

   Edit main.tf

   main.tf

   terraform {
     required_version = ">= 1.0"
   }
   
   locals {
     message = "Hello from a minimal Terraform module!"
   }
   
   output "message" {
     description = "A simple message from the module"
     value       = local.message
   }

2. Build an archive

   $ cd ../
   $ tar -czf simple.tar.gz simple

3. Publish a module docs.

4. Verify that the module was successfully published.

Publish ML Model

1. Create ML model with version docs.

2. Access the ML registry in the UI docs and upload an artifact (any file) using UI.

3. Verify that the file was successfully uploaded.

Publish Debian package

1. Enable Debian API

   Feature.enable(:debian_packages)

2. Build a package

   $ mkdir -p simple-package/DEBIAN
   $ cd simple-package

   Create DEBIAN/control with the minimum required fields:

   control

   Package: simple-package
   Version: 1.0
   Section: misc
   Priority: optional
   Architecture: all
   Maintainer: Your Name <your.email@example.com>
   Description: A simple package that does nothing
    This is a minimal Debian package created for demonstration purposes.
    It contains no files and performs no actions.

   From the parent directory of simple-package/:

   $ dpkg-deb --build simple-package 

   This will create simple-package.deb.

3. Create a distribution docs.

4. Publish a package with explicit distribution docs.

5. Verify that the package was successfully published.

Publish Rubygem package

Since the rubygems package registry is under development docs,
only publishing gem is available. Let's verify the changes proposed in this MR with it:

1. Enable the feature flag Feature.enable(:rubygem_packages)

2. Create a new project.

3. In the new project add .gitlab-ci.yml file with the following content:

   .gitlab-ci.yml

   ```yaml image: ruby

   run: before_script: - mkdir ~/.gem - echo "---" > ~/.gem/credentials - | echo "{CI_API_V4_URL}/projects/{CI_PROJECT_ID}/packages/rubygems: '${CI_JOB_TOKEN}'" >> ~/.gem/credentials - chmod 0600 ~/.gem/credentials # rubygems requires 0600 permissions on the credentials file script:

   • mkdir my_gem && cd
   • | tee -a my_gem.gemspec << END Gem::Specification.new do |s| s.name = 'my_gem' s.version = '0.0.1' s.summary = "This is an example!" s.authors = ["Ruby Coder"] s.add_development_dependency "pry" end END
   • gem build my_gem.gemspec
   • gem push my_gem-0.0.1.gem --host {CI_API_V4_URL}/projects/{CI_PROJECT_ID}/packages/rubygems

   </details>
   

4. Go to http://gdk.test:3000/<project path>/-/packages and check that the new gem my_gem was published.

Publish Helm chart

1. Build a chart docs.

2. Publish chart docs.

3. Verify that the chart was successfully published.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #548761 (closed)