Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VVV init script is unable to clone private git repos #1

Open
aquillano opened this issue Jun 20, 2016 · 2 comments
Open

VVV init script is unable to clone private git repos #1

aquillano opened this issue Jun 20, 2016 · 2 comments

Comments

@aquillano
Copy link

This is specifically a problem for us when trying to clone our decaturmakers.org repo. It happens because the vagrant provisioning process runs as root and doesn't have access to a forwarded SSH agent (During vagrant ssh, SSH agent forwarding does work, but that doesn't help us here). I have two solutions to the problem and thought this would be a good place to discuss, debate and decide on which solution we'd like to use.

  • Part of the initial setup would require you to create a Personal access token on github.com. We'd then have the vvv-init.sh script clone decaturmakers.org via HTTPS (using the personal access token) for authentication.
Pros Cons
Everything remains encapsulated in this single vvv-init.sh script There is an extra initial step of having to generate a personal access token
  • We use a Makefile to clone the decaturmakers.org repo on the host machine and then run the initial vagrant up. In this scenario the vvv-init.sh script would basically just do the automated WP installs using the wp-cli.
Pros Cons
Ideally, the initialization of the dev enviroment is a single command: make Can't really thing of any cons
@lewlefton
Copy link

I don't have a strong preference for either solution. I'm comfortable with both options. Creating a personal access token on github.com may potentially have additional benefits later but it will be an additional (one-time) step for newbies, too. A Makefile provides potentially more customization down the road but is a more traditional approach and may require installation of CLI dev tools (autoconf, etc?).

I'd say flip a coin or just choose one if there aren't any more opinions in the next day or so.

@aquillano
Copy link
Author

To your point, instead of using make, we could just use a new setup.sh script to kick things off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants