feat(release): "release create --publish-to-catalog" flag

Note

This MR targets feat(auth): support CI JOB TOKEN (!1778 - merged)

Description

In this change, we are moving the logic of publishing CI components into glab.

With this new command flag;

glab release create 3.0.0 --publish-to-catalog

glab will fetch the components from the current project, parses the component names and their specs, and sends a request to the /api/v4/projects/:PID/catalog/publish with a body.

Related Issues

Resolves #7679 (closed)

How it works E2E

1. If a CI job has the release keyword, GitLab adds a release script to the job when sending it to Runner.
2. If the project is not a Catalog resource, the script only consists of release-cli create --name=abc tag_name=1.0.0 ....
3. If the project is a Catalog resource, the script will be glab releases create 1.0.0 --publish-to-catalog.
4. When the job runs, it's required that the job environment has glab. (Runner generally fetches registry.gitlab.com/gitlab-org/release-cli:latest)
5. glab first creates a "release" with the tag "1.0.0" (POST /projects/:id/releases).
6. Then, glab publishes the version to the CI Catalog (POST /projects/:id/catalog/publish).

How has this been tested?

1. We need gitlab!167883 (merged) and the feature flag ci_release_cli_catalog_publish_option enabled in our local development environment.
2. For an easy test, I am simply copying the executables to /usr/local/bin;
   • ~glab: make && sudo cp ./bin/glab /usr/local/bin/glab
3. An example .gitlab-ci.yml for a component project;

create-release:
  rules:
    - if: $CI_COMMIT_TAG =~ /\d+/
  script: echo "Creating release $CI_COMMIT_TAG"
  release:
    tag_name: $CI_COMMIT_TAG
    description: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"

4. An example component template YAML file;

5. Create a new tag;

6. See the new pipeline;

7. Check the catalog resource

Types of changes

• [-] Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• [-] Breaking change (fix or feature that would cause existing functionality to change)
• Documentation
• [-] Chore (Related to CI or Packaging to platforms)
• [-] Test gap