Composer lock #79
Composer lock #79
Conversation
| - if [[ $DEPS == 'latest' ]]; then travis_retry composer update $COMPOSER_ARGS ; fi | ||
| - if [[ $DEPS == 'lowest' ]]; then travis_retry composer update --prefer-lowest --prefer-stable $COMPOSER_ARGS ; fi | ||
| - if [[ $TEST_COVERAGE == 'true' ]]; then travis_retry composer require --dev $COMPOSER_ARGS satooshi/php-coveralls ; fi | ||
| - travis_retry composer install $COMPOSER_ARGS |
There was a problem hiding this comment.
I'm a bit confused by the fact that we have this after the update commands. While I can see that it runs fine on Travis, it's confusing.
What's the rationale for doing an install after an update? Shouldn't it be the other way around?
There was a problem hiding this comment.
That is intended as a "catch-all" scenario: the updates are only executed in special cases, and executing an install right after an update is basically a no-op. Since every line of the install block represents a different build environment, I preferred to not enclose this one in a conditional block to make it stand out as the lowest common denominator.
There was a problem hiding this comment.
@stefanotorresi then maybe add --lock to composer update to just update lock file if install is called in all scenarious?
There was a problem hiding this comment.
@svycka good call! I forgot about that option!
There was a problem hiding this comment.
@svycka apparently --lock doesn't play well with --prefer-lowest, so I'm gonna have to revert that.
stefanotorresi
force-pushed
the
composer-lock
branch
from
e8b0e82
to
71494f7
Compare
|
@stefanotorresi It looked like you were still working on this when I was prepping the 2.7 release, so I didn't get it in. That said, I'm trying the approach with zend-test right now, and it's working brilliantly, so I'm definitely in favor! My only concern is the proliferation of test jobs; since Travis only allows 5 in parallel at any given time, this means the tests require at least two passes by Travis before completion. However, it ensures that code that purports to support multiple versions truly supports them, so it's a reasonable tradeoff in my opinion. |
stefanotorresi
force-pushed
the
composer-lock
branch
from
71494f7
to
f145ac8
Compare
fix travis lowest deps build and show installed packages fix travis coverage upload and lowest deps env fix travis global env directive fix travis lowest deps build tidy .travis.yml up
stefanotorresi
force-pushed
the
composer-lock
branch
from
f145ac8
to
9691170
Compare
|
@weierophinney rebased against latest develop to include the docs deploy steps. I've made some slight changes to those too, so please make sure they still work. :) |
|
on a side note, if we really wanted to reduce the jobs, maybe testing with lowest and latest deps on both 5.5 and 5.6 is not that useful, so we could get rid of 2 jobs, but I'm not sure it would do any good, because there would still be more than 5 jobs. |
resubmit of #63 targeting
developbranch.@weierophinney it worked like a charm :) the
DEPS=lowestenv does exactly what was being done with the package env vars, only now it looks simpler because it comes down to how the deps are defined incomposer.json, rather than overriding each one of them in.travis.yml.The PHPUnit requirement needed to be bumped up to
^4.5because one of the tests was using a Prophecy method, which has been introduced with that version.Let me know if you're satisfied and I'll proceed applying the same changes to all the components.