While trying out latest `main`, it became evident that CI is not really stable, in its current
state, because dependencies like `phpunit/phpunit`, `vimeo/psalm`, `phpstan/phpstan` and `squizlab/php_codesniffer`
keep shifting within the boundaries of `composer.json`.
In order to freeze them in place, `composer.lock` is introduced, so that they can be upgraded
individually, therefore preventing headaches when installing the project locally, for either
verifying a bug, or contributing to it.
This change is a bit of a shift from the previous approach, but should allow for better stability,
and better dependency upgrade/checking, so that @dependabot patches breaking CI can be identified
more easily.
* Run Psalm on src as well as Static Analysis Fixture
Psalm baselining feature is used to prevent immediate build failures -
psalm will just cause failures for errors caused by future changes to
the code.
See https://psalm.dev/docs/running_psalm/dealing_with_code_issues/#using-a-baseline-file
* Fix MixedArgument issues in OrderedTimeCodec
Potentially unpack should be documented as returning string[] instead of
array to make this unecassary.
* Fix Psalm PossiblyNullPropertyAssignmentValue issues
* Add psalm-immutable annotation to Uuid class
* Fix Psalm MixedArgument issues
* Fix MissingImmutableAnnotation psalm issue
* Fix Psalm MixedAssignment issue
* Fix Psalm InvalidReturnStatement / InvalidReturnType issue
* Add ImpureMethodCall issues to baseline.
Fixing these in one place just moves them somewhere else.
* Exclude psalm-baseline.xml from exported git archives
This covers most of the commonly used `Uuid` and `UuidInterface` API, and allows us
to pass around `UuidInterface` references as if they were pure.
Note that this only verifies the *contract* of a `UuidInterface`: it is still very
much possible to write mutable `UuidInterface` implementations (and `Uuid` itself
has such an edge-case, allowing for replacement of the static `UuidFactory` reference),
but if you really do mutate UUIDs at runtime, then your code is very much hurting your
project, and you should get rid of that detail.
The ramsey/uuid library has requirements to run on 32-bit and 64-bit
systems, as well as little-endian and big-endian systems. Travis CI only
provides hardware for testing 64-bit, little-endian CPU architectures,
but they recently announced support for Docker[^1].
After some research, I found it is possible to use [QEMU][] with
[chroot][] jails on Travis CI to emulate other CPU architectures and run
tests through these chroot jails[^2]. Unfortunately, it takes an awful
long time to set up a chroot jail, build PHP within it, and run the
tests. It wasn't reasonable to expect to do this on every single push to
the ramsey/uuid repository. This is where Docker comes in.
I was able to create chroot jails for each architecture and version of
PHP combination I need to test and then turn these into Docker images,
which Travis is able to download and run fairly quickly. The instances
on which Travis CI is running their Docker services do not currently
support phpenv or php-build, so I needed to masquerade as a Python
project and specify all PHP versions and CPU architectures in
environment variables in my `.travis.yml` configuration. I run
`composer install` and report to Coveralls outside of the Docker images,
but all tests are run within the Docker images.
The Docker image I created for PHP 7.0.0RC4 on MIPS architecture
produces segfaults when attempting to build PHP with Phar. PHP builds
okay without Phar, but then it produces segfaults when running any PHP
script on the image, so I'm leaving out 7.0.0RC4 on MIPS for now.
The Docker images for use with ramsey/uuid tests are available here:
<https://hub.docker.com/r/benramsey/ramsey-uuid/>.
[^1]: "Using Docker on Travis
CI," <http://blog.travis-ci.com/2015-08-19-using-docker-on-travis-ci/>
[^2]: "Running Travis CI tests on ARM architecture,"
<https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html>
[qemu]: http://wiki.qemu.org/Main_Page
[chroot]: https://en.wikipedia.org/wiki/Chroot