Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions assemblies/dynamic-plugins/assembly-front-end-plugin-wiring.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
[id="assembly-front-end-plugin-wiring.adoc_{context}"]
= Front-end plugin wiring
:context: assembly-front-end-plugin-wiring

You can configure front-end plugins to customize icons, integrate components at mount points, and provide or replace utility APIs.

// Extending the internal icon catalog
include::../modules/dynamic-plugins/proc-extending-internal-icon-catalog.adoc[leveloffset=+1]

// Defining dynamic routes for new plugin pages
include::../modules/dynamic-plugins/proc-defining-dynamic-routes-for-new-plugin-pages.adoc[leveloffset=+1]

// Customizing menu items in the sidebar navigation
include::../modules/dynamic-plugins/proc-customizing-sidebar-menu-items.adoc[leveloffset=+1]

// Bind to existing plugins
include::../modules/dynamic-plugins/proc-binding-to-existing-plugins.adoc[leveloffset=+1]

// Using mount points
include::../modules/dynamic-plugins/proc-using-mount-points.adoc[leveloffset=+1]

include::../modules/dynamic-plugins/proc-customizing-entity-page.adoc[leveloffset=+2]

include::../modules/dynamic-plugins/proc-adding-application-header.adoc[leveloffset=+2]

include::../modules/dynamic-plugins/proc-adding-application-listeners.adoc[leveloffset=+2]

include::../modules/dynamic-plugins/proc-adding-application-providers.adoc[leveloffset=+2]

// Customizing and extending entity tabs
include::../modules/dynamic-plugins/proc-customizing-and-extending-entity-tabs.adoc[leveloffset=+1]

// SignIn page
include::../modules/dynamic-plugins/con-using-custom-signinpage-component.adoc[leveloffset=+1]

// custom scaffolder extension
include::../modules/dynamic-plugins/con-providing-custom-scaffolder-field-extensions.adoc[leveloffset=+1]

// Provide additional Utility APIs
include::../modules/dynamic-plugins/proc-provide-additional-utility-apis.adoc[leveloffset=+1]

// Adding custom authentication provider settings
include::../modules/dynamic-plugins/proc-adding-custom-authentication-provider-settings.adoc[leveloffset=+1]

// Provide custom techdocs addons
include::../modules/dynamic-plugins/proc-provide-custom-techdocs-addons.adoc[leveloffset=+1]

// Customizing theme
include::../modules/dynamic-plugins/proc-customizing-theme.adoc[leveloffset=+1]
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
[id="con-providing-custom-scaffolder-field-extensions.adoc_{context}"]
= Providing custom Scaffolder field extensions

The Scaffolder component in {product} ({product-very-short}) enables users to create software components using templates through a guided wizard. You can extend the functionality of the Scaffolder by providing custom form fields as dynamic plugins using the `scaffolderFieldExtensions` configuration.

Custom field extensions allow you to add specialized form fields that capture domain-specific data during the scaffolding process, such as environment selectors, input validations, or repository checks.

When you configure custom scaffolder field extensions:

* The dynamic plugin exposes the field extension component using `createScaffolderFieldExtension`.
* Each field extension requires a unique `importName` for registration.
* You register multiple field extensions by listing each in the configuration.

[source,yaml]
----
dynamicPlugins:
frontend:
my-plugin: # The plugin package name
scaffolderFieldExtensions:
- importName: MyNewFieldExtension # References the exported scaffolder field extension component from your plugin
----

[NOTE]
====
The `module` field is optional and specifies which set of assets to access within the plugin. By default, the system uses the `PluginRoot` module, consistent with the `scalprum.exposedModules` key in the `package.json` file of your package.
====
26 changes: 26 additions & 0 deletions modules/dynamic-plugins/con-using-custom-signinpage-component.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
[id="con-using-custom-signinpage-component.adoc_{context}"]
= Using a custom SignInPage component

In {product} ({product-very-short}), the `SignInPage` component manages the authentication flow of the application. This component connects one or more authentication providers to the sign-in process. By default, {product-short} uses a static `SignInPage` that supports all built-in authentication providers.

When you configure a custom `SignInPage`:

