+
diff --git a/docs/overview/glossary.md b/docs/overview/glossary.md
deleted file mode 100644
index ab7d224f4d..0000000000
--- a/docs/overview/glossary.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-id: glossary
-title: Backstage Glossary
-# prettier-ignore
-description: List of terms, abbreviations, and phrases used in Backstage, together with their explanations.
----
-
-The Backstage Glossary lists terms, abbreviations, and phrases used in
-Backstage, together with their explanations. We encourage you to use the
-terminology below for clarity and consistency when discussing Backstage.
-
-See also [Authentication Glossary](../auth/glossary.md), a separate glossary of terms and phrases
-specifically related to the authentication and identity section of Backstage.
-
-### Backstage User Profiles
-
-There are three main user profiles for Backstage: the integrator, the
-contributor, and the end user (typically a software engineer).
-
-| Term | Explanation |
-| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Integrator | The **integrator** hosts the Backstage app and configures which plugins are available to use in the app. |
-| Contributor | The **contributor** adds functionality to the app by writing plugins. |
-| End user | The **end user** uses the app's functionality and interacts with its plugins. This profile covers the various roles that help deliver software. The typical end user is a **software engineer**, but users might also consider themselves _designers_, _data scientists_, _product owners_, _engineering managers_, _technical writers_, and so on. |
-| Software engineer | The **software engineer** is an **end user** who uses the app's functionality and interacts with its plugins in the course of writing and documenting code. This user is more likely to embed documentation in the code files they produce, and create rough drafts of conceptual pages in collaboration with a **technical writer** or _technical editor_. |
-| Technical writer | The **technical writer** is an **end user** who uses the app's functionality and interacts with its plugins in the course of writing and editing documentation. This user is more likely to produce and customize templates and produce conceptual pages to supplement documentation embedded in code files. |
diff --git a/docs/overview/logos.md b/docs/overview/logos.md
index ac54640e33..fe993cc378 100644
--- a/docs/overview/logos.md
+++ b/docs/overview/logos.md
@@ -12,31 +12,31 @@ The assets below are all in `.svg` format. Other formats are available in the
## Backstage logo
-
- 
+
+
-
- 
+
+
-
- 
+
+
## Backstage icon
diff --git a/docs/overview/support.md b/docs/overview/support.md
index 38bb60784f..0433683406 100644
--- a/docs/overview/support.md
+++ b/docs/overview/support.md
@@ -6,11 +6,11 @@ description: Support and Community Details and Links
- [Discord chatroom](https://discord.gg/backstage-687207715902193673) - Get support or discuss the
project.
-- [Stack Overflow](https://stackoverflow.com/questions/tagged/backstage) - Browse or ask questions on Stack Overflow.
- [Good First Issues](https://github.com/backstage/backstage/contribute) - Start
here if you want to contribute.
- [RFCs](https://github.com/backstage/backstage/labels/rfc) - Help shape the
technical direction by reviewing _Request for Comments_ issues.
+- [BEPs](https://github.com/backstage/backstage/tree/master/beps#backstage-enhancement-proposals-beps) - A Backstage Enhancement Proposal (BEP) is a way to propose, communicate and coordinate on new efforts for the Backstage project.
- [FAQ](../faq/index.md) - Frequently Asked Questions.
- [Code of Conduct](https://github.com/backstage/backstage/blob/master/CODE_OF_CONDUCT.md) -
This is how we roll.
@@ -23,41 +23,3 @@ description: Support and Community Details and Links
## Community Hub
Check out the Backstage.io [Backstage Community Hub](https://backstage.io/community) for the Community Sessions, recordings, and community resources.
-
-### Adding a recording to the meetup page
-
-To add a new recording to the [meetup page](https://backstage.io/on-demand)
-create a file in
-[`microsite/data/on-demand`](https://github.com/backstage/backstage/tree/master/microsite/data/on-demand)
-with your recording's information. Filenames should be in the format `yyyymmdd-xx.yaml`. The page will sort using the filename. Example file content:
-
-```yaml
----
-title: # name of the meetup
-date: February 23, 2022 # date, format: Month day, year.
-category: Meetup # Can be Event, Meetup, Webinar
-description: # description, summary
-youtubeUrl: # Url to youtube video
-youtubeImgUrl: # Url to the preview image, for Youtube this is the format: https://i1.ytimg.com/vi/
+ 
+ 
+ 
+
+
## Benefits
diff --git a/docs/permissions/concepts.md b/docs/permissions/concepts.md
index e7d65b3583..7c8b9e9f69 100644
--- a/docs/permissions/concepts.md
+++ b/docs/permissions/concepts.md
@@ -6,11 +6,11 @@ description: A list of important permission framework concepts
### Permission
-Any action that a user performs within Backstage may be represented as a permission. More complex actions, like executing a software template, may require authorization for multiple permissions throughout the flow. Permissions are identified by a unique name and optionally include a set of attributes that describe the corresponding action. Plugins are responsible for defining and exposing the permissions they enforce.
+Any action that a user performs within Backstage may be represented as a permission. More complex actions, like executing a [software template](../references/glossary.md#software-templates), may require [authorization](../references/glossary.md#authorization) for multiple permissions throughout the flow. Permissions are identified by a unique name and optionally include a set of attributes that describe the corresponding action. [Plugins](../references/glossary.md#plugin) are responsible for defining and exposing the permissions they enforce as well as enforcing restrictions from the permission framework.
### Policy
-User permissions are authorized by a central, user-defined permission policy. At a high level, a policy is a function that receives a Backstage user and permission, and returns a decision to allow or deny. Policies are expressed as code, which decouples the framework from any particular authorization model, like role-based access control (RBAC) or attribute-based access control (ABAC).
+User [permissions](../references/glossary.md#permission-permission-plugin) are authorized by a central, user-defined permission policy. At a high level, a policy is a function that receives a Backstage user and permission, and returns a decision to allow or deny. Policies are expressed as code, which decouples the framework from any particular [authorization](../references/glossary.md#authorization) model, like role-based access control (RBAC) or attribute-based access control (ABAC).
### Policy decision versus enforcement
@@ -18,8 +18,10 @@ Two important responsibilities of any authorization system are to decide if a us
### Resources and rules
-In many cases, a permission represents a user's interaction with another object. This object likely has information that policy authors can use to define more granular access. The permission framework introduces two abstractions to account for this: resources and rules. Resources represent the objects that users interact with. Rules are predicate-based controls that tap into a resource's data. For example, the catalog plugin defines a resource for catalog entities and a rule to check if an entity has a given annotation.
+In many cases, a permission represents a user's interaction with another object. This object likely has information that policy authors can use to define more granular access. The permission framework introduces two abstractions to account for this: [resources](../references/glossary.md#resource-permission-plugin) and [rules](../references/glossary.md#rule-permission-plugin). For example, the catalog plugin defines a resource for catalog entities and a rule to check if an entity has a given annotation.
### Conditional decisions
-Rules need additional data before they can be used in a decision. For example, the catalog plugin's "has annotation" rule needs to know what annotation to look for on a given entity. Once a rule is bound to relevant information it forms a condition. Conditions are then used to return a conditional decision from a policy. Conditional decisions tell the permission framework to delegate evaluation to the plugin that owns the corresponding resource. Permission requests that result in a conditional decision are allowed if all of the provided conditions evaluate to be true. This conditional behavior avoids coupling between policies and resource schemas, and allows plugins to evaluate complex rules in an efficient way. For example, a plugin may convert a conditional decision to a database query instead of loading and filtering objects in memory.
+[Rules](../references/glossary.md#rule-permission-plugin) need additional data before they can be used in a decision. Once a [rule](../references/glossary.md#rule-permission-plugin) is bound to relevant information it forms a [condition](../references/glossary.md#condition-permission-plugin). Conditional decisions tell the [permission framework](#permission) to delegate evaluation to the [plugin](#plugin) that owns the corresponding [resource](#resource-permission-plugin). Permission requests that result in a conditional decision are allowed if all of the provided conditions evaluate to be true.
+
+A good example would be the catalog plugin's "has annotation" rule which needs to know what annotation to look for on a given entity. The permission framework would respond to a request by the catalog plugin in this case with a condition decision. The catalog plugin would then need to correctly filter for entities matching the "has annotations" condition. This conditional behavior avoids coupling between policies and resource schemas, and allows plugins to evaluate complex rules in an efficient way. For example, a plugin may convert a conditional decision to a database query instead of loading and filtering objects in memory.
diff --git a/docs/permissions/custom-rules.md b/docs/permissions/custom-rules.md
index c0f4e3e156..9063ed7257 100644
--- a/docs/permissions/custom-rules.md
+++ b/docs/permissions/custom-rules.md
@@ -4,7 +4,7 @@ title: Defining custom permission rules
description: How to define custom permission rules for existing resources
---
-For some use cases, you may want to define custom [rules](./concepts.md#resources-and-rules) in addition to the ones provided by a plugin. In the [previous section](./writing-a-policy.md) we used the `isEntityOwner` rule to control access for catalog entities. Let's extend this policy with a custom rule that checks what [system](https://backstage.io/docs/features/software-catalog/system-model#system) an entity is part of.
+For some use cases, you may want to define custom [rules](../references/glossary.md#rule-permission-plugin) in addition to the ones provided by a plugin. In the [previous section](./writing-a-policy.md) we used the `isEntityOwner` rule to control access for catalog entities. Let's extend this policy with a custom rule that checks what [system](https://backstage.io/docs/features/software-catalog/system-model#system) an entity is part of.
## Define a custom rule
diff --git a/docs/permissions/getting-started.md b/docs/permissions/getting-started.md
index 01a268f7ef..e241f0e38e 100644
--- a/docs/permissions/getting-started.md
+++ b/docs/permissions/getting-started.md
@@ -48,7 +48,7 @@ The permissions framework uses a new `permission-backend` plugin to accept autho
```bash
# From your Backstage root directory
- yarn add --cwd packages/backend @backstage/plugin-permission-backend
+ yarn --cwd packages/backend add @backstage/plugin-permission-backend
```
2. Add the following to a new file, `packages/backend/src/plugins/permission.ts`. This adds the permission-backend router, and configures it with a policy which allows everything.
diff --git a/docs/permissions/overview.md b/docs/permissions/overview.md
index 693f848c82..8630b85e23 100644
--- a/docs/permissions/overview.md
+++ b/docs/permissions/overview.md
@@ -22,7 +22,7 @@ The permission framework was designed with a few key properties in mind:
- **Integrators** can author or configure policies that define which users can take certain actions upon which resources.
-
+
1. The user triggers a request to perform some action. The request specifies the authorization details using the permission specified by the plugin (in this case, a resource read action).
diff --git a/docs/permissions/plugin-authors/01-setup.md b/docs/permissions/plugin-authors/01-setup.md
index 8134fc0c39..a674d82e25 100644
--- a/docs/permissions/plugin-authors/01-setup.md
+++ b/docs/permissions/plugin-authors/01-setup.md
@@ -41,8 +41,8 @@ The source code is available here:
```sh
# From your Backstage root directory
- yarn add --cwd packages/backend @internal/plugin-todo-list-backend @internal/plugin-todo-list-common
- yarn add --cwd packages/app @internal/plugin-todo-list
+ yarn --cwd packages/backend add @internal/plugin-todo-list-backend @internal/plugin-todo-list-common
+ yarn --cwd packages/app add @internal/plugin-todo-list
```
3. Include the backend and frontend plugin in your application:
diff --git a/docs/permissions/plugin-authors/02-adding-a-basic-permission-check.md b/docs/permissions/plugin-authors/02-adding-a-basic-permission-check.md
index 23bc4e84f1..f3380bdb6f 100644
--- a/docs/permissions/plugin-authors/02-adding-a-basic-permission-check.md
+++ b/docs/permissions/plugin-authors/02-adding-a-basic-permission-check.md
@@ -4,9 +4,9 @@ title: 2. Adding a basic permission check
description: Explains how to add a basic permission check to a Backstage plugin
---
-If the outcome of a permission check doesn't need to change for different [resources](../concepts.md#resources-and-rules), you can use a _basic permission check_. For this kind of check, we simply need to define a [permission](../concepts.md#resources-and-rules), and call `authorize` with it.
+If the outcome of a permission check doesn't need to change for different [resources](../../references/glossary.md#resource-permission-plugin), you can use a _basic permission check_. For this kind of check, we simply need to define a permission, and call `authorize` with it.
-For this tutorial, we'll use a basic permission check to authorize the `create` endpoint in our todo-backend. This will allow Backstage integrators to control whether each of their users is authorized to create todos by adjusting their [permission policy](../concepts.md#policy).
+For this tutorial, we'll use a basic permission check to authorize the `create` endpoint in our todo-backend. This will allow Backstage integrators to control whether each of their users is authorized to create todos by adjusting their [permission policy](../../references/glossary.md#policy-permission-plugin).
We'll start by creating a new permission, and then we'll use the permission api to call `authorize` with it during todo creation.
diff --git a/docs/permissions/plugin-authors/03-adding-a-resource-permission-check.md b/docs/permissions/plugin-authors/03-adding-a-resource-permission-check.md
index a4d51b64d0..76c1a85e24 100644
--- a/docs/permissions/plugin-authors/03-adding-a-resource-permission-check.md
+++ b/docs/permissions/plugin-authors/03-adding-a-resource-permission-check.md
@@ -4,7 +4,7 @@ title: 3. Adding a resource permission check
description: Explains how to add a resource permission check to a Backstage plugin
---
-When performing updates (or other operations) on specific [resources](../concepts.md#resources-and-rules), the permissions framework allows for the decision to be based on characteristics of the resource itself. This means that it's possible to write policies that (for example) allow the operation for users that own a resource, and deny the operation otherwise.
+When performing updates (or other operations) on specific [resources](../../references/glossary.md#resource-permission-plugin), the permissions framework allows for the decision to be based on characteristics of the resource itself. This means that it's possible to write policies that (for example) allow the operation for users that own a resource, and deny the operation otherwise.
## Creating the update permission
diff --git a/docs/plugins/backend-plugin.md b/docs/plugins/backend-plugin.md
index d2e93bb08c..22d4bae371 100644
--- a/docs/plugins/backend-plugin.md
+++ b/docs/plugins/backend-plugin.md
@@ -69,7 +69,7 @@ to your backend.
```bash
# From your Backstage root directory
-yarn add --cwd packages/backend @internal/plugin-carmen-backend@^0.1.0 # Change this to match the plugin's package.json
+yarn --cwd packages/backend add @internal/plugin-carmen-backend@^0.1.0 # Change this to match the plugin's package.json
```
Create a new file named `packages/backend/src/plugins/carmen.ts`, and add the
diff --git a/docs/publishing.md b/docs/publishing.md
index 15813275de..29853955f1 100644
--- a/docs/publishing.md
+++ b/docs/publishing.md
@@ -140,4 +140,26 @@ process is used to release an emergency fix as version `6.5.1` in the patch rele
### When the release workflow is not triggered for some reason, such as a GitHub incident
-Ask one of the maintainers to force push master back to a previous commit and then push the release merge commit again.
+Ask one of the maintainers to trigger [the Deploy packages](https://github.com/backstage/backstage/actions/workflows/deploy_packages.yml) workflow with the "Unconditionally trigger the release job to run" checkbox set, on the `master` branch. Please validate first that nothing substantial has been pushed to master since the original failed release attempt! For this reason, it is wise to have the master branch locked until each release has gone through.
+
+### The release successfully published packages but failed when finalizing the release
+
+If it's an intermittent failure then it is safe to re-trigger the release workflow again.
+
+If re-triggering doesn't or won't help, the following steps can be taken to complete the release:
+
+- Manually create a git tag for the release if it doesn't already exist
+- Manually create a [new GitHub release](https://github.com/backstage/backstage/releases/new).
+- Trigger the repository dispatch workflow using the following request, replace `{title}
- -on {date}
- - {category} - -
-
- }
- body={{description}
} - footer={ - category.toLowerCase() === 'upcoming' ? ( - <> - - Event page - - - - Remind me - - - ) : ( - - Watch on YouTube - - ) - } - /> -); diff --git a/microsite/src/pages/on-demand/index.tsx b/microsite/src/pages/on-demand/index.tsx deleted file mode 100644 index 8d78c393ce..0000000000 --- a/microsite/src/pages/on-demand/index.tsx +++ /dev/null @@ -1,78 +0,0 @@ -import Layout from '@theme/Layout'; -import clsx from 'clsx'; -import React from 'react'; - -import { IOnDemandData, OnDemandCard } from './_onDemandCard'; -import pluginsStyles from './onDemand.module.scss'; -import { truncateDescription } from '@site/src/util/truncateDescription'; -import Link from '@docusaurus/Link'; - -//#region Plugin data import -const onDemandContext = require.context( - '../../../data/on-demand', - false, - /\.ya?ml/, -); - -const onDemandData = onDemandContext.keys().reduce( - (acum, id) => { - const pluginData: IOnDemandData = onDemandContext(id).default; - - acum[ - pluginData.category === 'Upcoming' ? 'upcomingEvents' : 'onDemandEvents' - ].push(truncateDescription(pluginData)); - - return acum; - }, - { - upcomingEvents: [] as IOnDemandData[], - onDemandEvents: [] as IOnDemandData[], - }, -); -//#endregion - -const Plugins = () => ( -
-
-
-
-
-
-
-
-
-
-
- Add an event or recording
-
- Community sessions
- -- Upcoming events and recorded sessions about updates, demos and - discussions. -
-Upcoming live events
- -
- {onDemandData.upcomingEvents.map(eventData => (
-
-
- Community on demand
- -
- {onDemandData.onDemandEvents.map(eventData => (
-
-