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

Allow selecting which sites to make active #474

Closed
tnorthcutt opened this Issue Oct 13, 2014 · 20 comments

Comments

Projects
None yet
9 participants
@tnorthcutt
Contributor

tnorthcutt commented Oct 13, 2014

I keep a number of sites (~20 right now) on one VVV install. Most of those, however, are only around for the rare instance when I need to work on them, and 90%+ of the time, I don't need them available. To speed up destroy, halt, up, provision, etc. it would be great to have a way to indicate which sites should be loaded at any given time. Perhaps a simple text file that provision.sh can look for, and if found, would then use to load only the sites explicitly defined?

I'm not sure if that's the best approach (and if it is, how exactly to implement that), but if given some direction, I'd be happy to submit a PR to implement this functionality.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Oct 13, 2014

Member

Great idea.

Probably the best way to go about implementing this is to introduce a .gitignore'ed file which contains the paths to exclude when provision.sh does these find calls:

For that matter, the file could have the list of files paths to search instead of the ones to exclude. In other words, if the includes file does not exist, use /srv/www. If it does exist, use the paths inside the file in the find command.

Member

westonruter commented Oct 13, 2014

Great idea.

Probably the best way to go about implementing this is to introduce a .gitignore'ed file which contains the paths to exclude when provision.sh does these find calls:

For that matter, the file could have the list of files paths to search instead of the ones to exclude. In other words, if the includes file does not exist, use /srv/www. If it does exist, use the paths inside the file in the find command.

@tnorthcutt

This comment has been minimized.

Show comment
Hide comment
@tnorthcutt

tnorthcutt Oct 13, 2014

Contributor

@westonruter thanks, that helps a lot. I'd lean toward having a list of paths to explicitly include, as opposed to exclude. Got any naming suggestions for the file?

included-sites
sites-include
include-only

Contributor

tnorthcutt commented Oct 13, 2014

@westonruter thanks, that helps a lot. I'd lean toward having a list of paths to explicitly include, as opposed to exclude. Got any naming suggestions for the file?

included-sites
sites-include
include-only

@DrewAPicture

This comment has been minimized.

Show comment
Hide comment
@DrewAPicture

DrewAPicture Oct 13, 2014

Contributor

+1. This is a great idea.

Contributor

DrewAPicture commented Oct 13, 2014

+1. This is a great idea.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Oct 13, 2014

Member

As a big bonus for explicitly whitelisting paths to include, the performance of the provisioning will be drastically improved. If you have a lot of sites in your VVV like I do, and a lot of directories, it can take a long time for these find commands to search through the /srv/www directory tree (and it has to do it 3 times). So as part of this, we could switch to -maxdepth 1.

Member

westonruter commented Oct 13, 2014

As a big bonus for explicitly whitelisting paths to include, the performance of the provisioning will be drastically improved. If you have a lot of sites in your VVV like I do, and a lot of directories, it can take a long time for these find commands to search through the /srv/www directory tree (and it has to do it 3 times). So as part of this, we could switch to -maxdepth 1.

@tnorthcutt

This comment has been minimized.

Show comment
Hide comment
@tnorthcutt

tnorthcutt Oct 13, 2014

Contributor

Roger, so if the included-sites (do we like that name?) file is found, then also change the maxdepth flag to -1?

Contributor

tnorthcutt commented Oct 13, 2014

Roger, so if the included-sites (do we like that name?) file is found, then also change the maxdepth flag to -1?

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Oct 13, 2014

Member

Yes, bingo. 👍

Member

westonruter commented Oct 13, 2014

Yes, bingo. 👍

@ereckers

This comment has been minimized.

Show comment
Hide comment
@ereckers

ereckers Oct 13, 2014

This is something I've been struggling with. I also run a ton of sites out of /www that I wouldn't mind skipping at times, even though I like keeping them around to reference code while developing. In my use case, I always wondered if I could just drop a file in the project directory called something like vvv-skip, next to vvv-init.sh and vvv-nginx.conf.

ereckers commented Oct 13, 2014

This is something I've been struggling with. I also run a ton of sites out of /www that I wouldn't mind skipping at times, even though I like keeping them around to reference code while developing. In my use case, I always wondered if I could just drop a file in the project directory called something like vvv-skip, next to vvv-init.sh and vvv-nginx.conf.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Oct 13, 2014

Member

I think the filename should be something like auto-setup-include-paths.

Member

westonruter commented Oct 13, 2014

I think the filename should be something like auto-setup-include-paths.

@jeremyfelt

This comment has been minimized.

Show comment
Hide comment
@jeremyfelt

jeremyfelt Oct 13, 2014

Member

Dig this idea. Agree with explicitly whitelisting paths to include.

I would love if this transitioned to a YAML config file over time, though I think we're okay with an individual file right now.

Member

jeremyfelt commented Oct 13, 2014

Dig this idea. Agree with explicitly whitelisting paths to include.

I would love if this transitioned to a YAML config file over time, though I think we're okay with an individual file right now.

@tnorthcutt

This comment has been minimized.

Show comment
Hide comment
@tnorthcutt

tnorthcutt Oct 13, 2014

Contributor

@jeremyfelt YAML is far enough out of my reach that I'm not the one for that 😄.

I'll move forward with a simple text file, with each directory to include on a separate line.

Contributor

tnorthcutt commented Oct 13, 2014

@jeremyfelt YAML is far enough out of my reach that I'm not the one for that 😄.

I'll move forward with a simple text file, with each directory to include on a separate line.

@joeguilmette

This comment has been minimized.

Show comment
Hide comment
@joeguilmette

joeguilmette Oct 14, 2014

+1, this is great

joeguilmette commented Oct 14, 2014

+1, this is great

@TobiasBg

This comment has been minimized.

