diff --git a/docs/accessibility/index.md b/docs/accessibility/index.md index da10d60dd2..021c8309be 100644 --- a/docs/accessibility/index.md +++ b/docs/accessibility/index.md @@ -52,7 +52,7 @@ Running this command will use the [Lighthouse config](https://github.com/backsta ::: -### Use Lighthouse Github Action on your own repo +### Use Lighthouse GitHub Action on your own repo If your Backstage plugin lives outside of the [Backstage main repository](https://github.com/backstage/backstage/), and you use GitHub Actions for continuous integration, we encourage you to add and modify the [Accessibility GitHub workflow](https://github.com/backstage/backstage/blob/master/.github/workflows/verify_accessibility.yml) to your needs. diff --git a/docs/auth/add-auth-provider.md b/docs/auth/add-auth-provider.md index 8ea8a4ffc0..51424f1c10 100644 --- a/docs/auth/add-auth-provider.md +++ b/docs/auth/add-auth-provider.md @@ -244,7 +244,7 @@ export const providerAuthenticator = createOAuthAuthenticator({ Here are some examples of authenticators that are already implemented in the codebase: - [Google](https://github.com/backstage/backstage/blob/master/plugins/auth-backend-module-google-provider/src/authenticator.ts) -- [Github](https://github.com/backstage/backstage/blob/master/plugins/auth-backend-module-github-provider/src/authenticator.ts) +- [GitHub](https://github.com/backstage/backstage/blob/master/plugins/auth-backend-module-github-provider/src/authenticator.ts) - [Okta](https://github.com/backstage/backstage/blob/master/plugins/auth-backend-module-okta-provider/src/authenticator.ts) ### Creating proxy auth based provider diff --git a/docs/auth/oidc.md b/docs/auth/oidc.md index 64da189fae..4040a272b4 100644 --- a/docs/auth/oidc.md +++ b/docs/auth/oidc.md @@ -20,7 +20,7 @@ to your provider name. ## Summary To add providers not enabled by default like OIDC, we need to follow some steps, we -assume you already have a sign in page to which we'll add the provider so users can +assume you already have a sign-in page to which we'll add the provider so users can sign in through the provider. In simple steps here's how you enable the provider: - Create an API reference to identify the provider. diff --git a/docs/backend-system/architecture/03-services.md b/docs/backend-system/architecture/03-services.md index 57f6b20b73..ad437e471e 100644 --- a/docs/backend-system/architecture/03-services.md +++ b/docs/backend-system/architecture/03-services.md @@ -197,7 +197,7 @@ When declaring a service factory you may also want to make the export the buildi ```ts export class DefaultFooService { static create(options: { transform: (foo: string) => string }) { - return new DefaultFooService(options.transform ?? (foo) => foo); + return new DefaultFooService(options.transform ?? ((foo) => foo); } private constructor(private readonly transform: (foo: string) => string) {} diff --git a/docs/backend-system/building-backends/08-migrating.md b/docs/backend-system/building-backends/08-migrating.md index 67104c7ba9..fb2923f4c9 100644 --- a/docs/backend-system/building-backends/08-migrating.md +++ b/docs/backend-system/building-backends/08-migrating.md @@ -431,7 +431,7 @@ catalog: /* highlight-add-end */ ``` -#### Github +#### GitHub For `GithubDiscoveryProcessor`, `GithubMultiOrgReaderProcessor` and `GithubOrgReaderProcessor`, first migrate to the equivalent Entity Provider. @@ -445,7 +445,7 @@ backend.add(import('@backstage/plugin-catalog-backend-module-github/alpha')); ``` If you were providing a `schedule` in code, this now needs to be set via configuration. -All other Github configuration in `app-config.yaml` remains the same. +All other GitHub configuration in `app-config.yaml` remains the same. ```yaml title="app-config.yaml" catalog: diff --git a/docs/backend-system/core-services/auth.md b/docs/backend-system/core-services/auth.md index f1243f11fe..8a3a63805d 100644 --- a/docs/backend-system/core-services/auth.md +++ b/docs/backend-system/core-services/auth.md @@ -73,7 +73,8 @@ router.get('/makes-calls', async (req, res) => { onBehalfOf: await httpAuth.credentials(req), targetPluginId: 'catalog', }); - // make a call using the token +}); +// make a call using the token ``` This ensures that the original caller and their associated permissions are @@ -106,7 +107,7 @@ objects. For example checking what type of principal (caller type - e.g. user or service) they represent. For example: ```ts -if (auth.isPrincipal(credentials, 'user)) { +if (auth.isPrincipal(credentials, 'user')) { // In here, the TypeScript type of the credentials object has been properly // narrowed to `BackstageCredentials` so you can // access its specific properties such as `credentials.principal.userEntityRef`. diff --git a/docs/backend-system/core-services/http-auth.md b/docs/backend-system/core-services/http-auth.md index 05a26fc075..13938c921d 100644 --- a/docs/backend-system/core-services/http-auth.md +++ b/docs/backend-system/core-services/http-auth.md @@ -47,6 +47,7 @@ can do so like this: router.get('/some-request', async (req, res) => { const credentials = await httpAuth.credentials(req, { allow: ['user'] }); // Do something with the credentials here +}); ``` The second argument is optional, but in this example we specified that we only diff --git a/docs/backend-system/core-services/user-info.md b/docs/backend-system/core-services/user-info.md index e9d17f1dd7..73f461d1ec 100644 --- a/docs/backend-system/core-services/user-info.md +++ b/docs/backend-system/core-services/user-info.md @@ -47,6 +47,7 @@ additional information about that principal. router.get('/some-request', async (req, res) => { const credentials = await httpAuth.credentials(req, { allow: ['user'] }); const info = await userInfo.getUserInfo(credentials); +}); ``` The `userInfo` service only deals with credentials that contain user principals, @@ -61,6 +62,8 @@ router.get('/some-request', async (req, res) => { if (auth.isPrincipal(credentials, 'user')) { const info = await userInfo.getUserInfo(credentials); // ... + } +}); ``` The user info contains data that was extracted during sign-in for the given diff --git a/docs/deployment/flightcontrol.md b/docs/deployment/flightcontrol.md index 14e0b308a6..fb2af87dd2 100644 --- a/docs/deployment/flightcontrol.md +++ b/docs/deployment/flightcontrol.md @@ -7,7 +7,7 @@ description: Deploying Backstage to AWS Fargate via Flightcontrol This guide explains how to deploy Backstage to [Flightcontrol](https://www.flightcontrol.dev?ref=backstage), a platform that fully automates deployments to Amazon Web Services (AWS). Flightcontrol supports git-driven and image registry deployments. -Before you begin, make sure you have a [Flightcontrol account](https://app.flightcontrol.dev/signup?ref=backstage) and a [Github account](https://github.com/login) to follow this guide. +Before you begin, make sure you have a [Flightcontrol account](https://app.flightcontrol.dev/signup?ref=backstage) and a [GitHub account](https://github.com/login) to follow this guide. # Creating a Dockerfile and .dockerignore diff --git a/docs/features/kubernetes/installation.md b/docs/features/kubernetes/installation.md index 279c9cbf3f..bd6a15a542 100644 --- a/docs/features/kubernetes/installation.md +++ b/docs/features/kubernetes/installation.md @@ -96,6 +96,7 @@ async function main() { // ... /* highlight-add-next-line */ apiRouter.use('/kubernetes', await kubernetes(kubernetesEnv)); +} ``` That's it! The Kubernetes frontend and backend have now been added to your diff --git a/docs/features/software-catalog/configuration.md b/docs/features/software-catalog/configuration.md index 67382aa6ce..554304d152 100644 --- a/docs/features/software-catalog/configuration.md +++ b/docs/features/software-catalog/configuration.md @@ -31,7 +31,7 @@ catalog (`UrlReaderProcessor`), so no processor configuration is needed. This processor _does however_ need an [integration](../../integrations/index.md) to understand how to retrieve a given URL. For the example above, you would need to configure the [GitHub integration](../../integrations/github/locations.md) to -read files from github.com. +read files from GitHub.com. The locations added through static configuration cannot be removed through the catalog locations API. To remove these locations, you must remove them from the diff --git a/docs/features/software-catalog/external-integrations.md b/docs/features/software-catalog/external-integrations.md index 4d5b283c4e..5d482fc3e4 100644 --- a/docs/features/software-catalog/external-integrations.md +++ b/docs/features/software-catalog/external-integrations.md @@ -543,6 +543,7 @@ export class UserEntityProvider implements EntityProvider { locationKey: 'hr-user-https://www.hrurl.com/', })), }) + } } ``` diff --git a/docs/features/software-templates/builtin-actions.md b/docs/features/software-templates/builtin-actions.md index 9816e20fac..5bfc038c1d 100644 --- a/docs/features/software-templates/builtin-actions.md +++ b/docs/features/software-templates/builtin-actions.md @@ -82,16 +82,16 @@ allow most templates built for `fetch:cookiecutter` to work without any changes. ```yaml title="template.yaml" steps: - id: fetch-base - name: Fetch Base - # highlight-remove-next-line - action: fetch:cookiecutter - # highlight-add-next-line - action: fetch:template - input: - url: ./skeleton - # highlight-add-next-line - cookiecutterCompat: true - values: + name: Fetch Base + # highlight-remove-next-line + action: fetch:cookiecutter + # highlight-add-next-line + action: fetch:template + input: + url: ./skeleton + # highlight-add-next-line + cookiecutterCompat: true + values: ``` ### Manual migration diff --git a/docs/features/software-templates/dry-run-testing.md b/docs/features/software-templates/dry-run-testing.md index dfabad265e..15c2684808 100644 --- a/docs/features/software-templates/dry-run-testing.md +++ b/docs/features/software-templates/dry-run-testing.md @@ -4,7 +4,7 @@ title: Dry Run Testing description: How to enable and implement dry run testing in actions --- -Scaffolder templates can be tested using the dry run feature of scaffolder actions. This allows you to simulate the effects of running a scaffolder action without making any actual changes to your environment, for example creating a webhook in Github. Once dry run is enabled in the scaffolder action, you can add handling to actions you use in your scaffolder templates to define how an action should operate in a dry run scenario. +Scaffolder templates can be tested using the dry run feature of scaffolder actions. This allows you to simulate the effects of running a scaffolder action without making any actual changes to your environment, for example creating a webhook in GitHub. Once dry run is enabled in the scaffolder action, you can add handling to actions you use in your scaffolder templates to define how an action should operate in a dry run scenario. ## Enabling dry run testing diff --git a/docs/features/software-templates/migrating-to-rjsf-v5.md b/docs/features/software-templates/migrating-to-rjsf-v5.md index 856841bdd4..8357d7567b 100644 --- a/docs/features/software-templates/migrating-to-rjsf-v5.md +++ b/docs/features/software-templates/migrating-to-rjsf-v5.md @@ -44,7 +44,7 @@ It's possible that if you have a hard dependency on any of the `@rjsf/*` librari /* highlight-remove-next-line */ import { FieldValidation } from '@rjsf/core'; /* highlight-add-next-line */ -import { FieldValidation } from '@rjsf/utils; +import { FieldValidation } from '@rjsf/utils'; ``` ## Escape hatch diff --git a/docs/frontend-system/building-apps/08-migrating.md b/docs/frontend-system/building-apps/08-migrating.md index 96e7dd2bd5..153f274588 100644 --- a/docs/frontend-system/building-apps/08-migrating.md +++ b/docs/frontend-system/building-apps/08-migrating.md @@ -287,6 +287,7 @@ const app = createApp({ ), }, ], +}); ``` Can be converted to the following extension: diff --git a/docs/getting-started/config/authentication.md b/docs/getting-started/config/authentication.md index 5d0262c682..2442d2b767 100644 --- a/docs/getting-started/config/authentication.md +++ b/docs/getting-started/config/authentication.md @@ -8,7 +8,7 @@ Audience: Admins or Developers ## Summary -We'll be walking you through how to setup authentication for your Backstage app using Github. After finishing this guide, you'll have both working authentication and users in your Backstage app to match to the users logging in! +We'll be walking you through how to setup authentication for your Backstage app using GitHub. After finishing this guide, you'll have both working authentication and users in your Backstage app to match to the users logging in! There are multiple authentication providers available for you to use with Backstage, feel free to follow [their instructions for adding authentication](../../auth/index.md). diff --git a/docs/getting-started/index.md b/docs/getting-started/index.md index 80b6115b3a..0d5529f611 100644 --- a/docs/getting-started/index.md +++ b/docs/getting-started/index.md @@ -23,11 +23,11 @@ If you are planning to contribute a new feature or bug fix to the Backstage proj This guide assumes a basic understanding of working on a Linux based operating system and have some experience with the terminal, specifically, these commands: `npm`, `yarn`. -- Access to a Unix-based operating system, such as Linux, MacOS or +- Access to a Unix-based operating system, such as Linux, macOS or [Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/) - A GNU-like build environment available at the command line. For example, on Debian/Ubuntu you will want to have the `make` and `build-essential` packages installed. - On MacOS, you will want to have run `xcode-select --install` to get the XCode command line build tooling in place. + On macOS, you will want to have run `xcode-select --install` to get the XCode command line build tooling in place. - An account with elevated rights to install the dependencies - `curl` or `wget` installed - Node.js [Active LTS Release](https://nodejs.org/en/about/previous-releases) installed using one of these diff --git a/docs/getting-started/logging-in.md b/docs/getting-started/logging-in.md index 7d6fb5d55b..16596865a2 100644 --- a/docs/getting-started/logging-in.md +++ b/docs/getting-started/logging-in.md @@ -12,7 +12,7 @@ This guide will provide a quick tutorial on how to log in to your Backstage inst ## Prerequisites -You should have already [have a standalone app](./index.md) and completed the Github OAuth app setup defined in [the authentication tutorial](./config/authentication.md). +You should have already [have a standalone app](./index.md) and completed the GitHub OAuth app setup defined in [the authentication tutorial](./config/authentication.md). ## 1. Login to Backstage @@ -22,13 +22,13 @@ If you're not already logged in, you should see a login screen like this, ![Screenshot of the login screen](../assets/getting-started/login-screen.png) -To login, you should choose the "Github" provider and click the "Sign in" button. This will redirect you to a Github OAuth page. Verify that the scopes mentioned on that page match the setup you did in [the authentication tutorial](./config/authentication.md). Once you click "Confirm", you will be brought back to the Backstage interface and signed in! +To login, you should choose the "GitHub" provider and click the "Sign in" button. This will redirect you to a GitHub OAuth page. Verify that the scopes mentioned on that page match the setup you did in [the authentication tutorial](./config/authentication.md). Once you click "Confirm", you will be brought back to the Backstage interface and signed in! If you are already logged in, you will be automatically brought to your Backstage instance. ## 2. Verify that you're logged in -Once you've logged in, find the "Settings" item in the navigation bar to the left. Click it and you will see your profile. If you see your profile picture and name from Github here, congratulations! You've successfully set up a Github authentication integration. +Once you've logged in, find the "Settings" item in the navigation bar to the left. Click it and you will see your profile. If you see your profile picture and name from GitHub here, congratulations! You've successfully set up a GitHub authentication integration. diff --git a/docs/openapi/definitions/auth.yaml b/docs/openapi/definitions/auth.yaml index 1ed649da9c..07b18866c6 100644 --- a/docs/openapi/definitions/auth.yaml +++ b/docs/openapi/definitions/auth.yaml @@ -9,7 +9,7 @@ info: The purpose of the Auth APIs in Backstage are to identify the user, and to provide a way for plugins to request access to 3rd party services on behalf of that user. - The API is supplied with a list of providers - such as `Google` or `Github` - and will add the endpoints + The API is supplied with a list of providers - such as `Google` or `GitHub` - and will add the endpoints described below to each of those providers. Read more about [User Authentication and Authorization in Backstage](https://github.com/backstage/backstage/blob/master/docs/auth/overview.md). diff --git a/docs/overview/threat-model.md b/docs/overview/threat-model.md index 74c055a86c..377e546024 100644 --- a/docs/overview/threat-model.md +++ b/docs/overview/threat-model.md @@ -79,7 +79,7 @@ By default all internal users are allowed to create and delete entities. If this By default, Scaffolding jobs execute directly on the host machine, including any actions defined in the template. Because the Scaffolder templates are considered a more sensitive area it is recommended to control access to create and update templates to trusted parties. Template execution is intended to be secure regardless of input, but we still recommend this additional layer of protection. The string templating is executed in a [node VM sandbox](https://github.com/laverdet/isolated-vm) to mitigate the possibility of remote code execution attacks. -The Scaffolder often has elevated permissions to for example create repositories in a Github organization. The operator should therefore be cautious of Scaffolder Templates that for example delete or update existing resources as the user input is typically user defined and can therefore delete or modify resources maliciously or by mistake. +The Scaffolder often has elevated permissions to for example create repositories in a GitHub organization. The operator should therefore be cautious of Scaffolder Templates that for example delete or update existing resources as the user input is typically user defined and can therefore delete or modify resources maliciously or by mistake. One strategy that allows you to reduce the access that the Scaffolder service has is to rely on user credentials when executing actions. For example, a GitHub App integration could be configured with read-only permissions, with a separate user OAuth token used to create repositories. This requires that your users have access to create repositories in the first place. diff --git a/docs/plugins/integrating-plugin-into-software-catalog.md b/docs/plugins/integrating-plugin-into-software-catalog.md index 1ec3df69cf..d47be7f4c0 100644 --- a/docs/plugins/integrating-plugin-into-software-catalog.md +++ b/docs/plugins/integrating-plugin-into-software-catalog.md @@ -54,7 +54,7 @@ To begin, you will need to import your plugin in the entities page. Located at your backstage app. ```tsx -import { MyPluginEntityContent } from '@backstage/plugin-my-plugin; +import { MyPluginEntityContent } from '@backstage/plugin-my-plugin'; ``` To add your component to the Entity view, you will need to modify the