Merge branch 'master' into add-topics-to-notification-settings
Signed-off-by: billyatroadie <bstalnaker@roadie.com>
This commit is contained in:
billyatroadie
@@ -1157,13 +1157,21 @@ export class MyIncrementalEntityProvider
|
||||
The last step is to implement the actual `next` method that will accept the cursor, call the API, process the result and return the result.
|
||||
|
||||
```ts
|
||||
import {
|
||||
ANNOTATION_LOCATION,
|
||||
ANNOTATION_ORIGIN_LOCATION,
|
||||
} from '@backstage/catalog-model';
|
||||
import { IncrementalEntityProvider } from '@backstage/plugin-catalog-backend-module-incremental-ingestion';
|
||||
|
||||
export class MyIncrementalEntityProvider
|
||||
implements IncrementalEntityProvider<Cursor, Context>
|
||||
{
|
||||
private readonly token: string;
|
||||
private readonly mySource: string;
|
||||
|
||||
constructor(token: string) {
|
||||
constructor(token: string, mySource: string) {
|
||||
this.token = token;
|
||||
this.mySource = mySource;
|
||||
}
|
||||
|
||||
getProviderName() {
|
||||
@@ -1181,6 +1189,7 @@ export class MyIncrementalEntityProvider
|
||||
cursor: Cursor = { page: 1 },
|
||||
): Promise<EntityIteratorResult<Cursor>> {
|
||||
const { apiClient } = context;
|
||||
const location = `${this.getProviderName()}:${this.mySource}`;
|
||||
|
||||
// call your API with the current cursor
|
||||
const data = await apiClient.getServices(cursor);
|
||||
@@ -1200,8 +1209,8 @@ export class MyIncrementalEntityProvider
|
||||
name: item.name,
|
||||
annotations: {
|
||||
// You need to define these, otherwise they'll fail validation
|
||||
[ANNOTATION_LOCATION]: this.getProviderName(),
|
||||
[ANNOTATION_ORIGIN_LOCATION]: this.getProviderName(),
|
||||
[ANNOTATION_LOCATION]: location,
|
||||
[ANNOTATION_ORIGIN_LOCATION]: location,
|
||||
},
|
||||
},
|
||||
spec: {
|
||||
|
||||
@@ -26,17 +26,30 @@ dependency to `@backstage/plugin-catalog-backend-module-bitbucket-server` to you
|
||||
yarn --cwd packages/backend add @backstage/plugin-catalog-backend-module-bitbucket-server
|
||||
```
|
||||
|
||||
And update your backend by adding the following line:
|
||||
### Installation with New Backend System
|
||||
|
||||
```ts title="packages/backend/src/index.ts"
|
||||
backend.add(import('@backstage/plugin-catalog-backend'));
|
||||
/* highlight-add-start */
|
||||
```ts
|
||||
// optional if you want HTTP endpojnts to receive external events
|
||||
// backend.add(import('@backstage/plugin-events-backend'));
|
||||
// optional if you want to use AWS SQS instead of HTTP endpoints to receive external events
|
||||
// backend.add(import('@backstage/plugin-events-backend-module-aws-sqs'));
|
||||
backend.add(import('@backstage/plugin-events-backend-module-bitbucket-server'));
|
||||
backend.add(
|
||||
import('@backstage/plugin-catalog-backend-module-bitbucket-server'),
|
||||
);
|
||||
/* highlight-add-end */
|
||||
```
|
||||
|
||||
You need to decide how you want to receive events from external sources like
|
||||
|
||||
- [via HTTP endpoint](https://github.com/backstage/backstage/tree/master/plugins/events-backend/README.md)
|
||||
- [via an AWS SQS queue](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md)
|
||||
|
||||
Further documentation:
|
||||
|
||||
- <https://github.com/backstage/backstage/tree/master/plugins/events-backend/README.md>
|
||||
- <https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md>
|
||||
- <https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-bitbucket-server/README.md>
|
||||
|
||||
## Configuration
|
||||
|
||||
To use the entity provider, you'll need a [Bitbucket Server integration set up](locations.md).
|
||||
|
||||
@@ -152,7 +152,7 @@ If you do so, `default` will be used as provider ID.
|
||||
Wildcards cannot be used if the `validateLocationsExist` option is set to `true`.
|
||||
- **`filters`** _(optional)_:
|
||||
- **`branch`** _(optional)_:
|
||||
String used to filter results based on the branch name.
|
||||
String used to filter results based on the branch name. Branch name cannot have any slash (`/`) characters.
|
||||
Defaults to the default Branch of the repository.
|
||||
- **`repository`** _(optional)_:
|
||||
Regular expression used to filter results based on the repository name.
|
||||
|
||||
@@ -86,13 +86,14 @@ catalog:
|
||||
|
||||
These config blocks have a lot of options in them, so we will describe each "root" key within the block separately.
|
||||
|
||||
> NOTE:
|
||||
>
|
||||
> If you want to import users and groups from different LDAP servers, you can define multiple providers with different names.
|
||||
> If they should come from the same server, you can define multiple users and groups blocks within the same provider using an array of users / groups.
|
||||
> Entries coming from the same block will be able to detect group memberships based on the `memberOf` attribute.
|
||||
>
|
||||
> If you want only to import users or groups, you can omit the groups or users block.
|
||||
:::note Note
|
||||
|
||||
If you want to import users and groups from different LDAP servers, you can define multiple providers with different names.
|
||||
If they should come from the same server, you can define multiple users and groups blocks within the same provider using an array of users / groups.
|
||||
Entries coming from the same block will be able to detect group memberships based on the `memberOf` attribute.
|
||||
If you want only to import users or groups, you can omit the groups or users block.
|
||||
|
||||
:::
|
||||
|
||||
### target
|
||||
|
||||
|
||||
@@ -104,4 +104,69 @@ Apart from STMP, the email processor also supports the following transmissions:
|
||||
- sendmail
|
||||
- stream (only for debugging purposes)
|
||||
|
||||
See more information at https://github.com/backstage/backstage/blob/master/plugins/notifications-backend-module-email/README.md
|
||||
See more information at <https://github.com/backstage/backstage/blob/master/plugins/notifications-backend-module-email/README.md>
|
||||
|
||||
### Slack Processor
|
||||
|
||||
Slack processor is used to send notifications to users and channels in Slack.
|
||||
|
||||
### Slack Configuration
|
||||
|
||||
To use this you'll need to create a Slack App or use an existing one. It should have at least the following scopes:
|
||||
`chat:write`, `users:read`, `im:write` (for direct message support).
|
||||
|
||||
Additionally you may include scopes `chat:write.public` in order to send messages to public channels your app is not
|
||||
a member of.
|
||||
|
||||
These scopes are under OAuth & Permissions. You will also want to save the Bot User OAuth Token. This will be needed
|
||||
in the following step to configure `app-config.yaml`.
|
||||
|
||||
### Configure Backstage
|
||||
|
||||
To install the Slack processor, add the `@backstage/plugin-notifications-backend-module-slack` package to your backend.
|
||||
|
||||
```bash
|
||||
yarn workspace backend add @backstage/plugin-notifications-backend-module-slack
|
||||
```
|
||||
|
||||
Add the Slack processor to your backend:
|
||||
|
||||
```ts
|
||||
// packages/backend/src/index.ts
|
||||
import { createBackend } from '@backstage/plugin-notifications-backend';
|
||||
const backend = createBackend();
|
||||
// ...
|
||||
backend.add(import('@backstage/plugin-notifications-backend-module-slack'));
|
||||
```
|
||||
|
||||
Using the token you obtained from your Slack App, configure the Slack module in your `app-config.yaml`.
|
||||
|
||||
```yaml
|
||||
notifications:
|
||||
processors:
|
||||
slack:
|
||||
- token: xoxb-XXXXXXXXX
|
||||
broadcastChannels: # Optional, if you wish to support broadcast notifications.
|
||||
- C12345678
|
||||
```
|
||||
|
||||
Multiple instances can be added in the `slack` array, allowing you to have multiple configurations if you need to send
|
||||
messages to more than one Slack workspace. Org-Wide App installation is not currently supported.
|
||||
|
||||
### Entity Requirements
|
||||
|
||||
Entities must be annotated with the following annotation:
|
||||
|
||||
- `slack.com/bot-notify`
|
||||
|
||||
The value may be any Slack ID supported by [chat.postMessage](https://api.slack.com/methods/chat.postMessage), for example a user (U12345678), channel (C12345678), group, or direct message chat.
|
||||
|
||||
It's also possible to use a user's email address or channel name, however IDs are recommended by Slack.
|
||||
Private channels/chats must use an ID.
|
||||
|
||||
### Observability
|
||||
|
||||
The processor includes the following counter metrics if you are exporting metrics using OpenTelemetry:
|
||||
|
||||
- `notifications.processors.slack.sent.count` - The number of messages sent
|
||||
- `notifications.processors.slack.error.count` - The number of messages that failed to send
|
||||
|
||||
@@ -11,23 +11,9 @@ public roadmap. This not a complete list of all work happening in and around the
|
||||
project, it only highlights the highest priority initiatives worked on by the
|
||||
core maintainers.
|
||||
|
||||
## 2024 Fall Roadmap
|
||||
## 2025 Spring Roadmap
|
||||
|
||||
The initiatives listed below are planned for release within the next half-year, starting in May 2024. The roadmap is updated every 6 months, and the next update is planned for November 2024.
|
||||
|
||||
### Backend System 1.0
|
||||
|
||||
The goal of this initiative is the stable 1.0 release of the [new backend system](../backend-system/index.md).
|
||||
This includes ensuring that all documentation is up to date, and includes API
|
||||
reviews and refactoring efforts to ensure that what is released is both stable
|
||||
and evolvable. You can follow along with this work in the [meta issue](https://github.com/backstage/backstage/issues/24493).
|
||||
|
||||
As part of this initiative, there will also be an exploration on how to
|
||||
simplify extension of backend services. It is not currently possible to augment
|
||||
backend services through declarative integration, they are instead only
|
||||
customizable through complete replacement. This also limits the ability to
|
||||
modularize services and scale ownership of the implementations. The goal is to
|
||||
provide a more flexible and scalable way to extend backend services.
|
||||
The initiatives listed below are planned for release within the next half-year, starting in November 2024. The roadmap is updated every 6 months, and the next update is planned for April 2024.
|
||||
|
||||
### New Frontend System - Ready for Adoption
|
||||
|
||||
@@ -40,53 +26,17 @@ This milestone also includes reaching and executing [rollout phase 2](https://gi
|
||||
Once the initial milestone is reached, the goal is to also build out broader
|
||||
support for the new frontend system in the core plugins.
|
||||
|
||||
### Backstage Security Audit
|
||||
|
||||
This is the second security audit of the Backstage project. It is done together,
|
||||
and with the support of the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/).
|
||||
This time the audit will in particular focus on the recently introduced
|
||||
[authentication system](https://github.com/backstage/backstage/tree/master/beps/0003-auth-architecture-evolution),
|
||||
but also cover other parts of the project.
|
||||
|
||||
### Plugin Metadata
|
||||
|
||||
The goal of this initiative is to provide better machine readable metadata for
|
||||
Backstage packages, available both at runtime, at build-time and as part of
|
||||
package registries. We want to surface information such as what packages make up
|
||||
a particular plugin, what features it provides, and more generally laying the
|
||||
foundation for an evolvable plugin metadata system.
|
||||
|
||||
### MUI v5 Green-light
|
||||
|
||||
Material-UI v4 is still the officially supported version of MUI in Backstage.
|
||||
While we have heard that adopters have had success using MUI 5, this is still an
|
||||
untested path with known bugs. The goal of this initiative is to iron out any
|
||||
remaining issues or gaps, and then provide a green light for migration to MUI 5.
|
||||
|
||||
### Configuration Improvements
|
||||
|
||||
This initiative aims to improve the configuration experience and reliability in
|
||||
Backstage. Areas for improvement include the way that configuration schema is
|
||||
loaded, the way that plugins access configuration that is not owned by them, how
|
||||
plugins read configuration, and how configuration visibility is handled.
|
||||
|
||||
### Versioned Documentation
|
||||
|
||||
The goal of this initiative is to provide versioned documentation at
|
||||
[backstage.io](https://backstage.io). This lets us provide documentation that is
|
||||
both up-to-date while at the same time not ahead of the latest release.
|
||||
|
||||
### Rework Pull Request & Issue Process
|
||||
|
||||
Our current review and issue triage process is centered around either core- or
|
||||
project area maintainers. The goal of this initiative is to make it simpler for
|
||||
more members of the community to be involved and contribute to this process.
|
||||
|
||||
### Catalog Observability
|
||||
### Catalog Performance
|
||||
|
||||
The goal of this initiative is to provide better tools for debugging catalog
|
||||
ingestion issues and to more generally reduce friction for setting up and
|
||||
maintaining the software catalog.
|
||||
The goal of this initiative is to improve the performance of the Software
|
||||
Catalog, both in terms of speeding up the read API and improving the ingestion
|
||||
process.
|
||||
|
||||
## How to influence the roadmap
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ The backend supplies a central logging service,
|
||||
[`rootLogger`](../backend-system/core-services/root-logger.md), as well as a plugin
|
||||
based logger, [`logger`](../backend-system/core-services/logger.md) from `coreServices`.
|
||||
To add additional granularity to your logs, you can create children from the plugin
|
||||
based logger, using the `.child()` method and provide is with JSON data. For example,
|
||||
based logger, using the `.child()` method and provide it with JSON data. For example,
|
||||
if you wanted to log items for a specific span in your plugin, you could do
|
||||
|
||||
```ts
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user