Merge branch 'community-page' of github.com:suuus/backstage into community-page
This commit is contained in:
Suzanne Daniels
@@ -51,11 +51,12 @@ export default async function createPlugin(
|
||||
// Let's use the username in the email ID as the user's default
|
||||
// unique identifier inside Backstage.
|
||||
const [id] = email.split('@');
|
||||
ent.push(stringifyEntityRef({
|
||||
const userEntityRef = stringifyEntityRef({
|
||||
kind: 'User',
|
||||
namespace: DEFAULT_NAMESPACE,
|
||||
name: id,
|
||||
}));
|
||||
});
|
||||
ent.push(userEntityRef);
|
||||
|
||||
// Let's call the internal LDAP provider to get a list of groups
|
||||
// that the user belongs to, and add those to the list as well
|
||||
@@ -68,7 +69,7 @@ export default async function createPlugin(
|
||||
|
||||
// Issue the token containing the entity claims
|
||||
const token = await ctx.tokenIssuer.issueToken({
|
||||
claims: { sub: id, ent },
|
||||
claims: { sub: userEntityRef, ent },
|
||||
});
|
||||
return { id, token };
|
||||
},
|
||||
@@ -130,6 +131,8 @@ can do this using the `CatalogIdentityClient` provided as context to Sign-In
|
||||
resolvers:
|
||||
|
||||
```ts
|
||||
import { DEFAULT_NAMESPACE, stringifyEntityRef } from '@backstage/catalog-model';
|
||||
|
||||
export default async function createPlugin(
|
||||
env: PluginEnvironment,
|
||||
): Promise<Router> {
|
||||
@@ -140,6 +143,11 @@ export default async function createPlugin(
|
||||
signIn: {
|
||||
resolver: async ({ profile: { email } }, ctx) => {
|
||||
const [id] = email?.split('@') ?? '';
|
||||
const userEntityRef = stringifyEntityRef({
|
||||
kind: 'User',
|
||||
namespace: DEFAULT_NAMESPACE,
|
||||
name: id,
|
||||
});
|
||||
// Fetch from an external system that returns entity claims like:
|
||||
// ['user:default/breanna.davison', ...]
|
||||
const ent = await externalSystemClient.getUsernames(email);
|
||||
@@ -150,7 +158,7 @@ export default async function createPlugin(
|
||||
logger: ctx.logger,
|
||||
});
|
||||
const token = await ctx.tokenIssuer.issueToken({
|
||||
claims: { sub: id, ent: fullEnt },
|
||||
claims: { sub: userEntityRef, ent: fullEnt },
|
||||
});
|
||||
return { id, token };
|
||||
},
|
||||
|
||||
@@ -180,6 +180,35 @@ These should be moved to `links` under the `output` object instead.
|
||||
|
||||
```
|
||||
|
||||
## Watch out for `dash-case`
|
||||
|
||||
The nunjucks compiler can run into issues if the `id` fields in your template steps use dash characters, since these IDs translate directly to JavaScript object properties when accessed as output. One possible migration path is to use `camelCase` for your action IDs.
|
||||
|
||||
```diff
|
||||
steps:
|
||||
- id: my-custom-action
|
||||
- ...
|
||||
-
|
||||
- id: publish-pull-request
|
||||
- input:
|
||||
- repoUrl: {{ steps.my-custom-action.output.repoUrl }} # Will not recognize 'my-custom-action' as a JS property since it contains dashes!
|
||||
|
||||
steps:
|
||||
+ id: myCustomAction
|
||||
+ ...
|
||||
+
|
||||
+ id: publishPullRequest
|
||||
+ input:
|
||||
+ repoUrl: ${{ steps.myCustomAction.output.repoUrl }}
|
||||
```
|
||||
|
||||
Alternatively, it's possible to keep the `dash-case` syntax and use brackets for property access as you would in JavaScript:
|
||||
|
||||
```yaml
|
||||
input:
|
||||
repoUrl: ${{ steps['my-custom-action'].output.repoUrl }}
|
||||
```
|
||||
|
||||
### Summary
|
||||
|
||||
Of course, we're always available on [discord](https://discord.gg/MUpMjP2) if
|
||||
|
||||
@@ -74,32 +74,26 @@ providers are used.
|
||||
storage solutions, source control systems).
|
||||
- [Instructions for upgrading from Alpha to Beta](how-to-guides.md#how-to-migrate-from-techdocs-alpha-to-beta)
|
||||
|
||||
**v1** ✅
|
||||
|
||||
TechDocs packages:
|
||||
|
||||
- '@backstage/plugin-techdocs'
|
||||
- '@backstage/plugin-techdocs-backend'
|
||||
- '@backstage/plugin-techdocs-node'
|
||||
- '@techdocs/cli'
|
||||
|
||||
was promoted to v1.0! To understand how this change affects the package, please check out our [versioning policy](https://backstage.io/docs/overview/versioning-policy).
|
||||
|
||||
### **Future work 🔮**
|
||||
|
||||
**General Availability (GA) release** -
|
||||
[Milestone](https://github.com/backstage/backstage/milestone/30)
|
||||
|
||||
- Bugs are rare, TechDocs APIs are stable and scales easily in large
|
||||
organizations.
|
||||
- Better integration with
|
||||
[Scaffolder V2](https://github.com/backstage/backstage/issues/2771) (e.g. easy
|
||||
to choose and plug documentation template with Software Templates).
|
||||
- Static site generator agnostic
|
||||
- Possible to configure several aspects about TechDocs (e.g. URL, homepage,
|
||||
theme).
|
||||
|
||||
**Implement Feedback loop** -
|
||||
[Milestone](https://github.com/backstage/backstage/milestone/31)
|
||||
|
||||
- A feedback loop between documentation reader and writer using TechDocs
|
||||
- The `+` in `docs-like-code+` experience
|
||||
|
||||
**TechDocs widget framework**
|
||||
|
||||
Platformize TechDocs with a widget framework so that it is easy for TechDocs
|
||||
contributors to add pieces of functionality and for users to choose which
|
||||
functionalities they want to adopt. As a pre-requisite, the re-architecture of
|
||||
TechDocs frontend [RFC](https://github.com/backstage/backstage/issues/3998)
|
||||
needs to be addressed.
|
||||
- [TechDocs Addon Framework](https://github.com/backstage/backstage/issues/9636)
|
||||
|
||||
## Tech stack
|
||||
|
||||
|
||||
@@ -131,15 +131,3 @@ layer for users to determine whether they have the permission to view a
|
||||
particular docs site. There are a handful of features which are extremely hard
|
||||
to develop without a tightly integrated backend in place. Hence, support for
|
||||
`techdocs` without `techdocs-backend` is limited and challenging to develop.
|
||||
|
||||
# Future work
|
||||
|
||||
_Ideas here are far fetched and not in the project's milestone for near future
|
||||
(~6 months)._
|
||||
|
||||
We currently depend on MkDocs to parse doc sites written in Markdown. And we
|
||||
store the generated static assets and re-use it later to render in Backstage. A
|
||||
better (futuristic) approach will be to directly parse whatever type of source
|
||||
files you have in your docs repository and directly render in Backstage in
|
||||
real-time. You can read more in this
|
||||
[RFC - Simplifying TechDocs Frontend Architecture](https://github.com/backstage/backstage/issues/3998).
|
||||
|
||||
@@ -160,10 +160,4 @@ techdocs:
|
||||
# object was not found (e.g. when the cache sercice is unavailable). The
|
||||
# default value is 1000
|
||||
readTimeout: 500
|
||||
|
||||
# (Optional and Legacy) Just another route in techdocs-backend where TechDocs requests the static files from. This URL uses an HTTP middleware
|
||||
# to serve files from either a local directory or an External storage provider.
|
||||
# You don't have to specify this anymore.
|
||||
|
||||
storageUrl: http://localhost:7007/api/techdocs/static/docs
|
||||
```
|
||||
|
||||
@@ -37,6 +37,7 @@ integrations:
|
||||
- accessKeyId: ${AWS_ACCESS_KEY_ID}
|
||||
secretAccessKey: ${AWS_SECRET_ACCESS_KEY}
|
||||
roleArn: 'arn:aws:iam::xxxxxxxxxxxx:role/example-role'
|
||||
externalId: 'some-id' # optional
|
||||
```
|
||||
|
||||
Configuration allows specifying custom S3 endpoint, along with
|
||||
|
||||
Reference in New Issue
Block a user