tektoncd / community Goto Github PK
View Code? Open in Web Editor NEWCommunity documentation for the Tekton project
Home Page: https://tekton.dev
License: Apache License 2.0
Community documentation for the Tekton project
Home Page: https://tekton.dev
License: Apache License 2.0
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.
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
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:
/cc Governing Board: @abayer @vdemeester @bobcatfish @afrittoli @imjasonh
Hi there, hope this issue is appropriate.
I would like my contribution to Tekton to be listed in the following Tekton rankings:
I added my affiliation to github_users.json.
Description
of the website ranking.I confirmed that my affiliation has been imported to github_users.json.
My affiliation will be listed in those rankings once I contributed to Tekton (any repositories such as community, dashboard, pipeline, etc.), right?
Thank you for your kind help.
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
Loops Requirements from KFP-Tekton and some projects at IBM:
Common loop cases would be supported in one pipeline-loops controller:
/cc @abayer @vdemeester @bobcatfish @afrittoli @imjasonh
Could you please approve it? Thanks!
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.
Thank you.
/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!
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:
So we should:
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
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 :)
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.
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
Proposal for creating tektoncd/experimental/generators.
This project was proposed with verbal support at the Tekton API WG on May 11th 2020.
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
/cc @bobcatfish @imjasonh
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
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
Decisions like who to add to what, or what teams to create:
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!
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.
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.
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.
The link in the contact.md to join the Slack of Tekton CD is not valid anymore
Please update https://github.com/tektoncd/community/blob/master/org/org.yaml with the results maintainer team and collaborators.
/cc @wlynch
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
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:
We should decide and document a process for adding bot accounts to the org.
Google Calendar Broken Links:
Triggers
CLI
Documentation
Productivity
https://github.com/tektoncd/community/blob/master/working-groups.md#documentation
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)
Based on the Tekton catalog integration proposal,
This folder/repository would host Catalog resource part of the proposal.
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).
@vdemeester and @sthaha would be the initial ones.
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.
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 )
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]
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?
Where's the code?
It would be nice to have a TABLE of TEPS in our docs, with at least the following details:
number | title | state | owners |
---|
We should provide a script to be executed when working on TEPs. The script should:
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
Hi!
It will be great to create and share usable Grafana dashboard for Pipeline Controller metrics on Grafana community. Is it possible?
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
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.
This issue is to discuss if the Katacoda's in the tektoncd website should be a part of the tekton org.
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.
We should have a table with information on labels and annotations. This should include:
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/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 project would enable users to specify in Pipelines
how to create and run PipelineRuns
, similarly to TaskRun
s, 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
/cc @abayer @vdemeester @bobcatfish @afrittoli @imjasonh (Governing Board)
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:
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.
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.
The KEP process includes a very thorough production readiness checklist (thanks @mattmoor !):
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!
What animal are the Tekton Friends?
Link to script works
Links to https://github.com/tektoncd/plumbing/blob/main/addpermissions.py which 404s.
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...
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
Add a CI job to validate org.yaml
Today we don't validate, so we can merge a PR that will fail the update.
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
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.
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 param
s:
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
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:
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.
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.
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.
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
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.