I think we should make an x/build/cmd/xb subcommand that makes a temp dir and clones a clean checkout into that tempdir and deploys from there. (and only allowing copying modified files if a flag like --dirty is given)

Another alternative is to always use Cloud Build to run the deploy process instead of running gcloud locally. Cloud Build can do a fresh checkout and run the deploy, thereby removing the local environment from the equation.

I've remembered something that should be taken into account if we consider removing/reducing .gitignore files.

Some of the env directories have scripts that use said directories for "caching" some artifacts, and avoiding re-downloading them if they're already present. For example:

https://github.com/golang/build/blob/1a1d5714b86442e273799824180b67685637717a/env/openbsd-amd64/make.bash#L26-L32

There's nothing to deploy inside app/appengine as of #34744, and cmd/coordinator is deployed via Cloud Build as part of progress on #57852.

I'm realizing that using Cloud Build from a local checkout doesn't entirely avoid the possibility of skew if there are mismatches between the checked-in .gitignore and .gcloudignore files. To really solve it, it'd need to be combined with remote repo cloning + triggering (e.g., as done in x/website deploys).

Since this issue refers to a component that doesn't exist and there haven't been noticeable problems in a long while, so I'll close it for now. We can file a new issue if this problem comes up again.