- clone this repository
git clone https://github.com/gardenlinux/package-build.git
- clone the package repository, e.g. iproute2
git clone https://github.com/gardenlinux/package-iproute2.git
- run
build
from the package-build repo with the package repository as argument./package-build/build package-iproute2
- optional: If a package build depends on other custom build packages you can provide the
--build-dependencies
flag with a directory containing the.deb
files of build-time dependencies
- optional: If a package build depends on other custom build packages you can provide the
The build artifacts (deb
files and others) are placed in a .build
directory in your package, for example in ./package-iproute2/.build/
.
The build
script takes arguments which may be used to customize the build.
--arch amd64
: Specify the architecture to build- Choices:
amd64
(default),arm64
- Choices:
--source-only
: Only build source archive--binary-only
: Only build the binary archives
To build using GitHub actions simply define a job with
uses: gardenlinux/package-build/.github/workflows/build.yml@main
The GitHub action jobs accepts various inputs:
Flag if this is a release build.
If set to true
this will cause the build job to automatically append gardenlinux0
as the version suffix and create a GitHub release from the resulting source and binary packages.
A list of other GitHub repositories to pull custom build-time dependencies from. In the format <repo> <tag>
Important
Build-time dependencies between packages are not updated automatically and need to be adjusted manually when needed
Specify the GitHub action runner on which to run the job
A full github workflow file to build a package and regularly try if a new version should be build looks as follows:
on:
push:
workflow_dispatch:
schedule:
- cron: '0 0 * * *'
jobs:
build:
uses: gardenlinux/package-build/.github/workflows/build.yml@main
with:
release: ${{ github.ref == 'refs/heads/main' }}
When running the GitHub action job with release: true
it automatically creates a new release with version suffix gardenlinux0
.
To create a patch release for this version:
- Check out the release tag and branch off from it
git fetch --tags git checkout <VERSION>gardenlinux0 git branch <VERSION> git checkout <VERSION>
- Apply modifications or backport patches from main
- Increment the version suffix. The GitHub action job which created the
<VERSION>gardenlinux0
tag automatically added aversion_suffix=gardenlinux0
line to theprepare_source
script. Simply increment this suffix. In certain scenarios you might want to backport this to an older GardenLinux version; in this case you will need to also update the .containerfile and use the proper one; e.g. ghcr.io/gardenlinux/repo-debian-snapshot@sha256:3577da968aa41816bf255e189925c6c67df1266effe800a7d0cd66cddc5760ca for version 1443. - Push the branch
If the action is setup to run on
git push origin <VERSION>
push
, as in the example above, this will trigger the build job to run which detects that this is a new version and thus causes it to be released, setting up the necessary tags and GitHub releases.
If we want to, for example, backport openssl 3.1.7 but this version does not exist in debian salsa step 3 of the above instructions would be to set the prepare_source
script to
version_orig=3.1.7
version="$version_orig-0"
git_src --branch "openssl-$version_orig" https://github.com/openssl/openssl.git
apt_src --ignore-orig openssl
version_suffix=gl0~bp1443
This will cause the package build to fetch all actual source file from the upstream openssl repo on github.com, while taking the debian folder from the apt source package. In the case that there are compatibility issues between the apt source debian folder and the new upstream source some patches might need to be added (see the apply_patches function in the source script).