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.

Sign up for GitHub

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

Jump to bottom

support v1 for sign and verify command #2216

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

support v1 for sign and verify command #2216

wants to merge 1 commit into from

Conversation

Yongxuanzhang
Copy link
Member

@Yongxuanzhang Yongxuanzhang commented Jan 17, 2024 •
edited

Changes

This commit adds v1 support for sign and verify.

close #2214

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)
  • Run the code checkers with make check
  • Regenerate the manpages, docs and go formatting with make generated
  • Commit messages follow commit message best practices

See the contribution guide
for more details.

Release Notes

tkn supports v1 Task and Pipeline sign and verify

@tekton-robot tekton-robot added the release-note Denotes a PR that will be considered when it comes time to generate release notes. label Jan 17, 2024
@tekton-robot
Copy link
Contributor

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@tekton-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign vdemeester after the PR has been reviewed.
You can assign the PR to them by writing /assign @vdemeester in a comment when ready.

The full list of commands accepted by this bot can be found 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 do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 17, 2024
@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 17, 2024
@Yongxuanzhang Yongxuanzhang changed the title support v1 for sign command support v1 for sign and verify command Jan 17, 2024
@Yongxuanzhang
Copy link
Member Author

/kind feature

@tekton-robot tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 17, 2024
@Yongxuanzhang Yongxuanzhang marked this pull request as ready for review January 17, 2024 21:28
@tekton-robot tekton-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 17, 2024
@Yongxuanzhang
Copy link
Member Author

/retest

@Yongxuanzhang Yongxuanzhang force-pushed the support-v1-sign branch 2 times, most recently from 58ff014 to 4e0f43a Compare January 18, 2024 17:23
@Yongxuanzhang
Copy link
Member Author

/retest

piyush-garg
piyush-garg reviewed Jan 23, 2024
View reviewed changes
pkg/cmd/pipeline/sign.go
@@ -70,7 +73,13 @@ or using kms
return err
}

crd := &v1beta1.Pipeline{}
var crd metav1.Object
Copy link
Contributor

Choose a reason for hiding this comment

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

We are reading the file provided by user as input, we can get the info about version from file content. Correct me if this is wrong. Why we need to take the input from user?

Also --pipeline-version flag does not look make sense for task commands

Copy link
Member

@chmouel chmouel Jan 24, 2024 •
edited

Choose a reason for hiding this comment

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

naming is hard 😅 I think the idea is to convey which tektoncd/pipeline version we want

but yeah that may be confusing?

any other suggestions? --crd-version perhaps ?

actually forget what i said, you are acutally right we can just autodetect this

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for the suggestion, but I don't know what would be the best way to do this.
How to read the version info from the file content? Scan the string? How to get the version v1 for this case?
e.g.

# apiVersion: v1beta1
apiVersion: v1
...

Copy link
Member Author

Choose a reason for hiding this comment

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

--pipeline-version means (Tekton) Pipeline Version, it was suggested in the previous comment of this PR. Maybe rename it to --api-version?Wdyt?

@Yongxuanzhang Yongxuanzhang force-pushed the support-v1-sign branch 2 times, most recently from 3a0dc09 to ed79e36 Compare February 8, 2024 18:52
@vdemeester
Copy link
Member

@Yongxuanzhang seems like it needs another rebase 🙏🏼

@Yongxuanzhang
support v1 for sign and verofy command
cc15802 
This commit adds v1 support for sign and verify.

Signed-off-by: Yongxuan Zhang yongxuanzhang@google.com
@Yongxuanzhang
Copy link
Member Author

@Yongxuanzhang seems like it needs another rebase 🙏🏼

Just rebased, sorry for the delay 🙏
I was focusing on something else in the past months

@piyush-garg
Copy link
Contributor

@Yongxuanzhang seems like it needs another rebase 🙏🏼

Just rebased, sorry for the delay 🙏 I was focusing on something else in the past months

Did you try with some approach for reading it through yaml ?

@Yongxuanzhang
Copy link
Member Author

Yongxuanzhang commented Apr 8, 2024 •
edited

@Yongxuanzhang seems like it needs another rebase 🙏🏼

Just rebased, sorry for the delay 🙏 I was focusing on something else in the past months

Did you try with some approach for reading it through yaml ?

Sorry I cannot think of a way which is not error prone. :(
Like I mentioned before, detecting the content from file can lead to unexpected outcome.

Since it is an experiment feature, why don't we start with the easier one then iterate?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pradeepitm12 pradeepitm12 Awaiting requested review from pradeepitm12

@vinamra28 vinamra28 Awaiting requested review from vinamra28

@chmouel chmouel Awaiting requested review from chmouel

@piyush-garg piyush-garg Awaiting requested review from piyush-garg

Assignees
No one assigned
Labels
kind/feature Categorizes issue or PR as related to a new feature. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

support v1 for sign and verify commands
6 participants
@Yongxuanzhang @tekton-robot @vdemeester @piyush-garg @chmouel @vinamra28