diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 1b753ec..77ac24e 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -39,6 +39,10 @@ jobs: run: | make build + - name: run test + run: | + make test + - name: Upload artifact uses: actions/upload-pages-artifact@v3 with: diff --git a/.vitepress/config.mts b/.vitepress/config.mts index 45a6157..cba27d0 100644 --- a/.vitepress/config.mts +++ b/.vitepress/config.mts @@ -18,9 +18,6 @@ export default defineConfig({ srcDir: 'src', - // Can be removed as soon as the legacy content is removed - srcExclude: ['**/legacy/**'], - vite: { server: { fs: { diff --git a/Makefile b/Makefile index 4608972..74c7067 100644 --- a/Makefile +++ b/Makefile @@ -13,6 +13,8 @@ DOCKERRUN=docker run \ -v $(PWD)/package.json:/opt/node_app/package.json \ naemon/docs:latest +.PHONY: test + build: node_modules npm run docs:build @@ -32,6 +34,11 @@ docker-server: clean: rm -rf node_modules + rm -rf .vitepress/dist/ + rm -rf .vitepress/cache/ + rm -rf package-lock.json + rm -rf src/documentation/developer/externalcommands/commands.c.cache + rm -rf src/public/news/feed.xml update_livestatus_json: docker run --rm -ti \ @@ -39,3 +46,7 @@ update_livestatus_json: bash -c "omd start >/dev/null; sudo su - demo -c \"echo -e 'GET columns\nColumns: table name description type\nOutputFormat: json\n' | lq\"" \ > src/documentation/usersguide/livestatus.columns.json fromdos src/documentation/usersguide/livestatus.columns.json + +test: + $(MAKE) build + npm run test diff --git a/package.json b/package.json index 511d378..fa3de24 100644 --- a/package.json +++ b/package.json @@ -6,12 +6,14 @@ "@types/node": "^22.12.0", "feed": "^4.2.2", "markdown-it-mathjax3": "^4.3.2", - "vitepress": "^1.5.0" + "vitepress": "^1.5.0", + "vitest": "^3.1.4" }, "scripts": { "docs:dev": "npx vitepress dev --host", "docs:build": "npx vitepress build", - "docs:preview": "npx vitepress preview" + "docs:preview": "npx vitepress preview", + "test": "vitest run" }, "dependencies": { "@fortawesome/fontawesome-free": "^6.7.0" diff --git a/src/documentation/usersguide/objectdefinitions.md b/src/documentation/usersguide/objectdefinitions.md index 327269d..d8e95fa 100644 --- a/src/documentation/usersguide/objectdefinitions.md +++ b/src/documentation/usersguide/objectdefinitions.md @@ -85,7 +85,7 @@ A host definition is used to define a physical server, workstation, device, etc. > [!IMPORTANT] > Directives in red are required, while those in black are optional. -``` +```js define host { host_name host_name // [!code error] alias alias // [!code error] @@ -421,7 +421,7 @@ Valid options are a combination of one or more of the following: - `o` = UP states - `d` = DOWN states - `u` = UNREACHABLE states -- +- @@ -687,7 +687,7 @@ configuration with [object tricks](objecttricks) or display purposes in the [CGI > [!IMPORTANT] > Directives in red are required, while those in black are optional. -``` +```js define hostgroup { hostgroup_name hostgroup_name // [!code error] alias alias // [!code error] @@ -812,7 +812,7 @@ The different arguments to a service definition are outlined below. > [!IMPORTANT] > Directives in red are required, while those in black are optional. -``` +```js define service { host_name host_name // [!code error] hostgroup_name hostgroup_name @@ -1081,6 +1081,7 @@ If you set this directive to a value of `0`, Naemon will determine a freshness t + event_handler: @@ -1092,6 +1093,7 @@ Read the documentation on The maximum amount of time that the event handler command can run is controlled by the [event_handler_timeout](configmain#event_handler_timeout) option. + event_handler_enabled *: @@ -1367,7 +1369,7 @@ configuration with [object tricks](objecttricks) or display purposes in the [CGI > [!IMPORTANT] > Directives in red are required, while those in black are optional. -``` +```js define servicegroup { servicegroup_name servicegroup_name // [!code error] alias alias // [!code error] @@ -1496,7 +1498,7 @@ The different arguments to a contact definition are described below. > [!IMPORTANT] > Directives in red are required, while those in black are optional. -``` +```js define contact { contact_name contact_name // [!code error] alias alias @@ -1784,7 +1786,7 @@ together for the purpose of sending out alert/recovery [!IMPORTANT] > Directives in red are required, while those in black are optional. -``` +```js define serviceescalation { host_name host_name // [!code error] hostgroup_name hostgroup_name @@ -2473,7 +2475,7 @@ More information on how host dependencies work (read this!) can be found > [!IMPORTANT] > Directives in red are required, while those in black are optional. -``` +```js define hostdependency { dependent_host_name host_name // [!code error] dependent_hostgroup_name hostgroup_name @@ -2622,7 +2624,7 @@ More information on how notification escalations work can be found [here](escala > [!IMPORTANT] > Directives in red are required, while those in black are optional. -``` +```js define hostescalation { host_name host_name // [!code error] hostgroup_name hostgroup_name diff --git a/src/documentation/usersguide/objectinheritance.md b/src/documentation/usersguide/objectinheritance.md index bc43df2..d44bb2b 100644 --- a/src/documentation/usersguide/objectinheritance.md +++ b/src/documentation/usersguide/objectinheritance.md @@ -41,27 +41,27 @@ The third variable is `register`. This variable is used to indicate whether or Values are as follows: - `0` = do NOT register object definition, - `1` = register object definition (this is the default). - + This variable is NOT inherited; every (partial) object definition used as a template must explicitly set the `register` directive to be `0`. This prevents the need to override an inherited `register` directive with a value of `1` for every object that should be registered. ## Local Variables vs. Inherited Variables One important thing to understand with inheritance is that "local" object variables always take precedence over variables defined in the template object. Take a look at the following example of two host definitions (not all required variables have been supplied): -``` +```js define host{ host_name bighost1 check_command check-host-alive notification_options d,u,r max_check_attempts 5 - name hosttemplate1 // [!code highlight] + name hosttemplate1 // [!code highlight] } define host{ host_name bighost2 max_check_attempts 3 - use hosttemplate1 // [!code highlight] + use hosttemplate1 // [!code highlight] } ``` @@ -85,25 +85,25 @@ You can see that the `check_command` and `notification_options` variables were i Objects can inherit properties/variables from multiple levels of template objects. Take the following example: -``` +```js define host{ host_name bighost1 check_command check-host-alive notification_options d,u,r max_check_attempts 5 - name hosttemplate1 // [!code highlight] + name hosttemplate1 // [!code highlight] } define host{ host_name bighost2 max_check_attempts 3 - use hosttemplate1 // [!code highlight] - name hosttemplate2 // [!code highlight] + use hosttemplate1 // [!code highlight] + name hosttemplate2 // [!code highlight] } define host{ host_name bighost3 - use hosttemplate2 // [!code highlight] + use hosttemplate2 // [!code highlight] } ``` @@ -138,25 +138,25 @@ There is no inherent limit on how "deep" inheritance can go, but you'll probably It is possible to use incomplete object definitions as templates for use by other object definitions. By "incomplete" definition, as in that all required variables of the object have not been supplied in the object definition. It may sound odd to use incomplete definitions as templates, but it is in fact recommended that you use them. Why? Well, they can serve as a set of defaults for use in all other object definitions. Take the following example: -``` +```js define host{ check_command check-host-alive notification_options d,u,r max_check_attempts 5 - name generichosttemplate // [!code highlight] - register 0 // [!code highlight] + name generichosttemplate // [!code highlight] + register 0 // [!code highlight] } define host{ host_name bighost1 address 192.168.1.3 - use generichosttemplate // [!code highlight] + use generichosttemplate // [!code highlight] } define host{ host_name bighost2 address 192.168.1.4 - use generichosttemplate // [!code highlight] + use generichosttemplate // [!code highlight] } ``` @@ -188,18 +188,18 @@ At the very least, using a template definition for default variables will save y Any [custom object variables](customobjectvars) that you define in your host, service, or contact definition templates will be inherited just like other standard variables. Take the following example: -``` +```js define host{ _customvar1 somevalue ; <-- Custom host variable _snmp_community public ; <-- Custom host variable - name generichosttemplate // [!code highlight] - register 0 // [!code highlight] + name generichosttemplate // [!code highlight] + register 0 // [!code highlight] } define host{ host_name bighost1 address 192.168.1.3 - use generichosttemplate // [!code highlight] + use generichosttemplate // [!code highlight] } ``` @@ -218,18 +218,18 @@ define host{ In some cases you may not want your host, service, or contact definitions to inherit values of string variables from the templates they reference. If this is the case, you can specify `null` as the value of the variable that you do not want to inherit. Take the following example: -``` +```js define host{ event_handler my-event-handler-command - name generichosttemplate // [!code highlight] - register 0 // [!code highlight] + name generichosttemplate // [!code highlight] + register 0 // [!code highlight] } define host{ host_name bighost1 address 192.168.1.3 - event_handler null // [!code highlight] - use generichosttemplate // [!code highlight] + event_handler null // [!code highlight] + use generichosttemplate // [!code highlight] } ``` @@ -249,17 +249,17 @@ Naemon gives preference to local variables instead of values inherited from temp This "additive inheritance" can be accomplished by prepending the local variable value with a plus sign (`+`). This features is only available for standard (non-custom) variables that contain string values. Take the following example: -``` +```js define host{ hostgroups all-servers - name generichosttemplate // [!code highlight] - register 0 // [!code highlight] + name generichosttemplate // [!code highlight] + register 0 // [!code highlight] } define host{ host_name linuxserver1 - hostgroups +linux-servers,web-servers // [!code highlight] - use generichosttemplate // [!code highlight] + hostgroups +linux-servers,web-servers // [!code highlight] + use generichosttemplate // [!code highlight] } ``` @@ -340,14 +340,14 @@ Why is this useful? It is mainly useful when setting a different `check_command` For instance: -``` +```js # On master define service { name service-distributed register 0 active_checks_enabled 0 check_freshness 1 - check_command !set_to_stale // [!code highlight] + check_command !set_to_stale // [!code highlight] } # On slave @@ -372,7 +372,7 @@ define service { Thus far, all examples of inheritance have shown object definitions inheriting variables/values from just a single source. You are also able to inherit variables/values from multiple sources for more complex configurations, as shown below. -``` +```js # Generic host template define host{ name generic-host // [!code error] @@ -393,7 +393,7 @@ define host{ # Development web server define host{ - use generic-host,development-server // [!code highlight] + use generic-host,development-server // [!code highlight] host_name devweb1 ... } @@ -401,7 +401,7 @@ define host{ ![Multiple Inheritance Sources](/images/usersguide/svg/multiple-templates1.svg) {.img-bg} -In the example above, `devweb1` is inheriting variables/values from two sources: `generic-host` and `development-server`. You'll notice that a `check_interval` variable is defined in both sources. +In the example above, `devweb1` is inheriting variables/values from two sources: `generic-host` and `development-server`. You'll notice that a `check_interval` variable is defined in both sources. Since `generic-host` was the first template specified in `devweb1`'s `use` directive, its value for the `check_interval` variable is inherited by the `devweb1` host. After inheritance, the effective definition of `devweb1` would be as follows: diff --git a/src/documentation/usersguide/objecttricks.md b/src/documentation/usersguide/objecttricks.md index 1fcc26c..bbbaf6c 100644 --- a/src/documentation/usersguide/objecttricks.md +++ b/src/documentation/usersguide/objecttricks.md @@ -33,7 +33,7 @@ You can enable regular expression matching for object names by using the [use_re If you want to create identical [services](objectdefinitions#service) that are assigned to multiple hosts, you can specify multiple hosts in the `host_name` directive. The definition below would create a service called `SOMESERVICE` on hosts `HOST1` through `HOSTN`. All the instances of the `SOMESERVICE` service would be identical (i.e. have the same check command, max check attempts, notification period, etc.). -``` +```js define service{ host_name HOST1,HOST2,HOST3,...,HOSTN // [!code highlight] service_description SOMESERVICE // [!code highlight] @@ -45,7 +45,7 @@ define service{ ### All Hosts In Multiple Hostgroups If you want to create identical services that are assigned to all hosts in one or more hostgroups, you can do so by creating a single service definition. How? The `hostgroup_name` directive allows you to specify the name of one or more hostgroups that the service should be created for. The definition below would create a service called `SOMESERVICE` on all hosts that are members of hostgroups `HOSTGROUP1` through `HOSTGROUPN`. All the instances of the `SOMESERVICE` service would be identical (i.e. have the same check command, max check attempts, notification period, etc.). -``` +```js define service{ hostgroup_name HOSTGROUP1,HOSTGROUP2,...,HOSTGROUPN // [!code highlight] service_description SOMESERVICE // [!code highlight] @@ -57,7 +57,7 @@ define service{ If you want to create identical services that are assigned to all hosts that are defined in your configuration files, you can use a wildcard in the `host_name` directive. The definition below would create a service called `SOMESERVICE` on **all hosts** that are defined in your configuration files. All the instances of the `SOMESERVICE` service would be identical (i.e. have the same check command, max check attempts, notification period, etc.). -``` +```js define service{ host_name * // [!code highlight] service_description SOMESERVICE // [!code highlight] @@ -69,7 +69,7 @@ define service{ If you want to create identical services on numerous hosts or hostgroups, but would like to exclude some hosts from the definition, this can be accomplished by preceding the host or hostgroup with a `!` symbol. -``` +```js define service{ host_name HOST1,HOST2,!HOST3,!HOST4,...,HOSTN // [!code highlight] hostgroup_name HOSTGROUP1,HOSTGROUP2,!HOSTGROUP3,!HOSTGROUP4,...,HOSTGROUPN // [!code highlight] @@ -84,7 +84,7 @@ define service{ If you want to create [service escalations](objectdefinitions#serviceescalation) for services of the same name/description that are assigned to multiple hosts, you can specify multiple hosts in the `host_name` directive. The definition below would create a service escalation for services called `SOMESERVICE` on hosts `HOST1` through `HOSTN`. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.). -``` +```js define serviceescalation{ host_name HOST1,HOST2,HOST3,...,HOSTN // [!code highlight] service_description SOMESERVICE // [!code highlight] @@ -96,7 +96,7 @@ define serviceescalation{ If you want to create service escalations for services of the same name/description that are assigned to all hosts in in one or more hostgroups, you can do use the `hostgroup_name` directive. The definition below would create a service escalation for services called `SOMESERVICE` on all hosts that are members of hostgroups `HOSTGROUP1` through `HOSTGROUPN`. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.). -``` +```js define serviceescalation{ hostgroup_name HOSTGROUP1,HOSTGROUP2,...,HOSTGROUPN // [!code highlight] service_description SOMESERVICE // [!code highlight] @@ -108,7 +108,7 @@ define serviceescalation{ If you want to create identical service escalations for services of the same name/description that are assigned to all hosts that are defined in your configuration files, you can use a wildcard in the `host_name` directive. The definition below would create a service escalation for all services called `SOMESERVICE` on **all hosts** that are defined in your configuration files. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.). -``` +```js define serviceescalation{ host_name * // [!code highlight] service_description SOMESERVICE // [!code highlight] @@ -122,7 +122,7 @@ If you want to create identical services escalations for services on numerous ho but would like to exclude some hosts from the definition, this can be accomplished by preceding the host or hostgroup with a `!` symbol. -``` +```js define serviceescalation{ host_name * // [!code highlight] hostgroup_name HOSTGROUP1,HOSTGROUP2,!HOSTGROUP3,!HOSTGROUP4,...,HOSTGROUPN // [!code highlight] @@ -138,7 +138,7 @@ If you want to create [service escalations](objectdefinitions#serviceescalation) If you feel like being particularly adventurous, you can specify a wildcard in both the `host_name` and `service_description` directives. Doing so would create a service escalation for **all services** that you've defined in your configuration files. -``` +```js define serviceescalation{ host_name HOST1 // [!code highlight] service_description * // [!code highlight] @@ -150,7 +150,7 @@ define serviceescalation{ If you want to create [service escalations](objectdefinitions#serviceescalation) for all multiple services assigned to a particular host, you can use a specify more than one service description in the `service_description` directive. The definition below would create a service escalation for services `SERVICE1` through `SERVICEN` on host `HOST1`. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.). -``` +```js define serviceescalation{ host_name HOST1 // [!code highlight] service_description SERVICE1,SERVICE2,...,SERVICEN // [!code highlight] @@ -162,7 +162,7 @@ define serviceescalation{ If you want to create service escalations for all services that belong in one or more servicegroups, you can do use the `servicegroup_name` directive. The definition below would create service escalations for all services that are members of servicegroups `SERVICEGROUP1` through `SERVICEGROUPN`. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.). -``` +```js define serviceescalation{ servicegroup_name SERVICEGROUP1,SERVICEGROUP2,...,SERVICEGROUPN // [!code highlight] other escalation directives... @@ -177,7 +177,7 @@ define serviceescalation{ If you want to create [service dependencies](objectdefinitions#servicedependency) for services of the same name/description that are assigned to multiple hosts, you can specify multiple hosts in the `host_name` and or `dependent_host_name` directives. In the example below, service `SERVICE2` on hosts `HOST3` and `HOST4` would be dependent on service `SERVICE1` on hosts `HOST1` and `HOST2`. All the instances of the service dependencies would be identical except for the host names (i.e. have the same notification failure criteria, etc.). -``` +```js define servicedependency{ host_name HOST1,HOST2 // [!code highlight] service_description SERVICE1 // [!code highlight] @@ -191,7 +191,7 @@ define servicedependency{ If you want to create service dependencies for services of the same name/description that are assigned to all hosts in in one or more hostgroups, you can do use the `hostgroup_name` and/or `dependent_hostgroup_name` directives. In the example below, service `SERVICE2` on all hosts in hostgroups `HOSTGROUP3` and `HOSTGROUP4` would be dependent on service `SERVICE1` on all hosts in hostgroups `HOSTGROUP1` and `HOSTGROUP2`. Assuming there were five hosts in each of the hostgroups, this definition would be equivalent to creating 100 single service dependency definitions! All the instances of the service dependency would be identical except for the host names (i.e. have the same notification failure criteria, etc.). -``` +```js define servicedependency{ hostgroup_name HOSTGROUP1,HOSTGROUP2 // [!code highlight] service_description SERVICE1 // [!code highlight] @@ -205,7 +205,7 @@ define servicedependency{ If you want to create service dependencies for all services assigned to a particular host, you can use a wildcard in the `service_description` and/or `dependent_service_description` directives. In the example below, **all services** on host `HOST2` would be dependent on **all services** on host `HOST1`. All the instances of the service dependencies would be identical (i.e. have the same notification failure criteria, etc.). -``` +```js define servicedependency{ host_name HOST1 // [!code highlight] service_description * // [!code highlight] @@ -219,7 +219,7 @@ define servicedependency{ If you want to create service dependencies for multiple services assigned to a particular host, you can specify more than one service description in the `service_description` and/or `dependent_service_description` directives as follows: -``` +```js define servicedependency{ host_name HOST1 // [!code highlight] service_description SERVICE1,SERVICE2,...,SERVICEN // [!code highlight] @@ -233,7 +233,7 @@ define servicedependency{ If you want to create service dependencies for all services that belong in one or more servicegroups, you can do use the `servicegroup_name` and/or `dependent_servicegroup_name` directive as follows: -``` +```js define servicedependency{ servicegroup_name SERVICEGROUP1,SERVICEGROUP2,...,SERVICEGROUPN // [!code highlight] dependent_servicegroup_name SERVICEGROUP3,SERVICEGROUP4,...SERVICEGROUPN // [!code highlight] @@ -245,7 +245,7 @@ define servicedependency{ If you want to create service dependencies for multiple services that are dependent on services on the same host, leave the `dependent_host_name` and `dependent_hostgroup_name` directives empty. The example below assumes that hosts `HOST1` and `HOST2` have at least the following four services associated with them: `SERVICE1`, `SERVICE2`, `SERVICE3`, and `SERVICE4`. In this example, `SERVICE3` and `SERVICE4` on `HOST1` will be dependent on both `SERVICE1` and `SERVICE2` on `HOST1`. Similarly, `SERVICE3` and `SERVICE4` on `HOST2` will be dependent on both `SERVICE1` and `SERVICE2` on `HOST2`. -``` +```js define servicedependency{ host_name HOST1,HOST2 // [!code highlight] service_description SERVICE1,SERVICE2 // [!code highlight] @@ -260,7 +260,7 @@ define servicedependency{ If you want to create [host escalations](objectdefinitions#hostescalation) for multiple hosts, you can specify multiple hosts in the `host_name` directive. The definition below would create a host escalation for hosts `HOST1` through `HOSTN`. All the instances of the host escalation would be identical (i.e. have the same contact groups, notification interval, etc.). -``` +```js define hostescalation{ host_name HOST1,HOST2,HOST3,...,HOSTN // [!code highlight] other escalation directives... @@ -271,7 +271,7 @@ define hostescalation{ If you want to create host escalations for all hosts in in one or more hostgroups, you can do use the `hostgroup_name` directive. The definition below would create a host escalation on all hosts that are members of hostgroups `HOSTGROUP1` through `HOSTGROUPN`. All the instances of the host escalation would be identical (i.e. have the same contact groups, notification interval, etc.). -``` +```js define hostescalation{ hostgroup_name HOSTGROUP1,HOSTGROUP2,...,HOSTGROUPN // [!code highlight] other escalation directives... @@ -282,7 +282,7 @@ define hostescalation{ If you want to create identical host escalations for all hosts that are defined in your configuration files, you can use a wildcard in the `host_name` directive. The definition below would create a hosts escalation for **all hosts** that are defined in your configuration files. All the instances of the host escalation would be identical (i.e. have the same contact groups, notification interval, etc.). -``` +```js define hostescalation{ host_name * // [!code highlight] other escalation directives... @@ -294,7 +294,7 @@ define hostescalation{ If you want to create identical host escalations on numerous hosts or hostgroups, but would like to exclude some hosts from the definition, this can be accomplished by preceding the host or hostgroup with a `!` symbol. -``` +```js define hostescalation{ host_name HOST1,HOST2,!HOST3,!HOST4,...,HOSTN // [!code highlight] hostgroup_name HOSTGROUP1,HOSTGROUP2,!HOSTGROUP3,!HOSTGROUP4,...,HOSTGROUPN // [!code highlight] @@ -309,7 +309,7 @@ define hostescalation{ If you want to create [host dependencies](objectdefinitions#hostdependency) for multiple hosts, you can specify multiple hosts in the `host_name` and/or `dependent_host_name` directives. The definition below would be equivalent to creating six separate host dependencies. In the example above, hosts `HOST3`, `HOST4` and `HOST5` would be dependent upon both `HOST1` and `HOST2`. All the instances of the host dependencies would be identical except for the host names (i.e. have the same notification failure criteria, etc.). -``` +```js define hostdependency{ host_name HOST1,HOST2 // [!code highlight] dependent_host_name HOST3,HOST4,HOST5 // [!code highlight] @@ -321,7 +321,7 @@ define hostdependency{ If you want to create host escalations for all hosts in in one or more hostgroups, you can do use the `hostgroup_name` and /or `dependent_hostgroup_name` directives. In the example below, all hosts in hostgroups `HOSTGROUP3` and `HOSTGROUP4` would be dependent on all hosts in hostgroups `HOSTGROUP1` and `HOSTGROUP2`. All the instances of the host dependencies would be identical except for host names (i.e. have the same notification failure criteria, etc.). -``` +```js define hostdependency{ hostgroup_name HOSTGROUP1,HOSTGROUP2 // [!code highlight] dependent_hostgroup_name HOSTGROUP3,HOSTGROUP4 // [!code highlight] @@ -336,7 +336,7 @@ define hostdependency{ If you want to create a hostgroup that has all hosts that are defined in your configuration files as members, you can use a wildcard in the `members` directive. The definition below would create a hostgroup called `HOSTGROUP1` that has **all hosts** that are defined in your configuration files as members. -``` +```js define hostgroup{ hostgroup_name HOSTGROUP1 members * // [!code highlight] diff --git a/test/check_pattern.test.js b/test/check_pattern.test.js new file mode 100644 index 0000000..add6dba --- /dev/null +++ b/test/check_pattern.test.js @@ -0,0 +1,29 @@ +import { assert, test } from 'vitest' + +const fs = require('fs'); +const path = require('path'); + +const DIST_DIR = path.join(__dirname, '../.vitepress/dist'); +const FORBIDDEN_PATTERN = ['[!code ']; + +function walk(dir) { + const files = fs.readdirSync(dir); + return files.flatMap(file => { + const fullPath = path.join(dir, file); + return fs.statSync(fullPath).isDirectory() + ? walk(fullPath) + : [fullPath]; + }); +} + +for (const word of FORBIDDEN_PATTERN) { + test(`rendered files should not contain "${word}"`, () => { + const htmlFiles = walk(DIST_DIR).filter(f => f.endsWith('.html')); + for (const file of htmlFiles) { + const content = fs.readFileSync(file, 'utf-8'); + if(content.includes(word)) { + assert.fail(`File ${path.relative(DIST_DIR, file)} contains forbidden pattern: "${word}"`); + } + } + }); +}