Enrique Encalada

@gabemontero take for example the following scenario: > A user defines a `Build` X. Then the same user cooks two `BuildRuns` that reference `Build` X. from the above, is up...

Can we close this issue in favor of https://github.com/shipwright-io/build/issues/56#issuecomment-718849155 and https://github.com/shipwright-io/build/issues/56#issuecomment-727895129 ? Or do we want to keep this as a reminder of the ongoing Tekton efforts mentioned in https://github.com/shipwright-io/build/issues/56#issuecomment-735926704...

hey @ashokponkumar good question. It really depends on the tools we use, like `kaniko`, `buildkit`, `buildpacks`. I know building for windows containers is not supported at least in Kaniko and...

@gabemontero this issue seems to cover two pieces: 1. Via the usage of ENV variables in the Build, to allow users to define a certificate path, e.g. by passing it...

@gabemontero ok, +1 on removing this from 1.0.0

@SaschaSchwarze0 sorry, im digesting the msgs, will provide my 2 cents soonish

My opinion is that we do not need to do anything, because of the following: 1. This use-case is only valid when a new `BuildRun` is created while the referenced...

> Remove fallback to pipeline and default service account. Instead we require the user to provide a service account name that exists (and can specify default, if he wants). If...

> So that is why I suggest change the generate=true and document the problem if end user switch to use generate=false @zhangtbj yes, I think we should do this as...

@SaschaSchwarze0 I think there is no need for this: > would be similar to what the e2e tests do = one passes an environment variable to the operator which is...