Skip to content
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

Open
abayer opened this issue Oct 5, 2022 · 13 comments · Fixed by #5671
Open

Should we support installing Pipeline without the resolvers? #5607

abayer opened this issue Oct 5, 2022 · 13 comments · Fixed by #5671
Labels
kind/misc Categorizes issue or PR as a miscellaneuous one. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@abayer
Copy link
Contributor

abayer commented Oct 5, 2022

See discussions on #5515 - as part of that PR, we're moving from v0.40's separate release.yaml, containing everything but the resolvers, and resolvers.yaml, just containing the contents of config/resolvers, to a unified release.yaml containing everything. @vdemeester requested that we retain the ability to install Pipeline without the resolvers, so we keep the separate resolvers.yaml as well, and add a new minimal-release.yaml, corresponding to v0.40's release.yaml (i.e., no resolvers).

This issue is to discuss whether we actually should have minimal-release.yaml+resolvers.yaml in addition to the full release.yaml, or if we should just have the full release.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

@abayer abayer added the kind/misc Categorizes issue or PR as a miscellaneuous one. label Oct 5, 2022
@abayer abayer added this to the Pipelines v0.41 milestone Oct 5, 2022
@vdemeester
Copy link
Member

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.".
So, based on that goal, I think we should support having pipeline without resolvers (and thus installing), and thus I would love if we ease the users UX when they don't want the resolvers.

@abayer
Copy link
Contributor Author

abayer commented Oct 5, 2022

It's moments like this that I miss Helm. =)

@jerop
Copy link
Member

jerop commented Oct 19, 2022

could this be addressed in tektoncd/operator which is used to configure installation?

@vdemeester
Copy link
Member

@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.

@vdemeester
Copy link
Member

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. 😝

abayer added a commit to abayer/tektoncd-pipeline that referenced this issue Oct 21, 2022
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 <[email protected]>
tekton-robot pushed a commit that referenced this issue Oct 21, 2022
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 <[email protected]>
JeromeJu pushed a commit to JeromeJu/pipeline that referenced this issue Oct 24, 2022
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 <[email protected]>
jagathprakash pushed a commit to jagathprakash/pipeline that referenced this issue Nov 2, 2022
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 <[email protected]>

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] <[email protected]>

Migrate PipelineRun Reconciler__TestReconcileTaskResolutionError

Signed-off-by: xin.li <[email protected]>

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 <[email protected]>

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] <[email protected]>

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] <[email protected]>

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] <[email protected]>

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 <[email protected]>

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] <[email protected]>

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] <[email protected]>

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] <[email protected]>

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] <[email protected]>

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 <[email protected]>

[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.
@danmanners
Copy link

Hey folks, this change has broken the ability to deploy Tekton Pipelines for both Flux and ArgoCD.

@vdemeester vdemeester reopened this Feb 20, 2023
@vdemeester
Copy link
Member

@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).

@danmanners
Copy link

danmanners commented Feb 22, 2023

@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)

@jwitrick
Copy link

jwitrick commented Mar 2, 2023

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).

@tekton-robot
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

@tekton-robot tekton-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 31, 2023
@tekton-robot
Copy link
Collaborator

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

@tekton-robot tekton-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jun 30, 2023
@vdemeester
Copy link
Member

/lifecycle frozen

@tekton-robot tekton-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. labels Jul 3, 2023
@jwitrick
Copy link

Please revisit this ... It should not be too difficult to split them. This is still BREAKING when using Kustomize.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/misc Categorizes issue or PR as a miscellaneuous one. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

6 participants