Show comment
Hide comment
@TobiasBg

TobiasBg Oct 21, 2014

Contributor

How about copying the webserver approach for naming, i.e. something like sites-available and sites-enabled?

Contributor

TobiasBg commented Oct 21, 2014

How about copying the webserver approach for naming, i.e. something like sites-available and sites-enabled?

@aljafor

This comment has been minimized.

Show comment
Hide comment
@aljafor

aljafor commented Oct 21, 2014

+1

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Oct 21, 2014

Member

@TobiasBg the problem with that is the sites being enabled will be arbitrary paths, not just directory names. You can't (or shouldn't) have a file named www/acmeclient/example.com/config.

Member

westonruter commented Oct 21, 2014

@TobiasBg the problem with that is the sites being enabled will be arbitrary paths, not just directory names. You can't (or shouldn't) have a file named www/acmeclient/example.com/config.

@EHLOVader

This comment has been minimized.

Show comment
Hide comment
@EHLOVader

EHLOVader Nov 6, 2014

Contributor

+1 but I have noted that there seems to be a lot of repeated work done when vagrant up or provision are run.

Would it be possible to only run the init.sh for unprovisioned sites or ones which changed? unless otherwise requested.

Contributor

EHLOVader commented Nov 6, 2014

+1 but I have noted that there seems to be a lot of repeated work done when vagrant up or provision are run.

Would it be possible to only run the init.sh for unprovisioned sites or ones which changed? unless otherwise requested.

@jeremyfelt jeremyfelt added this to the 1.3 Release milestone Nov 13, 2014

@joeguilmette

This comment has been minimized.

Show comment
Hide comment
@joeguilmette

joeguilmette Nov 20, 2014

Any way I can help move this feature along? I'd also really love to be able to toggle the default sites on and off, hopefully before an initial vagrant up. It really grinds my gears having the default sites in there as they are now. They really should be provisioned by auto-site-setup like any other project you'd add.

joeguilmette commented Nov 20, 2014

Any way I can help move this feature along? I'd also really love to be able to toggle the default sites on and off, hopefully before an initial vagrant up. It really grinds my gears having the default sites in there as they are now. They really should be provisioned by auto-site-setup like any other project you'd add.

@tnorthcutt

This comment has been minimized.

Show comment
Hide comment
@tnorthcutt

tnorthcutt Nov 20, 2014

Contributor

@joeguilmette feel free to chip in with a PR for this feature request. After evaluating it and trying a couple of angles, I've decided it's beyond my abilities/time for now.

Contributor

tnorthcutt commented Nov 20, 2014

@joeguilmette feel free to chip in with a PR for this feature request. After evaluating it and trying a couple of angles, I've decided it's beyond my abilities/time for now.

@joeguilmette

This comment has been minimized.

Show comment
Hide comment
@joeguilmette

joeguilmette Nov 21, 2014

Just shooting from the hip, but what about moving the entire root folder
from vvv/www/ to vvv/disabled-sites/

Then we'd just need some way to tell VVV not to load the db for sites in
that folder, right?

Another change I'd like to see is making the default WP installs optional.
That might take some work but I'm willing to do it in the near future.

On Thu Nov 20 2014 at 9:48:09 PM Travis Northcutt notifications@github.com
wrote:

@joeguilmette https://github.com/joeguilmette feel free to chip in with
a PR for this feature request. After evaluating it and trying a couple of
angles, I've decided it's beyond my abilities/time for now.


Reply to this email directly or view it on GitHub
#474 (comment)
.

joeguilmette commented Nov 21, 2014

Just shooting from the hip, but what about moving the entire root folder
from vvv/www/ to vvv/disabled-sites/

Then we'd just need some way to tell VVV not to load the db for sites in
that folder, right?

Another change I'd like to see is making the default WP installs optional.
That might take some work but I'm willing to do it in the near future.

On Thu Nov 20 2014 at 9:48:09 PM Travis Northcutt notifications@github.com
wrote:

@joeguilmette https://github.com/joeguilmette feel free to chip in with
a PR for this feature request. After evaluating it and trying a couple of
angles, I've decided it's beyond my abilities/time for now.


Reply to this email directly or view it on GitHub
#474 (comment)
.

@EHLOVader

This comment has been minimized.

Show comment
Hide comment
@EHLOVader

EHLOVader Nov 21, 2014

Contributor

If you really wanted to archive the sites like that, you could keep a sibling folder named archive in the vvv/ and move sites from www to archive.

Possibly even better would be to symlink from a sites folder into www as you are working on them.

Contributor

EHLOVader commented Nov 21, 2014

If you really wanted to archive the sites like that, you could keep a sibling folder named archive in the vvv/ and move sites from www to archive.

Possibly even better would be to symlink from a sites folder into www as you are working on them.

@jeremyfelt jeremyfelt modified the milestones: Next Release, Future Release Jul 20, 2015

@jeremyfelt jeremyfelt removed this from the Future Release milestone Aug 16, 2016

@jeremyfelt jeremyfelt removed this from the Future Release milestone Aug 16, 2016

@LoreleiAurora LoreleiAurora referenced this issue Aug 23, 2016

Merged

Split provisioners into external git repos #980

8 of 8 tasks complete

@jeremyfelt jeremyfelt added this to the 1.5.0 milestone Nov 4, 2016

@jeremyfelt

This comment has been minimized.

Show comment
Hide comment
@jeremyfelt

jeremyfelt Nov 4, 2016

Member

It is now possible to selectively enable and disable sites through a YAML config file after the merge of #980. 🎉

Member

jeremyfelt commented Nov 4, 2016

It is now possible to selectively enable and disable sites through a YAML config file after the merge of #980. 🎉

@jeremyfelt jeremyfelt closed this Nov 4, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment