-
-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Inspired by PR #38 from @afilina
Problems identified
- A lot of the commands to be run by the command replacement script use the same CLI arguments (
--parallel=1 --no-cache --no-colors --report-width=100
), so it would be nice to inject these in some way via the script instead of having to repeat these in every inline command.
However, if the script would inject these into the command to be run, the command placed in the markdown would not be able to overrule any of these options. - The command replacement script can currently not be run by contributors using Windows.
Potential solution direction
Originally posted by @jrfnl in #38 (comment) - see the PR for more context.
I have a brain wave about how we can do this in a way to still allow overruling these settings from the markdown: update the default values for these settings ahead of running the
phpcs
/phpcbf
commands found in the markdown files.In practice, this would mean running the following commands:
phpcs --config-set report_width 100 phpcs --config-set colors 0 phpcs --config-set parallel 1 phpcs --config-set cache 0PHPCS will use those defaults from then on and the defaults can be overruled for individual commands by passing CLI args.
But there's a down-side to this: when contributors would run the script locally, running the above would mess with the settings for their global PHPCS install.
Now, we could, of course, use the
CI
environment variable to only run the above commands when running in the context of GH Actions, but then the output someone would generate locally may be different from what they see when the Wiki is deployed for real.The only way I can currently think of to make this work in a stable manner, both in CI as well as for contributors locally, would probably be as follows:
- Run
phpcs --config-show
- Parse the output of the command.
The first line of the output should look like this if the contributor has a config set up for their global install:
Using config file: path/to/CodeSniffer.conf
If the contributor has no config set up for their global install, it will look like so:
Using config file:
- Grab the path to the
CodeSniffer.conf
file.- Temporarily rename that file. (Not copy, as otherwise additional pre-existing defaults from the contributor may still screw things up).
- Run the commands I listed above. That will create a new
CodeSniffer.conf
file.- Run the script
- After all command replacement has finished, delete the "new"
CodeSniffer.conf
file and rename the originalCodeSniffer.conf
file back toCodeSniffer.conf
.This would, of course, need to take into account that step 6 may fail/error out, while step 7 should still be run if that's the case.
What do you think ? Is this doable ?
As this would make the script yet more complicated - and it is already unlikely that the current script works cross-OS (i.e. probably won't work on Windows), I wonder if it might make sense to use a PHP script to do the command replacement instead ?
There is no specific reason for the script to be in bash. The choice for bash was mostly from originally trying to get something running directly in the GH Actions workflow and then moving it out to a separate script to make it convenient for running it locally.