Okay so just like #38 but about our Twitter account instead!! https://twitter.com/tektoncd

At the moment only a few folks have access to the twitter account, and this means when there are announcements such as https://twitter.com/chmouel/status/1168821072441090048 they have to come from ppl's personal accounts (thanks @chmouel !) and get retweeted by the tektoncd account.

It would be very cool if folks working on Tekton could make new tweets by opening and merging pull requests.

Open question(s): not sure how to represent actions like "liking" and retweeting other random tweets. Also don't want to block folks from using the Twitter account directly? (Or it will probably never be used to retweet anything) - maybe something can be done to reconcile the state of the twitter account with the repo periodically?

Hey everyone, I've been doing things with the cd.foundation's outreach commitee and we've been discussing Hacktoberfest and how Jenkins did it in the past, see https://www.jenkins.io/events/hacktoberfest/

I think it'd be a good opportunity to encourage folks to contribute to Tekton as part of Hacktoberfest and so I've been thinking of putting together some documentation - we could tell people which labels to use, who are handy contacts if they get stuck, and who are the awesome mentors/contacts to have.

As a start it could be something like added here into the readme at the top (so under, say, hacktoberfest-2020.md which we link to)...

@eddycharly on our recent Dashboard Working Group call suggested we do things a little more personable too as opposed to just some text - so a link to a short introductory video may be of use, as well as a mention of the project ideas we have for each area.

For project areas I'm thinking...

• Dashboard
• Pipeline
• CLI
• Catalog
• Website
• Experimental

Operator and Chains? Not sure about the learning curve here, unfamiliar with contributing to either, so could do with some experts.

Tagging @abayer @vdemeester @bobcatfish @eddycharly @dibyom @afrittoli @AlanGreene for input especially, should anyone want to share ideas on how to best go about it.

Please share this as well with anyone else you think can pitch in, thanks!

P.S, for the Dashboard we've got this so far, and this is from our most recent working group call.

Hacktoberfest

• Docs / website / katacoda enhancements
• Import
  • from catalog by version?
  • kubectl apply doesn’t work with generateName (needs to be a create) which is used in a lot of examples in the pipeline repo, so should the action be customisable or use a different method to import the resources tektoncd/dashboard#1552
  • Support git revision tektoncd/dashboard#1550
• Workspaces not supported for TaskRuns and PIpelineRuns tektoncd/dashboard#1283
• Anything for chains? Looks like no CRDs
• Single namespace install revisit (docs) tektoncd/dashboard#1018 and tektoncd/dashboard#1507
• Security revisit (anything preventing adoption)
• Platform support (e.g. clouds) - try and doc
• Any links/common themes to the other Tekton project areas?
• Update roadmap with progress to date / changes in approach etc.

What animal are the Tekton Friends?

Updating the org.yaml file managed by peribolos can end up breaking the sync, if the syntax is wrong or if, for example, a user is in both admin of the organization and members.

We should add a job on tektoncd/community that run some validation (periobolos dry-run) on PRs.

/cc @afrittoli

We have a shared Tekton calendar at https://github.com/tektoncd/community/blob/master/contact.md#calendar but at the moment only a couple of people can edit it, so when folks want to reschedule meetings (like @hrishin for the observability working group!), they have to find someone with access to the calendar.

What would be really great is if we could have the expected state of the Tekton calendar committed to this repo, and updates to it would be reflected in the Google calendar.

(And even better, it could be implemented with Tekton itself!)

p.s. this was actually @dlorenc 's idea

Hi team，
I encountered kankio deploy problems while building Tekton in a K8S clustered environment：
kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/master/kaniko/kaniko.yaml
Error from server (InternalError): error when creating "https://raw.githubusercontent.com/tektoncd/catalog/master/kaniko/kaniko.yaml": Internal error occurred: failed calling webhook "webhook.pipeline.tekton.dev": Post https://tekton-pipelines-webhook.tekton-pipelines.svc:443/defaulting?timeout=30s: context deadline exceeded

