Skip to content

Comments

add proposal for multi-stage CI pipeline#84

Open
JimBugwadia wants to merge 1 commit intomainfrom
multi-stage-ci
Open

add proposal for multi-stage CI pipeline#84
JimBugwadia wants to merge 1 commit intomainfrom
multi-stage-ci

Conversation

@JimBugwadia
Copy link
Member

No description provided.

Signed-off-by: Jim Bugwadia <jim@nirmata.com>

- `conformance.yaml`: Remove `prepare-images` job, download artifacts from `build-images` workflow
- `load-testing.yml`: Remove `prepare-images` job, download artifacts from `build-images` workflow
- `images-build.yaml`: Can be deprecated or refactored to use the centralized workflow
Copy link
Member

@aerosouund aerosouund Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

load testing was recently removed from pipelines that run on anything non code related

on:
  release:
    types: [published]
  pull_request:
    branches:
      - "main"
      - "release*"
    paths:
      - "cmd/**"
      - "pkg/**"

And it was never a required workflow for merging. given this, images are already being built only once in conformance.yaml. also, if workflows are running in parallel (load testing and conformance) and each of them builds the image then the net wait time is that of a single image build. Is there any other way you see this can enhance our posture apart from build time ?

**Go Module Cache:**

- Cache `${{ env.GOMODCACHE }}` and `${{ env.GOCACHE }}` in `setup-build-env` action
- Key: `go-mod-${{ runner.os }}-${{ hashFiles('**/go.sum') }}`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could be nice for accelerating the build of images in case each controller container redownloads all go mods during its build

run: npm test -- --shard=1/2 # Example of parallelizing
```

2. The `Slow CI Workflow (slow-ci.yml)`. This workflow triggers only after code is successfully merged into the main branch. This is where you run heavy end-to-end (E2E) tests, performance benchmarks, or complex integration suites.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in my opinion be the highest return activity in the list. I would add that removing e2e tests (entirely) from pre-merge checks is too risky at this point. but the policy library ones indeed can be taken away. we can revisit this after we have completed the exploration of testing tools to see if we are in shape to reduce reliance on e2e tests

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants