diff --git a/.github/vale/config/vocabularies/Backstage/accept.txt b/.github/vale/config/vocabularies/Backstage/accept.txt index 77b0fb1d46..f4091717b5 100644 --- a/.github/vale/config/vocabularies/Backstage/accept.txt +++ b/.github/vale/config/vocabularies/Backstage/accept.txt @@ -21,9 +21,9 @@ asciidoc async Atlassian autofix +autologout automations autoscaling -Autoscaling autoselect Avro backend's @@ -47,6 +47,7 @@ bundler bundlers bursty callout +camelCase CDNs Chai Chainguard diff --git a/docs/backend-system/core-services/http-auth.md b/docs/backend-system/core-services/http-auth.md index f3ce96fb25..ea667b144c 100644 --- a/docs/backend-system/core-services/http-auth.md +++ b/docs/backend-system/core-services/http-auth.md @@ -104,7 +104,7 @@ or [contribute](https://github.com/backstage/backstage/blob/master/CONTRIBUTING. ### Custom token extraction logic -In some cases, you might want to customize how tokens are extracted from incoming requests. It might be that you want to extract tokens from a different location in the request. To support this you can supply your own slightly modified httpAuth service. The `DefaultHttpAuthService` class is exported from `@backstage/backend-defaults/httpAuth` and it's static `create` method can be used to pass in a custom `getTokenFromRequest` extraction function. +In some cases, you might want to customize how tokens are extracted from incoming requests. It might be that you want to extract tokens from a different location in the request. To support this you can supply your own slightly modified `httpAuth` service. The `DefaultHttpAuthService` class is exported from `@backstage/backend-defaults/httpAuth` and it's static `create` method can be used to pass in a custom `getTokenFromRequest` extraction function. ```ts import { DefaultHttpAuthService } from '@backstage/backend-defaults/httpAuth'; diff --git a/docs/backend-system/core-services/root-http-router.md b/docs/backend-system/core-services/root-http-router.md index 1bda95a990..9c2c60957f 100644 --- a/docs/backend-system/core-services/root-http-router.md +++ b/docs/backend-system/core-services/root-http-router.md @@ -162,7 +162,7 @@ backend.add( Note that requests towards `/api/*` will never be handled by the `routes` handler unless a matching plugin exists, and will instead typically falling through to the `middleware.notFound()` handler. That is the case regardless of whether there is a configured `indexPath` or not. -The root HTTP Router service also allows for configuration of the underlying Node.js HTTP server object. This is useful for modifying settings on the HTTP server itself, such as server [timeout](https://nodejs.org/api/http.html#servertimeout), [keepAliveTimeout](https://nodejs.org/api/http.html#serverkeepalivetimeout), and [headersTimeout](https://nodejs.org/api/http.html#serverheaderstimeout). +The root HTTP Router service also allows for configuration of the underlying Node.js HTTP server object. This is useful for modifying settings on the HTTP server itself, such as server [`timeout`](https://nodejs.org/api/http.html#servertimeout), [`keepAliveTimeout`](https://nodejs.org/api/http.html#serverkeepalivetimeout), and [`headersTimeout`](https://nodejs.org/api/http.html#serverheaderstimeout). A `applyDefaults` helper is also made available to use the default app/router configuration while still enabling custom server configuration diff --git a/docs/features/search/declarative-integration.md b/docs/features/search/declarative-integration.md index b8f1c6ce5c..74d16d7c57 100644 --- a/docs/features/search/declarative-integration.md +++ b/docs/features/search/declarative-integration.md @@ -161,13 +161,13 @@ The `createSearchResultItemExtension` function returns a Backstage's extension r In this object, you can see exactly what will happen once the custom extension is installed: -- **[1] $$type**: declares that the object represents an extension; -- **[2] id**: Is a unique identification for the extension, the `plugin.search.result.item.techdocs` is the key used to configure the extension in the `app-config.yaml` file; -- **[3] at**: It represents the extension attachment point, so the value `plugin.search.page/items` says that the `TechDocs`'s search result item output will be injected as input on the "items" attachment expected by the search page extension; -- **[4] inputs**: in this case is an empty object because this extension doesn't expect inputs; -- **[5] output**: Object representing the artifact produced by the `TechDocs` result item extension, on the example, it is a react component reference; -- **[6] configSchema**: represents the `TechDocs` search result item configuration definition, this is the same schema that adopters will use for customizing the extension via `app-config.yaml` file; -- **[7] disable**: Says that the result item extension will be enable by default when the `TechDocs` plugin is installed in the app. +- **[1] `$$type`**: declares that the object represents an extension; +- **[2] `id`**: Is a unique identification for the extension, the `plugin.search.result.item.techdocs` is the key used to configure the extension in the `app-config.yaml` file; +- **[3] `at`**: It represents the extension attachment point, so the value `plugin.search.page/items` says that the `TechDocs`'s search result item output will be injected as input on the "items" attachment expected by the search page extension; +- **[4] `inputs`**: in this case is an empty object because this extension doesn't expect inputs; +- **[5] `output`**: Object representing the artifact produced by the `TechDocs` result item extension, on the example, it is a react component reference; +- **[6] `configSchema`**: represents the `TechDocs` search result item configuration definition, this is the same schema that adopters will use for customizing the extension via `app-config.yaml` file; +- **[7] `disable`**: Says that the result item extension will be enable by default when the `TechDocs` plugin is installed in the app. To complete the development cycle for creating a custom search result item extension, we should provide the extension via `TechDocs` plugin: diff --git a/docs/features/software-catalog/external-integrations.md b/docs/features/software-catalog/external-integrations.md index 0aef4565d9..298c686bea 100644 --- a/docs/features/software-catalog/external-integrations.md +++ b/docs/features/software-catalog/external-integrations.md @@ -775,7 +775,7 @@ sent. Luckily many external systems provide ETag support to check for changes which usually doesn't count towards the quota and saves resources both internally and externally. -The catalog has built in support for leveraging ETags when refreshing external +The catalog has built in support for leveraging `ETag`s when refreshing external locations in GitHub. This example aims to demonstrate how to add the same behavior for `system-x` that we implemented earlier. diff --git a/docs/features/software-catalog/index.md b/docs/features/software-catalog/index.md index 1f374385a4..53afb5205e 100644 --- a/docs/features/software-catalog/index.md +++ b/docs/features/software-catalog/index.md @@ -126,7 +126,7 @@ _starring_ of components: The software catalog is a great way to organize the infrastructure tools you use to manage the software. This is how Backstage creates one developer portal for all your tools. Rather than asking teams to jump between different -infrastructure UIs (and incurring additional cognitive overhead each time they +infrastructure user interfaces (and incurring additional cognitive overhead each time they make a context switch), most of these tools can be organized around the entities in the catalog. diff --git a/docs/features/software-catalog/life-of-an-entity.md b/docs/features/software-catalog/life-of-an-entity.md index 628b083ed2..c16fb8d523 100644 --- a/docs/features/software-catalog/life-of-an-entity.md +++ b/docs/features/software-catalog/life-of-an-entity.md @@ -133,7 +133,7 @@ the order of registration depends on the order in which the modules are loaded by the framework. It's possible to customize the order of the processors by modifying the -`catalog.processors..priority` configuration option. +`catalog.processorOptions..priority` configuration option. The default priority is `20`, and lower value means that the processor runs earlier. ::: diff --git a/docs/integrations/harness/locations.md b/docs/integrations/harness/locations.md index a3d0e2cfd4..a497dfa63b 100644 --- a/docs/integrations/harness/locations.md +++ b/docs/integrations/harness/locations.md @@ -30,4 +30,4 @@ check out https://developer.harness.io/docs/platform/automation/api/add-and-mana - `host`: The host of the Harness Code instance that you want to match on. - `token` (optional): The password or api token to authenticate with. -- `apiKey` (optional): The apiKey to authenticate with. +- `apiKey` (optional): The API key to authenticate with. diff --git a/docs/overview/adopting.md b/docs/overview/adopting.md index e924cfbeb0..8b5703288e 100644 --- a/docs/overview/adopting.md +++ b/docs/overview/adopting.md @@ -85,7 +85,7 @@ Examples of tactics we have used to evangelize Backstage internally: as to send out weekly digest emails showing how usage metrics have changed for individual plugins. -- Pro-actively identify new plugins. Reach out to teams that own internal UIs or +- Pro-actively identify new plugins. Reach out to teams that own internal user interfaces or platforms that you think would make sense to consolidate into Backstage. ## KPIs and metrics diff --git a/docs/plugins/new-backend-system.md b/docs/plugins/new-backend-system.md index 12525b9f95..cf983615b5 100644 --- a/docs/plugins/new-backend-system.md +++ b/docs/plugins/new-backend-system.md @@ -195,7 +195,7 @@ A `ServiceRef` is a named reference to an interface which are later used to reso Services is what provides common utilities that previously resided in the `PluginEnvironment` such as Config, Logging and Database. On startup the backend will make sure that the services are initialized before being passed to the plugin/module that depend on them. -ServiceRefs contain a scope which is used to determine if the serviceFactory creating the service will create a new instance scoped per plugin/module or if it will be shared. `plugin` scoped services will be created once per plugin/module and `root` scoped services will be created once per backend instance. +ServiceRefs contain a scope which is used to determine if the service factory creating the service will create a new instance scoped per plugin/module or if it will be shared. `plugin` scoped services will be created once per plugin/module and `root` scoped services will be created once per backend instance. #### Defining a Service