Registry Repositories

Functionality is available in Enterprise and Atlas versions.

Registry repositories - a platform feature that is a logical continuation of the container and package registry function. Unlike the general registry where, for example, Maven packages, Docker containers, and artifacts saved as Generic packages reside in a single shared registry, registry repositories store artifacts of only one specific type. The following features allow building any required file storage structure:

Access to artifacts, including those in external registries
Creating repositories at project, company, or entire service level
No limitations on the number of repositories themselves

Creating a Registry Repository

Registry repositories can be created at three possible access levels - project, company, and entire service:

Project - after creating a project, navigate to the Container and Package Registry section and select the Registry Repositories tab. Creating new Registry Repositories is available to project members with a role no lower than Administrator.
Company - after creating a company, navigate to the Container and Package Registry section and select the Registry Repositories tab. Creating new Registry Repositories is available to company members with an Administrator role.
Service - after accessing the Admin Panel, navigate to the Package Registry section and select the Registry Repositories tab. Creating new Registry Repositories is available only to Service Administrators.

All packages uploaded at the service level are available to every user in the general Package Registry section.

After clicking the New Registry Repository button, a dropdown list will appear where you need to select the type of the new repository.

Local Registry Repository

Represents a repository where you can upload your own packages or artifacts. To create, you need to specify:

Package type - the specific type of packages that will be available for upload to the repository.
Repository name - will be displayed in the general list of repositories. Can contain numbers, Latin letters, the - symbol, and be no longer than 64 characters.
Repository description - any information about the repository that may be useful. Can contain up to 600 characters. Optional field.
Anonymous access permission - determines whether package downloads via transport method from the repository are available to users without access to this repository.
Package deletion permission - determines whether deleting any packages within this repository is allowed.
Package overwrite type - determines whether overwriting existing packages within this repository is allowed.
GPG key pair - required for signing Maven and Debian packages. Optional field.

Proxy Registry Repository

Acts as an intermediary that can be accessed to download packages from external repositories. To create, you need to specify:

Package type - the specific type of packages that will be available for proxying. For proxy repositories, only the following package types can be selected: Maven, NPM, PyPi, NuGet, Container.
Repository name - will be displayed in the general list of repositories. Can contain numbers, Latin letters, the - symbol, and be no longer than 64 characters.
Repository description - any information about the repository that may be useful. Can contain up to 600 characters. Optional field.
URL - link to the external resource where requests will be proxied. For example, https://index.docker.io.
Username and Password / access token - credentials for authorization in the external repository. A connection test button is available.
Artifact storage permission - determines whether artifacts obtained from external repositories will be saved in the cache. Learn more about cache operation here.
Unused artifact lifetime - specifies the number of hours an artifact will remain in the cache since its last download. A value of 0 indicates no limit.
Artifact metadata caching period - number of seconds to cache metadata files before checking for new versions on the remote server. A value of 0 indicates no caching.
Offline mode - determines whether artifacts can be obtained only from the local cache.

Storing Proxied Artifacts

If the proxy registry repository has the Artifact storage permission option enabled, all artifacts proxied from external registries will be saved in the local cache. A separate repository will be created for storage with a name derived from the proxy repository's name - <proxy-repository-name>-cache.

This type of repository cannot be Deleted. Instead, you need to edit the parent proxy repository and disable the Artifact storage permission option. Cache operation settings are configured via parent proxy repository settings.

Virtual Registry Repository

Allows building a chain from other registry repositories of any type to access artifacts via a single URL. To create, you need to specify:

Package type - only repositories with this package type will be available for building the chain.
Repository name - will be displayed in the general list of repositories. Can contain numbers, Latin letters, the - symbol, and be no longer than 64 characters.
Repository description - any information about the repository that may be useful. Can contain up to 600 characters. Optional field.
Requests to proxy repositories - determines whether requests to proxy repositories can access the external registry or only retrieve artifacts from the cache. This setting is available only if the package type is Maven, NPM, PyPi, NuGet, Container.
Repositories - list of repositories that will be included in the virtual repository in the specified order. When requesting artifacts, the virtual repository always searches for them in the following order: all selected local repositories in the specified order, then proxy repositories, followed by virtual ones. Only repositories higher in the hierarchy are available for selection. For example, when creating a repository at the project level, repositories from this project, the parent company (if the project is owned by that company), and the entire service will be available for selection.
Deployment repository - a local repository where artifacts will be saved when uploaded to this virtual repository. Only repositories from the entity (project, company, or service) where this virtual repository is being created can be selected.

Publishing and Downloading Artifacts

Project or company members with a role no lower than Developer can publish artifacts to created local repositories, as well as virtual ones with a selected Deployment Repository. Downloading artifacts is available to any user with access to the registry repository. Artifacts can be published and downloaded both via the web interface and transport method.

Web Interface

To publish artifacts via the web interface, navigate to the Registry Repositories page and click the Upload button. After selecting the target repository, fields necessary for uploading the artifact will appear in the opened window. Depending on the package type specified for the selected repository, the set of fields will vary. After filling in the fields and selecting a file, click the Upload button to complete the artifact publication.

Target Path

By default, uploading via the web interface occurs as an artifact of a specific package type - the path to the uploaded artifact is formed based on the filled fields and meta-information of the selected file. To upload an artifact with a specific path, use the Target Path - uncheck the option to upload the file as an artifact of a specific package type and specify the required path in the unlocked field.

Example of Target Path operation.

When uploading the file archive.tgz to the local repository repository-name with the Generic package type, specify Package name - file-name and its Version - 1.0.0. When uploading as a Generic artifact, the selected file will be available at the path: repository-name/file-name/1.0.0/archive.tgz. To upload an artifact to the path folder/build.tar.gz, specify this string (including the filename) in the Target Path field.

Transport Method

To interact with repositories via the transport method, you need to obtain a GitFlic transport token. Instructions for obtaining the token can be found on this page.

Depending on the repository's package type, the actions required for publishing or downloading via the transport method vary. To get instructions, navigate to the Registry Repositories page, click the Install button, and select a repository. To apply the commands, fill in the fields enclosed in angle brackets, e.g., <transport token> with the necessary values. All information required for uploading is available on the artifact description page, which can be opened by selecting the artifact in the file tree on the general Registry Repositories page.

Learn more about the general principles of package managers and their operation in the GitFlic registry on this page.

Deleting Artifacts and Repositories

Deleting repositories is available to users with a role no lower than Administrator in parent entities. Select the desired repository, click the Delete button, choose the Delete repository option, and confirm deletion by entering the control string.

Deleting individual files, folders, artifact versions, or entire contents is available to users with a role no lower than Developer in parent entities. Select the desired entity, click the Delete button, choose the appropriate deletion option, and confirm deletion.

Deleted files with all their contents will be moved to the Trash, located at the bottom of the file tree. If a file remains in the trash for more than 7 days, it will be automatically permanently deleted. For immediate deletion, the Empty Trash function is available. The standard time files remain in the trash can be changed using the gitflic.atlas.trash_can.lifetime parameter in the application.properties configuration file.