kn source-list types: adding column to specify built-in source

[eletonia]

Description

kn source list-types currently shows the TYPE, NAME, and DESCRIPTION of available sources.
This PR adds a S column which shows whether the source is built-in or not:

$ kn source list-types
TYPE              S     NAME                                   DESCRIPTION
ApiServerSource   X     apiserversources.sources.knative.dev   Watch and send Kubernetes API events to addressable
ContainerSource   X     containersources.sources.knative.dev   Generate events by Container image and send to addressable
PingSource        X     pingsources.sources.knative.dev        Send periodically ping events to addressable
SinkBinding       X     sinkbindings.sources.knative.dev       Binding for connecting a PodSpecable to addressable

Changes

• changed human_readable_flags.go to add the new S column
• list_test.go now checks for S column and appropriate values
• source_list_test.go e2e test now checks for S column

Reference

Fixes a part of #633 More discussion is needed on how to handle plugin sources.

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[knative-prow-robot]

Welcome @eletonia! It looks like this is your first PR to knative/client 🎉

[knative-prow-robot]

Hi @eletonia. Thanks for your PR.

I'm waiting for a knative 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.

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[eletonia]

@googlebot I fixed it.

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[dsimansk]

@eletonia thanks for the contribution!

The change looks good at a first glance. However, google-cla bot is confused due to mix of 2 accounts adding commits. It'd better if you could squash all those commits into one under your preferred account.

You can check how to fill the licence agreement for the future contributions.

/ok-to-test

[dsimansk]

/lgtm

[eletonia]

/assign @rhuss

[maximilien]

Thanks for the contribution. The question is whether this could be done dynamically since as new sources are added and introduced you’ll need to change your hard coded list. Perhaps having a different issue to “upgrade” to that in future could allow this to be merged now and the enhancement done in future. WDYT?

[eletonia]

Details for apiserver, container, ping, and binding are hardcoded in other parts of the code since these are the available subcommands for for kn source:

$ kn source --help
Manage event sources

Usage:
  kn source SOURCE|COMMAND [options]

Aliases: 
  source, sources

Available Commands:
  apiserver   Manage Kubernetes api-server sources
  binding     Manage sink bindings
  container   Manage container sources
  list        List event sources
  list-types  List event source types
  ping        Manage ping sources

In a future issue with plugin support, we can dynamically display the description and source type if it is a plugin as suggested in the comments of this code

[itsmurugappan]

Thanks for your contribution, couple of things,

• should the values of this column be "Yes/No" or "BuiltIn/Plugin" ?
• to keep it simple, anything apart from the built in source could be displayed as plugin (for kafkasource, githubsource etc)

cc @navidshaikh @dsimansk @maximilien

[dsimansk]

* should the values of this column be "Yes/No" or "BuiltIn/Plugin" ?
* to keep it simple, anything apart from the built in source could be displayed as plugin (for kafkasource, githubsource etc)

Well, that'd easily imply that such a plugin actually exists to support the source, but it's not necessary true for a lot of eventing sources.

[rhuss]

Thanks for the PR, looks good in general, but I would be denser to save screen real estate. Also, I think that for the user it is only important whether a source is supported by the client or not, regardless of whether it is built-in or supported via a plugin.

E.g. instead of YES / NO, just use an "X" (and nothing if not builtin), and instead of "BUILT-IN" header, maybe just an "S" letter (or something else), or even no header. Then, I would put that in the second or third column, before the description because this column is of fixed length (ideally only 1 char), while a description can be long and varying in length. In general, the longest possible column should be last because this can be the only one that possible needs not to be truncated when being longer than a certain limit.

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[dsimansk]

@eletonia at least we know it's not my "consent". :)

[eletonia]

Thanks @dsimansk There are no other authors that need to consent. It may have to be manually confirmed:

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

[eletonia]

/retest

[dsimansk]

@itsmurugappan could you please try to comment with @googlebot I consent. I think, the merge commit might be confusing cla bot as it brings your changelog update from master branch.

@eletonia I believe for the manual confirmation it needs to be also Googler. It might be quicker to just create a fresh PR. @rhuss any suggestion would be welcome pls?

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[itsmurugappan]

@googlebot I consent.

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[rhuss]

@eletonia @dsimansk the best way is to locally squash everything to a local commit and then do a forced push. Then the googlebot is happy again :)

Alternatively you could of course do a fresh PR but I think the first option might be easier ?

[eletonia]

@dsimansk @rhuss Thanks for the suggestion! I squashed my commits and looks like all the tests are passing now

[dsimansk]

/retest

[eletonia]

/retest

[dsimansk]

Thanks @eletonia! I think it's all good now.
/approve
/lgtm

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dsimansk

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 [dsimansk]

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