Uploaded image for project: 'Kogito'
  1. Kogito
  2. KOGITO-2522

Webhooks seems not working when deploying a Kogito Build

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 0.13.0
    • 0.11.0
    • Operator
    • None
    • 2020 Week 28-30 (from Jul 6)

      I deployed the next Kogito Build:

      apiVersion: app.kiegroup.org/v1alpha1
      kind: KogitoBuild
      metadata:
        name: process-quarkus-example
      spec:
        runtimeImage:
          name: kogito-quarkus-jvm-ubi8-nightly
          tag: latest
        resources: {}
        targetKogitoRuntime: process-quarkus-example
        gitSource:
          contextDir: process-quarkus-example
          reference: master
          uri: 'https://github.com/kiegroup/kogito-examples'
        buildImage:
          name: kogito-quarkus-ubi8-s2i-nightly
          tag: latest
        artifact: {}
        runtime: quarkus
        type: RemoteSource
        webHooks:
          - secret: my_secret
            type: GitHub
      

      The above fails in the operator with the these errors:

      {
          "level": "error",
          "ts": 1594794255.2239687,
          "logger": "controller-runtime.controller",
          "msg": "Reconciler error",
          "controller": "kogitobuild-controller",
          "request": "jch-cucumber-be1e/process-quarkus-example",
          "error": "BuildConfig.build.openshift.io \"process-quarkus-example-builder\" is invalid: spec.triggers[1].github.allowEnv: Invalid value: build.WebHookTrigger{Secret:\"\", AllowEnv:true, SecretReference:(*build.SecretLocalReference)(0xc001c58010)}: git webhooks cannot allow env vars",
          "stacktrace": "github.com/go-logr/zapr.(*zapLogger).Error\n\t/home/jcarvaja/go/pkg/mod/github.com/go-logr/zapr@v0.1.1/zapr.go:128\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/home/jcarvaja/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.6.0/pkg/internal/controller/controller.go:258\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/jcarvaja/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.6.0/pkg/internal/controller/controller.go:232\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker\n\t/home/jcarvaja/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.6.0/pkg/internal/controller/controller.go:211\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1\n\t/home/jcarvaja/go/pkg/mod/k8s.io/apimachinery@v0.18.3/pkg/util/wait/wait.go:155\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil\n\t/home/jcarvaja/go/pkg/mod/k8s.io/apimachinery@v0.18.3/pkg/util/wait/wait.go:156\nk8s.io/apimachinery/pkg/util/wait.JitterUntil\n\t/home/jcarvaja/go/pkg/mod/k8s.io/apimachinery@v0.18.3/pkg/util/wait/wait.go:133\nk8s.io/apimachinery/pkg/util/wait.Until\n\t/home/jcarvaja/go/pkg/mod/k8s.io/apimachinery@v0.18.3/pkg/util/wait/wait.go:90"
      }
      

      Note that this is working when using Generic webhook. The issue is when passing the "AllowEnv" parameter (see line here). According to the documentation, the AllowEnv parameter should be true only when using a Generic webhook.

      Also, I think this is only supported in Openshift... not in Kubernetes. If so, we should not accept a kogito build with webhooks when running in Kubernetes to avoid misunderstandings. (I mean to raise an error when adding the kogito build via cli)

              jcarvaja@redhat.com Jose Carvajal Hilario
              jcarvaja@redhat.com Jose Carvajal Hilario
              Karel Suta Karel Suta
              Karel Suta Karel Suta
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: