Data migrations for communities
Mastered the User Guide and Developer Guide and ready to help with core Nitro Porter work? Buckle up.
You’ll want to clone the repo and run composer install on it.
This will include the development dependencies you’ll need.
You can optionally copy phpstan.neon.dist and phpunit.xml.dist, removing the .dist from both,
to customize them as needed (without committing them — they are ignored by git).
composer lint runs linting (PHPCS) with the PSR12 standard.composer delint runs a fix for linting issues (PHPCBF). It does its best.composer stan runs static analysis (PHPStan) as defined in phpstan.neon.dist.Use composer test to run the unit test (PHPUnit) suite as defined in phpunit.xml.dist.
This project desperately needs integration tests that simulate an actual migration.
Faker & Phinx are available for this purpose (see composer phinx and composer seed),
but they are not implemented as of this writing.
You must use fix: and feat: prefixes on your commit messages for the changelog automation to work.
Please use thoughtful, concise commit messages and make use of rebase & squash when preparing a pull request if you’re able.
Our unit of work is the commit, not the PR. It is therefore preferable to have multiple atomic commits than to squash an entire complex PR into 1 commit. If you don’t know what this means, that’s OK! You can contribute anyway and we’ll figure it out as we go.
Use composer changelog to run conventional-changelog, which will update the CHANGELOG.md.
We use semantic versioning.
If there are feat: commits since the last tag, it will assume a minor-point release.
Otherwise, it will assume a patch-level release.
Create a git tag in the form v0.0.0 to start a new release and finish the process on GitHub.
Ready-built ZIP files are distributed on GitHub with each release.
Build them with composer build, which triggers a Phing build in /build/current.
You will need to manually compress the generated folder into a ZIP.