Jason Hall

Perhaps I have an incomplete understanding of Skaffold's model, but I had assumed it would execute the build on the cluster (local or remote) that it uses the execute the...

It's not possible today, but I could imagine some changes that would enable it. Maybe some option to specify the volume that backs `/workspace`, instead of an `emptyDir` like it...

The Knative Serving controller is also deployed as a [`Deployment`](https://github.com/knative/serving/blob/master/config/controller.yaml) which listens for updates to `Configuration`, etc., CRDs, and responds accordingly. I'm not sure what advantage there would be of...

I think in Pipelines' model, the way you'd retry a failed build would be to create a new `PipelineRun` or `TaskRun` from the original `Pipeline`/`Task` definition, with the same `PipelineParams`....

That is a pretty unfortunate side effect, most of the builder images we use and recommend rely on the entrypoint to reduce stutter. It might be a deal-breaker. 😞 Another...

If you already have source in a volume on the cluster, it should already be possible to mount that volume into your steps, to somewhere other than `/workspace`, and build...

I don't want to dive too deeply into triggers too far just yet. I think we can say that if a build has a `gitSource`, it has the git-related parameters...

In GCB we look up the commit referenced by the branch/tag/ref before accepting the build, which lets us validate that the branch/whatever exists and is accessible to the builder service...

Sure. If a build specifies `gitSource` with `branch`/`tag`/`ref`, the controller will try to reach out to figure out what commit is currently referenced by that branch/tag/ref, and will populate that...

SGTM. If a build specifies `ref: "refs/heads/master"` should we be smart and realize they mean `branch: "master"`, and populate `${BRANCH_NAME}`? Should we populate `${REF_NAME}` if the user specifies a branch...