Please add support for gitlab_content registries

[W1M0R]

Feature Overview

The documentation lists local and github_content registry types. It would be nice to have a gitlab_content registry type to permit users of Gitlab Server (self-hosted) or gitlab.com as a source for aqua registries.

Why is the feature needed?

To allow enterprise users that use Gitlab server to host private aqua registries.

Workaround

The workaround is to:

1. download the registry file (https://your_private_gitlab_server.com/suzuki-shunsuke/private-aqua-registry/registry.yaml) and use it as a local registry
2. create a git submodule or git subtree to https://your_private_gitlab_server.com/suzuki-shunsuke/private-aqua-registry

Example Code

It will be used like this:

registries:
  - name: foo
    type: gitlab_content
    base_url: https://your_private_gitlab_server.com/
    repo_owner: suzuki-shunsuke
    repo_name: private-aqua-registry
    ref: main
    path: registry.yaml

packages:
  - name: suzuki-shunsuke/[email protected]
    registry: foo

This will use the registry defined at https://your_private_gitlab_server.com/suzuki-shunsuke/private-aqua-registry/registry.yaml (or more specifically: https://your_private_gitlab_server.com/suzuki-shunsuke/private-aqua-registry/-/raw/main/registry.yaml)

Note

A more generic alternative might be to add support for https registry types, that can be used like this:

registries:
  - name: foo
    type: https
    url: https://your_private_gitlab_server.com/suzuki-shunsuke/private-aqua-registry/-/raw/main/registry.yaml

packages:
  - name: suzuki-shunsuke/[email protected]
    registry: foo

[suzuki-shunsuke]

Thank you for your feedback.
We mainly focus on GitHub, not GitLab, so it's a bit difficult to prioritize GitLab support.
But we would be able to work on this when we have time.

About http type registry, we need to consider the authentication.

[W1M0R]

Thanks @suzuki-shunsuke, I understand.

In terms of the http registry, the most basic implementation would use an HTTP GET without any authentication. So it is left to the user to ensure that the url they are trying to access is open.

For users that need authentication, you could probably do what you did for github_content registries, and read an environment variable, e.g. AQUA_HTTP_AUTH_HEADER. The difficulty is when users have more than one http registry requiring different authentication methods. One option would be to have them set their own environment variables and then just inform aqua which environment variables provide the authentication.

For example:

registries:
  - name: foo1
    type: https
    url: https://your_private_gitlab_server.com/suzuki-shunsuke/private-aqua-registry-1/-/raw/main/registry.yaml
    auth_env: MY_HTTP_AUTH_1
  - name: foo2
    type: https
    url: https://your_private_gitlab_server.com/suzuki-shunsuke/private-aqua-registry-2/-/raw/main/registry.yaml
    auth_env: MY_HTTP_AUTH_2
  - name: foo3
    type: https
    url: https://your_private_gitlab_server.com/suzuki-shunsuke/private-aqua-registry-3/-/raw/main/registry.yaml
    auth_env: MY_HTTP_AUTH_3
    auth_env_encoding: base64

packages:
  - name: suzuki-shunsuke/[email protected]
    registry: foo1
  - name: suzuki-shunsuke/[email protected]
    registry: foo2
  - name: suzuki-shunsuke/[email protected]
    registry: foo3

In this example, the user sets two environment variables in their environment, which contain the content of the authorization header to access that resource, e.g.:

export MY_HTTP_AUTH_1="Basic <credential>"
export MY_HTTP_AUTH_2="Bearer <credential>"
export MY_HTTP_AUTH_3="<base64 encoded digest auth>"

In the case of digest authentication, the syntax might be cumbersome, so having a way to inform aqua to decode the environment variable from base64, could be helpful. This could be controlled by a registry setting (auth_env_encoding=base64 or auth_env_base64=true).