Default community health files for all repositories in this organisation.

• CODE_OF_CONDUCT
• FUNDING
• SECURITY

Individual repositories can overrule the default files by committing their own version of one or more of these files to the repository in question.
Keep in mind that doing so is discouraged in this organisation.

Additional community health files may be added over time and/or when GitHub adds support for them.

Aside from the community health files, this repository also offers a number of (mostly) configuration file driven re-usable GitHub Actions workflows.

What is meant by "configuration file driven", is that these workflows, by default, will silently bow out and not execute any checks.

Only if a specific configuration file is encountered in the root directory of the repository calling the reusable workflow, will the workflow execute the checks it is supposed to run.

This setup allows for (other) re-usable workflows to safely reference these workflows without immediately breaking CI builds for "end-user" repositories if the end-user repository does not comply with the rules in a new CI check (yet).

It also means that, as the configuration for each tool is always in a committed file in the "user" repository, it will be relatively straight-forward for contributors to run checks locally with the same configuration as used in CI.

The following re-usable workflows are available:

• reusable-markdownlint.yml which runs a (code-style) linter for Markdown/CommonMark files.
  Requires: a .markdownlint-cli2.yml or .markdownlint-cli2.yaml configuration file in the project root.
• reusable-phpstan.yml which runs the PHPStan tool.
  Requires: a phpstan.neon.dist or phpstan.neon configuration file in the project root.
  Inputs:
  • phpVersion: Optional. The PHP version to use. Defaults to 'latest'.
  • phpstanVersion: Optional. The PHPStan version to use. Defaults to the latest available version.
• reusable-remark.yml which runs a different linter for Markdown files which typically runs more QA-style checks, like checking for broken links.
  Requires: a .remarkrc configuration file in the project root.
  Optionally, a project can also include a .remarkignore file in the project root. This file will be respected, but has no influence on whether the tool will run.
  Inputs:
  • fail-on-warnings: Optional. Whether to exit as failed when there are warnings. Defaults to "true".
• reusable-yamllint.yml which runs two linters for Yaml files.
  1. yamllint which checks all YAML files for syntax validity, code style and runs some QA checks too.
     Requires: a .yamllint.yml or .yamllint.yaml configuration file in the project root.
     Inputs:
     • strict: Optional. Whether to enable strict mode. Defaults to "false".
  2. actionlint which runs a static analysis check on GitHub Actions workflow files only. Note: this check does not have a configuration file requirement.
• reusable-findtokenprops.yml to find any uses of the PHPCS static Tokens::$groupName properties.
  These properties have been (soft) deprecated since PHP_CodeSniffer 4.0.0 and should no longer be used in code bases which have dropped support for PHP_CodeSniffer 3.x.
  Note: this check does not have a configuration file requirement.

Example configuration files for most of these can be found in the root directory of this repository.

While it may be uncommon for a .github repository to contain tags, the tags are to allow workflows in repositories which use the above mentioned re-usable workflows to "pin" to a specific version of a workflow in a way that Dependabot can still update them.

This has two benefits:

1. Stability
   A change in the re-usable workflow itself, or in an action runner used by a re-usable workflow, can "break" builds.
   For example, an update of the DavidAnson/markdownlint-cli2-action action runner in the reusable-markdownlint workflow, may contain a newer version of the markdownlint tooling, which may contain new rules which could fail builds in repositories using the workflow.
   Pinning and letting Dependabot update these pins prevents these type of "unmanaged" CI breaks.
2. Security
   With commit-hash pinned workflows, the dependencies used are fixed to specific versions and updates are managed, which means that it is more difficult for an attacker to be able to infiltrate the workflow runs and get access to secrets and/or cause other havoc.