* The system loads the specified `importName` component from your dynamic plugin.
* The component returns a configured `SignInPage` that connects the desired authentication provider factories.
* Only one `signInPage` is specified for the application at a time.

[source,yaml]
----
dynamicPlugins:
frontend:
my-plugin: # The plugin package name
signInPage:
importName: CustomSignInPage
----

[NOTE]
====
The `package_name` specified under `dynamicPlugins.frontend` must match the `scalprum.name` value in the `package.json` file of your plugin to ensure the dynamic plugin loads correctly at runtime.

The `module` field is optional and allows specifying which set of assets must be accessed within the dynamic plugin. By default, the system uses the `PluginRoot` module.
====
22 changes: 22 additions & 0 deletions modules/dynamic-plugins/proc-adding-application-header.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
[id="proc-adding-application-header.adoc_{context}"]
= Adding application header

You can customize global headers by specifying configurations in the `app-config.yaml` file as shown in the following example:

[source,yaml]
----
# app-config.yaml
dynamicPlugins:
frontend:
my-plugin: # The plugin package name
mountPoints:
- mountPoint: application/header # Adds the header as a global header
importName: <header_component> # Specifies the component exported by the global header plugin
config:
position: above-main-content # Supported values: (`above-main-content`| above-sidebar`)
----

[NOTE]
====
To configure multiple global headers at different positions, add entries to the `mountPoints` field.
====
20 changes: 20 additions & 0 deletions modules/dynamic-plugins/proc-adding-application-listeners.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
[id="proc-adding-application-listeners.adoc_{context}"]
= Adding application listeners

You can add application listeners using the `application/listener` mount point as shown in the following example:

[source,yaml]
----
# app-config.yaml
dynamicPlugins:
frontend:
my-plugin: # The plugin package name
mountPoints:
- mountPoint: application/listener
importName: <exported listener component>
----

[NOTE]
====
You can configure multiple application listeners by adding entries to the `mountPoints` field.
====
25 changes: 25 additions & 0 deletions modules/dynamic-plugins/proc-adding-application-providers.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
[id="proc-adding-application-providers.adoc_{context}"]

= Adding application providers

You can add application providers using the `application/provider` mount point. You can use a mount point to configure a context provider as shown in the following example:

[source,yaml]
----
# app-config.yaml
dynamicPlugins:
frontend:
my-plugin: # The plugin package name
dynamicRoutes:
- path: /<route>
importName: Component # The component to load on the route
mountPoints:
- mountPoint: application/provider
importName: <exported provider component>
----

[NOTE]
====
. You can configure multiple application providers by adding entries to the `mountPoints` field.
. The `package_name` key under `dynamicPlugins.frontend` **must match** the `scalprum.name` value in the `package.json` file of your plugin. This ensures your dynamic plugin loads correctly at runtime.
====
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
[id="proc-adding-custom-authentication-provider-settings.adoc_{context}"]
= Adding custom authentication provider settings

You can install new authentication providers from a dynamic plugin that either adds additional configuration support for an existing provider or adds a new authentication provider. These providers are listed in the user settings section under the *Authentication Providers* tab.

You can use the `providerSettings` configuration to add entries for an authentication provider from a dynamic plugin, as shown in the following example:

[source,yaml]
----
dynamicPlugins:
frontend:
my-plugin: # The plugin package name
providerSettings:
# The title for the authentication provider shown above the user's profile image if available
- title: My Custom Auth Provider
# The description of the authentication provider
description: Sign in using My Custom Auth Provider
# The ID of the authentication provider as provided to the `createApiRef` API call.
provider: core.auth.my-custom-auth-provider
----

[NOTE]
====
`provider` looks up the corresponding API factory for the authentication provider to connect the provider's Sign In/Sign Out button.
====
44 changes: 44 additions & 0 deletions modules/dynamic-plugins/proc-binding-to-existing-plugins.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
[id="proc-binding-to-existing-plugins.adoc_{context}"]
= Binding to existing plugins

You can bind to existing plugins and their routes, and declare new targets sourced from dynamic plugins as shown in the following `routeBindings` configuration:

