The datolabs-io/backstage-plugins
repository is designed as a collaborative space to host and manage Backstage plugins developed by DatoLabs and the community. This repository provides plugin maintainers with tools for plugin management and publication. By contributing a plugin to this repository, maintainers agree to adhere to specific guidelines and a standardized release process detailed in this guide.
- [Contributing to datolabs-io/backstage-plugins](#Contributing to
datolabs-io/backstage-plugins
)
The plugins repository is under Apache 2.0 license. All plugins added & moved to the repository will be kept under the same license. If you are moving a plugin over make sure that no other license file is in the plugin workspace & all package.json
files either have no version defined or explicitly use "Apache 2.0".
Fork the repository into your own GitHub account and clone that code to your local machine. If you cloned a fork, you can add the upstream dependency like so:
git remote add upstream git@github.com:datolabs-io/backstage-plugins.git
git pull upstream main
After you have cloned the repository, you should run the following commands once to set things up for development:
cd backstage-plugins
yarn install
Most plugins come with a standalone runner that you can utilize to develop plugins in isolation. Navigate to a workspace and plugin folder and run yarn start
to launch the development standalone server.
For a richer development environment, some workspaces may provide a full Backstage environment that you can run with yarn dev
in the workspace root.
Important: Development environments are configured on a per-workspace basis. Check the workspace
README.md
for specific setup instructions.
All code is formatted with prettier
using the configuration in the repo. Configure your editor to format automatically, or use yarn prettier --write <file>
to format files.
All packages follow semantic versioning enforced through Changesets. This ensures proper version management and changelog generation.
To create a changeset:
- Navigate to the workspace root directory for your plugin
- Run
yarn changeset
- Select the packages and type of change
- Enter a description of the change
- Review the generated changeset file in
.changeset
- Commit the changeset file
Every PR with changes must include a changeset. Upon merging, a "Version Packages" PR will be created automatically. Merging this PR triggers the release process.
Workspace names should reflect their contained plugins (e.g., 'todo' for todo & todo-backend plugins).
To create a workspace:
cd backstage-plugins
yarn install
yarn create-workspace
Once you have a workspace, create new plugins using:
cd workspaces/your-workspace
yarn new
We use API Extractor to generate API Reports in Markdown format. To update or generate reports:
# Update all API reports
yarn build:api-reports
# Update specific plugin
yarn build:api-reports plugins/<your-plugin>
When submitting a PR, please:
- Include a clear description of changes
- Add appropriate changesets
- Update documentation as needed
- Include tests for new functionality
- Add screenshots for UI changes
- Ensure all commits are signed-off
The default merge strategy is squash merge. In cases where preserving commit history is important (like separate frontend/backend changes), rebase merge may be used with maintainer approval.
After submitting a PR:
- Automated checks will run
- Reviewers will be automatically assigned
- Address any feedback from reviewers
- Obtain required approvals
- Maintainers will merge approved PRs
Note: Keep your PR up to date by rebasing when needed. If you encounter
yarn.lock
conflicts, update your main branch and runyarn install
.
This CONTRIBUTING.md combines elements from both examples while:
- Customizing organization/repository names for DatoLabs
- Simplifying some sections while maintaining key information
- Adding clear structure with detailed but concise instructions
- Including practical tips for common contribution scenarios
- Maintaining focus on key workflows (changesets, API reports, PR process)
The main differences from the source files include:
- Removed organization-specific elements (like Red Hat's specific workflows)
- Simplified the migration process compared to the Backstage community version
- Focused on essential workflows while keeping instructions clear and actionable
- Added more direct guidance for common development tasks
- Streamlined the review process section
Would you like me to adjust any particular section or add more specific details for certain workflows?