* Run tests in random order
Being able to run tests in any order is a pre-requisite for being able
to run them in parallel.
* Reset type coverage between tests, fix affected tests
* Reset parser and lexer between test runs and on php version change
Previously lexer was reset, but parser kept the reference to the old
one, and reference to the parser was kept by StatementsProvider. This
resulted in order-dependent tests - if the parser was first initialized
with phpVersion set to 7.4 then arrow functions worked fine, but were
failing when the parser was initially constructed with settings for 7.3
This can be demonstrated on current master by upgrading to
nikic/php-parser:4.9 and running:
```
vendor/bin/phpunit --no-coverage --filter="inferredArgArrowFunction" tests/ClosureTest.php
```
Now all tests using PHP 7.4 features must set the PHP version
accordingly.
* Marked more tests using 7.4 syntax
* Reset newline-between-annotation flag between tests
* Resolve real paths before passing them to checkPaths
When checkPaths is called from psalm.php the paths are resolved, so we
just mimicking SUT behaviour here.
* Restore newline-between-annotations in DocCommentTest
* Tweak Appveyor caches
* Tweak TravisCI caches
* Tweak CircleCI caches
* Run tests in parallel
Use `vendor/bin/paratest` instead of `vendor/bin/phpunit`
* Use default paratest runner on Windows
WrapperRunner is not supported on Windows.
* TRAVIS_TAG could be empty
* Restore appveyor conditional caching
* Test against `roave/you-are-using-it-wrong`
* Added CI step to ensure BC of declared API
* Added step to ensure `composer.json` has all used deps
* Including CI check tools as dev dependencies
* Typo fix: s/backwards/backward
* Run `roave/backward-compatibility-check` off an isolated location with no other dependencies
* Run `test-with-real-projects` task with PHP 7.4 as base runtime
* Run `testing-with-real-projects` also against `ocramius/proxy-manager`
`ocramius/proxy-manager` is an extremely heavy `vimeo/psalm` consumer,
and relies on a lot of the templated types system to generate real
types for proxies produced by runtime evaluation.
Potentially useful for fork owners to test out phar deployment without affecting
the official psalm/phar repo.
To enable phar deployments from your own fork of psalm:
- Enable builds with Travis
- Create a github repository to hold recieve the built phar packages
- Create a new dedicated github user for the deployments
- From your main github account, invite the new user to collobrate on the phar repository
- From the new user's account, accept the invitation
- From the new user's account, obtain a 'new personal access token' ( https://github.com/settings/tokens/new ) with repo scope
- In travis settings for your fork of psalm, set two environment
variables:
- PHAR_REPO_SLUG - this should be the name the phar repo you set up earlier, e.g. fred/phar
- GITHUB_TOKEN - This is the personal access token of the new user you obtained above. Anyone who knows this token
can push to the repository, so keep it secret. Make sure 'Display value in build log' is
switched off'
Now any push to branches in your fork of psalm, should automatically
result in a commit containing the phar file in your phar repository.
- Phar signing moved to build-phar.sh (conditional on gpg keys
availability)
- Tagged phar releases moved to travis-deploy-phar.sh
- `travis-deploy-phar.sh` is now triggered via `script` deploy provider
Deployment to `psalm/phar` repo is possible only when travis runs on the
main `vimeo/psalm` repository people, so only attempt to deploy there
when `$GITHUB_TOKEN` is available.
