-
Notifications
You must be signed in to change notification settings - Fork 577
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
Update policy to bump Task/Pipeline versions whenever a change is made #784
Comments
/assign |
OCI bundle are not stable yet, so we can assume most of our user do not use them / have access to them. We can't rely on them completely until it's available for everyone. |
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 we need to establish this policy and make it easy to make bumps - @vinamra28 and I are discussing this draft: https://docs.google.com/document/d/1SGOkVrg0_s8ufbSTRl0Y4l_2zD_0QgUElEDZY0p8jSk/edit?usp=sharing |
Today, we don't always bump versions of resources when updating them. The guideline has been to bump versions only when behavior changes, but it's hard to figure out when the behavior has changed (a change that could be trivial to one user could be meaningful to another). Not bumping resource versions when changing them causes issues where the resource definition becomes dependent on the time when it was applied by the user - which causes unexpected failures as described in tektoncd#784. This issue also came up as an issue where users cannot depend on the Step indices because they can change: tektoncd/community#572 (review). In TEP-0003, we already proposed that a policy for versioning of resources: https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md#versioning-resources In Catalog Working Group on 01/13/2022, we revisted that policy and: - agreed to follow the versioning policy - make it easier to bump resources (see tektoncd/plumbing#994) This change documents the versioning policy. Fxes tektoncd#784
Today, we don't always bump versions of resources when updating them. The guideline has been to bump versions only when behavior changes, but it's hard to figure out when the behavior has changed (a change that could be trivial to one user could be meaningful to another). Not bumping resource versions when changing them causes issues where the resource definition becomes dependent on the time when it was applied by the user - which causes unexpected failures as described in tektoncd#784. This issue also came up as an issue where users cannot depend on the Step indices because they can change: tektoncd/community#572 (review). In TEP-0003, we already proposed that a policy for versioning of resources: https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md#versioning-resources In Catalog Working Group on 01/13/2022, we revisted that policy and: - agreed to follow the versioning policy - make it easier to bump resources (see tektoncd/plumbing#994) This change documents the versioning policy in the contributions guide. Fixes tektoncd#784
Today, we don't always bump versions of resources when updating them. The guideline has been to bump versions only when behavior changes, but it's hard to figure out when the behavior has changed (a change that could be trivial to one user could be meaningful to another). Not bumping resource versions when changing them causes issues where the resource definition becomes dependent on the time when it was applied by the user - which causes unexpected failures as described in tektoncd#784. This issue also came up as an issue where users cannot depend on the Step indices because they can change: tektoncd/community#572 (review). In TEP-0003, we already proposed that a policy for versioning of resources: https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md#versioning-resources In Catalog Working Group on 01/13/2022, we revisited that policy and: - agreed to follow the versioning policy - make it easier to bump resources (see tektoncd/plumbing#994) This change documents the versioning policy in the contributions guide. Fixes tektoncd#784
/lifecycle frozen |
initial work addressing this is here: https://github.com/tektoncd/community/blob/main/teps/0110-decouple-catalog-organization-and-reference.md |
Expected Behavior
As a user of Tasks in the catalog, when I use Task (or Pipeline) and I specify a specific version X, I should be confident that the Task (or Pipeline) I use at time Y is the same as the version at time Y+1, etc.
That is: if anything that is user facing in a Task (or Pipeline) changes, the version of should be bumped.
Actual Behavior
We make changes to Tasks without bumping the version, for example:
Anyone grabbing the git-clone 0.1 or 0.4 Task BEFORE these changes would get something different AFTER these changes (and which version will be available in our OCI registry? I'm assuming the latest one, but not sure?)
My understanding of why these changes being made without bumping the version is b/c we view these as additive; however:
Steps to Reproduce the Problem
I want to demonstrate an example of how this can impact a user by describing how this impacted me recently.
I've been working on a custom task that runs a Pipeline as a TaskRun (tektoncd/experimental#770) and I created an example Pipeline which used git-clone 0.3.
git-clone
withtkn hub install task git-clone
(i didnt explicitly specify the version i needed but let's pretend i said0.3
which is what i ended up working with)git-clone
and used it to experimentgit-clone
- I wrote the TaskRun I expected (with the git-clone steps, params, etc. embedded in it) based on thegit-clone
task i had installedgit-clone
0.3 yaml from the catalog repo and add it to atestdata
folderAdditional Info
I'm wondering if one reason we're doing this is we've made it too expensive to bump a version - bumping a version means creating a whole new directory of READMEs, yamls, examples, etc. (not to mention it's hard to tell what's changed b/w versions).
If that's the case, it might be worth revisiting our approach. OR we could try something different, now that we're publishing to an OCI registry, like deleting the old version when we make a change.
The text was updated successfully, but these errors were encountered: