diff --git a/docs/info/customizations.md b/docs/info/customizations.md index afb9cf53f4d3292bd364096a77f7fc073ab460d7..00725f124ee1a30d3d2f42843a485aa35a4e0472 100644 --- a/docs/info/customizations.md +++ b/docs/info/customizations.md @@ -15,7 +15,7 @@ variables: SKIP_PHPSTAN: 1 ``` -Most variables are global in scope, as in the example above, where the the `variables:` keyword is at the top level. But some variables, such as `DRUPAL_CORE` and `PHP_VERSION` need to be scoped to a particular job, because the value has to change between the different [job variants](./variants.md). In this case, use the appropriate composer job name, for example: +Most variables are global in scope, as in the example above, where the `variables:` keyword is at the top level. But some variables, such as `DRUPAL_CORE` and `PHP_VERSION` need to be scoped to a particular job, because the value has to change between the different [job variants](./variants.md). In this case, use the appropriate composer job name, for example: ``` composer: diff --git a/docs/jobs/cspell.md b/docs/jobs/cspell.md index 1c230e31415bcfff75735ff4252793e5a82baddd..49d1947554ff92a176ed22ca21081d502f45f428 100644 --- a/docs/jobs/cspell.md +++ b/docs/jobs/cspell.md @@ -34,7 +34,14 @@ To disable all spell checking on the next line of a file add a comment `cspell:d ### Disable spell checking for a block of lines To disable all checking within a block of lines, add a comment `cspell:disable` at the start of the block and `cspell:enable` at the end. This can also be used to ignore the entire file, by adding `cspell:disable` at the top but not having any corresponding `cspell:enable` -For `.md` files you can use the comment style `<!--- cspell:disable -->` or `[//]: # "cspell:disable"`. +For `.md` files you can use any valid comment syntax, for example +- `[] (cspell:disable)` +- `<!--- cspell:ignore mycustomthing -->` +- `[//] 'cspell:ignore mycustomthing '` + +When using `cspell:ignore` with quotes or brackets, you must include a space after the last word before the quote or bracket, otherwise that word will not be ignored. + +Unfortunately the comments using `[]` syntax _will be_ displayed in the page when editing using live preview, and when viewing the files in the GitLab repository, but they will be correctly hidden in the actual generated documentation sites. For `.json` files you can use the property name `_comment` which is ignored by json validation, so you would have `"_comment": "cspell:disable",` at the start and `"_comment": "cspell:enable",` at the end of the section to ignore. diff --git a/docs/jobs/phpunit.md b/docs/jobs/phpunit.md index 3d241a9d64854f789aae39db6baeb951275f715d..6d0c554db518aa219fbfe0d45ad82d2d4fa35304 100644 --- a/docs/jobs/phpunit.md +++ b/docs/jobs/phpunit.md @@ -143,3 +143,7 @@ Finally, and if you are using a Drupal core version that comes with PHPUnit 10 o variables: _PHPUNIT_EXTRA: '--fail-on-deprecation' ``` + +## Skipped Tests + +If a test is skipped (for example a Javascript test cannot run because the webdriver is not available) then this will be indicated in the log, but the job will not fail. To change this default behavior, you can add `--fail-on-skipped` to the `_PHPUNIT_EXTRA` variable or set this option in your projects own phpunit.xml configuration file. It will only have the required effect when using `_PHPUNIT_CONCURRENT=0` and running the phpunit binary directly, as this option is invalid when using `run-tests.sh` \ No newline at end of file diff --git a/docs/jobs/upgrade-status.md b/docs/jobs/upgrade-status.md index ed9f6ffcb39ee37e9bba9b58b5e29ef8c7f8d2ea..09120b6b86bbfe75decdd93a91ecce0be3a20219 100644 --- a/docs/jobs/upgrade-status.md +++ b/docs/jobs/upgrade-status.md @@ -14,12 +14,20 @@ The module provides the following key features: ## Enabling this job -This experimental job is controlled by the variable `RUN_JOB_UPGRADE_STATUS` which is set to `0` by default. To run the job you need to set the value to `1` in your `.gitlab-ci.yml` file. +This experimental job is controlled by the variable `RUN_JOB_UPGRADE_STATUS` which is set to `0` by default. To run the job you need to set the value to `1` in your `.gitlab-ci.yml` file, or better yet, in a manually created pipeline. ``` variables: RUN_JOB_UPGRADE_STATUS: '1' ``` +Note that by default, this job will use the value of `DRUPAL_CORE` based on what these templates define as 'current major'. That is generally not what you want during porting. Instead, if you want to run the job from the previous major to check for compatibility with the current major, you also need to define `DRUPAL_CORE` variable manually to point to the previous major. + +For example, at the time of writing, 11.1.x is 'current core', and '10.4.x' is 'previous major'. So if you want to run upgrade status on a project to check for D11 compatibility, you would create a manual pipeline with both of these variables defined: +``` + RUN_JOB_UPGRADE_STATUS: '1' + DRUPAL_CORE: '^10.4' +``` + ## Arguments to the `analyze` call You can pass additional arguments to the `drush upgrade_status:analyze` command by setting the `_UPGRADE_STATUS_ANALYZE_EXTRA` variable.