Enhancement: Run phpstan on GitHub Actions

[localheinz]

This PR

• runs phpstan on GitHub Actions

Follows #27.

[localheinz]

By introducing a matrix strategy here, we can reference the resolved values using ${{ matrix.php-version }}.

Since we only run the static analysis for a single PHP version, it might seem that it does not make a lot of sense.

However, in my experience, it's quite useful, as we can reference the ${{ matrix.php-version }} in multiple places without having to hard-code the actual PHP version.

Also note how the matrix values are appended to the job name:

💁‍♂️ For reference, see:

• https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategy

[localheinz]

If we decide to run the static analysis on PHP 7.4, we only need to change the value here.

[localheinz]

In order to do something with the code, we need to check out the repository first.

💁‍♂️ For reference, see:

• https://github.com/actions/checkout

[localheinz]

We could use one of the PHP binaries that are natively available instead.

However, these are currently limited to:

• php (PHP 7.4.8)
• php7.1 (PHP 7.1.33)
• php7.2 (PHP 7.2.32)
• php7.3 (PHP 7.3.20)
• php7.4 (PHP 7.4.8)

Additionally, a lot of extensions are installed, but not all (!) of them.

Instead, a lot of people use shivammathur/setup-php to set up a wider (!) range of PHP versions, along with code coverage (if need be) and desired extensions.

Shivam Mathur does a great job in maintaining this action, and is very responsive.

💁‍♂️ For reference, see:

• https://github.com/shivammathur/setup-php

[localheinz]

Steps can have outputs - for example, it is possible to define output parameters (like here) or environment variables.

Here we determine the composer cache directory, instead of hard-coding it, so we can reference it later.

💁‍♂️ For reference, see:

• https://getcomposer.org/doc/06-config.md#cache-dir
• https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-environment-variable
• https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-output-parameter

[localheinz]

With actions/cache we can cache arbitrary directories or files between jobs.

💁‍♂️ For reference, see:

• https://github.com/actions/cache

[localheinz]

Here we pick up the output parameter again to specify a value for the path input parameter.

Notice how we use the step identifier determine-composer-cache-directory to reference the value of the directory output of the corresponding step.

💁‍♂️ For reference, see:

• https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsid
• https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions

[localheinz]

Here we specify a value for the key input parameter, the cache key to use for caching the contents of the composer cache directory.

Notice how we use the ${{ matrix.php-version }} expression which resolves to the corresponding value in the build matrix. Here it will resolve to 7.2.

Also, we use the hashfiles() function to calculate a hash from composer.json as part of the cache key.

💁‍♂️ For reference, see:

• https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix
• https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#hashfiles

[localheinz]

Using the with key, we can specify a map of parameter names to values that are accepted by an action.

💁‍♂️ For reference, see:

• https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepswith

[localheinz]

Here we can list one or more cache keys.

Note that the inputs for an action need to be strings. If we want to specify more items, we need to use a multi-line string:

diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml
index e7b00a0..07b7e54 100644
--- a/.github/workflows/build.yaml
+++ b/.github/workflows/build.yaml
@@ -38,7 +38,9 @@ jobs:
         with:
           path: ${{ steps.determine-composer-cache-directory.outputs.directory }}
           key: php-${{ matrix.php-version }}-composer-${{ hashFiles('composer.json') }}
-          restore-keys: php-${{ matrix.php-version }}-composer-
+          restore-keys: |
+            php-${{ matrix.php-version }}-composer-
+            foo-bar-baz

       - name: Install highest dependencies from composer.json
         run: composer install --no-interaction

Also note that the value for the key input is automatically used as a key, so here we only specify additional, optional keys (or prefixes).

💁‍♂️ For reference, see:

• https://docs.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#matching-a-cache-key

[localheinz]

As you can see, the configuration is indeed a bit verbose.

Unfortunately, GitHub Actions does not yet support YAML anchors and references - both would allow to reduce duplication.

💁‍♂️ For reference, see:

• https://github.heygears.community/t/support-for-yaml-anchors/16128

[nikolaposa]

GitHub Actions does not yet support YAML anchors and references

I was just about to ask how we gonna reuse steps such as installing Composer dependencies between jobs. If duplication is inevitable, would it make sense to go with the approach of configuration file per job, so for example: coding-standards.yml, static-analysis.yml, tests.yml, etc.?

[localheinz]

@nikolaposa

I was just about to ask how we gonna reuse steps such as installing Composer dependencies between jobs. If duplication is inevitable, would it make sense to go with the approach of configuration file per job, so for example: coding-standards.yml, static-analysis.yml, tests.yml, etc.?

That would be possible, but take note that there is no way to enforce dependencies between workflows.

On the other hand, it is possible to do so for jobs - that is, you can hold of running jobs in a workflow until other jobs have completed by using the needs directive.

Perhaps do so at a later time, when necessary?

💁‍♂️ For reference, see:

• https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds

[nikolaposa]

Perhaps do so at a later time, when necessary?

Agreed. 👍

[localheinz]

Thank you, @nikolaposa!