Packaging Build Environment Management
Introduction to Packaging Environments
In our packaging process, we utilize Docker images for each OS/release/PostgreSQL version combination. Docker images offer a reliable and consistent environment for packaging software applications. They provide several advantages for the packaging process:
Isolation: Docker containers encapsulate applications and their dependencies, ensuring isolation from the underlying host system. This isolation helps prevent conflicts between different software components and provides a clean and reproducible environment for packaging.
Reproducibility: Docker environments enable the creation of reproducible packaging environments. By defining the dependencies and configurations within a Docker image, it becomes easier to recreate the same environment across different systems, ensuring consistent packaging results.
Portability: Docker environments are portable and can be easily shared across different systems. This portability ensures that the same packaging results can be achieved across different systems, eliminating environment-related issues.
Scalability: Docker environments can be easily scaled up or down to meet the packaging requirements. This scalability ensures that the packaging process can be efficiently adjusted to handle different workload sizes.
Other Benefits: Docker environments provide a secure, reliable, consistent, flexible, efficient, simple, and maintainable packaging environment. Docker isolates the packaging process from the underlying host system, ensuring a controlled and stable environment.
Docker Images for Various Package Types
We utilize Docker images for each OS/release/PostgreSQL version combination to create a reproducible and consistent packaging environment.
For Debian-based packages, we can use the same Docker image for all PostgreSQL versions.
For example, the Debian/10 Docker image can be used for both PostgreSQL 13 and PostgreSQL 14 packages.
However, for RPM-based packages, we need a dedicated Docker image for each PostgreSQL version.
For instance, we require a Docker image for CentOS/7 with PostgreSQL 13 and another Docker image for CentOS/7 with PostgreSQL 14 packages.
Here are the supported OS/release pairs:
- CentOS
centos/7
- Oracle Linux
oraclelinux/7
oraclelinux/8
- AlmaLinux
almalinux/9
- Debian
debian/buster
debian/bullseye
debian/bookworm
- Ubuntu
ubuntu/bionic
ubuntu/focal
ubuntu/jammy
ubuntu/kinetic
PGXN
Based on these OS/release pairs, the Docker images for each OS/release/PostgreSQL version combination are as follows:
- CentOS
centos/7 PostgreSQL 13
centos/7 PostgreSQL 14
centos/7 PostgreSQL 15
centos/7 PostgreSQL 16 (planned)
- Oracle Linux
oraclelinux/7 PostgreSQL 13
oraclelinux/7 PostgreSQL 14
oraclelinux/7 PostgreSQL 15
oraclelinux/7 PostgreSQL 16 (planned)
oraclelinux/8 PostgreSQL 13
oraclelinux/8 PostgreSQL 14
oraclelinux/8 PostgreSQL 15
oraclelinux/8 PostgreSQL 16 (planned)
- AlmaLinux
almalinux/9 PostgreSQL 13
almalinux/9 PostgreSQL 14
almalinux/9 PostgreSQL 15
almalinux/9 PostgreSQL 16 (planned)
- Debian
debian/buster (all PostgreSQL versions)
debian/bullseye (all PostgreSQL versions)
debian/bookworm (all PostgreSQL versions)
- Ubuntu
ubuntu/bionic (all PostgreSQL versions)
ubuntu/focal (all PostgreSQL versions)
ubuntu/jammy (all PostgreSQL versions)
ubuntu/kinetic (all PostgreSQL versions)
PGXN
Developing and Maintaining Docker Images
The Dockerfiles used to build Docker images are located in the “develop” branch of the packaging repository. We follow a template structure to auto-generate Docker files for each OS/release/PostgreSQL version combination. The templates used are:
Dockerfile-deb.tmpl: This template generates Docker files for Debian-based packages.
Dockerfile-rpm.tmpl: This template generates Docker files for RPM-based packages.
Dockerfile-pgxn.tmpl: This template generates Docker files for PGXN-based packages.
After making changes to the template files, the update_dockerfiles.sh script needs to be run to generate the Docker files for each OS/release/PostgreSQL version combination.
Once the changes are committed and pushed, the GitHub Actions workflow will build the Docker images using the generated Docker files.
After confirming that all Docker images are successfully built, the changes can be merged into the master branch.
When the changes are merged into the master branch, the GitHub Actions workflow will push the Docker images to the citus/packaging Docker Hub repository.
If you want to publish test images from citus/packaging-test, you can use the test pipeline. To use the test pipeline, change the current branch to your branch name. The test pipeline will then push the Docker images to the citus/packaging-test Docker Hub repository.