A bunch of stuff for the Travis CI

stecman / symfony-console-completion

Automatic tab-key completion for Symfony console application options, arguments and parameters

MIT License

421 stars 26 forks source link

A bunch of stuff for the Travis CI #34

Closed duncan3dc closed 9 years ago

duncan3dc commented 9 years ago

General tidy up to make each section readable and follow standard community practices.
Have travis run the unit tests (using phpunit)
Use composer update as well as composer install as the lock file is irrelevant for users, they'll be using the latest supported dependencies (from composer.json)
Also test against the lowest supported dependencies (from composer.json)
Added testing on the latest supported php version (5.6) and the upcoming release (7.0)

Doing all this uncovered an issue in the dependencies, where it was stated the phpunit 4.1 was required, when actually 4.4 is required. so I've bumped that requirement in composer.json

stecman commented 9 years ago

Thanks, @duncan3dc. I'm not sure about triggering 15 builds though - seems a bit excessive. What do you think about just running update and update --prefer-lowest, or maybe only running --prefer-lowest for one PHP version (so six builds)?

duncan3dc commented 9 years ago

@stecman Yeh, I'm against having composer.lock in the repo generally, I only left the composer install because you had it. Shall I remove composer.lock as well?

I think you need --prefer-lowest on every supported version though, or else you are not testing all your supported versions. So that would be 10 builds

aik099 commented 9 years ago

I'm for composer.lock being committed because it explicitly allows for library developers to work using same dependency versions.

The COMPOSER_OPTS is a bit too much. Nobody really does that. In dependency testing the only needed stuff is:

test against latest stable versions
test against latest unstable versions

In general you can restrict matrix by checking all these unusual combinations for a single php version only.

duncan3dc commented 9 years ago

I'm not sure 'Nobody really does that' is a relevant argument. By adding in this check an issue with the dependencies was actually found. If that doesn't state the value of this then I'm not sure what else could

duncan3dc commented 9 years ago

I've removed the composer install commands and the composer.lock file now.

aik099 commented 9 years ago

My apologies for not backing up my Nobody really does that argument. Can you please reference well known packages/repos that use proposed Travis CI techniques.

Also it would be interesting to see these standard community practices explained somewhere in more detail, e.g. on Travis CI website or another as solid location.

duncan3dc commented 9 years ago

@aik099 I don't care who else does it, what I care about is that using that technique has located a dependency issue. So what reason do you have to not use that that technique to detect issues in the future?

It's a relatively new composer feature, so I don't expect it to have widespread usage yet anyway.

aik099 commented 9 years ago

I don't care who else does it

If you don't care, then please don't use standard community practices terms and such without backing up your words.

It's a relatively new composer feature, so I don't expect it to have widespread usage yet anyway.

This was Google says about --prefer-lowest: http://evertpot.com/testing-composer-prefer-lowest/

Also:

please restrict usage of --prefer-lowest to only PHP 5.4 to dramatically decrease total build count
adding another option to fail build if it fails on one of PHP version would also be useful

duncan3dc commented 9 years ago

@aik099 What's your point with that google link? It just seems to back me up so I'm not sure why you are posting it without comment.

standard community practices referred to sequencing the php versions in lowest to highest, and putting things under before_install, install, script, etc.

duncan3dc commented 9 years ago

@stecman Are you in agreement with @aik099? He seems to be speaking like a project collaborator here. If so I'll close this PR and be on my way. I was only trying to help you catch potential issues in your project as a thank you.

aik099 commented 9 years ago

I'm posting a link so that anybody else stumbling on this issue in future won't need to find relevant info by himself.

I'm ok with improving Travis CI build, but I believe, that some work is still required on that .travis.yml file before it can be merged.

stecman commented 9 years ago

I'd probably opt for doing something like what symfony/symfony does. Technically yes it's not testing all supported combinations, but testing all combinations feels like testing that the dependencies work with the PHP versions they claim to, more than testing the code in this library.