[root@master ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
master Ready master 29d v1.18.3
node1 Ready 29d v1.18.2
node2 Ready 29d v1.18.2

[root@master ~]# kubectl get all -n tekton-pipelines
NAME READY STATUS RESTARTS AGE
pod/tekton-dashboard-5dc59677c9-h8sm2 1/1 Running 0 3h45m
pod/tekton-pipelines-controller-f5945cf7b-gkzck 1/1 Running 0 17h
pod/tekton-pipelines-webhook-859cd5c766-sd4d4 1/1 Running 0 17h
pod/tekton-triggers-controller-788d5f47f4-5rn4n 1/1 Running 0 17h
pod/tekton-triggers-webhook-66dbd655d7-z75w9 1/1 Running 0 17h

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/tekton-dashboard NodePort 10.106.85.130 9097:32428/TCP 3h45m
service/tekton-pipelines-controller ClusterIP 10.96.93.96 9090/TCP 17h
service/tekton-pipelines-webhook ClusterIP 10.97.83.226 9090/TCP,8008/TCP,443/TCP 17h
service/tekton-triggers-controller ClusterIP 10.100.194.28 9090/TCP 17h
service/tekton-triggers-webhook ClusterIP 10.100.206.64 443/TCP 17h

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/tekton-dashboard 1/1 1 1 3h45m
deployment.apps/tekton-pipelines-controller 1/1 1 1 17h
deployment.apps/tekton-pipelines-webhook 1/1 1 1 17h
deployment.apps/tekton-triggers-controller 1/1 1 1 17h
deployment.apps/tekton-triggers-webhook 1/1 1 1 17h

NAME DESIRED CURRENT READY AGE
replicaset.apps/tekton-dashboard-5dc59677c9 1 1 1 3h45m
replicaset.apps/tekton-pipelines-controller-f5945cf7b 1 1 1 17h
replicaset.apps/tekton-pipelines-webhook-859cd5c766 1 1 1 17h
replicaset.apps/tekton-triggers-controller-788d5f47f4 1 1 1 17h
replicaset.apps/tekton-triggers-webhook-66dbd655d7 1 1 1 17h

tekton-pipelines build yaml：
kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
kubectl apply --filename https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
kubectl apply -f https://github.com/tektoncd/dashboard/releases/download/v0.7.0/tekton-dashboard-release.yaml

Hi there, I am working for Tekton development.

Could you please tell me the about Tekton's roadmap?? Or could you please share the document about the roadmap?

Especially I'd like to know when Tekton pipeline, dashboard, cli, etc... will go GA.
Honestly I have read the document roadmap.md but I could not find out when Tekton will go GA.

Some of contributors may be wondering this, e.g. this slack message.

N.B.

• In my understanding, once Tekton goes GA, the value of the version becomes 1.0.0 or more.
• this issue might be related with an issue #256 .

Thank you.

I propose adding a catalog folder to the experimental repo. This experiment would provide maintained task and pipeline definition for people to use in their Tekton Pipeline instances. This would act the same as knative/build-templates but for Tekton objects

Each "definitions" (template, pipeline) would be in a separate directory along with a README.md and a Kubernetes manifest, so you can choose which to install on your cluster.

cc @bobcatfish

Based on the Tekton catalog integration proposal,

This folder/repository would host Catalog resource part of the proposal.

Background

This adds a new CRD, name Catalog, which allow the user to refer which catalog to register on the cluster. This would also bring a tkn-catalog binary (that could be taken into account by tkn) to interact with those CR.

apiVersion: tekton.dev/v1alpha1
kind: Catalog
metadata:
  name: upstream
spec:
  url: https://github.com/tektoncd/catalog
  revision: v0.7 # optional, default would be master or the default branch
  namespace: my-local-catalog
  update: # optional (defaults value to define)
    auto: true
    Interval: 1d # interval of auto-updates
---
apiVersion: tekton.dev/v1alpha1
kind: Catalog
metadata:
  name: openshift
spec:
  url: https://github.com/openshift/catalog
  version: v0.7 # optional, and semver (aka any v0.7.x would be used)
  update: # optional (defaults value to define)
    auto: true
    Interval: 1d
  Priority: 100
---
apiVersion: tekton.dev/v1alpha1
kind: Catalog
metadata:
  name: secret
spec:
  url: [email protected]:vdemeester/my-private-catalog.git
  update: # optional (defaults value to define)
    auto: true
    Interval: 1d
  secret: github-secret # to-be-defined (use creds-init as Task ?)

As this is highly experimental, we only wish to be a folder in the tektoncd/experimental (and we will see later on if it make sense to be on its own or not).

Maintainers

@vdemeester and @sthaha would be the initial ones.

The KEP process includes a very thorough production readiness checklist (thanks @mattmoor !):

https://github.com/kubernetes/enhancements/blob/master/keps/NNNN-kep-template/README.md#production-readiness-review-questionnaire

Probably worth looking at these one at a time and seeing if any translate over - however @vdemeester maybe you already did this in which case I'm happy to close this.

At first glance it looks like many of them won't exactly translate to Tekton, and maybe we can build up a list like this over time, but if there's anything we can learn from this list and just adopt let's do it!

This issue is to discuss the use of vanity url for tektoncd go project.

Go has a mechanism for custom or “vanity” import paths. In addition to the common hosting sites (GitHub, Bitbucket, etc) and custom VCS URLs (.git, .hg, etc) known to the go command, this mechanism can be used to point a custom URL to any of the above listed services.

Taking the lists from the knative issue

• Vanity URLs are nice.
• They can help with repo sprawl.
• And have useful self-documenting properties when a regular website is provided at the host.
• They also allow vendors and partners to donate code without hardcoding the name of the vendor or partner forever and ever, amen.
• Similarly they allow codebases to move through multiple orgs (eg, elafros-incubator, elafros, elafros-attic) with minimal disruption.

Non vanity import paths are considered harmful. If you are a serious project, enforce a vanity import path. #golang
https://twitter.com/rakyll/status/892805962867683328

Also see:

• https://sagikazarmark.hu/blog/vanity-import-paths-in-go/
• knative/serving#4521

Where's the code?

Hi there, hope this issue is appropriate.

What I hope

I would like my contribution to Tekton to be listed in the following Tekton rankings:

• https://tekton.devstats.cd.foundation/d/5/companies-table?orgId=1&var-period_name=Last%20month&var-metric=contributions
• https://www.stackalytics.com/unaffiliated?project_type=tekton-group&module=community@tekton&date=7

What I did

I added my affiliation to github_users.json.

• This is because I found I need to add my affiliation to github_users.json in the Description of the website ranking.
• And in order to add it, I need to edit developers_affiliations2.txt, stored in gitdm repository.
  • gitdm>README.md told it to me.

I confirmed that my affiliation has been imported to github_users.json.

What I need to know

My affiliation will be listed in those rankings once I contributed to Tekton (any repositories such as community, dashboard, pipeline, etc.), right?

• for example, this issue will be counted to the ranking?
• Or is anything else required?

Thank you for your kind help.

This issue is is to track the proposal to create a new repository called homebrew-tektoncd.

The repository will be storing homebrew formulas of the different tekton projects starting with the cli.

Background

Homebrew is a popular package manager to install softwares on OSX

Brew offers a way for projects to provide their own thrid-party repositories which is called taps. The way the taps work is by a naming convention with an homebrew- prefixed repository in the project github organisation.

For example having a repository called homebrew-tektoncd in the tektoncd github org will allow users to simply add the tap with :

brew tap tektoncd/tektoncd

You can then have multiple formulas in there like tektoncd-cli, which the user can install with :

brew install tektoncd-cli

Example

I have a personal brew repository for tektoncd-cli located here :

https://github.com/chmouel/homebrew-tektoncd-cli/

which has been succesfully used for the last few cli releases to provide an easy way to install tektoncd-cli

Maintainers

I and @vdemeester will be maintaining it.

Since we are using goreleaser brew plugin (for at least the cli) to automatically update the formulas when releasing there should be very minimal maintainance.

Related

• tektoncd/plumbing#43
• Homebrew/homebrew-core#43360
• tektoncd/cli#99

The GitHub topics may be a great way to discover e.g. Tekton Pipelines. E.g. continuous-integration is a good way to list popular CI-systems. We should add more and relevant topics to our repositories.

Proposed topic additions to Pipelines repository:

• [continuous-integration]
• [continuous-delivery]
• [continuous-deployment]
• [devops]
• [gitops]

GitHub allows for the creation of a .github repository for defining default config files for common community files (CONTRIBUTING, CODE_OF_CONDUCT, issue templates, etc). https://help.github.com/en/github/building-a-strong-community/creating-a-default-community-health-file

It'd be great to have the repo to centralize common files, and provide useful defaults for issue templates (e.g. bug, feature request, question).

My reading of the docs is that these are defaults, and individual projects would be free to override these if they wanted.

In tektoncd/pipeline#2903 @vdemeester and I started discussing the role of Makefiles when using a Tekton based CI/CD workflow, and then we started talking about the potential differences between what CI/CD runs and what an engineer runs as part of their developer workflow.

I believe that being part of a developer's local workflow is in line with Tekton's mission but @vdemeester disagrees.

I'd like to discuss this further and establish:

1. If it is part of Tekton's mission
2. And if (1), what do we need to change in the mission to reflect this

I propose adding a knative-eventing-extension folder to the experimental repo. This experiment would provide maintained working code showing how Knative eventing could trigger pipeline and task runs from typical eventing sources like GitHub, GitLab, etc.

This work will also include an extension to the Tekton dashboard so that a user can see how the various pieces fit together from code change to pipeline run to running application.

/kind question

Is there any process in place for getting edit access to the projects tab for project management? I'd like to get access in experimental for myself and @dibyom so we can manage project pages for the results and generators projects.

Thanks!

Hi!

I was looking to add the Docs working group to my calendar to start joining. I clicked the link on this page https://github.com/tektoncd/community/edit/master/working-groups.md and it gave me an invite that ran from Dec 19 to Feb 19 (today is May 29) at 13:00 EST.

I pinged @afrittoli (a teammate) and he informed me that it was 11:00 EST :-O

I'm worried more links are wrong/broken, which could be a barrier to entry for new members.

Feature request

Introduce a controller dedicated to sending CloudEvents in the format specified by the CDF SIG Events / CDEvents, which can be later extended to support multiple formats of CloudEvents and events specific options and features.

Tekton defines low level abstractions like Tasks and Pipelines. The SIG Events protocol defines higher level abstractions too, like “Change”, “Build”, “Deployment” and more.
When Tekton is used through an opinionated CI/CD system on top, Tekton would send the events related to tasks and pipelines only. When Tekton is used standalone, we would like to provide users a mechanism to identify their Tekton Tasks and Pipelines as implementations of higher level abstractions, and have Tekton send the corresponding events too. This would be most likely implemented through some form of annotation on Tekton resources.

We would like to start with a project in the tektoncd/experimental repo, with the end goal to either incorporated into tektoncd/pipeline or alternatively become a new project in the tektoncd org. Initial owners of the project will be Vibhav Bobade and Andrea Frittoli.

As described in the community repo, the first step is to present the idea in a WG.
This was done in the WG on Wed May 26th. The next step is to create an issue in the community repo.

Use case

The CDF SIG Events mission is to define a common event based protocol for CI/CD systems to interoperate. An initial draft of the protocol specification is available on the SIG repo. The protocol is based on CloudEvents.

Tekton can already generate CloudEvents for several events, but the format of such events is Tekton specific, and cannot be customized.

Interoperability is key to the success of Tekton, and supporting this new format of CloudEvents would help DevOps engineers and architects integrating Tekton with other CI/CD systems as well as collecting metrics from heterogeneous CI/CD workflows.

Additional Information

It was already proposed to move Tekton support for CloudEvents to a dedicated binary / controller. This work could align with that proposal and implement a controller that could send both the existing format as well as new formats of CloudEvents.

Based on "part of" the Tekton Catalog and Hub Design, I would like to propose having the "tekon hub" project as an experimental project initially.> The Tekton Hub is a web interface where users can both discover existing components and register their components.

As we iterate on our processes around accepting community owned components, we will follow best practices from Helm and start out with only supporting components in tektoncd/catalog, but once we are happy with the process, we will accept community contributions as well.
[…]
The code supporting this hub will live in the tektoncd org and the official instance will be available at hub.tekton.dev.

We already started some work on this at Red Hat, and we would like to upstream these into that project (and later one a full-fledge project )

/cc @sthaha @siamaksade @bobcatfish

Google Calendar Broken Links:
Triggers
CLI
Documentation
Productivity

https://github.com/tektoncd/community/blob/master/working-groups.md#documentation

This is a proposal for a new experimental component to provide a new concept for gates - that is, gating pipeline execution at critical points until criteria is met. Complex pipelines often need to stop and await certain criteria before proceeding. Unlike conditions, gates are excepted to take at least N time duration before proceeding - eg, before promotion step verify that N metric is at or above X threshold for Y hours before proceeding.

Using a dedicated concept will make logical time accounting possible. A pipeline with a defined gate should not be timing out (or accruing time against the timeouts) in the same way that any other pipeline steps or conditions should. A "gate" is configured to wait and gather metrics for at least N duration to pass, so it does not make sense to count this time against the pipeline or step timeout.

Like a step or condition, a gate is an interface where any image is used, but my test implementation will use my prometheus-gate experiment image. This will allow any pipeline to await results from any valid rangequery for a period of time before proceeding past. In this way, any service that can provide metrics via Prometheus can await defined min/max/equality values inside Pipelines.

The link in the contact.md to join the Slack of Tekton CD is not valid anymore

The full proposal text is outlined here: https://docs.google.com/document/d/1dJjNTOXsT_dMZIX4i5iRw10fRQZBQqUP8YmbN2AwhAA/edit#

(shared with tekton-dev)

I'd like to discuss this in the June 3rd community meeting.

Feature request

We already has experimental project cel
That's very useful, but one shortage: cannot evaluate expression with a predefined variable.
for example: job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'
The job_priority is a predefined variables somewhere.

To handle the gap, one solution is introduce the dependency between the params:

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-with-context-
spec:
  ref:
    apiVersion: cel.tekton.dev/v1alpha1
    kind: CEL
  params:
    - name: name
      value: "'hello'"
    - name: types
      value: "type(name)"
    - name: expression-use-context
      value: "name + ' is type of ' + types"

basically, the idea is the subsequent param could leverage previously param for evaluation, see the type(name) leverage the name which is the first param. it has been implements in the PR: tektoncd/experimental#717

That's could work, but not good enough, a better solution is to define a dedicated CRD for it, fortunately there is no CRD in cel for now.

A draft idea is:

apiVersion: custom.tekton.dev/v1alpha1
kind: CEL
metadata:
  name: example
spec:
  vars:
  - name: job_priority
    value: high
  - name: alert_enable
    value: "true"

We have vars to store variables which will be leveraged by evaluation.

There should be two scenario:

• Run.spec.ref with name

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-with-context-
spec:
  ref:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: CEL
    name: example
  params:
    - name: job_severity
      value: "job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'"
    - name: types
      value: "type(job_severity)"
    - name: alert_enable
      value: "false" 

Then the variables defined in CR: example will be leveraged by evaluation, and after calculated the new expression and its result will be add to example.

• Run.spec.ref with no name

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-without-context-
spec:
  ref:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: CEL
  params:
    - name: red
      value: "{'blue': '0x000080', 'red': '0xFF0000'}['red']"
    - name: blue
      value: "{'blue': '0x000080', 'red': '0xFF0000'}['blue']"
    - name: is-red
      value: "{'blue': '0x000080', 'red': '0xFF0000'}['red'] == '0xFF0000'"
    - name: is-blue
      value: "{'blue': '0x000080', 'red': '0xFF0000'}['blue'] == '0xFF0000'"

The behavior will keep same with current implements.

Need your feedback:
/cc @jerop @afrittoli

Use case

We should decide and document a process for adding bot accounts to the org.

This issue is to discuss if the Katacoda's in the tektoncd website should be a part of the tekton org.

Background

The way you create a Katacoda courses is by creating a repo with each course being in a seperate folder. Katacoda will give you a webhook that you must add in order for the courses to sync.
How to create Katacoda Course

The link for the Katacoda on the website is owned by @ncskier. https://katacoda.com/ncskier/scenarios/tekton-dashboard

Minikube allows us to create more Katacoda coursers; however, is there is not a process to contribute to these courses. I think have these coursers under the Tekton org would be a good idea.

Feature request

Add a CI job to validate org.yaml

Use case

Today we don't validate, so we can merge a PR that will fail the update.

We should have a table with information on labels and annotations. This should include:

• The label key itself
• Whether it is reserved for system usage
• What it is used by

We can also document prefixes "foo.bar.tekton.dev" and what they are used for, and if they are reserved.

Proposal for creating tektoncd/experimental/generators.

This project was proposed with verbal support at the Tekton API WG on May 11th 2020.

The problem the project will solve

Help users bootstrap pipelines in a configurable way. This is intended to be an experimental project to explore a DSL / configuration option in parallel to other efforts like D2iQ's DSL, that stays closer to the original Tekton Pipeline/Task spec.

Pipeline Issue: tektoncd/pipeline#2590

Who will own it

• @wlynch
• @dibyom
• @YolandaDu1997

/cc @bobcatfish @imjasonh

I propose work on a Tekton Dashboard similar in spirit to the Kubernetes Dashboard. In other words ... a general-purpose web UI for Tekton CD. Similar to the Kubernetes dashboard this would be an optional component that follows all changes in the Tekton CD project. Under the covers it will look similar to the Kubernetes Dashboard with a static web UI and Go back-end.

Our initial goal for the dashboard is to provide a basic UI to show execution results for Pipeline and Task runs as well as providing a view on to other involved Tekton resources in the cluster. The dashboard should be lightweight, up-to-date, and follow the Tekton CD pipeline project in terms of how's it built, managed, and released.

We'd like to do a demo to the WG but then begin work in a tektoncd/dashboard or tektoncd/tekton-dashboard repository.

Proposal for creating tektoncd/experimental/pipelines-in-pipelines to incubate Pipelines in Pipelines project

Per process, this project was proposed with verbal support at the Tekton API WG on Feb 1st 2021

The problem the project will solve

The project would enable users to specify in Pipelines how to create and run PipelineRuns, similarly to TaskRuns, as further described in this issue.

One use case is providing a set of Tasks as a complete unit of execution, as demonstrated by an example @madbence shared in tektoncd/pipeline#2134 (comment):

"This feature would be really useful for us. eg. right now we have a task that can set the status on a given commit, and a task that can execute unit tests (eg. run npm test, etc.). We'd like to distribute a task/pipeline that can combine these (eg. set the commit to pending, run unit tests, set commit status to success/failure)".

"We'd like to provide to option to use set-status and run-unit-tests in a pipeline, and to be able to use a "higher-level" task, like run-unit-tests-with-commit-status".

Other use cases are discussed in doc and will be explored further in a TEP.

Prototype: https://github.com/jerop/experimental/tree/piprun/pipelines-in-pipelines
Issue: tektoncd/pipeline#2134

Who will own it

• @jerop
• @bobcatfish
• @imjasonh
• @afrittoli

/cc @abayer @vdemeester @bobcatfish @afrittoli @imjasonh (Governing Board)

It would be nice to have a TABLE of TEPS in our docs, with at least the following details:

We should provide a script to be executed when working on TEPs. The script should:

• update the table if needed
• create a new TEP from the template with an available number
• check that TEPs have the required header info

The same script should be used in a CI job to check if the table is up to date and the proposed changes are ok.

/kind feature

Installation and upgrade of Tekton Pipeline including dashboard installation or tasks in catalog repo is currently a manual process. Kubernetes Operator provides us with a framework to simplify this tedious job. Operator also provides us with a great way to move between version when there are breaking changes (alpha1 -> beta1).

Operator was introduced in this blog post and is documented at OperatorHub.io.

The goal of an Operator is to put operational knowledge into software. Previously this knowledge only resided in the minds of administrators, various combinations of shell scripts or automation software like Ansible. It was outside of your Kubernetes cluster and hard to integrate. With Operators, we changed that.

With the Operator Lifecycle Manager and OperatorHub.io it makes it easier for admins to manage their cluster.

Operators got a lot of traction at Red Hat after OpenShift 4 was redesigned around it. Soon after, we started working on Operators to simplify installation of Knative and Tekton. see:

• https://github.com/openshift/tektoncd-pipeline-operator/
• https://github.com/openshift-knative/

Starting with the Knative Serving project, Knative has adopted the operators upstream.

Knative Serving Operator is a project aiming to deploy and manage Knative Serving in an automated way.

• https://github.com/knative/serving-operator

The Tekton Operator recently recieved external contributions around installation of Dashboard as an addon which lead us to believe that adoption of the may be useful for the community and hence the proposal for Tekton to adopt Operator.

As a starting point, we could use tektoncd-pipeline-operator and move it under the tektoncd organization.

/cc @sthaha @nikhil-thomas @chmouel

This would bring the code in the proposal and product requirements for Tekton Listener proposal and eventbinding into its own experimental directory.

TektonListener code -> tektoncd/pipeline#783
Event binding expansion branch -> tektoncd/pipeline@master...iancoffey:event-binding

This code could live here while it is being matured.

I am split between whether a single directory for the listener and event binding concept is fine, or if splitting them into two experiment directories is better. I think one is fine to start with.

This issue is to track the proposal to create a repository called friends under tektoncd. The full proposal can be viewed here:
https://docs.google.com/document/d/1y57N9hFEe4N9Zx7jBLaBbMjrppK-hCDwwBlx2bVz7aE/edit

(available to anyone in the tekton-dev group)

Hi!

It will be great to create and share usable Grafana dashboard for Pipeline Controller metrics on Grafana community. Is it possible?

Tekton components have independent releases.
Document how releases work in Tekton, explain why, help users navigate through releases.
Write docs so that it may be exposed via our website.

Eventually it would be good to have a compatibility matrix generated out of test results :)

