Skip to content
openshift-pipelinesPublic

About

Repository to hack things around in the openshift-pipelines organization

Topics

Resources

Stars

2 stars

Watchers

3 watching

Forks

Repository files navigation

openshift-pipelines hack repository

Contains a bunch of hack used for openshift-pipelines repositories.

  • Generate prow configuration (and sync in openshift/release)
    • For task* repositories.
  • Generate github workflows "matrix" for task* repositories.
  • Generate and store the configuration for Konflux resources and automation (build PipelineRuns, ReleasePlans, etc)

Adding New Release

Now release can be added just a click of button.

  • From Action Menu on github select action "Release Action - New Release"
  • Run Workflow with the following inputs:
    • Select main branch
    • Version: Provide the version you want to add e.g 1.23 (will create the tag 1.23.0-RC-1)
  • This workflow will add new PR to hack repo with updated version configuration for the Release Candidate.
  • Verify the PR and merge
  • Repeat the above for subsequent Release Candidate builds
  • When ready to create the final pre-stage release, from the Action Menu on Github run select the action "Release Action - Finalize RC"
  • Run the workflow with the following inputs:
    • Select main branch
    • Version: Provide the version you want to finalize (e.g. 1.23)
  • This workflow will add new PR to the hack repo that removes the RC suffix from the release's version.
  • Verify the PR and merge

After the initial PR is merged then new workflow will be triggered which will generate release configuration in all the Repos. The initial release will be configured as a Release Candidate with a version like 1.23.0-RC-1.


Downstream Branch Creation

When generating Konflux configuration for a new release version, the tool automatically creates the corresponding release branch (e.g. release-v1.25.x) in each downstream repository if it does not already exist.

Branch source selection

The tool uses the immediate predecessor release-v{major}.{minor-1}.x as the source branch. This ensures new releases start from stable content rather than unreleased development work.

The tool will fail if:

  • The target branch is not a versioned release branch (expected format: release-vX.Y.x)
  • Major version bump detected (minor == 0) — requires manual branch creation
  • Previous release branch doesn't exist on remote — requires manual creation

No automatic fallback: If the predecessor branch is missing, you must create the target branch manually. This prevents accidentally creating release branches from development content (next/nightly).


Adding New Patch

When planning a new patch release for a specific minor verson then it is essential to tag the images appropriately.

  • From Action Menu on github select action "Automated Release Actions"
  • Run Workflow
  • Select appropriate Branch
  • Action : new-patch
  • Version: Provide the version you want to add e.g 1.23
  • Run Workflow
  • This workflow will add new PR to hack repo with updated version configuration.
  • Verify the PR and merge

After PR is merged then new workflow will be triggered which will generate release configuration in all the Repos.


Refreshing Upstream Branches

Upstream branches for next release are syned daily. if there is any update in upstream branch name the you will see a PR in hack repo with updated upstream branches in next.yaml.

You can also trigger this workflow manually for next branch or any other branch

It is recommended not to update the upstream branches for released versions. however you may need to update the upstream versions for unreleased versions which you can do by this workflow.

  • From Action Menu on github select action "Automated Release Actions"
  • Run Workflow
  • Select appropriate Branch
  • Action : update-upstream-versions
  • Version: Provide the downstream minor version you want to add or update. e.g "1.23" or "next"
  • Run Workflow
  • This workflow will add new PR to hack repo with updated version configuration.
  • Verify the PR and merge After PR is merged then new workflow will be triggered which will generate release configuration in all the Repos.

Konflux Repository Configuration

Every repository built on Konflux has a configuration file in config/downstream/repos/<repo>.yaml. A repository declares one or more components, and each component maps to a Konflux component (and image).

name: tekton-kueue
upstream: tektoncd/tekton-kueue
no-prefix-upstream: true
min-version: 1.25
components:
  - name: kueue
    prefetch-input: |
      [{"type": "gomod", "path": "upstream"}, {"type": "rpm", "path": ".konflux/rpms"}]

File name, name and version ranges

The file name (config/downstream/repos/<key>.yaml) is the key the repository is referenced by: in the repository list of config/downstream/applications/*.yaml and in the branches map of config/downstream/releases/*.yaml. The GitHub repository that is actually built comes from the name field, which falls back to the file name when it is not set.

Together with min-version and max-version this allows two configurations to describe the same repository for different release ranges. That is how a component is renamed without touching released versions — tekton-scheduler.yaml (max-version: 1.24) and tekton-kueue.yaml (min-version: 1.25) both build openshift-pipelines/tekton-kueue, but 1.24 and older keep the scheduler component and the pipelines-scheduler-rhel9 image, while 1.25 and later get the kueue component and the pipelines-kueue-rhel9 image.

dockerfile

Optional, set per component. When it is not set it defaults to .konflux/dockerfiles/<component-name>.Dockerfile.

Only set it explicitly when the Dockerfile in the downstream repository does not follow that convention, otherwise leave it out so the component and its Dockerfile stay in sync.

prefetch-input

Optional, set per component. It is passed to the build PipelineRun as the Cachi2 prefetch-input parameter. When neither the component nor the repository sets it, it defaults to {"type": "rpm", "path": ".konflux/rpms"}.

A value set on the component replaces that default, so when a component needs more than one prefetch source, list all of them — including the RPM one, if the build needs RPMs:

    prefetch-input: |
      [{"type": "gomod", "path": "upstream"}, {"type": "rpm", "path": ".konflux/rpms"}]

Set the value to NONE (on the component or the repository) to disable prefetching completely.


TODO for automation: (waveywaves)

  • version given as name for downstream components (console, manual-approval-gate, tekton-cache)
  • for repos which have an upstream, the lastest patch release for a minor release can be picked up from the upstream repo itself.
  • cache was introduced in 1.18 and pruner in 1.19

About

Repository to hack things around in the openshift-pipelines organization

Topics

Resources

Stars

2 stars

Watchers

3 watching

Forks

Releases

Packages

Used by

Contributors

Languages