From a955768ebcbfaa13b4359f9f129985a33fd9a3c9 Mon Sep 17 00:00:00 2001 From: Philipp Bammes Date: Thu, 5 Sep 2024 08:48:58 +0200 Subject: [PATCH] docs: align line lengths and quotes --- README.md | 4 +-- docs/archive-creation.md | 30 +++++++++++---------- docs/assets-compilation.md | 7 ++--- docs/automatic-release.md | 23 ++++++++-------- docs/build-and-push-assets.md | 51 ++++++++++++++++++++--------------- docs/ddev-playwright.md | 49 +++++++++++++++++++-------------- docs/js.md | 6 ++--- docs/php.md | 10 +++---- docs/wp-scripts.md | 9 ++++--- 9 files changed, 106 insertions(+), 83 deletions(-) diff --git a/README.md b/README.md index c67c7ff5..dca429dd 100644 --- a/README.md +++ b/README.md @@ -6,8 +6,8 @@ With [GitHub Actions](https://github.com/features/actions), you can create custo software development lifecycle directly in your GitHub repository. These workflows consist of different tasks, called actions, that can be executed automatically when certain events occur. -At Syde, we use GitHub Actions for a wide range of tasks. From various quality assurance tests -(e.g. static analysis checks, PHPUnit tests, etc.), to asset (pre)compilation +At Syde, we use GitHub Actions for a wide range of tasks. From various quality assurance tests ( +e.g., static analysis checks, PHPUnit tests, etc.), to asset (pre)compilation with [Composer Asset Compiler](https://github.com/inpsyde/composer-asset-compiler), release generation, deployments (CI/CD), and container registry management: all automatable, recurring tasks are performed in GitHub Actions. diff --git a/docs/archive-creation.md b/docs/archive-creation.md index 05f9c5e7..38e677f8 100644 --- a/docs/archive-creation.md +++ b/docs/archive-creation.md @@ -1,6 +1,7 @@ # Create plugin archive -This action can be used to create plugin archives in a controlled and isolated environment via GitHub Actions. +This action can be used to create plugin archives in a controlled and isolated environment via +GitHub Actions. To achieve that, the reusable workflow: @@ -11,7 +12,8 @@ To achieve that, the reusable workflow: 5. Executes Rector if configured by the package 6. Re-installs dependencies without dev-dependencies 7. Sets current commit hash and plugin version in the plugin's main file -8. Runs `wp dist-archive` to create the final archive (with builtin support for a `.distignore` file) +8. Runs `wp dist-archive` to create the final archive (with builtin support for a `.distignore` + file) 9. Uploads it as an artifact for download or further processing ## Simple usage example @@ -45,24 +47,24 @@ jobs: |-----------------------|---------------------------------------------------------------|------------------------------------------------------------------------------------------------| | `NODE_OPTIONS` | `''` | Space-separated list of command-line Node options | | `NODE_VERSION` | `18` | Node version with which the assets will be compiled | -| `NPM_REGISTRY_DOMAIN` | `"https://npm.pkg.github.com/"` | Domain of the private npm registry | -| `PACKAGE_MANAGER` | `"yarn"` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | -| `COMPOSER_ARGS` | `'--no-dev --no-scripts --prefer-dist --optimize-autoloader'` | Set of arguments passed to Composer when gathering production dependencies | -| `PHP_VERSION` | `"8.0"` | PHP version to use when gathering production dependencies | -| `PHP_VERSION_BUILD` | `"8.0"` | PHP version to use when executing build tools | -| `ARCHIVE_NAME` | `""` | The name of the zip archive (falls back to the repository name) | -| `PLUGIN_MAIN_FILE` | `"index.php"` | The name of the main plugin file | -| `PLUGIN_FOLDER_NAME` | `""` | The name of the plugin folder (falls back to the archive name, if set, or the repository name) | +| `NPM_REGISTRY_DOMAIN` | `'https://npm.pkg.github.com/'` | Domain of the private npm registry | +| `PACKAGE_MANAGER` | `'yarn'` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | +| `COMPOSER_ARGS` | `'--no-dev --no-scripts --prefer-dist --optimize-autoloader'` | Set of arguments passed to Composer when gathering production dependencies | +| `PHP_VERSION` | `'8.0'` | PHP version to use when gathering production dependencies | +| `PHP_VERSION_BUILD` | `'8.0'` | PHP version to use when executing build tools | +| `ARCHIVE_NAME` | `''` | The name of the zip archive (falls back to the repository name) | +| `PLUGIN_MAIN_FILE` | `'index.php'` | The name of the main plugin file | +| `PLUGIN_FOLDER_NAME` | `''` | The name of the plugin folder (falls back to the archive name, if set, or the repository name) | | `PLUGIN_VERSION` | - | The new plugin version | -| `PRE_SCRIPT` | `""` | Run custom shell code before creating the release archive | +| `PRE_SCRIPT` | `''` | Run custom shell code before creating the release archive | | `COMPILE_ASSETS_ARGS` | `'-v --env=root'` | Set of arguments passed to Composer Asset Compiler | #### A note on `PLUGIN_VERSION` The workflow will accept any arbitrary string and will use it without validation or sanitization. -Adding this would mean reduced flexibility at increased complexity. Adding standardization/validation -is encouraged but should take place in the controlling workflow, where the conventions and requirements -of the project/team/client are known. +Adding this would mean reduced flexibility at increased complexity. Adding +standardization/validation is encouraged but should take place in the controlling workflow, where +the conventions and requirements of the project/team/client are known. ## Secrets diff --git a/docs/assets-compilation.md b/docs/assets-compilation.md index ab44304f..9686e778 100644 --- a/docs/assets-compilation.md +++ b/docs/assets-compilation.md @@ -2,7 +2,8 @@ This workflow utilizes the [Composer Asset Compiler](https://github.com/inpsyde/composer-asset-compiler) to compile assets. -For details, refer to [Pre-compilation](https://github.com/inpsyde/composer-asset-compiler#pre-compilation). +For details, refer +to [Pre-compilation](https://github.com/inpsyde/composer-asset-compiler#pre-compilation). **Simplest possible example:** @@ -25,8 +26,8 @@ jobs: | `NODE_OPTIONS` | `''` | Space-separated list of command-line Node options | | `NODE_VERSION` | `18` | Node version with which the assets will be compiled | | `NPM_REGISTRY_DOMAIN` | `https://npm.pkg.github.com/` | Domain of the private npm registry | -| `PACKAGE_MANAGER` | `yarn` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | -| `PHP_VERSION` | `"8.0"` | PHP version with which the assets compilation is to be executed | +| `PACKAGE_MANAGER` | `'yarn'` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | +| `PHP_VERSION` | `'8.0'` | PHP version with which the assets compilation is to be executed | | `COMPOSER_ARGS` | `'--prefer-dist'` | Set of arguments passed to Composer | | `COMPILE_ASSETS_ARGS` | `'-v --env=root'` | Set of arguments passed to Composer Asset Compiler | diff --git a/docs/automatic-release.md b/docs/automatic-release.md index a36ba741..a9ff81a4 100644 --- a/docs/automatic-release.md +++ b/docs/automatic-release.md @@ -1,19 +1,20 @@ # Automatic release -This workflow utilizes [semantic-release](https://github.com/semantic-release/semantic-release) to create a package -release. -Note that you must stick to -their [commit message convention](https://github.com/semantic-release/semantic-release#commit-message-format) to use it. +This workflow utilizes [semantic-release](https://github.com/semantic-release/semantic-release) to +create a package release. Note that you must stick to +their [commit message convention](https://github.com/semantic-release/semantic-release#commit-message-format) +to use it. -You can provide a `release.config.js` file in your repository to create a custom release that uses the following -semantic-release plugins: +You can provide a `release.config.js` file in your repository to create a custom release that uses +the following semantic-release plugins: - [git](https://github.com/semantic-release/git) - [npm](https://github.com/semantic-release/npm) - [exec](https://github.com/semantic-release/exec) -Otherwise, the workflow will create the release with a [standard set of configurations](../templates/automatic-release/release.config.js), updating the version in the -following files: +Otherwise, the workflow will create the release with +a [standard set of configurations](../templates/automatic-release/release.config.js), updating the +version in the following files: - `CHANGELOG.md` - `composer.json` @@ -21,9 +22,9 @@ following files: - `package.json` - `style.css` or the main plugin file (automatically discovered by the workflow) -By default, every push to the `main` and `next` branches will release a stable version, and every push to the `alpha` -and `beta` branches will create a pre-release version. -If you want to use a different configuration, please provide your custom `release.config.js` file. +By default, every push to the `main` and `next` branches will release a stable version, and every +push to the `alpha` and `beta` branches will create a pre-release version. If you want to use a +different configuration, please provide your custom `release.config.js` file. **Simplest possible example:** diff --git a/docs/build-and-push-assets.md b/docs/build-and-push-assets.md index d5fd9459..276e0fc2 100644 --- a/docs/build-and-push-assets.md +++ b/docs/build-and-push-assets.md @@ -10,26 +10,29 @@ To achieve that, the reusable workflow: ## Where are assets stored -Two inputs can be used to define branches as assets storage: `BUILT_BRANCH_NAME` and `RELEASE_BRANCH_NAME`. +Two inputs can be used to define branches as assets storage: `BUILT_BRANCH_NAME` and +`RELEASE_BRANCH_NAME`. -`BUILT_BRANCH_NAME` is used only for `branch` events. If defined, compiled assets will be stored in the branch of this -name. For example, if `BUILT_BRANCH_NAME` is set to `${{ github.ref_name }}-built`, when pushing to the `main` branch, -compiled assets will be stored in the `main-built` branch (the branch will be created if it does not exist). +`BUILT_BRANCH_NAME` is used only for `branch` events. If defined, compiled assets will be stored in +the branch of this name. For example, if `BUILT_BRANCH_NAME` is set to +`${{ github.ref_name }}-built`, when pushing to the `main` branch, compiled assets will be stored in +the `main-built` branch (the branch will be created if it does not exist). -`RELEASE_BRANCH_NAME` is only used for tag events. If defined and the tag being pushed points to the latest commit of -the default branch of the GitHub repository, compiled assets will be pushed to the branch of this name, and the tag will -be moved there (the branch will be created if it does not exist). +`RELEASE_BRANCH_NAME` is only used for tag events. If defined and the tag being pushed points to the +latest commit of the default branch of the GitHub repository, compiled assets will be pushed to the +branch of this name, and the tag will be moved there (the branch will be created if it does not +exist). -The main benefit of using `BUILT_BRANCH_NAME` is not to pollute the main development branch -with commits containing compiled assets. With `RELEASE_BRANCH_NAME`, you can gain linear tag history -by always tagging only the latest commit from the main development branch. +The main benefit of using `BUILT_BRANCH_NAME` is not to pollute the main development branch with +commits containing compiled assets. With `RELEASE_BRANCH_NAME`, you can gain linear tag history by +always tagging only the latest commit from the main development branch. ## Build script In step *2* above, the assets are "built", whatever that means for a package. For maximum flexibility, the workflow relies on a "script" to be defined in `package.json`. There are two -possible building scripts: a "*dev*" script which is executed on regular pushes to branches, and -a "*prod*" script, which is executed when a tag is pushed. +possible building scripts: a "*dev*" script which is executed on regular pushes to branches, and a " +*prod*" script, which is executed when a tag is pushed. By default, the two scripts are `encore dev` and `encore prod`, but can be configured via [inputs](#inputs). @@ -41,8 +44,8 @@ is moved** to point to the commit that contains the compiled assets. ## Recommendations for consuming packages -- The consuming packages compiled assets' target folder(s) must be **git-ignored** and marked - as `linguist-generated` in `.gitattributes`. +- The consuming packages compiled assets' target folder(s) must be **git-ignored** and marked as + `linguist-generated` in `.gitattributes`. - The calling workflows should use ["concurrency" settings](https://docs.github.com/en/actions/using-jobs/using-concurrency) to avoid conflicts when a push happens before the current workflow is not completed. @@ -88,7 +91,8 @@ jobs: This is not the simplest possible example, but it showcases all the recommendations. -**Note**: Do not set `cancel-in-progress: true` to the `concurrency` setting because it interrupts the workflow. +**Note**: Do not set `cancel-in-progress: true` to the `concurrency` setting because it interrupts +the workflow. ## Configuration parameters @@ -99,7 +103,7 @@ This is not the simplest possible example, but it showcases all the recommendati | `NODE_OPTIONS` | `''` | Space-separated list of command-line Node options | | `NODE_VERSION` | `18` | Node version with which the assets will be compiled | | `NPM_REGISTRY_DOMAIN` | `https://npm.pkg.github.com/` | Domain of the private npm registry | -| `PACKAGE_MANAGER` | `yarn` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | +| `PACKAGE_MANAGER` | `'yarn'` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | | `WORKING_DIRECTORY` | `'./'` | Working directory path | | `COMPILE_SCRIPT_PROD` | `'build'` | Script added to `npm run` or `yarn` to build production assets | | `COMPILE_SCRIPT_DEV` | `'build:dev'` | Script added to `npm run` or `yarn` to build development assets | @@ -210,7 +214,8 @@ jobs: > Can I have multiple output folders for my package? What about files? -Yes, `inputs.ASSETS_TARGET_PATHS` and `inputs.ASSETS_TARGET_FILES` accept multiple space-separated paths for directories and files, respectively. +Yes, `inputs.ASSETS_TARGET_PATHS` and `inputs.ASSETS_TARGET_FILES` accept multiple space-separated +paths for directories and files, respectively. ```yaml name: Build and push assets @@ -268,7 +273,8 @@ hash that triggered the compilation. As for the "noise", it will indeed be there. However, considering that all workflow commit messages start with the prefix `[BOT]`, it would be quite easy to ignore them without any cognitive effort. -By defining `BUILT_BRANCH_NAME`, you keep commits containing compiled assets separated in the built branch. +By defining `BUILT_BRANCH_NAME`, you keep commits containing compiled assets separated in the built +branch. --- @@ -315,8 +321,10 @@ Please note that in such cases it is a good practice not to use a "personal" Git For tags, the pushed tag name is always used. -For branches, it depends on the `BUILT_BRANCH_NAME` input value. For example, when `BUILT_BRANCH_NAME` -is `${{ github.ref_name}}-built` and the branch triggering the workflow is `main`, the built branch name will resolve +For branches, it depends on the `BUILT_BRANCH_NAME` input value. For example, when +`BUILT_BRANCH_NAME` +is `${{ github.ref_name}}-built` and the branch triggering the workflow is `main`, the built branch +name will resolve to `main-built`. In this case, require the `dev-main-built` branch in `composer.json`. --- @@ -332,4 +340,5 @@ The logic in the example above will behave like this: - If `github.ref_name` is equal to `dev-main`, the value of `BUILT_BRANCH_NAME` will be `main` - If `github.ref_name` is equal to `dev-beta`, the value of `BUILT_BRANCH_NAME` will be `beta` - If `github.ref_name` is equal to `dev-alpha`, the value of `BUILT_BRANCH_NAME` will be `alpha` -- If none of the above conditions are met, the value of `BUILT_BRANCH_NAME` will be `''`, which is the default +- If none of the above conditions are met, the value of `BUILT_BRANCH_NAME` will be `''`, which is + the default diff --git a/docs/ddev-playwright.md b/docs/ddev-playwright.md index c1873e97..42f9b451 100644 --- a/docs/ddev-playwright.md +++ b/docs/ddev-playwright.md @@ -3,22 +3,31 @@ This reusable workflow: 1. Launches DDEV. -2. Runs the provided command such as `ddev orchestrate` from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template) to set up the environment (install WP, plugins, ...). -3. If the Ngrok auth token is provided, it sets up Ngrok. Ngrok can be needed if some third-party service, e.g., webhooks, must access the website. - 1. Launches Ngrok, using `vendor/bin/ddev-share` from [inpsyde/ddev-tools](https://github.com/inpsyde/ddev-tools) by default. - 2. Saves the URL to the specified env variable, `BASEURL` by default. -4. Installs Playwright and its dependencies via the provided command, such as `yarn install && yarn playwright install --with-deps` or `ddev pw-install-host` from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template). -5. Runs Playwright tests via the provided command, such as `yarn playwright test` or `ddev pw-host test` from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template). +2. Runs the provided command such as `ddev orchestrate` + from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template) + to set up the environment (install WP, plugins, ...). +3. If the Ngrok auth token is provided, it sets up Ngrok. Ngrok can be needed if some third-party + service, e.g., webhooks, must access the website. + 1. Launches Ngrok, using `vendor/bin/ddev-share` + from [inpsyde/ddev-tools](https://github.com/inpsyde/ddev-tools) by default. + 2. Saves the URL to the specified env variable, `BASEURL` by default. +4. Installs Playwright and its dependencies via the provided command, such as + `yarn install && yarn playwright install --with-deps` or `ddev pw-install-host` + from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template). +5. Runs Playwright tests via the provided command, such as `yarn playwright test` or + `ddev pw-host test` + from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template). It is possible to add any env variables for the "host" and for DDEV. -The "host" env variables (`ENV_VARS`) can be used in the tests (Playwright runs outside of DDEV), such as user credentials or credit card numbers. -To keep things simple and avoid passing hundreds of variables, -consider using an `.env` file, and commit `.env.example` with usable defaults for parameters that do not have to be secret, -then add `cp .env.example .env` in `PLAYWRIGHT_INSTALL_CMD` (`ddev pw-install-host` already includes it). +The "host" env variables (`ENV_VARS`) can be used in the tests (Playwright runs outside of DDEV), +such as user credentials or credit card numbers. To keep things simple and avoid passing hundreds of +variables, consider using an `.env` file, and commit `.env.example` with usable defaults for +parameters that do not have to be secret, then add `cp .env.example .env` in +`PLAYWRIGHT_INSTALL_CMD` (`ddev pw-install-host` already includes it). -Use the DDEV env variables (`DDEV_ENV_VARS`) for debug flags of your project needed for the tests to run properly -(e.g., using placeholder product images or non-live mode). +Use the DDEV env variables (`DDEV_ENV_VARS`) for debug flags of your project needed for the tests to +run properly (e.g., using placeholder product images or non-live mode). Also, it is possible to change some DDEV config values, such as the PHP version (`PHP_VERSION`). @@ -56,14 +65,14 @@ jobs: | Name | Default | Description | |--------------------------|---------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `PHP_VERSION` | `""` | PHP version which will override the version set in the DDEV config | -| `NODE_VERSION` | `""` | Node version which will override the version set in the DDEV config | -| `DDEV_ORCHESTRATE_CMD` | `""` | The command for setting up the DDEV website, such as `ddev orchestrate` from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template) | -| `PLAYWRIGHT_INSTALL_CMD` | `""` | The command for installing Playwright and its deps, such as `yarn install && yarn playwright install --with-deps` or `ddev pw-install-host` from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template) | -| `PLAYWRIGHT_RUN_CMD` | `""` | The command for running Playwright tests, such as `yarn playwright test` or `ddev pw-host test` from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template) | -| `PLAYWRIGHT_DIR` | `"tests/Playwright"` | The path to the Playwright project | -| `NGROK_START_CMD` | `"vendor/bin/ddev-share"` | The command for starting Ngrok, such as `ddev-share` from [inpsyde/ddev-tools](https://github.com/inpsyde/ddev-tools) | -| `BASEURL_ENV_NAME` | `"BASEURL"` | The name of the env variable with the base URL for Playwright, used for overwriting it with the URL from Ngrok | +| `PHP_VERSION` | `''` | PHP version which will override the version set in the DDEV config | +| `NODE_VERSION` | `''` | Node version which will override the version set in the DDEV config | +| `DDEV_ORCHESTRATE_CMD` | `''` | The command for setting up the DDEV website, such as `ddev orchestrate` from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template) | +| `PLAYWRIGHT_INSTALL_CMD` | `''` | The command for installing Playwright and its deps, such as `yarn install && yarn playwright install --with-deps` or `ddev pw-install-host` from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template) | +| `PLAYWRIGHT_RUN_CMD` | `''` | The command for running Playwright tests, such as `yarn playwright test` or `ddev pw-host test` from [inpsyde/ddev-wordpress-plugin-template](https://github.com/inpsyde/ddev-wordpress-plugin-template) | +| `PLAYWRIGHT_DIR` | `'tests/Playwright'` | The path to the Playwright project | +| `NGROK_START_CMD` | `'vendor/bin/ddev-share'` | The command for starting Ngrok, such as `ddev-share` from [inpsyde/ddev-tools](https://github.com/inpsyde/ddev-tools) | +| `BASEURL_ENV_NAME` | `'BASEURL'` | The name of the env variable with the base URL for Playwright, used for overwriting it with the URL from Ngrok | ## Secrets diff --git a/docs/js.md b/docs/js.md index 08ceb379..32f51b22 100644 --- a/docs/js.md +++ b/docs/js.md @@ -2,8 +2,8 @@ ## Unit tests JavaScript -This workflow runs [Jest](https://jestjs.io/). It does so by executing the binary in -the `./node_modules/.bin/` folder. +This workflow runs [Jest](https://jestjs.io/). It does so by executing the binary in the +`./node_modules/.bin/` folder. **Simplest possible example:** @@ -25,7 +25,7 @@ jobs: | `NPM_REGISTRY_DOMAIN` | `https://npm.pkg.github.com/` | Domain of the private npm registry | | `NODE_VERSION` | `18` | Node version with which the unit tests are to be executed | | `JEST_ARGS` | `'--reporters=default --reporters=github-actions'` | Set of arguments passed to Jest | -| `PACKAGE_MANAGER` | `yarn` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | +| `PACKAGE_MANAGER` | `'yarn'` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | **Note**: The default `github-actions` reporter requires Jest 28 or higher. diff --git a/docs/php.md b/docs/php.md index 29949fd5..3b15d0db 100644 --- a/docs/php.md +++ b/docs/php.md @@ -25,7 +25,7 @@ jobs: | Name | Default | Description | |-----------------|----------------------------------------------------------|-------------------------------------------------| -| `PHP_VERSION` | `"8.0"` | PHP version with which the scripts are executed | +| `PHP_VERSION` | `'8.0'` | PHP version with which the scripts are executed | | `COMPOSER_ARGS` | `'--prefer-dist'` | Set of arguments passed to Composer | | `PHPCS_ARGS` | `'--report-full --report-checkstyle=./phpcs-report.xml'` | Set of arguments passed to PHP_CodeSniffer | | `CS2PR_ARGS` | `'--graceful-warnings ./phpcs-report.xml'` | Set of arguments passed to cs2pr | @@ -61,8 +61,8 @@ versions. ## Static code analysis -This workflow runs [Psalm](https://psalm.dev/). It does so by executing the binary in -the `./vendor/bin/` folder. +This workflow runs [Psalm](https://psalm.dev/). It does so by executing the binary in the +`./vendor/bin/` folder. **Simplest possible example:** @@ -117,8 +117,8 @@ with multiple PHP versions, use the [Lint PHP](#lint-php) workflow. ## Unit tests PHP -This workflow runs [PHPUnit](https://phpunit.de/). It does so by executing the binary in -the `./vendor/bin/` folder. +This workflow runs [PHPUnit](https://phpunit.de/). It does so by executing the binary in the +`./vendor/bin/` folder. **Simplest possible example:** diff --git a/docs/wp-scripts.md b/docs/wp-scripts.md index f1e181ef..43b06120 100644 --- a/docs/wp-scripts.md +++ b/docs/wp-scripts.md @@ -3,15 +3,16 @@ ## Lint This workflow runs [ESLint](https://eslint.org/), [Stylelint](https://stylelint.io/), -and [markdownlint](https://github.com/DavidAnson/markdownlint) wrapped in the -the [`@wordpress/scripts`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/) +and [markdownlint](https://github.com/DavidAnson/markdownlint) wrapped in the the [ +`@wordpress/scripts`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/) library. It does so by executing the `wp-scripts` binary in the `./node_modules/.bin/` folder. **Simplest possible example:** ```yml name: Static code analysis assets -on: [push] +on: + push: jobs: wp-scripts-lint: uses: inpsyde/reusable-workflows/.github/workflows/wp-scripts-lint.yml@main @@ -26,7 +27,7 @@ jobs: | `NODE_OPTIONS` | `''` | Space-separated list of command-line Node options | | `NODE_VERSION` | `18` | Node version with which the assets will be compiled | | `NPM_REGISTRY_DOMAIN` | `https://npm.pkg.github.com/` | Domain of the private npm registry | -| `PACKAGE_MANAGER` | `yarn` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | +| `PACKAGE_MANAGER` | `'yarn'` | Package manager with which the dependencies should be installed (`npm` or `yarn`) | | `LINT_TOOLS` | `'["js", "style", "md-docs"]'` | Array of checks to be executed by @wordpress/scripts | | `ESLINT_ARGS` | `''` | Set of arguments passed to `wp-script lint-js` | | `STYLELINT_ARGS` | `''` | Set of arguments passed to `wp-script lint-style` |