Supporting multiple catalog hubs in Pipelines-as-Code. Goals Let platform administrators setup multiple hub endpointCurrently, Pipelines as Code allows customization of the catalog hub from where the tasks are fetched, using upstream hub as default.Platforms Administrators may want to configure multiple catalog hubs to utilize tasks from different locations. For example, they might have their own set of tasks from their own hub and also want to use tasks from the official upstream Hub. Let the user specify the catalog hub from which they want to fetch tasks in the PipelineRun.Users should be able to specify in the PipelineRun from which catalog hub they want to fetch tasks. This allows them to use tasks from different catalog hubs within the same PipelineRun. Non-Goals This applies only to Pipelines as Code's remote resolution from hub feature using annotations and does not apply to the Tekton custom resolver feature. Design

With Pipelines-as-Code, you can effortlessly connect your code on popular Git platforms like GitHub to your Tekton Pipelines. One of the key benefits of Pipelines-as-Code is its contribution to security. It empowers you to ensure that only trusted contributors or owners have the ability to run your Pipelines. Default execution rules By default, when a user sends a Pull Request to your repository, the PipelineRun will only be executed if: The user is an Owner or a Collaborator of the repository. The user is a member of the organization and the repository is owned by the organization.

Goal Let PAAC actions and access be driven by groups of people as defined on the Git Platforms (ie: Github teams) instead of all or nothing Description PAAC currently let anyone runs a pipelinerun as long they are on the Github organisation or a contributor of the repo where the pull request run. It allows the users issuing a /ok-to-test or /retest to let non contributor to run the tests. Problem on a large organisation, not everyone can be trusted for every repositories to let run a CI or let someone else running the CI.

Video: Doc: https://pipelinesascode.com Preparation Created Sample Repo: https://github.com/chmouel/pac-demo (fork it!!) Installed Kind https://kind.sigs.k8s.io/ (any kubernetes platform works) Only tekton pipelines+dashboard and a ingress pointing to dashboard (setting up dashboard and ingress is optional) Installed latest version of tkn-pac from https://pipelinesascode.com/docs/guide/cli/#install

Statement Admin install the PAC application on their organization enabled for every repository on that cluster. Owner is the owner of a private Repo OrgUser orguser is a user of the organisation but not part of the private Repo OrgUser create a CRD in a namespace with the URL of private Repo on cluster and is able to read the content of the repository in that namespace and even has access to a token (scoped, temporary and limited) for operations. This only can happen if the Owner had created .tekton/pr* files with git-clone into her repository.

Table of Contents GOALS Pipeline generation Notes Testing locally Future GOALS

What is it As stated upstream here It should be possible to define Pipeline and Task definitions and have them committed to a repo which they act on (e.g. this is the intent of the tekton dir in this repo!). Changes to these definitions that are committed to the repo should be picked up and used as soon as they are merged Changes to these definitions in pull requests should be used when testing the pull request, but without affecting any other Runs (e.g. already executing Runs, Runs executing against other Pull Requests) Typical scenario Github PR tested with a Pipeline CI

# v0.5.0 Release TektonCD CLI is a major release that add compatibility with TektonCD Pipeine release v0.8.0, creating new resources interactively, starting pipeline with new resources, task describe and start commands among other features and bugfixes. Tektoncd-cli in now in homebrew-core, but the tap is still the preferred method for installing the latest version of tektoncd-cli, since both have the same name by default it will use the homebrew-core version which could be slightly outdated,

# TektonCD Release ## High Level In order to make a fully integrated TektonCD release, we have to cordinate the downstream release of multiple components : * Tagged images of `pipeline` based on UBI pushed to quay.io. * An `olm` manifest referencing these images. * A `cli` released, compatible with the `pipeline` release. * A tagged release of the `catalog` tasks compatible with the `pipeline` release. * A set of `catalog` images tagged for the `catalog` release. # Details These steps have

# CI Images Test on Operator ## Pick up the build namespace * Go to your PR and open the raw build-log. totxt pick-up where the namespace for your PR has been created. You should look like for a log message like this : ``` 2019/09/20 08:51:52 Creating namespace ``` now you know that `ci-op-z1jqr9id` is the repository, you shoudd have access to that namespace on https://api.ci.openshift.org/console/ as long as you are the owner of that PR (it creates a `Rolebinding` for this). ## Generate