Summary
Add end-to-end installation, upgrade, and removal tests for Debian and RPM packages. The current smoke test validates init-script behavior in isolation but cannot detect failures in package-maintainer scripts, service-manager selection, account provisioning, or permission migration.
Context
Recent changes in build-deb.sh and build-rpm.sh substantially alter service user/group creation, runtime directory ownership, configuration permissions, and systemd-versus-SysV detection. These operations are privileged, distribution-specific, and required to remain idempotent across fresh installs and upgrades.
tests/service-init-smoke.sh and the checks in .github/workflows/package-builder.yml provide useful shell-level coverage, but they do not install the generated artifacts or execute their lifecycle hooks in realistic environments. A package can therefore build successfully while leaving hlquery unable to start, read its configuration, or preserve service availability during an upgrade.
For a high-performance search engine, packaging regressions are especially costly because they can make persistent indexes unavailable even when the database engine itself is healthy.
Proposed Implementation
- Add container-based lifecycle tests for supported Debian- and RPM-family distributions.
- Build the package once, then test:
- Fresh installation and creation of the expected service account and group.
- Correct ownership and restrictive access for runtime configuration.
- Idempotent reinstall and upgrade from a previously packaged version.
- Startup and status checks through systemd when it is operational.
- SysV fallback when
systemctl exists but systemd is not the active init system.
- Removal and purge behavior without deleting persistent index data unintentionally.
- Run a minimal hlquery readiness probe after installation instead of relying only on service-manager exit codes.
- Assert that failed account creation or invalid permissions cause the package transaction to fail with actionable diagnostics.
- Add the lifecycle suite to
.github/workflows/package-builder.yml after each package build, while retaining tests/service-init-smoke.sh for fast static feedback.
Impact
This would catch the highest-risk packaging failures before release, protect upgrades from service outages, verify security-sensitive permissions, and ensure that both init-system paths remain functional. It would also make future packaging hardening substantially safer by converting implicit installation assumptions into executable compatibility guarantees.
Summary
Add end-to-end installation, upgrade, and removal tests for Debian and RPM packages. The current smoke test validates init-script behavior in isolation but cannot detect failures in package-maintainer scripts, service-manager selection, account provisioning, or permission migration.
Context
Recent changes in
build-deb.shandbuild-rpm.shsubstantially alter service user/group creation, runtime directory ownership, configuration permissions, and systemd-versus-SysV detection. These operations are privileged, distribution-specific, and required to remain idempotent across fresh installs and upgrades.tests/service-init-smoke.shand the checks in.github/workflows/package-builder.ymlprovide useful shell-level coverage, but they do not install the generated artifacts or execute their lifecycle hooks in realistic environments. A package can therefore build successfully while leaving hlquery unable to start, read its configuration, or preserve service availability during an upgrade.For a high-performance search engine, packaging regressions are especially costly because they can make persistent indexes unavailable even when the database engine itself is healthy.
Proposed Implementation
systemctlexists but systemd is not the active init system..github/workflows/package-builder.ymlafter each package build, while retainingtests/service-init-smoke.shfor fast static feedback.Impact
This would catch the highest-risk packaging failures before release, protect upgrades from service outages, verify security-sensitive permissions, and ensure that both init-system paths remain functional. It would also make future packaging hardening substantially safer by converting implicit installation assumptions into executable compatibility guarantees.