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

kubectl plugin #8

Closed
steren opened this issue Jan 19, 2019 · 8 comments
Closed

kubectl plugin #8

steren opened this issue Jan 19, 2019 · 8 comments
Labels
kind/compatibility Issues type regarding compatibility of client

Comments

@steren
Copy link

steren commented Jan 19, 2019 •
edited
Loading

Hi,
I have no real idea what a kubectl plugin is, but I heard of them and want to open the dialog, mostly to hear opinions and capture the rationale.
I also learnt about krew, a kubectl plugin manager.

Would it make sense to have a kubectl plugin for Knative?

If so, should it be in addition to kn? or could kn be delivered as a kubectl plugin? or should it replace kn?

Having a kubectl plugin that facilitates the usage of Knative resources could be very Kubernetes... native :)

CC @sixolet
@sixolet
Copy link
Contributor

sixolet commented Jan 19, 2019 via email

@steren
Copy link
Author

steren commented Jan 22, 2019

Thanks, that makes sense.

CC @ahmetb

@ahmetb
Copy link

ahmetb commented Jan 22, 2019 •
edited
Loading

Unless you plan on exposing kn as kubectl serverless [...] or something like that, you probably shouldn't use plugins.

That said, using https://github.com/kubernetes/cli-runtime helps you reuse the flag parsing, printing etc functionality from kubectl.

I'm happy to discuss kubectl plugins anytime. But unless the client would be advertised as a kubectl subcommand, it is probably not the best fit.

@steren
Copy link
Author

steren commented Jan 22, 2019

I actually opened this issue to discuss this point: do we need a standalone kn client? or would a kubectl plugin be more idiomatic to our user base?

@maximilien
Copy link
Contributor

maximilien commented Apr 23, 2019 •
edited
Loading

I believe we need a standalone kn client. And having plugins to extend / experiment on the client is also useful.

We had some discussion on this on 04/16/2019. I have some opinions and would like to restart the discussion if others are interested.

@maximilien
Copy link
Contributor

maximilien commented May 3, 2019 •
edited
Loading

Since this issue is discussing kn as a kubectl plugin, which is a valid issue for discussion, I am opening a different one on adding plugins to kn itself, see issue #92.

I will present and demo a proposal during Tuesday 04/06/2019's call.

@rhuss
Copy link
Contributor

rhuss commented May 4, 2019

I actually opened this issue to discuss this point: do we need a standalone kn client? or would a kubectl plugin be more idiomatic to our user base?

I think one of the main motivation of the kn client is to be completely agnostic to Kubernetes and also be able to support Knative implementations which are not based on Kubernetes.

Having plugins for kn though is a different story.

@sixolet sixolet added the kind/compatibility Issues type regarding compatibility of client label Jul 11, 2019
@steren
Copy link
Author

steren commented Jul 26, 2019

Seems like the consensus is to not ship via a kubectl plugin but via a standalone binary. Closing.

@steren steren closed this as completed Jul 26, 2019
coryrc pushed a commit to coryrc/client that referenced this issue May 14, 2020
@adrcunha @knative-prow-robot
Add e2e test (knative#119)
ce1328a 
Current (only) test verifies the `e2e-tests.sh` helper script.

Fixes knative#8
eletonia added a commit to eletonia/client that referenced this issue Mar 8, 2021
@eletonia
# This is a combination of 9 commits.
bc044cf 
# This is the 1st commit message:
adding BUILT-IN SOURCE column for kn source list-types

# The commit message knative#2 will be skipped:

#	changing list test to check for BUILT-IN SOURCE column

# The commit message knative#3 will be skipped:

#	changing e2e source list test to check for BUILT-IN SOURCE column

# The commit message knative#4 will be skipped:

#	adding CHANGELOG entry

# The commit message knative#5 will be skipped:

#	kn source list-types: changing BUILT-IN SOURCE to BUILT-IN and moving DESCRIPTION column to the end

# The commit message knative#6 will be skipped:

#	changing BUILT-IN SOURCE to BUILT-IN in changelog

# The commit message knative#7 will be skipped:

#	Update CHANGELOG.adoc
#
#	Co-authored-by: David Simansky <dsimansk@redhat.com>

# The commit message knative#8 will be skipped:

#	kn source list-types: changing column header to S, values to X, and moving to second column

# The commit message knative#9 will be skipped:

#	fixing CHANGELOG merge conflict
knative-prow-robot pushed a commit that referenced this issue Mar 9, 2021
@eletonia
kn source-list types: adding column to specify built-in source (#1246)
a9687c6 
* # This is a combination of 9 commits.
# This is the 1st commit message:
adding BUILT-IN SOURCE column for kn source list-types

# The commit message #2 will be skipped:

#	changing list test to check for BUILT-IN SOURCE column

# The commit message #3 will be skipped:

#	changing e2e source list test to check for BUILT-IN SOURCE column

# The commit message #4 will be skipped:

#	adding CHANGELOG entry

# The commit message #5 will be skipped:

#	kn source list-types: changing BUILT-IN SOURCE to BUILT-IN and moving DESCRIPTION column to the end

# The commit message #6 will be skipped:

#	changing BUILT-IN SOURCE to BUILT-IN in changelog

# The commit message #7 will be skipped:

#	Update CHANGELOG.adoc
#
#	Co-authored-by: David Simansky <dsimansk@redhat.com>

# The commit message #8 will be skipped:

#	kn source list-types: changing column header to S, values to X, and moving to second column

# The commit message #9 will be skipped:

#	fixing CHANGELOG merge conflict

* adding BUILT-IN SOURCE column for kn source list-types
Kaustubh-pande pushed a commit to Kaustubh-pande/client that referenced this issue Aug 8, 2023
@openshift-cherrypick-robot @mgencur
SRVCLI-363 Build multiarch test images (knative#8)
128ff03 
Simply list all the test images. The previous find command included also
o./vendor/knative.dev/serving/test/test_images/grpc-ping/proto which is
not correct and the image build would be redundant.

Co-authored-by: Martin Gencur <mgencur@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/compatibility Issues type regarding compatibility of client
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@maximilien @rhuss @ahmetb @steren @sixolet