json schema wrongly required fields

[ilyagorban-codefresh]

Describe the bug
While validating using the jsonschema with kubeconform tool (I tried other json validators as well), I found couple of inconsistencies (not required required fields):

• (EventSource): For field (root): Must validate one and only one schema (oneOf) - For field spec.calendar.interval-time: schedule is required
• (EventSource): For field (root): Must validate one and only one schema (oneOf) - For field spec.github.push: id is required - For field spec.github.push: owner is required - For field spec.github.push: repository is required

To Reproduce
Yaml with calendar' schedule requirement:

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: calendar-eventsource
spec:
  eventBusName: some-eventbus
  calendar:
    interval-time:
      interval: 8760h

Yaml with github push id,repo,owner requirement

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: git-source
spec:
  replicas: 2
  eventBusName: some-eventbus
  service:
    ports:
      - port: 80
        targetPort: "80"
  github:
    push:
      repositories:
        - owner: organization-name
          names:
            - repo-name
      webhook:
        endpoint: /git-source/
        port: "80"
        method: POST
        url: https://some-url
      events:
        - push
      apiToken:
        name: github-token
        key: token
      insecure: true
      active: true
      contentType: json

Steps to reproduce the behavior:

1. install kubeconform tool
2. launch in terminal where you saved the yamls above: kubeconform -schema-location https://raw.githubusercontent.com/argoproj/argo-events/master/api/jsonschema/schema.json -strict -output tap .
3. See error

Expected behavior
Absence of errors on validation

Environment (please complete the following information):

• Argo: v3.2.0-rc4
• Argo Events: v1.5.0

Additional context

---

Message from the maintainers:

If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

[MosenzonTal]

👍

[daniel-codefresh]

@whynowy This happens because the schema is based on our swagger.json, and all of the fields that were mentioned above are not marked as optional. Do you think we can mark them as optional at least until they are completely removed in v1.6?
Anyway you can assign this one to me

[whynowy]

@whynowy This happens because the schema is based on our swagger.json, and all of the fields that were mentioned above are not marked as optional. Do you think we can mark them as optional at least until they are completely removed in v1.6? Anyway you can assign this one to me

That seems to be the only way. Feel free to assigned to yourself, thanks @daniel-codefresh!

[daniel-codefresh]

@whynowy heres the related PR: #1421

[ilyagorban-codefresh]

I can confirm that it stopped to show errors, but absence of interval in calendar now does not trigger errors at all.

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: calendar-eventsource
spec:
  eventBusName: some-eventbus
  calendar:
    interval-time:
      blabla: 8760h

[daniel-codefresh]

@ilyagorban-codefresh That's because interval isn't a mandatory field, for example this is a completely valid Calendar eventsource:

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: calendar-eventsource
spec:
  eventBusName: some-eventbus
  calendar:
    interval-time:
      schedule: "30 * * * *"

[ilyagorban-codefresh]

@daniel-codefresh I thought about oneOf example. Although I don't know how it is possible to set in open API to be converted to json schema

[ilyagorban-codefresh]

https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/

[daniel-codefresh]

@ilyagorban-codefresh Yes, oneOf would've been a great option, but again the json schema is generated automatically based on the swagger schema and unfortunately oneOf isn't supported in swagger v2, nor by the k8s openapi generators that we're using, therefore I think there's probably no quick or maintainable solution for this ATM, without needing to change the whole schema generation process.

[ilyagorban-codefresh]

You are right, so we can close the ticket - thank you for your help!!!