Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-5052

Customize konflux build pipeline

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Critical Critical
    • None
    • None
    • Operator
    • None
    • GitOps Crimson - Sprint 3261, GitOps Crimson - Sprint 3262, GitOps Crimson - Sprint 3263, GitOps Crimson - Sprint 3264, GitOps Crimson - Sprint 3265

      Story (Required)

      As a user of gitops on konflux, I want my build process to be customized to the team's specifications. 

      Background (Required)

      There are numerous customizations available with konflux build pipelines- see the documentation here: https://konflux-ci.dev/docs/how-tos/configuring/customizing-the-build/. 

      As a team we will need to determine what we would like to customize to suit our needs. Some questions that we need to decide on as a team are:

      1. How long konflux should save the images that it builds for pull requests?
      2. Do we want to add compliance checks?
      3. Do we want to add the sast-snyk-check which runs snyk as part of our konflux pipelines?
      4. Do we want to use our own quay repo to control user permissions? (The default is that all pipelines will push the images to a registry-service.kind-registry:5001 which is set up during installation)
      5. Do we need to have hermetic builds?
      6. Do we want to have certain components only rebuild when specific paths get updated
      7. Do we want to include any custom build-time (tekton) tasks? (basic ones are listed here, any additional ones we will need to add ourselves)

      Once we have decided on these questions, we need to implement them in our konflux configurations.

      Out of scope

      • adding applications/components
      • testing of complete pipeline

      Approach (Required)

      Follow the instructions in this document: https://konflux-ci.dev/docs/how-tos/configuring/customizing-the-build/ 

      Dependencies

      Depends on questions above being answered as a team
      Acceptance Criteria (Mandatory)

      • Discuss questions as a team (ex: in a cabal meeting)
      • follow documentation to turn those customizations into configuration code 

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Legend

      Unknown

      Verified

      Unsatisfied

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

              aveerama@redhat.com Abhishek Veeramalla
              rescott1 Regina Scott (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: