Types of PKGBUILDs

There are 2 types of repos packaging-wise:

  1. The ones that have all required files in the new pkgbuilds repo and don't reference any external repo in PKGBUILDs source()
  2. The ones requiring external repositories as source. These are listed in the SOURCES files below, packages not listed here are automatically packages of the first category:

This file provides the needed information to check for the new version with the scheme $repourl $pkgbuildPathInPkgbuildsRepo $GitlabProjectId

Releasing a new version

This means executing the following for doing changes and releasing a new version:

  1. Would be modified directly in the new pkgbuilds repo, along with their source. Versions are bumped in the PKGBUILD itself and deployments need to happen by increasing pkgver + supplying a fitting commit message (append [deploy pkgname ] to it)
  2. In case of modifying these, one would make the changes to the source files repo (not the new PKGBUILDs one). Then, if a new version should be built, one would push the corresponding tag to that repo (omitting "v", adding v breaks the PKGBUILD!). That's everything needed in case no packaging changes (adding new dependencies for example) that require changing the PKGBUILD occur. The half-hourly pipeline of the PKGBUILD repo then checks for the existence of a new tag. Once a new one gets detected, the PKGBUILD gets updated and deployment occurs via [deploy *] in the commit message. If PKGBUILD changes need to be implemented, this would of course indicate doing it as described in 1. This would increase pkgrel only and not the actual version.

There are currently three bash scripts responsible for CI/CD:

Past pipeline runs may be reviewed by visiting the pipelines page.