We want to create strong community of contributors -- all working together to create the kind of delightful experience that Backstage deserves.
Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given. ❤️
In general, we aim to stick as closely as possible to the contribution guidelines which apply to the Backstage project. If something is not covered in this document, please assume that the appropriate Backstage guideline will apply.
This repository will gather the plugins we have worked on, so contribution is more than welcome both in this repository in general, and in a scope of a particular plugin.
No one likes bugs. Report bugs as an issue here.
Look through the GitHub issues for bugs or problems that other users are having. If you're having a problem yourself, feel free to contribute a fix for us to review.
The best way to send feedback is to file an issue.
If you are proposing a feature:
- Explain in detail how it would work.
- Explain the wider context about what you are trying to achieve.
- Keep the scope as narrow as possible, to make it easier to implement.
- Remember that this is a volunteer-driven project, and that contributions are welcome :)
As the number of plugins included in this repository increases, so does importance of good E2E tests which will make sure everything runs as it is expected. In order to contribute to this, very important aspect, of this repository, we urge you to follow guidelines below:
E2E tests are integrated under /packages/app/cypress folder where you will find specific E2E test for every plugin under /packages/app/cypress/integrations. This means you should follow that pattern and add tests in appropriate plugin test files. We would also encourage you to add more fixtures under /packages/app/cypress/fixtures. For testing purposes you can use test-entity.yaml file which can be found under /packages/entities, which we have created especially for this purpose.
Have you started using any/some/all of our plugins? Adding your company to ADOPTERS really helps the project.
So...feel ready to jump in? Let's do this. 💯 👏
Start by reading repository README to get set up for local development. If you need help, just jump into our Discord chatroom.
We use the backstage-cli to build, serve, lint, test and package all the plugins.
As such, the same coding guidelines as in Backstage repository mostly apply.
We use changesets in order to prepare releases. To make the process of generating releases easy, please include changesets with your pull request. This will result in a every package affected by a change getting a proper version number and an entry in its `CHANGELOG.md.
Any time a patch, minor, or major change aligning to Semantic Versioning is made to any published package in plugins/, a changeset should be used.
In general, changesets are not needed for the documentation, build utilities or similar.
- Run
yarn changeset - Select which packages you want to include a changeset for
- Select impact of change that you're introducing, using
minorfor breaking changes andpatchotherwise. - Explain your changes in the generated changeset. See examples of well written changesets.
- Add generated changeset to Git
- Push the commit with your changeset to the branch associated with your PR
For more information, checkout adding a changeset documentation in the changesets repository.
Plugins are automatically published when a version bump is merged to the main branch. Please include version bumps with your pull requests if you would like them to be released.
We subscribe to the Spotify FOSS code of conduct which is used by the Backstage project.
If you experience or witness unacceptable behavior—or have any other concerns—please report it by contacting us via [email protected].
See SECURITY.md