TEST-INFRA: [ci-pipeline-design] Introduce a build stage #2849

Open
opened 2026-04-04 20:54:45 +00:00 by freemo · 0 comments
Owner

Metadata

  • Branch: chore/ci-pipeline-build-stage
  • Commit Message: chore(ci): introduce build stage grouping packaging and deployment jobs
  • Milestone: v3.6.0
  • Parent Epic: #2810

Background and Context

The CI pipeline currently runs the build, docker, and helm jobs in parallel with the test jobs. These jobs are related to packaging and deployment and are logically distinct from test execution. Grouping them into a dedicated build stage that runs only after tests have passed improves pipeline clarity, enforces a correct dependency order, and prevents wasted packaging effort when tests are failing.

Expected Behavior

A build stage exists in ci.yml that contains the build, docker, and helm jobs. This stage is gated on the successful completion of all test jobs, ensuring packaging and deployment artefacts are only produced from verified code.

Acceptance Criteria

  • A build stage is defined in ci.yml.
  • The build, docker, and helm jobs are members of the build stage and no longer run in parallel with test jobs.
  • The build stage declares an explicit dependency on the test stage(s) so it only runs after all tests pass.
  • The CI pipeline remains fully functional end-to-end after the change.

Supporting Information

  • Relates to the broader CI Quality Gates Restoration effort tracked in #2810.
  • The ci.yml file is the primary file to be modified.

Subtasks

  • Create a new build stage in ci.yml
  • Move the build job to the new build stage
  • Move the docker job to the new build stage
  • Move the helm job to the new build stage
  • Add needs: / stage dependency so the build stage only runs after test jobs pass
  • Verify the pipeline runs correctly end-to-end in CI
  • Run nox (all default sessions), fix any errors
  • Verify coverage >= 97% via nox -s coverage_report

Definition of Done

This issue is complete when:

  • All subtasks above are completed and checked off.
  • The build stage is implemented in ci.yml and runs only after the test jobs have passed.
  • The build, docker, and helm jobs are part of the build stage and no longer run in parallel with test jobs.
  • The CI pipeline is more organised and easier to understand.
  • A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
  • The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
  • The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.
  • All nox stages pass.
  • Coverage >= 97%.

Automated by CleverAgents Bot
Supervisor: Test Infrastructure | Agent: ca-new-issue-creator

## Metadata - **Branch**: `chore/ci-pipeline-build-stage` - **Commit Message**: `chore(ci): introduce build stage grouping packaging and deployment jobs` - **Milestone**: v3.6.0 - **Parent Epic**: #2810 ## Background and Context The CI pipeline currently runs the `build`, `docker`, and `helm` jobs in parallel with the test jobs. These jobs are related to packaging and deployment and are logically distinct from test execution. Grouping them into a dedicated `build` stage that runs only after tests have passed improves pipeline clarity, enforces a correct dependency order, and prevents wasted packaging effort when tests are failing. ## Expected Behavior A `build` stage exists in `ci.yml` that contains the `build`, `docker`, and `helm` jobs. This stage is gated on the successful completion of all test jobs, ensuring packaging and deployment artefacts are only produced from verified code. ## Acceptance Criteria - A `build` stage is defined in `ci.yml`. - The `build`, `docker`, and `helm` jobs are members of the `build` stage and no longer run in parallel with test jobs. - The `build` stage declares an explicit dependency on the test stage(s) so it only runs after all tests pass. - The CI pipeline remains fully functional end-to-end after the change. ## Supporting Information - Relates to the broader CI Quality Gates Restoration effort tracked in #2810. - The `ci.yml` file is the primary file to be modified. ## Subtasks - [ ] Create a new `build` stage in `ci.yml` - [ ] Move the `build` job to the new `build` stage - [ ] Move the `docker` job to the new `build` stage - [ ] Move the `helm` job to the new `build` stage - [ ] Add `needs:` / stage dependency so the `build` stage only runs after test jobs pass - [ ] Verify the pipeline runs correctly end-to-end in CI - [ ] Run `nox` (all default sessions), fix any errors - [ ] Verify coverage >= 97% via `nox -s coverage_report` ## Definition of Done This issue is complete when: - [ ] All subtasks above are completed and checked off. - [ ] The `build` stage is implemented in `ci.yml` and runs only after the test jobs have passed. - [ ] The `build`, `docker`, and `helm` jobs are part of the `build` stage and no longer run in parallel with test jobs. - [ ] The CI pipeline is more organised and easier to understand. - [ ] A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - [ ] The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - [ ] The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done. - [ ] All nox stages pass. - [ ] Coverage >= 97%. --- **Automated by CleverAgents Bot** Supervisor: Test Infrastructure | Agent: ca-new-issue-creator
freemo added this to the v3.6.0 milestone 2026-04-04 20:54:54 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
cleveragents/cleveragents-core#2849
No description provided.