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

Add upgrade test against previous server version to prevent regressions #6896

Merged
merged 1 commit into from
Jul 17, 2023

Conversation

JeromeJu
Copy link
Member

@JeromeJu JeromeJu commented Jul 4, 2023

Changes

This commit adds an upgrade test cases to test against previous server
version by adding a light-weight test checking the existing functionalities of
simple resources so as to prevent regressions introduced in the current
release. It creates a pipelineRun with a basic TaskRun and a basic
Pipeline with a Simple PipelineTask and examines the runs created are successful.

This helps prevent the regression where the client has introduced regressions towards the last release i.e. Regression: PipelineTaskRunSpec.Metadata incompatible with older webhooks

fixes: #5782

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

  • [n/a] Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
  • Has Tests included if any functionality added or changed
  • Follows the commit message standard
  • Meets the Tekton contributor standards (including functionality, content, code)
  • Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
  • [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.
  • [n/a] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

NONE

@tekton-robot tekton-robot added the release-note-none Denotes a PR that doesnt merit a release note. label Jul 4, 2023
@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jul 4, 2023
@JeromeJu
Copy link
Member Author

JeromeJu commented Jul 4, 2023

/kind misc

@tekton-robot tekton-robot added the kind/misc Categorizes issue or PR as a miscellaneuous one. label Jul 4, 2023
Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick note, slightly related to this but not entirely: the e2e-tests-upgrade.sh runs based of latest releases (so 0.49 today for example) but not from latest LTS upgrade, which I think, would be interesting/important as well 👼🏼

@@ -0,0 +1,180 @@
//go:build e2e
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As is it will be executed on all go_test_e2e run which.. might or might not be something we want ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I think it might actually be nice to have it with the e2e tests. Since upgrade tests aren't run as part of CI, having this test in e2e tests would ensure breaking changes to these tests aren't checked in. It might be a better solution just to run upgrade tests in CI though.

Copy link
Member

@lbernick lbernick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JeromeJu can you please add more info to your commit message/PR description about the types of regressions these changes are intended to catch?

@@ -0,0 +1,180 @@
//go:build e2e
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I think it might actually be nice to have it with the e2e tests. Since upgrade tests aren't run as part of CI, having this test in e2e tests would ensure breaking changes to these tests aren't checked in. It might be a better solution just to run upgrade tests in CI though.

test/upgrade_test.go Outdated Show resolved Hide resolved
test/upgrade_test.go Outdated Show resolved Hide resolved
test/upgrade_test.go Outdated Show resolved Hide resolved
test/upgrade_test.go Outdated Show resolved Hide resolved
test/e2e-tests-upgrade.sh Outdated Show resolved Hide resolved
@JeromeJu JeromeJu force-pushed the upgrade-regression branch 3 times, most recently from 384459a to 8d32c04 Compare July 7, 2023 13:54
test/upgrade_test.go Outdated Show resolved Hide resolved
test/upgrade_test.go Outdated Show resolved Hide resolved
test/upgrade_test.go Outdated Show resolved Hide resolved
test/upgrade_test.go Outdated Show resolved Hide resolved
test/upgrade_test.go Outdated Show resolved Hide resolved
}

expectedTaskRun := getExpectedTaskRunUpgrade(t, taskRunName, namespace, pipelineRunName, task1Name)
if d := cmp.Diff(expectedTaskRun, r, append([]cmp.Option{filterV1TaskRunSA, filterV1StepState, filterOwnerReference, filterV1TaskRunStatus, filterV1SidecarState, filterVolumeMountsName, filterTaskRunStatusProvenance}, filterV1TaskRunFields...)...); d != "" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does filterV1TaskRunStatus ignore? same with filterV1PipelineRunStatus. it sounds like it ignores the whole status; is it actually specific fields?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are the filters in test dir for ignoring StartTime and CompletionTime at

filterV1beta1PipelineRunStatus = cmpopts.IgnoreFields(v1beta1.PipelineRunStatusFields{}, "StartTime", "CompletionTime")
.

I changed it to filterTaskRunStatusFields into this file.

test/upgrade_test.go Outdated Show resolved Hide resolved
test/e2e-tests-upgrade.sh Outdated Show resolved Hide resolved
test/upgrade_test.go Outdated Show resolved Hide resolved
test/e2e-tests-upgrade.sh Outdated Show resolved Hide resolved
This commit adds an upgrade test cases to test against previous server
version by adding a light-weight test checking the existing functionalities of
simple resources so as to prevent regressions introduced in the current
release. It creates a pipelineRun with a basic TaskRun and a basic
Pipeline with a Simple PipelineTask and examines the runs created are successful.

This helps prevent the regression where the client has introduced regressions towards the last release i.e. [Regression: PipelineTaskRunSpec.Metadata incompatible with older webhooks](tektoncd#4913)
}

expectedPipelineRun := parse.MustParseV1PipelineRun(t, fmt.Sprintf(expectedSimplePipelineRunYaml, pipelineRunName, namespace, pipelineName, taskRunName))
if d := cmp.Diff(expectedPipelineRun, pr, append([]cmp.Option{filterV1PipelineRunStatus, filterV1PipelineRunSA, filterPipelineRunStatusFields}, filterV1PipelineRunFields...)...); d != "" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if d := cmp.Diff(expectedPipelineRun, pr, append([]cmp.Option{filterV1PipelineRunStatus, filterV1PipelineRunSA, filterPipelineRunStatusFields}, filterV1PipelineRunFields...)...); d != "" {
if d := cmp.Diff(expectedPipelineRun, pr, filterV1PipelineRunStatus, filterV1PipelineRunSA, filterPipelineRunStatusFields, filterV1PipelineRunFields...); d != "" {

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if this could work according to https://pkg.go.dev/github.com/google/go-cmp/cmp#Diff seems we need to take in a slice instead of expanding it 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If filterV1PipelineRunFields is an array, then I think it can't work as suggested @lbernick (because of Go 😅 )

@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lbernick

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 7, 2023
Copy link
Member

@Yongxuanzhang Yongxuanzhang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 17, 2023
@tekton-robot tekton-robot merged commit 3364c72 into tektoncd:main Jul 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/misc Categorizes issue or PR as a miscellaneuous one. lgtm Indicates that a PR is ready to be merged. release-note-none Denotes a PR that doesnt merit a release note. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add client/server compatibility tests
5 participants