Evaluate test execution policy in container image build

[josecelano]

Goal

Decide whether tests should continue running inside the container image build path, and if not, define a safer and faster workflow policy that separates validation from packaging while preserving quality.

Background

The current Containerfile runs tests during image build stages. At the same time, test verification is already executed in testing.yaml. This may duplicate expensive work and increase runtime in both container.yaml and testing.yaml paths.

This coupling also scales poorly when packaging targets grow. If the same source revision is packaged in multiple forms (for example multi-architecture container images, Linux distribution packages, or other release artifacts), embedding test execution in each packaging path can repeat the same validation work many times.

Two policy ideas need explicit evaluation:

1. Quality gate alternative: do not run test execution in container build, but enforce image publication or release flow only after testing workflow passes.
2. Debugging flexibility: optionally allow building an image from commits that fail tests, so maintainers can reproduce failures in external environments.

This issue is analysis-first and baseline-driven. Any policy change must preserve trust in merge and release checks.

Acceptance Criteria

• AC1: The report quantifies runtime cost of test execution in the container build path.
• AC2: Duplicate versus unique test coverage is documented for container and testing workflows.
• AC3: At least one policy option separates validation from packaging and preserves strict quality gates.
• AC4: A safe and explicit debug-image policy is defined for failure reproduction use cases.
• AC5: Recommended policy is justified with performance and risk evidence.

Related

• Parent EPIC: EPIC: Improve PR Workflow Performance #1840
• Baseline analysis: Baseline workflow profiling and bottleneck analysis (EPIC #1840) #1841
• Full spec: docs/issues/open/ (after spec PR merge)