THIS IS A PROPOSAL.
Sets the fallback reviewers for pull requests to be a new `reviewers` team, which is a superset of `maintainers`.
The Backstage project sees a very large amount of activity. The project configuration currently has the `maintainers` team set as the gatekeepers of all pull requests, no matter how small or large. This puts pressure on the individual maintainers and can lead to longer lead times than desired.
As Spotify staffs up, and as external contributors move closer to the core of development, I propose that there needs to exist an intermediate step between "general contributor" and "full maintainer".
I propose that the set of people that shall have the rights to approve/merge pull requests is larger than just the maintainers. This would let us reduce pressure on individual maintainers and to expand the team at Spotify in an effective way. We could more easily perform goalie (rotating designated support person) duties with an extended team without using up critical maintainer voting slots.
It is important to note that the reviewers are not expected to behave as maintainers. Issues that are contested, or changes that have significant architectural effects on the code base, shall still be decided upon by maintainers. There is a certain amount of trust involved. This pull request puts the reviewers team at the root of the entire code base, but future tweaks may put the maintainers team as an owner of certain sub-directories if desired, to limit the reviewers' area of influence.
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
In order to use this plugin, you must set the
`backstage.io/code-coverage` annotation on your entity.
```yaml
backstage.io/code-coverage: enabled
```
There's a feature to only include files that are in SCM in the coverage
report, this is helpful to not count generated files for example. To
enable this set the `backstage.io/code-coverage` annotation to
`scm-only`.
```yaml
backstage.io/code-coverage: scm-only
```
The backend plugin provides API endpoints for submitting code-coverage
reports. Currently jacoco and cobertura are supported. These reports
are normalized to a json format that is stored in the database.
```json
// curl -X POST -H "Content-Type:text/xml" -d @cobertura.xml "localhost:7000/api/code-coverage/Component/default/entity-name?coverageType=cobertura"
{
"links": [
{
"href": "http://localhost:7000/api/code-coverage/Component/default/entity-name",
"rel": "coverage"
}
]
}
```
It also provides some additional API endpoints:
* Viewing the latest report
* Viewing a more condensed history of code coverage values
* Retrieving file contents from source-control, used by the UI
Provides a graph of code coverage change over time, as well as a file
view where you can see the highlighted lines.
Co-authored-by: nissayeva <natashaaay@gmail.com>
Signed-off-by: alde <r.dybeck@gmail.com>
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
Fredrik Adelöw