Configuring plugins in Red Hat Developer Hub
{subtitle}
Abstract
- 1. Plugins in Red Hat Developer Hub
- 2. Dynamic plugin installation
- 2.1. Preinstalled dynamic plugins
- 2.2. Community plugins migration to the GitHub Container Registry
- 2.3. Red Hat supported plugins
- 2.4. Technology Preview plugins
- 2.5. Red Hat Technology Preview plugins
- 2.6. Community plugins
- 2.7. Deprecated plugins
- 2.8. Other installable plugins
- 2.9. Installing and using Ansible plug-ins for Red Hat Developer Hub
- 2.10. Installation and configuration of Keycloak
- 2.11. Installation and configuration of Nexus Repository Manager
- 2.12. Installation and configuration of Tekton
- 2.13. Enabling and configuring Argo CD plugin
Red Hat Developer Hub (RHDH) is an enterprise-grade, integrated developer platform, extended through plugins, that helps reduce the friction and frustration of developers while boosting their productivity.
1. Plugins in Red Hat Developer Hub
The Red Hat Developer Hub application offers a unified platform with various plugins. Using the plugin ecosystem within the Developer Hub application, you can access any kind of development infrastructure or software development tool.
The plugins in Developer Hub maximize the productivity and streamline the development workflows by maintaining the consistency in the overall user experience.
2. Dynamic plugin installation
The dynamic plugin support is based on the backend plugin manager package, which is a service that scans a configured root directory (dynamicPlugins.rootDirectory in the app config) for dynamic plugin packages and loads them dynamically.
You can use the dynamic plugins that come preinstalled with Red Hat Developer Hub or install external dynamic plugins from a public NPM registry.
2.1. Preinstalled dynamic plugins
Red Hat Developer Hub is preinstalled with a selection of dynamic plugins.
The following preinstalled dynamic plugins are enabled by default:
-
@red-hat-developer-hub/backstage-plugin-analytics-module-adoption-insights -
@red-hat-developer-hub/backstage-plugin-adoption-insights -
@red-hat-developer-hub/backstage-plugin-adoption-insights-backend -
@backstage-community/plugin-analytics-provider-segment -
@backstage/plugin-techdocs -
@backstage/plugin-techdocs-module-addons-contrib -
@backstage/plugin-techdocs-backend -
@backstage/plugin-events-backend-module-github -
@red-hat-developer-hub/backstage-plugin-extensions -
@red-hat-developer-hub/backstage-plugin-extensions-backend -
@red-hat-developer-hub/backstage-plugin-catalog-backend-module-extensions -
@red-hat-developer-hub/backstage-plugin-global-floating-action-button -
@red-hat-developer-hub/backstage-plugin-global-header -
@red-hat-developer-hub/backstage-plugin-dynamic-home-page -
@red-hat-developer-hub/backstage-plugin-scaffolder-backend-module-orchestrator -
@red-hat-developer-hub/backstage-plugin-orchestrator -
@red-hat-developer-hub/backstage-plugin-orchestrator-form-widgets -
@red-hat-developer-hub/backstage-plugin-orchestrator-backend -
@red-hat-developer-hub/backstage-plugin-orchestrator-backend-module-loki -
@red-hat-developer-hub/backstage-plugin-quickstart -
@backstage-community/plugin-scaffolder-backend-module-regex
The dynamic plugins that require custom configuration are disabled by default.
Upon application startup, for each plugin that is disabled by default, the install-dynamic-plugins init container within the Developer Hub pod log displays a message similar to the following:
======= Skipping disabled dynamic plugin ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic
To enable this plugin, add a package with the same name to the Helm chart and change the value in the disabled field to ‘false’. For example:
global:
dynamic:
includes:
- dynamic-plugins.default.yaml
plugins:
- package: ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic
disabled: false
The default configuration for a plugin is extracted from the dynamic-plugins.default.yaml file, however, you can use a pluginConfig entry to override the default configuration.
2.2. Community plugins migration to the GitHub Container Registry
Breaking Change in RHDH 1.9
Starting with Red Hat Developer Hub 1.9, community-supported plugins are no longer distributed as bundled wrappers in the Developer Hub container image. These plugins are now built using GitHub Actions and published exclusively to the GitHub Container Registry (ghcr.io).
If you use the plugins listed in this section, you must update your dynamic plugins configuration (in dynamic-plugins-default.yaml, your ConfigMap or CustomResource) to use the new oci://ghcr.io/… paths.
2.2.1. What changed
In Developer Hub 1.8 and earlier, community plugins were:
- Wrapped and bundled in the Developer Hub container image.
-
Referenced by using local paths, such as
./dynamic-plugins/dist/<plugin-name>.
Starting with Developer Hub 1.9, community plugins are:
- Built using GitHub Actions from the rhdh-plugin-export-overlays repository.
-
Published to
ghcr.io/redhat-developer/rhdh-plugin-export-overlays. Referenced by using OCI registry paths, such as
oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/<plugin-name>:<tag>.TipTo ensure environment stability, use a SHA256 digest instead of a version tag.
2.2.2. Migration steps
To migrate your configuration:
-
Identify plugins in your ConfigMap or CustomResource that use local paths starting with
./dynamic-plugins/dist/. Find the corresponding
ghcr.iopath in the following migration table:# Before (RHDH 1.8 and earlier) plugins: - package: ./dynamic-plugins/dist/backstage-community-plugin-jenkins disabled: false # After (RHDH 1.9+) plugins: - package: oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/backstage-community-plugin-jenkins:bs_1.45.3__0.26.0 disabled: false- Update your configuration to use the new OCI registry path.
2.2.3. Understanding the tag format
The ghcr.io image tags use the following format: bs_<backstage-version>__<plugin-version>
Example: bs_1.45.3__0.26.0: where * bs_1.45.3: Built against Backstage version 1.45.3 * 0.26.0: Nodejs-packaged Backstage plugin, version 0.26.0
2.2.4. Community plugins migration table
The following table lists all 35 community-supported plugins that have been migrated from bundled wrappers to ghcr.io.
Replace <tag> with the version tag corresponding to your Developer Hub version. For the latest tags, see the rhdh-plugin-export-overlays repository.
To ensure environment stability, use a SHA256 digest instead of a version tag.
| Plugin Name | Old Path (RHDH 1.8) | New Path (RHDH 1.9+) |
|---|---|---|
|
3Scale |
|
|
|
ArgoCD Backend |
|
|
|
Azure DevOps Backend |
|
|
|
Catalog Backend Module Azure DevOps Annotator Processor |
|
|
|
Catalog Backend Module Bitbucket Cloud |
|
|
|
Catalog Backend Module Bitbucket Server |
|
|
|
Datadog |
|
|
|
Dynatrace |
|
|
|
GitHub Actions |
|
|
|
GitHub Insights |
|
|
|
GitHub Issues |
|
|
|
GitHub Pull Requests |
|
|
|
GitLab Backend |
|
|
|
JFrog Artifactory |
|
|
|
Jenkins Backend |
|
|
|
Jenkins Scaffolder Backend Module |
|
|
|
Jira |
|
|
|
Lighthouse Backend |
|
|
|
Nexus Repository Manager |
|
|
|
PagerDuty Backend |
|
|
|
Quay Backend |
|
|
|
Roadie ArgoCD Backend |
|
|
|
Scaffolder Backend ArgoCD |
|
|
|
Scaffolder Backend Module Azure DevOps |
|
|
|
Scaffolder Backend Module Bitbucket Cloud |
|
|
|
Scaffolder Backend Module Bitbucket Server |
|
|
|
Scaffolder Backend Module DotNet |
|
|
|
Scaffolder Backend Module Gerrit |
|
|
|
Scaffolder Backend Module Quay |
|
|
|
Scaffolder Backend Module SonarQube |
|
|
|
Scaffolder Backend Module Utils |
|
|
|
Search Backend Module Azure DevOps |
|
|
|
Security Insights |
|
|
|
SonarQube Backend |
|
|
|
Tekton |
|
|
2.2.5. Plugins remaining bundled in RHDH 1.9
The following plugins remain bundled in 1.9 while transitioning to ghcr.io distribution in a future release:
| Plugin Name | Old Path (RHDH 1.9) | New Path (RHDH 1.10+) |
|---|---|---|
|
Quay |
|
|
|
Scaffolder Backend Module Quay |
|
|
|
Tekton |
|
|
|
Scaffolder Backend ArgoCD |
|
|
2.2.6. Troubleshooting
2.2.6.1. Plugin not loading after migration
If a plugin fails to load, perform the following checks:
-
Verify the
ghcr.iopath is correct and the image tag or digest exists. -
Confirm your cluster has network access to
ghcr.io. - Review Developer Hub logs for OCI pull errors.
To avoid unexpected updates, use a SHA256 digest instead of a tag.
2.2.6.2. Finding available tags
To list available image tags for a plugin, run the following command:
# Using skopeo (filter for bs_ tags only, excluding pr_ and next__ tags) skopeo list-tags docker://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/<plugin-name> | jq -r '.Tags[]' | grep '^bs_'
2.2.7. Additional resources
2.3. Red Hat supported plugins
Red Hat supports the following 29 plugins:
| Name | Plugin | Version | Path and required variables |
|---|---|---|---|
|
Adoption Insights |
0.6.2 |
| |
|
Adoption Insights |
|
0.6.2 |
|
|
Analytics Module Adoption Insights |
|
0.6.2 |
|
|
Analytics Provider Segment |
1.22.2 |
| |
|
Dynamic Home Page |
1.10.4 |
| |
|
GitHub Org |
0.3.16 |
| |
|
GitHub |
0.11.2 |
| |
|
GitHub |
0.9.2 |
| |
|
Global Floating Action Button |
|
1.7.3 |
|
|
Global Header |
1.20.1 |
| |
|
Keycloak |
3.16.0 |
| |
|
Kubernetes |
0.20.4 |
| |
|
Kubernetes |
|
2.13.0 |
|
|
Ldap |
0.12.0 |
| |
|
MS Graph |
0.8.2 |
| |
|
Orchestrator Form Widgets |
|
1.6.1 |
`` |
|
Orchestrator |
5.4.0 |
`` | |
|
Orchestrator |
|
8.6.0 |
`` |
|
Orchestrator |
|
1.3.2 |
`` |
|
Quickstart |
1.8.2 |
| |
|
RBAC |
1.47.4 |
| |
|
Regex |
2.11.0 |
| |
|
Signals |
0.3.10 |
| |
|
Tech Radar |
1.13.0 |
| |
|
Tech Radar |
1.12.0 |
| |
|
TechDocs Module Addons Contrib |
1.1.30 |
| |
|
TechDocs |
1.16.0 |
| |
|
TechDocs |
2.1.2 |
| |
|
Topology |
2.9.4 |
|
- For more information about configuring KeyCloak, see Configuring dynamic plugins.
- For more information about configuring TechDocs, see Configuring TechDocs.
2.4. Technology Preview plugins
Red Hat Developer Hub includes a select number of Technology Preview plugins, available for customers to configure and enable. These plugins are provided with support scoped per Technical Preview terms, might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information on Red Hat Technology Preview features, see Technology Preview Features Scope.
2.5. Red Hat Technology Preview plugins
Red Hat provides Technology Preview support for the following 18 plugins:
| Name | Plugin | Version | Path and required variables |
|---|---|---|---|
|
ACR |
1.20.2 |
| |
|
Bulk Import |
7.0.1 |
| |
|
Bulk Import |
7.0.1 |
| |
|
Events Backend Module GitHub |
0.4.6 |
| |
|
Extensions |
0.14.3 |
| |
|
Extensions |
|
0.14.3 |
|
|
Extensions |
0.14.3 |
| |
|
GitLab Org |
0.2.15 |
| |
|
GitLab |
0.7.5 |
| |
|
GitLab |
0.10.0 |
| |
|
Kubernetes |
0.12.13 |
| |
|
Notifications |
0.5.11 |
| |
|
Notifications |
0.3.16 |
| |
|
Notifications |
0.6.0 |
| |
|
Orchestrator Backend Module Loki |
|
1.0.0 |
|
|
Pingidentity |
|
0.9.0 |
|
|
Scaffolder Relation Processor |
|
2.11.0 |
|
|
Signals |
0.0.25 |
|
2.6. Community plugins
Red Hat Developer Hub (RHDH) includes a select number of community-supported plugins, available for customers to enable and configure. These community plugins are augmented by Red Hat to be dynamic plugin capable, and are provided with support scoped per Technical Preview terms.
RHDH includes the following 4 community plugins:
| Name | Plugin | Version | Path and required variables |
|---|---|---|---|
|
Argo CD |
2.12.2 |
`` | |
|
Azure |
0.2.15 |
| |
|
Http Request |
5.5.1 |
| |
|
ServiceNow |
|
2.11.0 |
|
Additional resources
2.7. Deprecated plugins
Red Hat Developer Hub (RHDH) includes a number of deprecated plugins, which are no longer being actively developed. It is recommended that if you depend on any of these plugins, you migrate to an alternative solution as soon as possible, as these plugins will be removed in a future release.
RHDH includes the following 2 deprecated plugins:
| Name | Plugin | Version | Path and required variables |
|---|---|---|---|
|
OCM |
5.11.1 |
| |
|
OCM |
5.12.2 |
|
2.8. Other installable plugins
The following Technology Preview plugins are not preinstalled and must be installed from an external source:
| Name | Plugin | Version | Installation Details |
|---|---|---|---|
|
Ansible Automation Platform Frontend |
1.0.0 | ||
|
Ansible Automation Platform |
1.0.0 | ||
|
Ansible Automation Platform Scaffolder Backend |
1.0.0 |
2.9. Installing and using Ansible plug-ins for Red Hat Developer Hub
Ansible plug-ins for Red Hat Developer Hub deliver an Ansible-specific portal experience with curated learning paths, push-button content creation, integrated development tools, and other opinionated resources.
The Ansible plug-ins are a Technology Preview feature only.
Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
2.10. Installation and configuration of Keycloak
The Keycloak backend plugin, which integrates Keycloak into Developer Hub, has the following capabilities:
- Synchronization of Keycloak users in a realm.
- Synchronization of Keycloak groups and their users in a realm.
2.10.1. Installation
The Keycloak plugin is pre-loaded in Developer Hub with basic configuration properties. To enable it, set the disabled property to false as follows:
global:
dynamic:
includes:
- dynamic-plugins.default.yaml
plugins:
- package: ./dynamic-plugins/dist/backstage-community-plugin-catalog-backend-module-keycloak-dynamic
disabled: false2.10.2. Basic configuration
To enable the Keycloak plugin, you must set the following environment variables:
-
KEYCLOAK_BASE_URL -
KEYCLOAK_LOGIN_REALM -
KEYCLOAK_REALM -
KEYCLOAK_CLIENT_ID -
KEYCLOAK_CLIENT_SECRET
2.10.3. Advanced configuration
Schedule configuration
You can configure a schedule in the app-config.yaml file, as follows:
catalog:
providers:
keycloakOrg:
default:
# ...
# highlight-add-start
schedule: # optional; same options as in TaskScheduleDefinition
# supports cron, ISO 8601 duration strings, and duration objects
frequency: { minutes: 1 }
# supports ISO 8601 duration strings and duration objects
timeout: { minutes: 1 }
initialDelay: { seconds: 15 }
# highlight-add-end
If you have made any changes to the schedule in the app-config.yaml file, then restart to apply the changes.
Keycloak query parameters
You can override the default Keycloak query parameters in the app-config.yaml file, as follows:
catalog:
providers:
keycloakOrg:
default:
# ...
# highlight-add-start
userQuerySize: 500 # Optional
groupQuerySize: 250 # Optional
# highlight-add-endCommunication between Developer Hub and Keycloak is enabled by using the Keycloak API. Username and password, or client credentials are supported authentication methods.
The following table describes the parameters that you can configure to enable the plugin under catalog.providers.keycloakOrg.<ENVIRONMENT_NAME> object in the app-config.yaml file:
| Name | Description | Default Value | Required |
|---|---|---|---|
|
|
Location of the Keycloak server, such as |
"" |
Yes |
|
|
Realm to synchronize |
|
No |
|
|
Realm used to authenticate |
|
No |
|
|
Username to authenticate |
"" |
Yes if using password based authentication |
|
|
Password to authenticate |
"" |
Yes if using password based authentication |
|
|
Client ID to authenticate |
"" |
Yes if using client credentials based authentication |
|
|
Client Secret to authenticate |
"" |
Yes if using client credentials based authentication |
|
|
Number of users to query at a time |
|
No |
|
|
Number of groups to query at a time |
|
No |
When using client credentials, the access type must be set to confidential and service accounts must be enabled. You must also add the following roles from the realm-management client role:
-
query-groups -
query-users -
view-users
2.10.4. Limitations
If you have self-signed or corporate certificate issues, you can set the following environment variable before starting Developer Hub:
NODE_TLS_REJECT_UNAUTHORIZED=0
The solution of setting the environment variable is not recommended.
2.11. Installation and configuration of Nexus Repository Manager
The Nexus Repository Manager plugin displays the information about your build artifacts in your Developer Hub application. The build artifacts are available in the Nexus Repository Manager.
The Nexus Repository Manager plugin is a Technology Preview feature only.
Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information on Red Hat Technology Preview features, see Technology Preview Features Scope.
Additional detail on how Red Hat provides support for bundled community dynamic plugins is available on the Red Hat Developer Support Policy page.
2.11.1. For administrators
2.11.1.1. Installing and configuring the Nexus Repository Manager plugin
Installation
The Nexus Repository Manager plugin is pre-loaded in Developer Hub with basic configuration properties. To enable it, set the disabled property to false as follows:
global:
dynamic:
includes:
- dynamic-plugins.default.yaml
plugins:
- package: ./dynamic-plugins/dist/backstage-community-plugin-nexus-repository-manager
disabled: falseConfiguration
Set the proxy to the desired Nexus Repository Manager server in the
app-config.yamlfile as follows:proxy: '/nexus-repository-manager': target: 'https://<NEXUS_REPOSITORY_MANAGER_URL>' headers: X-Requested-With: 'XMLHttpRequest' # Uncomment the following line to access a private Nexus Repository Manager using a token # Authorization: 'Bearer <YOUR TOKEN>' changeOrigin: true # Change to "false" in case of using self hosted Nexus Repository Manager instance with a self-signed certificate secure: trueOptional: Change the base URL of Nexus Repository Manager proxy as follows:
nexusRepositoryManager: # default path is `/nexus-repository-manager` proxyPath: /custom-pathOptional: Enable the following experimental annotations:
nexusRepositoryManager: experimentalAnnotations: trueAnnotate your entity using the following annotations:
metadata: annotations: # insert the chosen annotations here # example nexus-repository-manager/docker.image-name: `<ORGANIZATION>/<REPOSITORY>`,
2.11.2. For users
2.11.2.1. Using the Nexus Repository Manager plugin in Developer Hub
The Nexus Repository Manager is a front-end plugin that enables you to view the information about build artifacts.
Prerequisites
- Your Developer Hub application is installed and running.
- You have installed the Nexus Repository Manager plugin. For the installation process, see Section 2.11.1.1, “Installing and configuring the Nexus Repository Manager plugin”.
Procedure
- Open your Developer Hub application and select a component from the Catalog page.
Go to the BUILD ARTIFACTS tab.
The BUILD ARTIFACTS tab contains a list of build artifacts and related information, such as VERSION, REPOSITORY, REPOSITORY TYPE, MANIFEST, MODIFIED, and SIZE.
2.12. Installation and configuration of Tekton
You can use the Tekton plugin to visualize the results of CI/CD pipeline runs on your Kubernetes or OpenShift clusters. The plugin allows users to visually see high level status of all associated tasks in the pipeline for their applications.
2.12.1. For administrators
2.12.1.1. Installation
Prerequisites
-
You have installed and configured the
@backstage/plugin-kubernetesand@backstage/plugin-kubernetes-backenddynamic plugins. -
You have configured the Kubernetes plugin to connect to the cluster using a
ServiceAccount. The
ClusterRolemust be granted for custom resources (PipelineRuns and TaskRuns) to theServiceAccountaccessing the cluster.NoteIf you have the RHDH Kubernetes plugin configured, then the
ClusterRoleis already granted.-
To view the pod logs, you have granted permissions for
pods/log. You can use the following code to grant the
ClusterRolefor custom resources and pod logs:kubernetes: ... customResources: - group: 'tekton.dev' apiVersion: 'v1' plural: 'pipelineruns' - group: 'tekton.dev' apiVersion: 'v1' ... apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: backstage-read-only rules: - apiGroups: - "" resources: - pods/log verbs: - get - list - watch ... - apiGroups: - tekton.dev resources: - pipelineruns - taskruns verbs: - get - listYou can use the prepared manifest for a read-only
ClusterRole, which provides access for both Kubernetes plugin and Tekton plugin.Add the following annotation to the entity’s
catalog-info.yamlfile to identify whether an entity contains the Kubernetes resources:annotations: ... backstage.io/kubernetes-id: <BACKSTAGE_ENTITY_NAME>
You can also add the
backstage.io/kubernetes-namespaceannotation to identify the Kubernetes resources using the defined namespace.annotations: ... backstage.io/kubernetes-namespace: <RESOURCE_NS>
Add the following annotation to the
catalog-info.yamlfile of the entity to enable the Tekton related features in RHDH. The value of the annotation identifies the name of the RHDH entity:annotations: ... janus-idp.io/tekton : <BACKSTAGE_ENTITY_NAME>
Add a custom label selector, which RHDH uses to find the Kubernetes resources. The label selector takes precedence over the ID annotations.
annotations: ... backstage.io/kubernetes-label-selector: 'app=my-app,component=front-end'
Add the following label to the resources so that the Kubernetes plugin gets the Kubernetes resources from the requested entity:
labels: ... backstage.io/kubernetes-id: <BACKSTAGE_ENTITY_NAME>
NoteWhen you use the label selector, the mentioned labels must be present on the resource.
Procedure
The Tekton plugin is pre-loaded in RHDH with basic configuration properties. To enable it, set the disabled property to false as follows:
global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: ./dynamic-plugins/dist/backstage-community-plugin-tekton disabled: false
2.12.2. For users
2.12.2.1. Using the Tekton plugin in RHDH
You can use the Tekton front-end plugin to view PipelineRun resources.
Prerequisites
- You have installed the Red Hat Developer Hub (RHDH).
- You have installed the Tekton plugin. For the installation process, see Installing and configuring the Tekton plugin.
Procedure
- Open your RHDH application and select a component from the Catalog page.
Go to the CI tab.
The CI tab displays the list of PipelineRun resources associated with a Kubernetes cluster. The list contains pipeline run details, such as NAME, VULNERABILITIES, STATUS, TASK STATUS, STARTED, and DURATION.
Click the expand row button besides PipelineRun name in the list to view the PipelineRun visualization. The pipeline run resource includes tasks to complete. When you hover the mouse pointer on a task card, you can view the steps to complete that particular task.
2.13. Enabling and configuring Argo CD plugin
You can use the Argo CD plugin to visualize the Continuous Delivery (CD) workflows in OpenShift GitOps. This plugin provides a visual overview of the application’s status, deployment details, commit message, author of the commit, container image promoted to environment and deployment history.
2.13.1. Using the Argo CD plugin
Prerequisites
- You have enabled the Argo CD plugin in Red Hat Developer Hub RHDH.
Procedures
- Select the Catalog tab and choose the component that you want to use.
Select the CD tab to view insights into deployments managed by Argo CD.
Select an appropriate card to view the deployment details (for example, commit message, author name, and deployment history).
-
Click the link icon (
) to open the deployment details in Argo CD.
-
Click the link icon (
Select the Overview tab and navigate to the Deployment summary section to review the summary of your application’s deployment across namespaces. Additionally, select an appropriate Argo CD app to open the deployment details in Argo CD, or select a commit ID from the Revision column to review the changes in GitLab or GitHub.
Additional resources