Generate OpenAPI specification and Swagger file

[jinchihe]

Changes

The PR is going to generate OpenAPI specification, and generate Swagger file according to the OpenAPI specification.

Submitter Checklist

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

• Includes tests (if functionality changed/added):

• Includes docs (if user facing)

• Commit messages follow commit message best practices

• Release notes block has been filled in or deleted (only if no user facing changes)

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

None

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Jin Chi He (ffbdcfd)

[tekton-robot]

Hi @jinchihe. Thanks for your PR.

I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jinchihe]

/cc @vdemeester

[vdemeester]

@jinchihe thanks for the PR 👼

Firstly, I'm not sure that's good place to put the SDK here, personally it's better to have a separate repo to maintain SDK, such as python and java (if needed) etc... I'm waiting for comments from maintainers for this.

I tend to agree, we could have the SDK in a separate repository (a bit like k8s.io/client-go).

Overall, I think it look good, but I feel we should split the PR into several :

1. adding openapi gen (go code and schemas) in one PR
2. swagger in another
3. the sdk generation in a third and/or in a separate repository 😉

/cc @afrittoli @bobcatfish @sbwsg

[bobcatfish]

Would it make sense to have keep the python client lib generation as a separate project, maybe in experimental or a separate repo? @tektoncd/core-maintainers

[imjasonh]

Would it make sense to have keep the python client lib generation as a separate project, maybe in experimental or a separate repo? @tektoncd/core-maintainers

I would prefer that. Either as a directory in tektoncd/experimental, or just as a separately-owned repo outside the Tekton org, based on Tekton-owned generated Swagger.

Basically, I definitely think Tekton should own Swagger doc generation, but I don't want to own generated Python (or any non-Go) client libraries since I don't think we can rely on sufficient Python expertise in case there are issues.

[jinchihe]

I tend to agree, we could have the SDK in a separate repository (a bit like k8s.io/client-go).

Overall, I think it look good, but I feel we should split the PR into several :

1. adding openapi gen (go code and schemas) in one PR
2. swagger in another
3. the sdk generation in a third and/or in a separate repository 😉

@vdemeester Thank you for the comments. Make sense, we may can commit the openapi and swagger in tektoncd/pipeline repo, and commit sdk after the separate repository (may be named tektoncd/sdk) created.

[jinchihe]

I would prefer that. Either as a directory in tektoncd/experimental, or just as a separately-owned repo outside the Tekton org, based on Tekton-owned generated Swagger.

Basically, I definitely think Tekton should own Swagger doc generation, but I don't want to own generated Python (or any non-Go) client libraries since I don't think we can rely on sufficient Python expertise in case there are issues.

@imjasonh why put outside the Tekton org? personally I suggest to maintain that inside of Tekton org, you know, that has close relationship with tekton/pipeline and very import for tekton end user. If you‘re worry about sufficient Python expertise, this is open source, I think if have problems, more and more Python expertise will take part in :-)

[imjasonh]

@imjasonh why put outside the Tekton org? personally I suggest to maintain that inside of Tekton org, you know, that has close relationship with tekton/pipeline and very import for tekton end user. If you‘re worry about sufficient Python expertise, this is open source, I think if have problems, more and more Python expertise will take part in :-)

Perhaps I should rephrase. 😄 I'd like to start with the generated Python client (and other generated clients) in a non-Tekton repo, or in tektoncd/experimental where user expectations around ownership and support are more relaxed. If there's sufficient interest and usage of the clients in the future, and if an interested owner steps up, we could promote it to a separate tektoncd/* repo, or possibly eventually into tektoncd/pipeline -- but I don't think we should start there.

Having generated clients means having a release process for them, publishing them to PyPi, etc., and I just don't think there's enough dedicated expertise or interest among Tekton owners and partners at this time to justify adding that burden. If the clients are a hit and are widely used, then presumably some dependent user would be willing to step and own generating and releasing new clients, and debugging the inevitable user issues. The best way to gauge use and interest is to start by publishing them -- anywhere -- and seeing how they get adopted.

[jinchihe]

@imjasonh @vdemeester OK thanks. I will separate the PR to keep the openapi and swagger parts in this repo, and commit the generated python SDK in tektoncd/experimental.

[jinchihe]

@imjasonh @vdemeester As above discussion, I keep the OpenAPI and swagger parts in the tektoncd/pipeline repo, and move the generated SDK to tektoncd/experimental.

if so, the PR is ready for reviewing and testing. I will update summary and description. Thanks.

[vdemeester]

/ok-to-test
/kind feature

[ghost]

/hold

[ghost]

Hey sorry @jinchihe could you update the commit message to:

1. Remove mention of Python SDK
2. Describe the actual changes you've made with a couple paragraphs?

After that I think this is ready to go!

[ghost]

/approve cancel

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1beta1/openapi_generated.go	Do not exist	0.0%

[jinchihe]

@sbwsg so sorry... I missed your comments, update later. I already updated that and removed SDK related message.

And I noticed there are some changes in types, so I also re-generated the OpenAPI specification and Swagger file. Thanks a lot!

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1beta1/openapi_generated.go	Do not exist	0.0%

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1beta1/openapi_generated.go	Do not exist	0.0%

[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

[ghost]

/hold cancel

[vincent-pli]

/lgtm