Package: arch-release-promotion
This project allows for promotion and synchronization of existing releases of a
project in Arch Linux’s Gitlab instance.Releases of a project (e.g.project) may consist of several release types
(e.g.image_aandimage_b), which are addressed separately.A promotion encompasses - per release type - PGP signatures for relevant
artifacts (optional), a torrent file (optional) and a JSON payload which can be
used byarchwebto display
information about each release type.Synchronization with a local directory can be achieved for a configurable
maximum amount of release versions (each consisting of their respective
configured release types) of a project.RequirementsArch-release-promotion is Python based. All language specific requirements are
specified in itspyproject.toml.Additionally,arch-release-promotionrequiresgnupgto handle detached PGP signatures.UseAfter installation, refer to the output ofarch-release-promotion-handarch-release-sync-h.ConfigurationThe command-line toolsarch-release-promotionandarch-release-syncmake use of two sources of configuration:makepkg.confis read from
any of its locations in the same priority asmakepkgdoes.
All of the below can also be passed to the tool via environment variables:GPGKEYis recognized for establishing which PGP key to use for signingPACKAGERis recognized for establishing who is doing the signature and
is important forWKDlookupMIRRORLIST_URL(not used by makepkg) is used during the generation of
torrent files to add webseeds (defaults to"https://archlinux.org/mirrorlist/?country=all&protocol=http&protocol=https")GITLAB_URL(not used by makepkg) is used to connect to a GitLab
instance to select, download and promote releases of a project (defaults to"https://gitlab.archlinux.org")PRIVATE_TOKEN(not used by makepkg) is used to authenticate against the
GitLab instance. Thepersonal access tokenneeds to provide write access for the target project.projects.tomlis a configuration file that provides the configuration for a
project and its releases. Configuration files are read and merged with
descending priority from/etc/arch-release-promotion/projects.tomland$XDG_CONFIG_HOME/arch-release-promotion/projects.toml(which defaults to$HOME/.config/arch-release-promotion/projects.tomlif$XDG_CONFIG_HOMEis unset).
Please refer toexamples/example.tomlfor further
reference in regards to the available optionsOpenmetricsIf the upstream project offers anopenmetricsbased metrics file, the data from it can be used as additional information in
the JSON payload.The following metrics are considered.Version metricsDescription and version information about e.g. packages can be derived fromversion_infometrics of typeinfo, that define aname,descriptionandversionlabel.For the metrics to be considered, they have to be configured by adding aversion_metricslist (a list of names to look for) to a release of a
project.# TYPE version_info info
# HELP version_info Package description and version information
version_info{name="my-package",description="Version of my-package used for build",version="1.0.0-1"} 1The above metrics entry would result in the following JSON representation:"version_metrics":[{"name":"my-package","description":"Version of my-package used for build","version":"1.0.0-1"}]Size metricsArtifact size information in MebiBytes (MiB) and description can be derived
fromartifact_bytesmetrics of typegauge, that define anameand adescriptionlabel.For the metrics to be considered, they have to be configured by adding asize_metricslist (a list of names to look for) to a release of a
project.# TYPE artifact_bytes gauge
# HELP artifact_bytes Artifact sizes in Bytes
artifact_bytes{name="foo",description="Size of foo in MiB"} 832The above metrics entry would result in the following JSON representation:"size_metrics":[{"name":"foo","description":"Size of foo in MiB","size":832}]Amount metricsInformation on the amount of something (e.g. packages) and description can be
derived fromdata_countmetrics of typesummary, that define anameand adescriptionlabel.For the metrics to be considered, they have to be configured by adding aamount_metricslist (a list of names to look for) to a release of a
project.# TYPE data_count summary
# HELP data_count The amount of something used in some context
data_count{name="foo",description="The amount of packages in foo"} 369The above metrics entry would result in the following JSON representation:"amount_metrics":[{"name":"foo","description":"The amount of packages in foo","amount":369}]Promotion artifactThe promotion artifact is a ZIP compressed file (promotion.zip), that is
uploaded to the project before its link is added to the release that it is
promoting.The file contains one directory for each release type that the project offers.
In each release type directory there are is aJSON payload(<release_type>-<version>.json), a directory
(<release_type>-<version>/) containing signatures for any files that have
been setup for detached signatures and optionally a torrent file
(<release_type>-<version>.json) that is created for the release type’s
build artifactsandthe detached signatures contained in the promotion
artifact.example
├── example-0.1.0
│   └── artifact.tar.gz.sig
├── example-0.1.0.json
└── example-0.1.0.torrentJSON payloadThe promotion of a release encompasses one or more JSON payloads, that describe
each release type in the release.{"amount_metrics":[{"name":"foo","description":"The amount of packages in foo","size":369}],"developer":"Foobar McFooface <foobar@mcfooface.com>","files":["something.txt","something.txt.sig"],"name":"foo","pgp_public_key":"SOMEONESPGPKEYID","size_metrics":[{"name":"foo","description":"Size of foo in MiB","size":832}],"torrent_file":"foo-0.1.0.torrent","version_metrics":[{"name":"my-package","description":"Version of my-package used for build","version":"1.0.0-1"}],"version":"0.1.0"}amount_metrics: A list of objects that describe the amount of something
(optional). The list depends on whether the project’s configuration definesamount_metricsand whether those metrics are available in the specific
release.developer: The full uid of the person promoting (and optionally signing
artifacts in) the release type.files: A list of files in the release type.name: The name of the release type.pgp_public_key: The PGP key ID of the key signing files in the release
type.size_metrics: A list of objects that describe the size of something
(optional). The list depends on whether the project’s configuration definessize_metricsand whether those metrics are available in the specific
release.torrent_file(optional): The name of a torrent file created for the
release type. The value depends on whether the configuration for the release
type setscreate_torrenttoTrue.version_metrics: A list of objects that describe the version of something
(optional). The list depends on whether the project’s configuration definesversion_metricsand whether those metrics are available in the specific
release.version: The version of the release type.SynchronizationThe synchronization of releases works by retrieving the list of promoted
releases of the project from the remote. For each promoted release version, the
promotion artifact is downloaded and used to establish whether all of the
configured release types are fully synchronized.Location and cleanupAll release types for each release version are synchronized to a local
directory. The directory and and the maximum amount of synchronized release
versions are configurable globally or per project.sync_dir
├── example_a
│   ├── example_a-0.1.0
│   │   ├── foo.txt
│   │   └── foo.txt.sig
│   ├── example_a-0.1.0.json
│   ├── example_a-0.1.0.torrent
│   └── latest -> example_a-0.1.0
└── example_b
    ├── example_b-0.1.0
    │   ├── bar.txt
    │   └── bar.txt.sig
    ├── example_b-0.1.0.json
    ├── example_b-0.1.0.torrent
    └── latest -> example_b-0.1.0Alatestsymlink is created to point at the currently latest version of
each release type.Any files and directories that are not owned by versions of release types of
the currently synchronized release versions are removed from the
synchronization directory.If changes are introduced to files in the target directory (due to a
synchronization action), it is possible to write a Unix timestamp to a file
that is configurable globally or per project (the directory in which the file
resides in has to exist).System integrationFor systemd based systems there are example systemd system service and timer
files that are provided inexamples/systemd/.
The provided service file relies on the userarch-release-syncwhich may be
created using thesysusers.dintegration
provided inexamples/sysusers.d/.LicenseArch-release-promotion is licensed under the terms of theGPL-3.0-or-later(seeLICENSE).