@@ -4,6 +4,35 @@ order: 3
44---
55# PIE Maintainers Handbook
66
7+ Thank you for taking an interest in contributing to PIE. This guide is written to help humans develop on PIE.
8+
9+ ## Contributing to PIE
10+
11+ ## Reporting bugs
12+
13+ If you think you have a bug, please [ open an issue] ( https://github.com/php/pie/issues ) , and include:
14+
15+ - What platform and PIE version you're using
16+ - A summary of:
17+ - What are you trying to do?
18+ - What do you expect to happen?
19+ - What is actually happening?
20+ - The steps to reproduce the issue - please use the ` -v ` verbose flag (or higher)
21+ - Complete error messages and/or logs, including stack traces (hint: use ` -v ` for verbose), but please redact sensitive information
22+
23+ ## Submitting PRs
24+
25+ Please ** do not** just submit PRs for features or ideas without discussing them first. ** Start by
26+ [ creating a discussion] ( https://github.com/php/pie/discussions ) first** if there is not already an open discussion or
27+ issue. If there is already an open discussion or issue, please comment and wait for feedback before starting any work.
28+ This is because the work may already be in progress or being investigated already. The PIE project is actively being
29+ developed, and many features are already in discussion or being developed, so if you do not discuss with us first, you
30+ may be duplicating work already in progress.
31+
32+ > [ !TIP]
33+ > We try to stay on top of issues already being worked on with the ` maintainer investigating ` purple label. If you see
34+ > this on an issue, it is very likely we are already looking into this.
35+
736## Branching strategy
837
938Since 1.3.0, we operate a branch per minor release, with an ` x ` for the patch
@@ -22,6 +51,129 @@ Bugfixes/patches should be based on the oldest supported or desired patch
2251version. For example, if a bug affects the 1.3 series, a PR should be made
2352from the feature branch to the ` 1.3.x ` branch.
2453
54+ ## Developing on PIE
55+
56+ > [ !IMPORTANT]
57+ > Please read the above section BEFORE doing work on PIE; PIE is in very active development by the PHP Foundation, and
58+ > many features/issues are already being worked on.
59+
60+ All the below tests are run in CI, on various versions of PHP, to ensure they do not get missed! However, when
61+ developing on PIE, you will likely need to run some, or all, of these tests by hand.
62+
63+ > [ !TIP]
64+ > The development guide is primarily aimed at Linux systems, please adjust accordingly for your own platform.
65+
66+ ### Unit & Integration Tests
67+
68+ > [ !CAUTION]
69+ > The integration test suite interacts directly with the PHP installation that is used to run the tests. This may
70+ > result in the ` asgrim/example-pie-extension ` extension being added (sometimes in a broken state) to your PHP install.
71+ > Do not run this using a PHP installation that you care about!
72+
73+ We use PHPUnit, which is installed with Composer, and can be run with:
74+
75+ ``` shell
76+ sudo vendor/bin/phpunit
77+ ```
78+
79+ If you have multiple versions of PHP, you may add that in, e.g.:
80+
81+ ``` shell
82+ sudo /usr/bin/php8.3 vendor/bin/phpunit
83+ ```
84+
85+ > [ !TIP]
86+ > ` sudo ` ** is** required due to the way some of the tests interact with ` sudo `
87+
88+ Coverage HTML report can be generated with:
89+
90+ ``` shell
91+ sudo XDEBUG_MODE=coverage vendor/bin/phpunit --coverage-html coverage
92+ ```
93+
94+ ### Behaviour Testing
95+
96+ The primary features are documented in ` features/*.feature ` , in [ Gherkin] ( https://cucumber.io/docs/gherkin/ ) format.
97+
98+ Some of these features are implemented as behaviour tests, using [ Behat] ( https://behat.org/ ) . However, these tests
99+ should NOT be run on your machine directly. Instead, there is a predefined and controlled environment made with Docker.
100+ This is done because many of the tests require specific dependencies, and this helps provide a repeatable test harness.
101+
102+ This can be run in two steps; first build the Docker container:
103+
104+ ``` shell
105+ GITHUB_TOKEN=$( composer config --global --auth github-oauth.github.com) docker buildx build --file .github/pie-behaviour-tests/Dockerfile --secret id=GITHUB_TOKEN,env=GITHUB_TOKEN -t pie-behat-test .
106+ ```
107+
108+ Optionally, pass the ` --build-arg PHP_VERSION=8.3 ` parameter to the above command to change the version of PHP used in
109+ the test. Then you may run the tests with:
110+
111+ ``` shell
112+ docker run --volume .:/github/workspace -ti pie-behat-test
113+ ```
114+
115+ ### End-to-end Testing
116+
117+ We have a small number of end-to-end type tests, that are designed to ensure PIE runs in particular ways in different
118+ systems. The test runner is a shell script that builds a Docker target, and runs it; and fails if a non-zero exit
119+ occurs.
120+
121+ ``` shell
122+ test/end-to-end/dockerfile-e2e-test.sh
123+ ```
124+
125+ This is particularly useful for testing different setups (e.g. Alpine, Ubuntu, Fedora, Brew, etc.) and ensuring build
126+ tools and system dependencies are automatically installed.
127+
128+ ### Static Analysis
129+
130+ We use [ PHPStan] ( https://phpstan.org/ ) and several plugins to run static analysis on the codebase. You can run this:
131+
132+ ``` shell
133+ vendor/bin/phpstan
134+ ```
135+
136+ ### Coding Standards
137+
138+ We use [ PHP_CodeSniffer] ( https://github.com/PHPCSStandards/PHP_CodeSniffer/ ) using the
139+ [ Doctrine Coding Standard] ( https://github.com/doctrine/coding-standard ) to check and automatically fix CS issues.
140+
141+ To check the CS conformity:
142+
143+ ``` shell
144+ vendor/bin/phpcs
145+ ```
146+
147+ To attempt to auto-apply CS fixes:
148+
149+ ``` shell
150+ vendor/bin/phpcbf
151+ ```
152+
153+ ### Mutation Testing
154+
155+ Install the ` infection.phar ` according to the [ Infection PHP documentation] ( https://infection.github.io/guide/installation.html#Phar ) .
156+
157+ Tests can be run with:
158+
159+ ``` shell
160+ sudo infection --min-msi=68 --min-covered-msi=68 --threads=max
161+ ```
162+
163+ > [ !TIP]
164+ > As with the tests, ` sudo ` is required due to the way some of the tests interact with ` sudo `
165+
166+ ### Documentation
167+
168+ Documentation can be generated with:
169+
170+ ``` shell
171+ .github/docs/build-docs.sh
172+ ```
173+
174+ This is not normally needed, unless you are changing the template, as CI will generate the documentation and publish to
175+ the GitHub Page.
176+
25177## Release process
26178
27179Make sure you have the latest version of the trunk to be released, for example,
0 commit comments