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/e2e-tests
folder where you will find specific E2E test for every plugin. This means you should follow that pattern and add tests in appropriate plugin test files. 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.
As an engine for the testing we are using Playwright.
To execute end to end test locally you would need to install dependencies. TL/DR: run npx playwright install-deps
.
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 GitHub discussions.
We do require that all commits are signed. How to sign commits: signing-commits.
Don't forget to specify correct git user for signature, e.g. run git config user.email [email protected]
.
See also telling-git-about-your-signing-key.
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
minor
for breaking changes andpatch
otherwise. - 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.
Please include changeset files your pull requests if you would like them to be released. To create a changeset file run yarn changeset
and commit the resulting file to the pull request.
After merging a changeset file to main, a subsequent pull request is created automatically that makes the actual version bumps of the plugins/packages based on the changeset files. When this pull request is merged, the plugins and packages are automatically published to npm.
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, see Oriflame GitHub Home Page.
See SECURITY.md