manual build and deploy process fails if git user.useConfigOnly option is set about blt

[ba66e77]

As an attempt at a workaround, I tried the following process and while it worked to push code, the site is failing because the vendor directory is gitignored in the deploy directory, so isn't committed and pushed to the target repo.

• ./bolt.sh deploy:artifact:build
• added my user creds to git config of deploy dir
• ./bolt.sh deploy:artifact:commit -Ddeploy.commitMsg="--commit message---"
• ./bolt.sh deploy:artifact:push-all -Ddeploy.branch='--target branch name--'

[grasmash]

Hm. This is a tricky problem.

We've found that it's best to wipe out the deploy directory prior to generating the artifact, since it's the only way to ensure a clean build.

I'm thinking the only two options are:

1. Don't wipe out the deploy dir. This would allow your manually git config to persist, but the steps necessary feel ugly.
2. Allow git username and email to be configurable by Bolt. This is a bit tough because it's local machine specific, and cannot be committed to the repo. We'd need to re-introduce a local.yml file. @danepowell @geerlingguy I feel like we had other reasons to consider re-introducing a local.yml. I like keeping the number of config files to a minimum, but I'm open to input!

[danepowell]

Preserving the deploy/.git directory isn't a crazy idea. In fact it ties in nicely to #22. So both of these issues could probably be solved together.

I don't think I want to build in specific support for a git username and email, since it really seems like an edge case. Deploys are typically run from a CI tool, and I can't imagine a scenario where a dedicated CI tool needs to support multiple Git identities for deployments. Feel free to prove me wrong though.

[danepowell]

Well, #22 was solved differently, I agree with Matt that preserving the .git directory isn't the best solution to this.

My recommendation would be to support two new arguments (git.email and git.username or something) that deploy:commit uses. And these could be added to project.local.yml.

@ba66e77 is this still a requirement for you?

[ba66e77]

Yes, it still is. I've swallowed my pride and removed the useConfigOnly option in order to work around it, but that causes its own set of issues. I'd dearly love if this could be supported somehow.

Setting the new arguments you mentioned in the project.local.yml certainly seems viable to me.

[danepowell]

@ba66e77 feel like testing #1323?

You can apply it as a patch to an existing project like so: https://patch-diff.githubusercontent.com/raw/acquia/blt/pull/1323.patch