Add dataBase64 flag for Ping Source

[xtreme-sameer-vohra]

Feature request

For parity to be able to create a ping source using the kn cli

Use case

Use the dataBase64 for binary data as shown in the docs

kn source ping create test-ping-source --schedule "*/2 * * * *" --dataBase64: "ZGF0YQ==" --sink ksvc:event-display

[dsimansk]

I wonder if should just add a plain --dataBase64 flag, that's pretty much straightforward and fast to do.
On the other hand I'd like something like more sophisticated --data flag that could try to detect base64 encoding automatically, or --data "base64:Hello!" that encodes the data for the kn user.

Wdyt? @rhuss @navidshaikh @maximilien

[dsimansk]

In addition a quick observation dataBase64 is available sources/v1beta2, but kn is still on v1alpha2 for the backward compatibility support.

https://github.com/knative/eventing/blob/master/pkg/apis/sources/v1beta2/ping_types.go#L80-L83
https://github.com/knative/client/blob/master/pkg/sources/v1alpha2/ping_client.go#L24

[eclipselu]

ContentType is also needed if we consider feature parity with v1beta2 PingSource.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[dsimansk]

/remove-lifecycle stale
/kind good-first-issue

[dsimansk]

/assign @vyasgun

[knative-prow-robot]

@dsimansk: GitHub didn't allow me to assign the following users: vyasgun.

Note that only knative members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @vyasgun

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.

[vyasgun]

/assign

[rhuss]

I think we could have the following options:

• --data : for string data (we have that)
• --encoding=text or base64 to specify the encoding (i.e. which field to use and how to deal with the encoding). When base64 is given, encode the data (if not already encoded maybe) and use the base64 data field in the resource
• --file for specifying a file. I think this is important as for binary data you typically want to pick it up from a file, encode it and send it. A file would be base64 encoded by default, only when --encoding text is given, then use the file literally and put it into data: field.

Actually, I would not offer an option to specify literal bas64 on the CLI but would do the translation all internally (and also wouldn't expose the field to be set directly). That is the value-add that a CLI can offer.
However we could be smart and detect whether a given --data is already a valid base64 encoded. If this is the case and no --encoding is given, then autodetect the field to put the data on.