* 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.
Previous versions failed. This will delete all files except hidden files. The only hidden files that we expect to exist at present are the .git directory and .gitignore
Previously a user of the phar distribution would have to invoke psalm as
`vendor/bin/psalm.phar`. This is different to the command given in
the psalm documentation, `vendor/bin/psalm`
I also copied all files from the psalm/phar repo into
assets/psalm-phar, so that development can be concentrated in this repo.
The travis-deploy-phar.sh should copy any changes made back into the
psalm/phar.git repo.
- 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
- Run phpcs once, not on every row of build matrix
- Start coverage builds only when regular test builds succeed
- Always build phar (to see if it builds)
- Automatically deploy psalm.phar on tag builds (no more missing phars)
Also fixesvimeo/psalm#921
This is a compact output format that is easy to write scripts that parse.
(And errors fit on a single line)
- E.g. jenkins violation plugin works reliably with pylint.
The multi-line details are deliberately omitted.
An application can output 'console' to stdout and to
a pylint file at the same time.
Files with the extension .pylint will use this format.
Document the emacs and pylint output formats in `psalm --help`
An optional followup task would be to create unique issue codes,
I don't have any use cases for that.
