feat(tool-images): add GLPK and MariaDB Connector/C system-library images

Jobs that build against GLPK or a MySQL client library had no
capability to supply them on the stock runner image. Both are now
reference system-library images following the sysroot payload
contract, built on the runner image's Ubuntu release.

GLPK uses its own arithmetic rather than GMP and ships no pkg-config
file, as the distribution's development package does not either, so a
build finds it through the CPATH and LIBRARY_PATH the hook sets.

MariaDB Connector/C stands in for the distribution's MySQL client
development package: libmariadb.pc, the libmysqlclient names, and
mariadb_config with a mysql_config copy, both of which find their
prefix from their own path. Its authentication plugins are built into
the library, since it would load them from an absolute directory a
relocated payload cannot provide; the build fails if one is left to
load.

The relocation suite checks both from /opt/sysroot: their programs in
the stock image, and C programs compiled against them in the build
runner image, including the plugins MySQL 8 servers ask for.

Author: Mearman

.github/workflows/publish-tool-images.yml

@@ -36,6 +36,8 @@ jobs:
           - {name: openmpi, kind: sysroot}
           - {name: highs, kind: sysroot}
           - {name: libpq, kind: sysroot}
+          - {name: glpk, kind: sysroot}
+          - {name: libmariadb, kind: sysroot}
           - {name: build, kind: runner}
         platform:
           - {arch: amd64, runner: ubuntu-latest}
@@ -130,6 +132,8 @@ jobs:
           - {name: openmpi, kind: sysroot}
           - {name: highs, kind: sysroot}
           - {name: libpq, kind: sysroot}
+          - {name: glpk, kind: sysroot}
+          - {name: libmariadb, kind: sysroot}
           - {name: build, kind: runner}
     steps:
       - uses: actions/checkout@v7

.github/workflows/system-libraries.yml

@@ -1,13 +1,15 @@
 name: System libraries
 
