RHTAP Backstage Plugins

Table of Contents

• Basic Information
  • Our Plugins
  • Plugin Distribution
  • Community Collaboration
  • Communication Channels
• Learning Resources
  • Basic Concepts
  • Hands-on Exercises
• Getting Access
  • Becoming a Plugin Maintainer
• Your Responsibilities
• Creating Pull Requests
• Testing
  • RHDH-local
  • Running Services Locally
• Helpful Links
  • Languages and Libraries
  • Service Documentation

Basic Information

Our Plugins

We maintain these plugins in the Backstage community:

• Multi Source Security Viewer
• Quay
• Red Hat ArgoCD
• Tekton

We don't maintain these plugins, but we do add features when needed:

• Jenkins
• Azure Devops

Plugin Distribution

We distribute our plugins as OCI artifacts that get loaded into RHDH.

The system that generates and distributes these plugins is currently being developed.

Community Collaboration

The Backstage repository is open source and not owned by Red Hat. This means:

• You'll work with Spotify developers and other external contributors
• PR reviews may depend on external developers' schedules
  • Some reviewers have set "office hours" that are not in-line with our plans(e.g., only reviewing PRs on Fridays)
• You'll need to monitor open Github issues related to our plugins
  • Create Jira issues for these Github issues to track the work

Communication Channels

You can join the Backstage community channels listed here: https://github.com/backstage/community?tab=readme-ov-file#backstage-community They use Discord as their main communication channel.

You can also add their community meetings to your Google calender, but there's no expectation to join these meetings.

Learning Resources

Basic Concepts

Before diving into development, understand:

• What is Backstage and its purpose
• What is RHDH (Red Hat Developer Hub)
• What is RHTAP?

Hands-on Exercises

Get practical experience with:

• Backstage prerequisites
• Running Backstage locally
• Introduction to Plugins
• Adding a plugin to your Backstage instance

Getting Access

Becoming a Plugin Maintainer

Follow these steps to become a plugin maintainer:

1. Get added to the CODEOWNERS file for our specific plugins
   • Example: See this PR
2. Request permission to be added as a plugin maintainer
   • Create an issue using this template
   • Select Option 3 (plugin maintainer)
   • Include a link to your CODEOWNERS PR
   • Be patient - the review process can take some time

Your Responsibilities

As a plugin maintainer, you'll need to follow the guidelines outlined here: https://github.com/backstage/community-plugins/blob/main/docs/plugin-maintainers-guide.md

Creating Pull Requests

When submitting changes:

1. Generate a changeset
   • Refer to semantic versioning to determine the correct bump-type
2. Complete as much of the PR checklist as possible

Testing

RHDH-local

For testing your plugins in RHDH you can use RHDH-local with our configs.

Your plugins should be loaded from OCI artifacts.

See these docs for more info on dynamic plugins and how to create and load OCI artifacts in RHDH.

Running services locally

Instead of provisioning a cluster you can follow these instructions for running services locally:

• ArgoCD
• Jenkins
• Tekton

Helpful Links

Languages and Libraries

• TypeScript Documentation
• PatternFly Component Library
• Material-UI (MUI) Component Library

Service documentation

• Tekton
• ArgoCD
• Quay
• Azure
  • Using Self-Hosted Linux Agents for Pipelines
  • Using Personal Access Tokens