Add more Release artifact types

Problem to solve

Once https://gitlab.com/gitlab-org/gitlab-ce/issues/56022 is completed, we have a way to generate releases directly in the .gitlab-ci.yml and point to a URL as artifact. There's still one big piece missing, however - the ability to create the release binary package itself and put it somewhere that it can be downloaded. This could be a file hosted internally somewhere (GitLabs pages?), a pointer to an artifact link, or a container image reference.

Target audience

TBD

Further details

TBD

Proposal

Allow specifying a local set of files that can be created as a release archive, then make it available at some standard URL within the project. Alternatively, selecting an artifact set and promoting it to be a never-expiring release (something like https://gitlab.com/gitlab-org/gitlab-ce/issues/47878.) Also, pointing to a specific container image.

In the existing implementation (https://gitlab.com/gitlab-org/gitlab-ce/issues/56022), building the release package and uploading it somewhere is up to the user (see enumerated steps in script section):

...

runRelease:
  script: #these are manual tasks implemented by the user, and not automatically handled currently
    - # do some final release preparation
    - # manually build release zip
    - # manually upload release zip to http://my.awesome.download.site/1.0-$CI_COMMIT_SHORT_SHA.zip
  release:
    name: My $CI_PROJECT_NAME Release 1.0-$CI_COMMIT_SHORT_SHA
    tag_name: $CI_COMMIT_TAG
    ref: $CI_COMMIT_REF_NAME
    description: |
      CHANGELOG:
        - Feature A
        - Feature B
    assets:
      links: [
        { name: "Documentation",
          url: "http://my.awesome.docs.site/1.0-$CI_COMMIT_SHORT_SHA"
        }
        { name: "1.0-$CI_COMMIT_SHORT_SHA.zip",
          url: "http://my.awesome.download.site/1.0-$CI_COMMIT_SHORT_SHA.zip"
        }
      ]

...

We should refactor this so that something like the following is possible:

...

runRelease:
  script: 
    - # do some final release preparation
  release:
    name: My $CI_PROJECT_NAME Release 1.0-$CI_COMMIT_SHORT_SHA
    tag_name: $CI_COMMIT_TAG
    ref: $CI_COMMIT_REF_NAME
    description: |
      CHANGELOG:
        - Feature A
        - Feature B
    assets:
      links: [
        { name: "Documentation",
          url: "http://my.awesome.docs.site/1.0-$CI_COMMIT_SHORT_SHA"
        }

      ]
      packages: [
        { name: "1.0-$CI_COMMIT_SHORT_SHA",
          format: "zip",
          path: "output/release"
        }
      ]

...

In this example, the job would know how to create a zipfile containing everything in the output/release folder, and name it with the appropriate filename and extension. We should allow any file format supported for the source code. The file would be automatically uploaded to a repository and a release would be created with a pointer to that URL. The job would then replace the packages section in the yaml with a link and make the appropriate API call to the Release API.

What does success look like, and how can we measure that?

TBD

Links / references

TBD