File Release Management Specifications

There is an interesting feature request at GitLab that could implement better "release" visibility for projects
 

Project Use Case

Let's talk about the arbitrary project Tartempion for the use-case.

The project's team finally got their first release. They need to publish a distribution for download.
The OW2 Policy informally tells us that at release time, any OW2 project should at least provide:

  1. Sources
  2. Binaries
  3. Doc

One should be able to upload those files to OW2, large or small and make them available.

Technically speaking, it requires the user releasing the files (the publisher) to be:

  • identified as an OW2 user (community user).
  • registered as a member of the project (possibly among others projects) - and to belong to the related project's release manager role within the users directory.

CI/CD driven

In an ultimate goal, the distribution of released file should be possible from any automated system (scripts or any CI/CD software).

Statistics

Implementing a way to retrieve metrics about what has been downloaded from the download repository, for a given project, is mandatory.

Data structure

  • A project contain packages(s). Package is assumed the synonym for Component.
  • A Package contains release(s). A Release holds the release name which can be a version number or a string, or both.
  • A Release contains file(s)

The scheme hierarchy is then /<projectName>/<packageName>/<releaseName>/<file>

For example, Tartempion project can have the package Extractor and the release either a name mandela or version number 2.2.5 which in turn contains the files.

Taking the above example we come to:

(root)/tartempion/Extractor/mandela/myfilename.x.y
(root)/tartempion/Extractor/2.2.5/myfilename.x.y

API centric backend

At a glance we don't need an UI in the first iteration of the service but a solid REST-based API backend.

Token-enabled authentication

We don't want to store personal credentials as username and passwords in Ci/Cd jobs. So the system should provide a Token mechanism.

A valid Token is returned upon:
- successful authentication as an OW2 user (login/password)
- The user belongs to the Release manager role.

Elementary backend features

- Get the list of eligible projects for release distribution.
- Get the list of released Packages within a project with related metadata (creation/modification timestamps, related download URLs).
- Get the list of released Releases within a Package and related metadata (as above + changelog + checksums)
- Create a new Package
- Create a new Release

More essential metric-oriented features:
By essence all those data are time-related : day,week,month,year,any.
- Get download counts
- Get transferred volumes
- Others meta-data (IP address for geoloc...)

File upload scenario

Let's say our user belongs to the release manager role of the project Tartempion, and he wants to upload binaries for this project, in a package Extractor with version number 2.2.5.

- auth with login/password, returns valid Token
- using Token, POST with fields : projectName, packageName, releaseName and the binary file.

Error handling if one of those fields doesn't match.

File Management

It should be possible to remove anything at Package, Release and File level.