Skip to content

stackrox/rox-ci-image

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

202 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

GitHub Action

StackRox CI & Build Images

This repository holds the Dockerfiles for images used in StackRox CI & builds.

Image Tags and Release Process

Each image flavor (e.g. stackrox-test, scanner-test) is pushed to quay.io/stackrox-io/apollo-ci with three types of tags:

Tag Example Updated when Use in
versioned stackrox-test-0.5.7 Every merge to main (auto-tagged) Release branch prow configs, pinned references
latest stackrox-test-latest Every new version tag on main Testing rox-ci-image version in openshift/release PRs with /pj-rehearse before promoting to stable.
stable stackrox-test-stable Manual promotion via workflow Master/nightly prow configs in openshift/release

How it works

  1. Merge to main -- tag.yaml auto-creates a semver tag (e.g. 0.5.8)
  2. Tag push -- build.yaml builds all images, pushes versioned tags, and updates latest (only if the tag is the highest version on main)
  3. Promote to stable -- run manually when ready:
    gh workflow run promote-stable.yaml
    # or with a specific version:
    gh workflow run promote-stable.yaml -f version=0.5.8
    This does a server-side retag (no rebuild) of all image flavors from the specified version (default: latest) to stable.

Updating prow jobs in openshift/release

Prow job configs in the openshift/release repository reference these images via build_root.image_stream_tag. The tags must first be mirrored in core-services/image-mirroring/_config.yaml.

  • Master/nightly configs: use stable tag -- periodically, automatically picks up promoted versions without config changes.
  • Release branch configs: pin to a specific version (e.g. scanner-test-0.5.7) for reproducibility.
  • latest tag: use only for testing PRs against openshift/release. latest is a moving target and should not be used for required jobs -- it is intended only for validation before promoting to stable.

Mirroring new versions to openshift CI

To mirror a new versioned tag for release branch use:

  1. Add an entry to core-services/image-mirroring/_config.yaml in openshift/release
  2. PR requires testplatform team review

The latest and stable floating tags are mirrored once and do not need updates per version.

Step-by-step: Making a CI Image Change

Example: you need to bump a dependency or add a tool to the CI image.

  1. Make your change on a branch and open a PR in this repo.
  2. Merge to main -- once approved, merge the PR. The tag.yaml workflow auto-creates a semver tag (e.g. 0.5.8).
  3. Wait for the build -- the build.yaml workflow builds all image flavors and pushes both versioned and latest tags to quay.io.
  4. Test in openshift/release -- open a PR in openshift/release that references the latest tag and run /pj-rehearse to validate affected prow jobs. No config change is needed if the jobs already use latest.
  5. Promote to stable -- once rehearsals pass, run the promote-stable workflow (or gh workflow run promote-stable.yaml). This retags lateststable. Master/nightly prow jobs pick up the new image automatically.
  6. Pin release branches (if needed) -- for release branch configs, update openshift/release to reference the specific versioned tag (e.g. stackrox-test-0.5.8). This requires testplatform review.

Note: There is only one latest tag per flavor, so only one rox-ci-image change can be tested via rehearsal at a time. Coordinate with others if multiple changes are in flight.

Updating the Go Version

To bump the Go version across all Docker images in this repository, use the automated script:

./scripts/bump_go_version.sh <target_version>

Example

./scripts/bump_go_version.sh 1.24.6

What the script does

  1. Validates the target Go version format
  2. Fetches the SHA256 checksum for go<version>.linux-amd64.tar.gz from https://go.dev/dl/
  3. Automatically finds all Dockerfiles containing GOLANG_VERSION argument
  4. Updates GOLANG_VERSION and GOLANG_SHA256 in all found Dockerfiles
  5. Creates a new branch named bump-go-<version>
  6. Commits the changes with a descriptive message
  7. Pushes the branch to origin
  8. Creates a pull request (requires GitHub CLI)

Requirements

  • Clean git working tree (no uncommitted changes)
  • Push access to the repository
  • GitHub CLI installed and authenticated

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Packages

 
 
 

Contributors