Uploaded image for project: 'OpenShift Pipelines'
  1. OpenShift Pipelines
  2. SRVKP-472

Pipelines as Code (MVP)

    XMLWordPrintable

Details

    • Config-as-code for Pipeline (MVP)
    • Done
    • SECFLOWOTL-54 - Enable Git workflows for outerloop
    • 100
    • 100% 100%

    Description

      Goal

      As a developer, I want to store the pipeline definition (YAML) alongside the application code in a git repository and run from the git repo, so that the pipeline definition is versioned and tracked similar to the code. Developer should be able to add their repositories that contain pipeline definitions and execute the pipeline on Git events from that repository

      Problem

      On one hand tracking changes to pipelines is difficult when done directly on Kubernetes, and on the other hand if stored in Git then it’s a manual work to keep the pipeline object in sync with Git.
       

      Acceptance Criteria

      • Documentation exists on how the GitHub org admin can enable config-as-code for their organization
      • Developer can store pipeline definitions inside their Git repository for post-merge commit and pull-requests
      • Developers can specify separate pipelines for post-merge commit and pull requests
      • Developers can refer to "repository url" and "revision" as variables inside their pipelines
      • Developers can use config-as-code with private GitHub repositories
      • Developers can push to private image registries through the pipelines that are stored in their Git repository
      • Developers can limit the group of users who can trigger a pipeline through commit/pr to specific GitHub orgs and GitHub teams
      • Developers can declare Tekton Tasks used in their pipelines from the same Git repository or referenced by URL
      • Developers can choose the namespace where their pipelines are executed
      • Developers have access to the pipeline executions (diagram, logs, etc) of their pipeline provided they have the necessary RBAC permissions to the specified target namespace
      • The pipeline execution contain all tasks (inline spec) declared in the Git repository and do not rely on Tasks on the cluster
      • Internal PipelineRun and TaskRuns generated as part of config-as-code infrastructure are garbage collected
      • Developer can configure prunning to retain the last N pipelineruns or pipelineruns from last D days

      Estimation

      XL

      Attachments

        Issue Links

          Activity

            People

              cboudjna@redhat.com Chmouel Boudjnah
              ssadeghi@redhat.com Siamak Sadeghianfar
              Votes:
              1 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: