* Qual: ci: Run pre-commit/php-cs with cache (#28079)
This adds a hook to .pre-commit-config.yaml and updates the workflow
to run php-cs with cache when it is run for all files.
When running on changed files only, the cache is not useful.
The php-codesniffer ruleset.xml was cleaned up (duplicates removal/formatted)
* Fix: Make all 'relative paths' absolute (#28196)
# Fix: Make all 'relative paths' absolute
The phpcs ruleset xml file's relative exclude patterns are relative to
the filename(s) provided on the command line.
Hence with partial verifications, the path exclusion does not function
as we would like.
Removing the relative-path attribute from the patterns the exclusion
works.
At the same time, the patterns were optimized and a comment was added.
* Qual: Optimize workflow (#28386)
# Qual: Optimize workflow
The log annotation based on the pre-commit logs is now simplified.
* Qual: Lower severity on php-cs messages that should not block (#28072)
# Qual: Lower severity on php-cs messages that should not block
Some warning messages result in php-cs having an exit code of 2 and others
only have an exit ocde of 1. When the exit code is 2, the warnings are fixable
by php-cbf.
In order to be able to filter on the warnings in the github ci flow, but still
show them in the travis flow, I lower the level of the warnings that should not
be blocking to 4.
At the same time, the php-cs configuration in pre-commit now requires that the
severity is minimum 5 to show the message (level 5 is the default for all warnings
and errors).
So this will limit the warning messages to the ones that should result in a failing
ci action. If any new cases are discovered, they should also be lowered in the
php-cs configuration file.
* Qual: ci: Run pre-commit/php-cs with cache (#28079)
This adds a hook to .pre-commit-config.yaml and updates the workflow
to run php-cs with cache when it is run for all files.
When running on changed files only, the cache is not useful.
The php-codesniffer ruleset.xml was cleaned up (duplicates removal/formatted)
This change to the workflow will run phpcs on all files in develop,
17.0, 18.0, ... (rule== branch ends in .0).
This ensures that phpcs is run in a github workflow for fast phpcs
issue detection in the develop and other main branches.
Ultimately, this means that the PHPCS action can be disabled
in branches where it is active. But I propose to verify that
the updated action does the job as expected (tested in a fork
it is ok).
Backport the pre-commit tool to bring extra checks to the older versions
so that they are fixed earlier before merging in upper versions.
Other PRs will be created for backporting to 18.0 and 19.0.
The PRs should be accepted in reverse order:
- develop;
- 19.0:
- 18.0;
- 17.0.
That should avoid merge conflicts and ensure that options (and ignored
messages or steps) are adapted to the version branch.
* Qual: Backport pre-commit to 17.0
Backport the pre-commit tool to bring extra checks to the older versions
so that they are fixed earlier before merging in upper versions.
Other PRs will be created for backporting to 18.0 and 19.0.
The PRs should be accepted in reverse order:
- develop;
- 19.0:
- 18.0;
- 17.0.
That should avoid merge conflicts and ensure that options (and ignored
messages or steps) are adapted to the version branch.
* Qual: Backport pre-commit to 18.0
# Qual: Backport pre-commit to 18.0
Backport the pre-commit tool to bring extra checks to the older versions
so that they are fixed earlier before merging in upper versions.
Other PRs will be created for backporting to 18.0 and 19.0.
The PRs should be accepted in reverse order:
- develop;
- 19.0:
- 18.0;
- 17.0.
That should avoid merge conflicts and ensure that options (and ignored
messages or steps) are adapted to the version branch.
* Qual: Backport pre-commit to 19.0
# Qual: Backport pre-commit to 19.0
Backport the pre-commit tool to bring extra checks to the older versions
so that they are fixed earlier before merging in upper versions.
Other PRs will be created for backporting to 18.0 and 19.0.
The PRs should be accepted in reverse order:
- develop;
- 19.0:
- 18.0;
- 17.0.
That should avoid merge conflicts and ensure that options (and ignored
messages or steps) are adapted to the version branch.