Make it clear for whom TektonCD is intended, in order to guide future design discussion and decisions. There was a document in K8s and now in Helm useful as a template
https://github.com/helm/community/blob/master/user-profiles.md

Lets add user-profiles.md to Tekton in the community repo. Optionally have Tekton's user-profiles.md reference its inspiration in Helm

Proposal for creating tektoncd/experimental/cel to incubate Common Expression Language Custom Tasks project

Per process, this project was proposed with verbal support at the Tekton WG on Jan 13th 2021

The problem the project will solve

CEL Custom Tasks will allow us to experiment with CEL in Tekton Pipelines without adding CEL directly to the Tekton API surface

CEL Custom Tasks would be useful in evaluating more complex expressions for guarding execution of Tasks beyond what we support in WhenExpressions, read more

Related issues:

• tektoncd/pipeline#3149
• tektoncd/pipeline#2812
• tektoncd/pipeline#2219
• tektoncd/pipeline#2127
• tektoncd/pipeline#1393

Who will own it

• @jerop
• @bobcatfish
• @pritidesai
• @imjasonh
• @bigkevmcd

Updates

• Project: https://github.com/tektoncd/experimental/tree/master/cel
• TEP: #314

/cc Governing Board: @abayer @vdemeester @bobcatfish @afrittoli @imjasonh

