Fix the installer when running in Vagrant #278
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## develop #278 +/- ##
==========================================
Coverage 94.26% 94.26%
Complexity 336 336
==========================================
Files 47 47
Lines 855 855
==========================================
Hits 806 806
Misses 49 49 Continue to review full report at Codecov.
|
dshoreman
force-pushed
the
installer-fixup
branch
from
b150a00
to
dff15ad
Compare
The project folder was originally configured to use 998 as the user and primary group IDs in ceb733c, where 998 is the ID of the servidor user/group... or was on my machine. Turns out, that's not always the case--in #274 the servidor user got a different UID/GID, resulting in a failed install due to permissions. We can't set the owner/group to `servidor` until it exists, so this adds an inline shell provisioner specifically for creating the user. To run that before the installer though, we need a 3-step process. The first is `vagrant up` because you can't `vagrant provision` before the VM is created. Although `up` will fail to mount shares, we can then provision the user before restarting the VM (to get shares back) to run install. The process is long-winded and composer *still* has permission issues, but this at least solves the race condition with the servidor user.
Due to a bug in Virtualbox, there is a race condition when using vboxsf for the synced folders where Composer extracts and deletes files faster than Virtualbox can keep them in sync. Adding the `--perfer-source` option to composer will stop it using the compressed distribution packages to avoid the extract/delete issue. Also adds a separate ./storage mount with the www-data group to fix an issue with writing the Laravel error log. **Related:** * https://www.virtualbox.org/ticket/18776 * laravel/homestead#1240 (comment)
Turns out running composer with --prefer-source is slooooooow. we're talking like... 30 minutes slow. It's normally done in less than two. This adds a check in the makefile to see if we have composer available, and if so we'll run it before creating the Vagrant VM which will cut out much of the process when it comes to composer install in the installer. No need to make any changes in the installer itself as composer is smart enough that it will only install any packages if they're different to what was already installed 5 minutes previous. That's only likely to happen if someone has a custom composer config that changes things.
dshoreman
force-pushed
the
installer-fixup
branch
from
dff15ad
to
6ce750f
Compare
Since we're already installing composer packages during env setup, we may as well install npm dependencies and compile the frontend assets too. While we're at it, the readme also gets a bit of an overhaul.
dshoreman
force-pushed
the
installer-fixup
branch
2 times, most recently
from
af4b4d1
to
9ec2c96
Compare
The version of `sed` available on OSX is an outdated piece of garbage,
like most system utilities in the apple world. It doesn't like the
`{/.../,+1d}` expression to "find this line and delete it and the one
after", but since the lines in question are the ones that include the
install scripts, we kinda *need* to remove them.
Ironic that fixing this the easy way would create an Infinite Loop...
I'm not about to turn the sed command into something 20 lines long just
to satisfy OSX, so instead we check for gnu-sed before falling back to
sed-proper. If it turns out we're using `sed` and uname == Darwin, that
means they didn't brew install gnu-sed and thus we abort compilation.
dshoreman
force-pushed
the
installer-fixup
branch
from
9ec2c96
to
b8206fc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This splits the Vagrant provisioning into a 3-step process to solve the issue with the servidor user needing to be created since we can't rely on IDs. When we're running in Vagrant, the installer will now skip user creation, leaving it to the
userprovisioner.Issues with composer install are caused by a race condition due to a bug in Virtualbox, so to fix that we add the
--prefer-sourceflag. That's incredibly slow though, so we also check for the existence of composer on the host and run it locally if possible via a newdev-envmake target that will nuke all caches etc before reconstructing the whole environment.Fixes #274