fix(docs): Fixed various letter casing and script errors

Signed-off-by: Łukasz Jernaś <lukasz.jernas@allegro.com>

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.
 

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

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.

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) {}

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:

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<BackstageUserPrincipal>` so you can
   // access its specific properties such as `credentials.principal.userEntityRef`.

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

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

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
 

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

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

docs/features/software-catalog/external-integrations.md

@@ -543,6 +543,7 @@ export class UserEntityProvider implements EntityProvider {
         locationKey: 'hr-user-https://www.hrurl.com/',
       })),
     })
+  }
 }
 
 ```

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

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
 

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

docs/frontend-system/building-apps/08-migrating.md

@@ -287,6 +287,7 @@ const app = createApp({
       ),
     },
   ],
+});
 ```
 
 Can be converted to the following extension:

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).
 

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

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.
 
 <!-- Would like to have more FAQs here for help instead of funneling to Discord -->
 

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).

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.
 

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