Motivation
Currently, BlueBuild drivers (GitHub, GitLab, Local) implement opinionated tagging logic that automatically prefixes/suffixes alt-tags with metadata (e.g., branch names, OS versions). While useful for many, this creates friction for projects requiring strict, non-opinionated OCI naming—such as Bazzite or other standardized distributions—often necessitating external yq patching in CI pipelines.
Proposed Solution
Introduce a centralized Tagging Policy Engine in blue-build-utils that:
- Supports a declarative
tagging field in recipe.yml.
- Uses regex-based matching to apply custom expansion rules to
alt-tags.
- Provides a placeholder system (
{tag}, {os_version}, {timestamp}, {short_sha}) for granular control.
- Maintains backward compatibility by falling back to legacy expansion logic if no policies are defined.
Benefits
- Zero-Patching: Users can achieve complex naming (e.g.,
stable-41.20241021) directly from the recipe.
- Maintainability: Centralizes tagging logic, removing redundancy from individual drivers.
- Standardization: Enables BlueBuild to be a non-opinionated builder for any containerized OS project.
Motivation
Currently, BlueBuild drivers (GitHub, GitLab, Local) implement opinionated tagging logic that automatically prefixes/suffixes
alt-tagswith metadata (e.g., branch names, OS versions). While useful for many, this creates friction for projects requiring strict, non-opinionated OCI naming—such as Bazzite or other standardized distributions—often necessitating externalyqpatching in CI pipelines.Proposed Solution
Introduce a centralized Tagging Policy Engine in
blue-build-utilsthat:taggingfield inrecipe.yml.alt-tags.{tag},{os_version},{timestamp},{short_sha}) for granular control.Benefits
stable-41.20241021) directly from the recipe.