Closed dstepe closed 4 years ago
We could try. It will make every build way slower, but if it doesn’t crash, I’m ok with it.
I think this is sorted out now. The composer.lock
file previously included laravel/framework
version 5.5. I'm still not quite sure what caused that to be included, but it was not installed with a fresh start. That led to a number of test failures because Laravel framework features (like app()
) were not bootstrapped. That issue was resolved by requiring the orchestra/testbench
dependency which helps get the Laravel framework running during tests. There were a couple of tests to fix as a result of various updates, but overall, it was straightforward.
I took this opportunity to bump the required Laravel components to a minimum of 6 and a maximum of 8. Version 6 is what you will get for development right now. (More on that with a later PR.)
I restored the supported versions and will work on a new PR.
You mentioned a concern with the jobs being slower without the composer.lock
file. What are your goals for the CI jobs? I ask because this relates to what I want to suggest next.
You mentioned a concern with the jobs being slower without the
composer.lock
file. What are your goals for the CI jobs? I ask because this relates to what I want to suggest next.
It's not a big deal for a small project like this one, but without a composer.lock
file, now Composer takes around 45s on every job to decide which dependencies to install, while it was 0 before. We are talking about 2 extra minutes to run all CI jobs.
I think it's fine, considering how annoying is to deal with conflicts in the lock file and Composer updating all dependencies when you just want to update one...
I've run into composer memory issues in the past and using COMPOSER_MEMORY_LIMIT generally solves the issue. I've not used CircleCI much, but this looks like it might work. Now to see how the build runs.