Add support for BuildConfig and ImageStreams

[kadel]

BuildConfig should be a new type in Kedge file.

We should do it the same way as other types. Merging BuildConfigSpec with ObjectMeta and adding it under new root level key buildconfigs

This will also require adding ImageStreams in the same way (merging ImageStreamSpec with ObjectMeta`.

full example of Kedge file with BuildConfig (using cusom s2i) and ImageStreams:

name: guestbook-backend
controller: DeploymentConfig
containers:
  - name: backend
    image: guestbook-backend:v1
    env:
      - name: MONGODB_PASSWORD
        value: foo
      - name: MONGODB_USERNAME
        value: foo 
      - name: MONGODB_DATABASE
        value: foo
      - name: MONGODB_SERVER
        value: foo
triggers:
  - type: ConfigChange 
  - type: ImageChange 
    imageChangeParams:
      automatic: true
      containerNames:
        - backend
      from:
        kind: ImageStreamTag
        name: guestbook-backend:v1

imageStreams:
  - name: go-17-centos7
    tags:
      - name: skip-download-when-vendored
        from:
          kind: DockerImage
          name: quay.io/tomkral/go-17-centos7:skip-download-when-vendored
  - name: guestbook-backend
    tags:
      - name: v1

buildConfigs:
  - source: 
      git:
       uri: "https://github.com/kadel/guestbook-demo-backend"
    strategy:
      sourceStrategy:
        from:
          kind: ImageStreamTag
          name: go-17-centos7:skip-download-when-vendored 
    output:
      to:
        kind: ImageStreamTag
        name: guestbook-backend:v1
    triggers:
      - type: GitHub
        github:
          secret: secret

imageStreams definetly has to be list. But how about buildConfigs? Does it make sense to have multiple buildConfig if we can have only one controller in one file (or one section of the file).
It might make sense to have only one buildConfig to stay consistent with one controller.

[pradeepto]

Related to / Duplicated of #309

Sort of related to #331

cc @kadel @surajssd

[surajssd]

The only problem with root level bc is that how do we tell it which container it should build for if pod has multiple containers?

[surajssd]

Because the amount of information in your proposal, someone has to give is way too much and I think some of it can be auto generated/populated if we put/embed the buildconfigspec inside containerspec

[kadel]

The only problem with root level bc is that how do we tell it which container it should build for if pod has multiple containers?

That is defined inside BuildConfig. See output section in BuildConfig definition.
It can be either ImageStream or any other docker registry (https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#build-output)

DeploymentConfig is hooked to that ImageStream so it triggers deployment what IS changes

[kadel]

Because the amount of information in your proposal, someone has to give is way too much and I think some of it can be auto generated/populated if we put/embed the buildconfigspec inside containerspec

This is the typical way how it is done in OpenShift. We need to support this either way.
After we add this we can start thinking about improving it with shortcuts.

[concaf]

This has been merged in #445 and #466 and #467