[source,yaml]
----
# dynamic-plugins-config.yaml
plugins:
- plugin: <plugin_path_or_url>
disabled: false
pluginConfig:
dynamicPlugins:
frontend:
my-plugin: # The plugin package name
routeBindings:
targets: # A new bind target
# (Optional): Defaults to importName. Explicit name of the plugin that exposes the bind target.
- name: barPlugin
# (Required): Explicit import name that reference a BackstagePlugin<{}> implementation.
importName: barPlugin
# # (Optional): Same as key in `scalprum.exposedModules` key in the `package.json` file of the plugin.
module: CustomModule
bindings:
- bindTarget: "barPlugin.externalRoutes" # (Required): One of the supported or imported bind targets
bindMap: # A required map of route bindings similar to `bind` function options
headerLink: "fooPlugin.routes.root"
----

To configure `routeBindings`, complete the following steps:

. Define new targets using `routeBindings.targets`. Set the required `importName` to a `BackstagePlugin<{}>` implementation.

. Declare route bindings using the *routeBindings.bindings* field by setting `bindTarget` to the name of the target to bind to. This is a dynamic or static target, such as:
+
** `catalogPlugin.externalRoutes`

** `catalogImportPlugin.externalRoutes`

** `techdocsPlugin.externalRoutes`

** `scaffolderPlugin.externalRoutes`
+
You can extend existing pages with additional content using mount points, which are predefined identifiers available throughout the application.
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
[id="proc-customizing-and-extending-entity-tabs.adoc_{context}"]

= Customizing and extending entity tabs

You can customize and extend the set of tabs using the `entityTabs` configuration as follows:

[source,yaml]
----
# dynamic-plugins-config.yaml
plugins:
- plugin: <plugin_path_or_url>
disabled: false
pluginConfig:
dynamicPlugins:
frontend:
my-plugin: # The plugin package name
entityTabs:
# Specify a new tab
- path: /new-path
title: My New Tab
mountPoint: entity.page.my-new-tab
# Change an existing tab's title or mount point
- path: /
title: General
mountPoint: entity.page.overview
# Specify the sub-path route in the catalog where this tab is available
- path: "/pr"
title: "Changed Pull/Merge Requests" # Specify the title you want to display
priority: 1
# The base mount point name available on the tab. This name expands to create two mount points per tab, with` /context` and with `/cards`
mountPoint: "entity.page.pull-requests"
- path: "/"
title: "Changed Overview"
mountPoint: "entity.page.overview"
# Specify the order of tabs. The tabs with higher priority values appear first
priority: -6
----

You can configure dynamic front-end plugins to target the mount points exposed by the entityTabs configuration. The following are the default catalog entity routes in the default order:

.Input parameters
[cols="20%,20%,30%,30%", frame="all", options="header"]
|===
|Route
|Title
|Mount Point
|Entity Kind

|`/`
|Overview
|`entity.page.overview`
|Any

|`/topology`
|Topology
|`entity.page.topology`
|Any

|`/issues`
|Issues
|`entity.page.issues`
|Any

|`/pr`
|CPull/Merge Requests
|`entity.page.pull-requests`
|Any

|`/ci`
|CI
|`entity.page.ci``
|VAny

|`/cd`
|CD
|`entity.page.cd`
|Any

|`/kubernetes`
|Kubernetes
|`entity.page.kubernetes`
|Any

|`/image-registry`
|Image Registry
|`entity.page.image-registry`
|Any

|`/monitoring`
|Monitoring
|`entity.page.monitoring`
|Any

|`/lighthouse`
|Lighthouse
|`entity.page.lighthouse`
|Any

|`/api`
|Api
|`entity.page.api`
|kind: Service or kind: Component

|`/dependencies`
|Dependencies
|`entity.page.dependencies`
|kind: Component

|`/docs`
|Docs
|`entity.page.docs`
|Any

|`/definition`
|Definition
|`entity.page.definition`
|kind: API

|`/system`
|Diagram
|`entity.page.diagram`
|kind: System
|===

[NOTE]
====
Mount points within Catalog such as _`entity.page.*`_ are rendered as tabs and become visible only if at least one plugin contributes to them, or if they can render static content.
====
Loading