At the moment, all of the working groups are recording via youtube and end up in my personal inbox (because i own the calendar maybe? I dont even know). This means:

• I am the only one who has access to them until I upload them to the shared drive
• If i go on vacation or get behind, no one can see the videos!
• Also only Google employees can start recording the calls

So we should:

• Find a way to record videos that can be initiated by non-Google folks too (maybe zoom? might need budget help here from the CDF)
• Add automation (maybe with Tekton??) to automatically publish the videos and make them available:
  • Definitely in the shared drive
  • Maybe also in a slack notificaiton
  • Maybe somehow added to the meeting notes too

Feature request

Please update https://github.com/tektoncd/community/blob/master/org/org.yaml with the results maintainer team and collaborators.

/cc @wlynch

Proposal for creating tektoncd/experimental/pipeline-loops to incubate Pipeline level loops project

Per process, this project was has been presented at working group on March 17th 2021

The problem the project will solve

Loops Requirements from KFP-Tekton and some projects at IBM:

• Loop run sequency tasks based on the array value of user defined or the output from other tasks
• Support multi loop parameters
• Run pipeline loop with condition together. The loop will be keep creating util the condition in the loop is satisfied.
• Support user to define the loop parameters as: ‘From’, ‘to’ and ‘step’.
• Achieve pipeline level loops by one controller. 

Common loop cases would be supported in one pipeline-loops controller:

Who will own it

• @afrittoli
• @fenglixa
• @vincent-pli

/cc @abayer @vdemeester @bobcatfish @afrittoli @imjasonh
Could you please approve it? Thanks!

Expected Behavior

Link to script works

Actual Behavior

Links to https://github.com/tektoncd/plumbing/blob/main/addpermissions.py which 404s.

Current behaviour

Management of org membership, the teams we are using in tektoncd and who is on them, is super ad-hoc and based mostly around folks privately messaging ppl with enough power (e.g. me , @vdemeester , @dlorenc @abayer @kimsterv ) to get access to stuff. Most changes are not recorded anywhere, so none of us probably even really know what kind of changes the other folks are making XD

Desired behaviour

Decisions like who to add to what, or what teams to create:

• Should be clearly recorded (ideally in github itself!)
• Should have an obvious path forward (e.g. how does a random new contributor know what to do to get added to the org?)

Additional info

The folks working on Kubernetes ( + @fejta ) have created a tool called periobolos (https://github.com/kubernetes/test-infra/tree/master/prow/cmd/peribolos) which looks like it might do everything we need!