Allow create prowjob with annotations

[krzyzacy]

So I need to store some extra into into the prowjob, however label is restricted to 256 chars and a certain charaterset, which I cannot store a string in run time (see #9045).. Try to make annotation first class

/area prow
/assign @stevekuznetsov @BenTheElder @cjwagner

[stevekuznetsov]

Adding structured data into annotations is an anti-pattern that is strongly not suggested in k/k. This is reminiscent of #6852. The current approach seems to be to add optional fields that are set only sometimes...

[krzyzacy]

humm? It's not structured data, but only some urls that labels cannot take, which seems annotation would be appropriate?

[BenTheElder]

Adding structured data into annotations is an anti-pattern that is strongly not suggested in k/k. This is reminiscent of #6852. The current approach seems to be to add optional fields that are set only sometimes...

Er regarding #6852 I don't see how adding another optional field first class would make things less muddy. Annotations are fine for controller managed data? Long also != structured.

The docs for annotations specifically call out use cases like this: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/

Build, release, or image information like timestamps, release IDs, git branch, PR numbers, image hashes, and registry address.

[stevekuznetsov]

The impl here is fine
/lgtm
/hold

Is this data we otherwise hold in labels for GitHub jobs? Can we add this to spec somewhere? Sure, adding new fields is not going to be better, but it's at least structured and can at least be validated, if we wanted to. I was imagining the set of data the gerrit reporter would need (not any specific annotation) would be a structure with more semantic meaning than "all fields are strings and optional"

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: krzyzacy, stevekuznetsov

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:

• prow/OWNERS [krzyzacy,stevekuznetsov]

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

[krzyzacy]

So each gerrit change contains an ID which is basically something like host+repo+SHA, and gerrit host is a url, repo can be /a/n/y/t/h/i/n/g, I have to store the ID in order to use that for reporting later, and that cannot be a label.

[krzyzacy]

We can guard people from using this function to store a blob of json into annotations, if that's the concern. (Currently they can still do it via editing the metadata)

/hold cancel