Use PipelineWorkspaceDeclaration instead of WorkspacePipelineDeclaration 👷‍♀️

[bobcatfish]

Changes

This is a super minor change to rename WorkspacePipelineDeclaration to
PipelineWorkspaceDeclaration. WorkspacePipelineDeclaration sounds like
it's a pipeline declaration inside of a workspace, but actually its
meant to be a workspace declaration inside of a pipeline!

I'm trying to pickup some of the work started in #1936
and this seemed like a reasonable improvement to carve off and merge on
its own :D

co-authored with @sbwsg

/kind cleanup

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• [n/a] Includes tests (if functionality changed/added)
• [n/a] Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide for more details.

Double check this list of stuff that's easy to miss:

• If you are adding a new binary/image to the cmd dir, please update
  the release Task to build and release this image.

Reviewer Notes

If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

Release Notes

The field WorkspacePipelineDeclaration in the API go library is now called PipelineWorkspaceDeclaration

[tekton-robot]

This PR cannot be merged: expecting exactly one kind/ label

Available kind/ labels are:

kind/bug: Categorizes issue or PR as related to a bug.
kind/flake: Categorizes issue or PR as related to a flakey test
kind/cleanup: Categorizes issue or PR as related to cleaning up code, process, or technical debt.
kind/design: Categorizes issue or PR as related to design.
kind/documentation: Categorizes issue or PR as related to documentation.
kind/feature: Categorizes issue or PR as related to a new feature.
kind/misc: Categorizes issue or PR as a miscellaneuous one.

[ghost]

Possibly silly question but: Does renaming things count as API changes to someone writing code against a Pipeline client?

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbwsg

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:

• OWNERS [sbwsg]

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

[jlpettersson]

Possibly silly question but: Does renaming things count as API changes to someone writing code against a Pipeline client?

I was thinking about this too. This is just a change of the Go-client API, but no changes in the Yaml API or REST API - so I would not count it as an "api change" ?

[pritidesai]

Possibly silly question but: Does renaming things count as API changes to someone writing code against a Pipeline client?

I was thinking about this too. This is just a change of the Go-client API, but no changes in the Yaml API or REST API - so I would not count it as an "api change" ?

Ditto, would not count as an API Change 👍 but CLI repo has a reference here:

https://github.com/tektoncd/cli/blob/85e53f79d71f9373b22a9ed62c0dd06b4e9f54f7/pkg/cmd/pipeline/start_test.go#L3152

How does this change impact CLI? /lgtm if its not breaking CLI 😲

[vdemeester]

I was thinking about this too. This is just a change of the Go-client API, but no changes in the Yaml API or REST API - so I would not count it as an "api change" ?

I doesn't count as an API change, and we can "smooth" things when doing those changes too by using type alias and a // Deprecated: use … comment 😉

// WorkspacePipelineDeclaration creates a named slot in a Pipeline that a PipelineRun […]
// Deprecated: use PipelineWorkspaceDeclaration type instead
type WorkspacePipelineDeclaration = PipelineWorkspaceDeclaration

That would ensure that we do not break external user and give them time to switch to the new type before removing it 👼 😉

[bobcatfish]

Added the alias like you suggested @vdemeester , PTAL!

I also opened #2748 to create more clarity around our policy for client lib changes.

[pritidesai]

thanks @bobcatfish
/lgtm