Date
Attendees
Away
Goals
- Discuss PR process for UI modules and propose required steps prior to accepting PR.
- Discuss SonarQube Quality Gate required configuration and enforcement.
Helpful information to review prior to meeting:
- FOLIO-1049 - Getting issue details... STATUS
- FOLIO-1344 - Getting issue details... STATUS
- https://dev.folio.org/guides/code-analysis/
- https://docs.sonarqube.org/display/SONAR/Metric+Definitions
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 5 min | Open tasks housekeeping | Anton | |
| 30 min | PR process for UI modules | The Team | Please see note for this line item below. |
| 20 min | QualityGate | The Team | UI Testing team agreed to start using default SonarQube Quality Gate configuration. It will be tuned as required in the future. |
| 5 min | Next steps for BigTest implementation | The Team |
PR process for UI modules
| New Code | Old Code |
IDE |
|
|
Feature Branch Build |
|
|
Master Branch Build |
|
|
It may take multiple merges and build to Master for a module manually promoted for the nightly integration testing.
PR approval requirements
The team agreed not to make PA approval as a mandatory requirement for the merge to Master.
However, while the rule is not being physically enforced, UI Testing Team strongly suggest the following:
The fact that code review is not enforced via GitHub doesn’t mean it is not required.
Contributors who consistently merging to Master without code review will be not appreciated.
Developers should be actively seeking code review unless it is a real emergency change.
Code review step is included into DoD for a user story. Product owners shouldn’t accept stories that are missing code review.
Developer should plan PR timing to ensure that code review can be completed.
Avoid commits to Master on Friday.