diff --git a/.github/workflows/static-analysis-js.yml b/.github/workflows/static-analysis-js.yml new file mode 100644 index 00000000..bf0dc626 --- /dev/null +++ b/.github/workflows/static-analysis-js.yml @@ -0,0 +1,96 @@ +name: Static code analysis JavaScript + +on: + workflow_call: + inputs: + NPM_REGISTRY_DOMAIN: + description: Domain of the private npm registry. + default: https://npm.pkg.github.com/ + required: false + type: string + NODE_VERSION: + description: Node version with which the static analysis is to be executed. + default: 18 + required: false + type: string + NODE_OPTIONS: + description: Space-separated list of command-line Node options. + type: string + default: '' + required: false + secrets: + NPM_REGISTRY_TOKEN: + description: Authentication for the private npm registry. + required: false + GITHUB_USER_EMAIL: + description: Email address for the GitHub user configuration. + required: false + GITHUB_USER_NAME: + description: Username for the GitHub user configuration. + required: false + GITHUB_USER_SSH_KEY: + description: Private SSH key associated with the GitHub user passed as `GITHUB_USER_NAME`. + required: false + ENV_VARS: + description: Additional environment variables as a JSON formatted object. + required: false + +jobs: + static-analysis-js: + timeout-minutes: 5 + runs-on: ubuntu-latest + env: + NODE_OPTIONS: ${{ inputs.NODE_OPTIONS }} + NODE_AUTH_TOKEN: ${{ secrets.NPM_REGISTRY_TOKEN }} + NODE_CACHE_MODE: '' + GITHUB_USER_EMAIL: ${{ secrets.GITHUB_USER_EMAIL }} + GITHUB_USER_NAME: ${{ secrets.GITHUB_USER_NAME }} + GITHUB_USER_SSH_KEY: ${{ secrets.GITHUB_USER_SSH_KEY }} + steps: + - name: Checkout + uses: actions/checkout@v4 + + - name: Set up custom environment variables + env: + ENV_VARS: ${{ secrets.ENV_VARS }} + if: ${{ env.ENV_VARS }} + uses: actions/github-script@v7 + with: + script: | + JSON + .parse(process.env.ENV_VARS) + .forEach(envVar => core.exportVariable(envVar.name, envVar.value)); + + - name: Set up SSH + if: ${{ env.GITHUB_USER_SSH_KEY != '' }} + uses: webfactory/ssh-agent@v0.9.0 + with: + ssh-private-key: ${{ env.GITHUB_USER_SSH_KEY }} + + - name: Set up Git + run: | + git config --global user.email "${{ env.GITHUB_USER_EMAIL }}" + git config --global user.name "${{ env.GITHUB_USER_NAME }}" + + - name: Set up node cache mode + run: | + if [ -f "${GITHUB_WORKSPACE}/package-lock.json" ] || [ -f "${GITHUB_WORKSPACE}/npm-shrinkwrap.json" ]; then + echo "NODE_CACHE_MODE=npm" >> $GITHUB_ENV + else + echo "No lock files found" + fi + + - name: Set up node + uses: actions/setup-node@v4 + with: + node-version: ${{ inputs.NODE_VERSION }} + registry-url: ${{ inputs.NPM_REGISTRY_DOMAIN }} + cache: ${{ env.NODE_CACHE_MODE }} + + - name: Install dependencies + env: + ARGS: ${{ env.NODE_CACHE_MODE == 'npm' && 'ci' || 'install' }} + run: ${{ format('npm {0}', env.ARGS) }} + + - name: Run tsc + run: ./node_modules/.bin/tsc --noEmit --skipLibCheck --pretty false 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 53eed181..b5f52f68 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 @@ -60,9 +62,9 @@ jobs: #### 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 f01dc0ea..4e2cb6fb 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:** @@ -20,15 +21,15 @@ jobs: ### Inputs -| Name | Default | Description | -|-----------------------|-------------------------------|-----------------------------------------------------------------------------------| -| `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.2'` | 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 | +| Name | Default | Description | +|-----------------------|---------------------------------|-----------------------------------------------------------------------------------| +| `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.2'` | 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 | ### Secrets 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 d82a50fd..6ed04676 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,28 +91,29 @@ 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 ### Inputs -| Name | Default | Description | -|-----------------------|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------| -| `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`) | -| `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 | -| `MODE` | `''` | Mode for compiling assets (`prod` or `dev`) | -| `ASSETS_TARGET_PATHS` | `'./assets'` | Space-separated list of target directory paths for compiled assets | -| `ASSETS_TARGET_FILES` | `''` | Space-separated list of target file paths for compiled assets | -| `BUILT_BRANCH_NAME` | `''` | Sets the target branch for pushing assets on the `branch` event | -| `RELEASE_BRANCH_NAME` | `''` | On tag events, target branch where compiled assets are pushed and the tag is moved to | -| `PHP_VERSION` | `'8.2'` | PHP version with which the PHP tools are to be executed | -| `PHP_TOOLS` | `''` | PHP tools supported by [shivammathur/setup-php](https://github.com/shivammathur/setup-php#wrench-tools-support) to be installed | +| Name | Default | Description | +|-----------------------|---------------------------------|---------------------------------------------------------------------------------------------------------------------------------| +| `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`) | +| `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 | +| `MODE` | `''` | Mode for compiling assets (`prod` or `dev`) | +| `ASSETS_TARGET_PATHS` | `'./assets'` | Space-separated list of target directory paths for compiled assets | +| `ASSETS_TARGET_FILES` | `''` | Space-separated list of target file paths for compiled assets | +| `BUILT_BRANCH_NAME` | `''` | Sets the target branch for pushing assets on the `branch` event | +| `RELEASE_BRANCH_NAME` | `''` | On tag events, target branch where compiled assets are pushed and the tag is moved to | +| `PHP_VERSION` | `'8.2'` | PHP version with which the PHP tools are to be executed | +| `PHP_TOOLS` | `''` | PHP tools supported by [shivammathur/setup-php](https://github.com/shivammathur/setup-php#wrench-tools-support) to be installed | ## Secrets @@ -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..80224b31 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..e663b2cd 100644 --- a/docs/js.md +++ b/docs/js.md @@ -1,9 +1,11 @@ + + # Reusable workflows – JavaScript ## 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:** @@ -22,10 +24,10 @@ jobs: | Name | Default | Description | |-----------------------|----------------------------------------------------|-----------------------------------------------------------------------------------| -| `NPM_REGISTRY_DOMAIN` | `https://npm.pkg.github.com/` | Domain of the private npm registry | +| `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. @@ -56,3 +58,58 @@ jobs: NODE_VERSION: 14 JEST_ARGS: 'my-test --reporters=jest-junit --coverage' ``` + +## Static analysis JavaScript + +This workflow runs +the [TypeScript compiler](https://www.typescriptlang.org/docs/handbook/compiler-options.html) with +the `--noEmit` argument. It does so by executing the `tsc` binary in the `./node_modules/.bin/` +folder. + +**Simplest possible example:** + +```yml +name: Static code analysis JavaScript +on: + push: +jobs: + static-analysis-js: + uses: inpsyde/reusable-workflows/.github/workflows/static-analysis-js.yml@main +``` + +### Configuration parameters + +#### Inputs + +| Name | Default | Description | +|-----------------------|---------------------------------|-----------------------------------------------------| +| `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 | + +#### Secrets + +| Name | Description | +|-----------------------|------------------------------------------------------------------------------| +| `NPM_REGISTRY_TOKEN` | Authentication for the private npm registry | +| `GITHUB_USER_EMAIL` | Email address for the GitHub user configuration | +| `GITHUB_USER_NAME` | Username for the GitHub user configuration | +| `GITHUB_USER_SSH_KEY` | Private SSH key associated with the GitHub user passed as `GITHUB_USER_NAME` | +| `ENV_VARS` | Additional environment variables as a JSON formatted object | + +**Example with configuration parameters:** + +```yml +name: Static code analysis JavaScript +on: + pull_request: +jobs: + static-analysis-js: + uses: inpsyde/reusable-workflows/.github/workflows/static-analysis-js.yml@main + secrets: + NPM_REGISTRY_TOKEN: ${{ secrets.NPM_REGISTRY_TOKEN }} + ENV_VARS: >- + [{"name":"EXAMPLE_USERNAME", "value":"${{ secrets.USERNAME }}"}] + with: + NODE_VERSION: 18 +``` diff --git a/docs/php.md b/docs/php.md index 0c206634..3cf89c1d 100644 --- a/docs/php.md +++ b/docs/php.md @@ -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..16404fc5 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 [ +`@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 @@ -21,17 +22,17 @@ jobs: #### Inputs -| Name | Default | Description | -|-------------------------|--------------------------------|-----------------------------------------------------------------------------------| -| `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`) | -| `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` | -| `MARKDOWNLINT_ARGS` | `''` | Set of arguments passed to `wp-script lint-md-docs` | -| `PACKAGE_JSONLINT_ARGS` | `''` | Set of arguments passed to `wp-scripts lint-pkg-json` | +| Name | Default | Description | +|-------------------------|---------------------------------|-----------------------------------------------------------------------------------| +| `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`) | +| `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` | +| `MARKDOWNLINT_ARGS` | `''` | Set of arguments passed to `wp-script lint-md-docs` | +| `PACKAGE_JSONLINT_ARGS` | `''` | Set of arguments passed to `wp-scripts lint-pkg-json` | > :information_source: **By default, "pkg-json" is not part of the `LINT_TOOLS` input.** > :information_source: **The `--formatter github` flag is hardcoded into the `wp-script lint-style`