-# Builds each reference system-library capability image in tool-images/ (Open MPI, HiGHS, libpq) natively on amd64 and arm64 and proves it works relocated (tests/system_libraries/run.sh): its payload is copied to /opt/sysroot as the role's init container copies it, the role's own job-started hook applies the environment the role renders for it, and inside the stock actions-runner image the payload's programs run from there, and inside the reference build runner image (tool-images/build) a program compiled against the payload does (for Open MPI, a two-process mpirun). Only on changes that can affect them. Builds nothing it publishes.
+# Builds each reference system-library capability image in tool-images/ (Open MPI, HiGHS, libpq, GLPK, MariaDB Connector/C) natively on amd64 and arm64 and proves it works relocated (tests/system_libraries/run.sh): its payload is copied to /opt/sysroot as the role's init container copies it, the role's own job-started hook applies the environment the role renders for it, and inside the stock actions-runner image the payload's programs run from there, and inside the reference build runner image (tool-images/build) a program compiled against the payload does (for Open MPI, a two-process mpirun). Only on changes that can affect them. Builds nothing it publishes.
 
 on:
   pull_request:
     paths:
       - tool-images/openmpi/**
       - tool-images/highs/**
       - tool-images/libpq/**
+      - tool-images/glpk/**
+      - tool-images/libmariadb/**
       - tool-images/build/**
       - tests/system_libraries/**
       - tests/capabilities/render.yml
@@ -32,7 +34,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        payload: [openmpi, highs, libpq]
+        payload: [openmpi, highs, libpq, glpk, libmariadb]
         platform:
           - {arch: amd64, runner: ubuntu-latest}
           - {arch: arm64, runner: ubuntu-24.04-arm}

README.md

@@ -47,7 +47,7 @@ An Unraid host runs the same cluster role as any other Docker host (it ships Doc
 
 ### Capabilities
 
-A profile can also add tools, libraries and setup to its runner pods when they start, rather than baking them into a runner image someone has to build, publish and patch: `capabilities` names entries of `github_runner_arc_capabilities`. A tool-cache capability is a public, pinned image holding a tool in the Actions tool-cache layout; an init container copies it into the runner's `RUNNER_TOOL_CACHE`, where `actions/setup-node`, `setup-tflint` and other setup actions that consult the cache find it and skip their download, and it can also be put on `PATH` for a tool no setup action looks up. A system-library capability is a public, pinned image holding a relocatable install prefix (shared libraries, headers, pkg-config files, programs) for what cannot live in the tool cache, such as an MPI implementation, a solver library or a database client library; an init container copies it into a sysroot (`/opt/sysroot` by default), and the job-started hook puts the sysroot on `PATH`, `LD_LIBRARY_PATH`, `LIBRARY_PATH`, `CPATH`, `PKG_CONFIG_PATH` and `CMAKE_PREFIX_PATH` and sets any relocation variable the library needs. A hook capability is a script run before each job's first step, through a job-started hook mounted from a ConfigMap. A profile with its own `runs_on_label` then works as a named runner, for example one with Terraform, TFLint and the AWS CLI, or one with Open MPI and a solver library, that workflows select with `runs-on`, all from one values file and the stock `actions-runner` image. `tool-images/` has Dockerfiles for reference tool images (Node.js, Terraform, TFLint, the AWS CLI) reference system-library images (Open MPI, HiGHS, libpq) and a reference build runner image (the stock runner image with a C toolchain, for jobs that compile against those libraries), which `.github/workflows/publish-tool-images.yml` publishes when started by hand or by a `tool-images-*` tag; `roles/github_runner_arc/README.md`'s Capabilities section has the tool-image and payload contracts, how each reference library is declared and proven to work from a relocated prefix, how to build an image of your own, and where capabilities apply.
+A profile can also add tools, libraries and setup to its runner pods when they start, rather than baking them into a runner image someone has to build, publish and patch: `capabilities` names entries of `github_runner_arc_capabilities`. A tool-cache capability is a public, pinned image holding a tool in the Actions tool-cache layout; an init container copies it into the runner's `RUNNER_TOOL_CACHE`, where `actions/setup-node`, `setup-tflint` and other setup actions that consult the cache find it and skip their download, and it can also be put on `PATH` for a tool no setup action looks up. A system-library capability is a public, pinned image holding a relocatable install prefix (shared libraries, headers, pkg-config files, programs) for what cannot live in the tool cache, such as an MPI implementation, a solver library or a database client library; an init container copies it into a sysroot (`/opt/sysroot` by default), and the job-started hook puts the sysroot on `PATH`, `LD_LIBRARY_PATH`, `LIBRARY_PATH`, `CPATH`, `PKG_CONFIG_PATH` and `CMAKE_PREFIX_PATH` and sets any relocation variable the library needs. A hook capability is a script run before each job's first step, through a job-started hook mounted from a ConfigMap. A profile with its own `runs_on_label` then works as a named runner, for example one with Terraform, TFLint and the AWS CLI, or one with Open MPI and a solver library, that workflows select with `runs-on`, all from one values file and the stock `actions-runner` image. `tool-images/` has Dockerfiles for reference tool images (Node.js, Terraform, TFLint, the AWS CLI) reference system-library images (Open MPI, HiGHS, GLPK, libpq, MariaDB Connector/C) and a reference build runner image (the stock runner image with a C toolchain, for jobs that compile against those libraries), which `.github/workflows/publish-tool-images.yml` publishes when started by hand or by a `tool-images-*` tag; `roles/github_runner_arc/README.md`'s Capabilities section has the tool-image and payload contracts, how each reference library is declared and proven to work from a relocated prefix, how to build an image of your own, and where capabilities apply.
 
 ## Build, test, and smoke-test
 
@@ -63,7 +63,7 @@ A profile can also add tools, libraries and setup to its runner pods when they s
   kubectl get pods -n arc-runners-<org>           # zero runner pods when idle is expected, not a bug
   ```
 - **Confirm no disk accumulates across repeated runner jobs:** the Docker host's disk usage (inside the VM, on a host that runs Docker in one) must stay flat across repeated `test-arc-runner.yml` runs.
-- **Test capabilities:** `tests/capabilities/run.sh` builds the reference Node.js tool image and libpq system-library image, renders a profile with capabilities through the ARC role and the scale-set chart, and runs a pod from the chart's runner template in a throwaway kind cluster to check that the tool reaches the tool cache and `PATH` and the library reaches the sysroot and its search paths; `.github/workflows/capabilities.yml` runs it on pull requests. `tests/system_libraries/run.sh [openmpi|highs|libpq]...` proves each reference system-library image works relocated: it copies the payload to `/opt/sysroot` as the role's init container does, applies the role's job-started hook, and runs the payload's programs in the stock `actions-runner` image and a program compiled against it in the reference build runner image (`tool-images/build`, the stock image with `build-essential` and `pkg-config`), including a two-process `mpirun` for Open MPI; `.github/workflows/system-libraries.yml` runs it on amd64 and arm64 on pull requests. The images under `tool-images/` build with `docker buildx build --platform linux/arm64,linux/amd64 tool-images/<name>`; `.github/workflows/publish-tool-images.yml` publishes them (see Releases), and the release workflow does not.
+- **Test capabilities:** `tests/capabilities/run.sh` builds the reference Node.js tool image and libpq system-library image, renders a profile with capabilities through the ARC role and the scale-set chart, and runs a pod from the chart's runner template in a throwaway kind cluster to check that the tool reaches the tool cache and `PATH` and the library reaches the sysroot and its search paths; `.github/workflows/capabilities.yml` runs it on pull requests. `tests/system_libraries/run.sh [openmpi|highs|libpq|glpk|libmariadb]...` proves each reference system-library image works relocated: it copies the payload to `/opt/sysroot` as the role's init container does, applies the role's job-started hook, and runs the payload's programs in the stock `actions-runner` image and a program compiled against it in the reference build runner image (`tool-images/build`, the stock image with `build-essential` and `pkg-config`), including a two-process `mpirun` for Open MPI; `.github/workflows/system-libraries.yml` runs it on amd64 and arm64 on pull requests. The images under `tool-images/` build with `docker buildx build --platform linux/arm64,linux/amd64 tool-images/<name>`; `.github/workflows/publish-tool-images.yml` publishes them (see Releases), and the release workflow does not.
 - **Lint:** `.github/workflows/ci.yml` runs Shellcheck, actionlint, yamllint, hadolint, an Ansible syntax check, ansible-lint (at its `production` profile), and a collection build check on every push and pull request, plus commitlint (on every commit in a pull request, and on the pull request's own title) on pull requests specifically - all gated by one `required-checks` job so a repository ruleset only ever has to require that one check regardless of how many lint jobs exist. hadolint's warning-level pinning advice is visible but non-blocking (`--failure-threshold error`): this repo deliberately floats several images/packages on `latest` rather than pinning. yamllint's config lives in `.yamllint`, relaxing the three default rules that conflict with this project's own conventions (long single-line comments, no leading `---`, GitHub Actions' `on:` key).
 - **Commit messages:** `.husky/commit-msg` runs commitlint locally (after `npm ci`), the same check CI's commitlint job applies, so a message semantic-release would mishandle is rejected before it is pushed. The machine-wide hooks dispatcher hands off to it; without one, `git config core.hooksPath .husky` enables it.