Johannes Scheuermann

This is the resulting build: ```bash apiVersion: build.knative.dev/v1alpha1 kind: Build metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"build.knative.dev/v1alpha1","kind":"Build","metadata":{"annotations":{},"name":"example-build","namespace":"default"},"spec":{"steps":[{"args":["echo","hello-example","one"],"image":"ubuntu"}]}} creationTimestamp: "2019-05-08T18:34:07Z" generation: 1 name: example-build namespace: default resourceVersion: "163654" selfLink: /apis/build.knative.dev/v1alpha1/namespaces/default/builds/example-build uid: dcfc8c4c-71bf-11e9-b521-42010aa4007f spec:...

I found this in the docs https://knative.dev/docs/build/builds/#steps but I don't know if this is outdated or an outlook :D

I think if we solve https://github.com/FoundationDB/fdb-kubernetes-operator/issues/245 also solve this issue right?

Ah right, I mixed them both up 👍

CC @ltsampros I know that you look at this, would that be a good candidate for you to work on?

@brownleej was the idea to add the log group of the cluster when running a command? Otherwise the log group is already set the the env value in the container:...

Hm, that's interesting my test actually showed that the `LogGroup` was set but let me confirm that. In addition to that the env variable should already be passed down to...

I'll try to verify that again and see if there are any logs that have the wrong LogGroup. If the LogGroup is set correctly in all logs I would go...

Once https://github.com/apple/foundationdb/pull/6311 merged we can add the feature for new releases.

I don't think that kustomize offers too much here since this would require some templating.