* Split unit test over multiple jobs in GitHub Actions, lowering the total run time
* rename FileManipulationTest to FileManipulationTestCase so it does not run as a standalone Test
* 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.