-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we support installing Pipeline without the resolvers? #5607
Comments
To add to this, in the TEP goals, there is : "Allow operators to completely remove the code paths that fetch Tekton resources from remotes they don't want to support.". |
It's moments like this that I miss Helm. =) |
could this be addressed in tektoncd/operator which is used to configure installation? |
@jerop it could be addressed by the operator for sure yes. I think I am ok if we include the resolvers in the release.yaml and not provide another yaml without them. Users and tools who do not want to use them can mutate the release.yaml to skip those. |
Just so it's clear, this means I am fine to close this issue and ship a release.yaml that includes resolvers and nothing else. 😝 |
Closes tektoncd#5607 After discussion, we've decided to get rid of the separate `resolvers.yaml` and the resolver-less `minimal-release.yaml`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
Closes #5607 After discussion, we've decided to get rid of the separate `resolvers.yaml` and the resolver-less `minimal-release.yaml`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
Closes tektoncd#5607 After discussion, we've decided to get rid of the separate `resolvers.yaml` and the resolver-less `minimal-release.yaml`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
Add start and end time, as well as details about the owner resource to to the resource requests. Example: NAME OWNERKIND OWNER SUCCEEDED REASON STARTTIME ENDTIME git-40e5840171b418bcbd0bfa73defec338 TaskRun git-resolver-p75s8 True 2022-10-05T09:16:08Z 2022-10-05T09:16:10Z git-6ecf81c8e0b418bcbd0c05c1bc3cd0c5 TaskRun git-resolver-tmvqd True 2022-10-05T09:11:20Z 2022-10-05T09:11:22Z git-e97b40047eb418bcbd0be5341ed71802 TaskRun git-resolver-xdq55 False ResolutionFailed 2022-10-05T09:19:51Z 2022-10-05T09:19:52Z Signed-off-by: Andrea Frittoli <andrea.frittoli@uk.ibm.com> Bump google.golang.org/grpc from 1.50.0 to 1.50.1 Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.50.0 to 1.50.1. - [Release notes](https://github.com/grpc/grpc-go/releases) - [Commits](grpc/grpc-go@v1.50.0...v1.50.1) --- updated-dependencies: - dependency-name: google.golang.org/grpc dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Migrate PipelineRun Reconciler__TestReconcileTaskResolutionError Signed-off-by: xin.li <xin.li@daocloud.io> Remove minimal-release.yaml and resolvers.yaml Closes tektoncd#5607 After discussion, we've decided to get rid of the separate `resolvers.yaml` and the resolver-less `minimal-release.yaml`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com> Bump k8s.io/apimachinery from 0.25.2 to 0.25.3 Bumps [k8s.io/apimachinery](https://github.com/kubernetes/apimachinery) from 0.25.2 to 0.25.3. - [Release notes](https://github.com/kubernetes/apimachinery/releases) - [Commits](kubernetes/apimachinery@v0.25.2...v0.25.3) --- updated-dependencies: - dependency-name: k8s.io/apimachinery dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Bump k8s.io/api from 0.25.2 to 0.25.3 Bumps [k8s.io/api](https://github.com/kubernetes/api) from 0.25.2 to 0.25.3. - [Release notes](https://github.com/kubernetes/api/releases) - [Commits](kubernetes/api@v0.25.2...v0.25.3) --- updated-dependencies: - dependency-name: k8s.io/api dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Bump k8s.io/client-go from 0.25.2 to 0.25.3 Bumps [k8s.io/client-go](https://github.com/kubernetes/client-go) from 0.25.2 to 0.25.3. - [Release notes](https://github.com/kubernetes/client-go/releases) - [Changelog](https://github.com/kubernetes/client-go/blob/master/CHANGELOG.md) - [Commits](kubernetes/client-go@v0.25.2...v0.25.3) --- updated-dependencies: - dependency-name: k8s.io/client-go dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> resolution/framework : inject the request name in the context Similar to the namespace, it might be of interest for the resolver to get access to its name, as well as the namespace. Today this is only the case for the namespace. On possible use case for this is, if the resolver wants to create another kubernetes object and set owner reference on it. Signed-off-by: Vincent Demeester <vdemeest@redhat.com> CSI workspace to Beta This commit removes the alpha feature gate for the csi workspace so that it becomes a beta feature. Remove PipelineRun cancelation of Runs when Pipeline Task timeout is reached TestWaitCustomTask_PipelineRun/Wait_Task_Retries_on_Timeout has been flaky for a while. This commit stops the PipelineRun reconciler from cancelling Run when it detects that the task-level Timeout configured for the Run has passed, which will address the flake (similar to tektoncd#5134 which addresses TestPipelineRunTimeout). Bump github.com/containerd/containerd from 1.6.8 to 1.6.9 Bumps [github.com/containerd/containerd](https://github.com/containerd/containerd) from 1.6.8 to 1.6.9. - [Release notes](https://github.com/containerd/containerd/releases) - [Changelog](https://github.com/containerd/containerd/blob/main/RELEASES.md) - [Commits](containerd/containerd@v1.6.8...v1.6.9) --- updated-dependencies: - dependency-name: github.com/containerd/containerd dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Bump github.com/google/go-containerregistry from 0.11.0 to 0.12.0 Bumps [github.com/google/go-containerregistry](https://github.com/google/go-containerregistry) from 0.11.0 to 0.12.0. - [Release notes](https://github.com/google/go-containerregistry/releases) - [Changelog](https://github.com/google/go-containerregistry/blob/main/.goreleaser.yml) - [Commits](google/go-containerregistry@v0.11.0...v0.12.0) --- updated-dependencies: - dependency-name: github.com/google/go-containerregistry dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Bump github.com/stretchr/testify from 1.8.0 to 1.8.1 Bumps [github.com/stretchr/testify](https://github.com/stretchr/testify) from 1.8.0 to 1.8.1. - [Release notes](https://github.com/stretchr/testify/releases) - [Commits](stretchr/testify@v1.8.0...v1.8.1) --- updated-dependencies: - dependency-name: github.com/stretchr/testify dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Bump github.com/sigstore/sigstore from 1.4.4 to 1.4.5 Bumps [github.com/sigstore/sigstore](https://github.com/sigstore/sigstore) from 1.4.4 to 1.4.5. - [Release notes](https://github.com/sigstore/sigstore/releases) - [Commits](sigstore/sigstore@v1.4.4...v1.4.5) --- updated-dependencies: - dependency-name: github.com/sigstore/sigstore dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> fix tekton documentation contributor`s guide link Add Beta feature gate for projected workspace This commit adds the Beta feature gate for projected workspace in v1. [TEP-0115] Support Artifact Hub in Hub Resolver Part of [issues/667]. This commit adds support to resolve catalog resource from the [Artifact Hub] while keeping current functionality of fetching resources from Tekton Hub. - Change 1: The 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"`, and fetches resources from user's private instance of Tekton Hub when setting `type` to `"tekton"`. - Change 2: Prior 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. - Change 3: Prior 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. /kind feature [Artifact Hub]: https://artifacthub.io/ [issues/667]: tektoncd/hub#667 [TEP-0089] Modify entrypoint to sign the results. Breaking down PR tektoncd#4759 originally proposed by @pxp928 to address TEP-0089 according @lumjjb suggestions. Plan for breaking down PR is PR 1.1: api PR 1.2: entrypointer (+cmd line + test/entrypointer) Entrypoint takes results and signs the results (termination message). PR 1.3: reconciler + pod + cmd/controller + integration tests Controller will verify the signed result. This commit corresponds to 1.2 above. Bump HorizontalPodAutoscaler apiVersion to v2 Before this, we get a warning when applying the HPA: Warning: autoscaling/v2beta1 HorizontalPodAutoscaler is deprecated in v1.22+, unavailable in v1.25+; use autoscaling/v2 HorizontalPodAutoscaler This also bumps the min version to 1.23. Signed-off-by: Vincent Demeester <vdemeest@redhat.com> [TEP-0089] Enable SPIRE for signing taskrun results in alpha. Breaking down PR tektoncd#4759 originally proposed by @pxp928 to address TEP-0089 according @lumjjb suggestions. Plan for breaking down PR is PR 1.1: api PR 1.2: entrypointer (+cmd line + test/entrypointer) Entrypoint takes results and signs the results (termination message). PR 1.3: reconciler + pod + cmd/controller + integration tests Controller will verify the signed result. This commit corresponds to 1.3 above.
Hey folks, this change has broken the ability to deploy Tekton Pipelines for both Flux and ArgoCD. |
@danmanners do you have an example of how one deploys Tekton Pipelines witsh Fluy or ArgoCD (aka the Application or other CRD used and the possible layout of a repo or something). |
@vdemeester hey, my apologies for the delay. I WAS able to get it working with ArgoCD, but I don't have Flux up and going in my cluster and from conversations with other folks using Flux it seems very broken using Flux. My ArgoCD application can be found here; note that I was able to successfully deploy this by entirely removing the namespace field. You can compare that manifest to this ArgoCD application for Tekton Triggers. Once I can find an example of the flux deployment failing, I'll link it here. EDIT: I see you already saw it here (#5931) |
I am also running into this issue when using Flux (kustomize) with the newly combined release file. Can we get the files separated again or instead move all the resolver resources into the tekton-pipelines namespace (i am not a big fan of having X namespaces for each tool). |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
/lifecycle frozen |
Please revisit this ... It should not be too difficult to split them. This is still BREAKING when using Kustomize. |
See discussions on #5515 - as part of that PR, we're moving from v0.40's separate
release.yaml
, containing everything but the resolvers, andresolvers.yaml
, just containing the contents ofconfig/resolvers
, to a unifiedrelease.yaml
containing everything. @vdemeester requested that we retain the ability to install Pipeline without the resolvers, so we keep the separateresolvers.yaml
as well, and add a newminimal-release.yaml
, corresponding to v0.40'srelease.yaml
(i.e., no resolvers).This issue is to discuss whether we actually should have
minimal-release.yaml
+resolvers.yaml
in addition to the fullrelease.yaml
, or if we should just have the fullrelease.yaml
.(I've put this in the v0.41 milestone, because I do think we need a definitive resolution before we cut v0.41, so that we don't end up having
minimal-release.yaml
for just one release etc)cc @tektoncd/core-maintainers
/kind misc
The text was updated successfully, but these errors were encountered: