Skip to content

Latest commit

 

History

History
34 lines (25 loc) · 2.03 KB

sonar-qube-workflow.md

File metadata and controls

34 lines (25 loc) · 2.03 KB

SonarQube workflow

Goals

 The Airbyte monorepo receives contributions from a lot of developers, and there is no way around human errors while merging PRs. Likely every language has different tools for testing and validation of source files. And while it's best practice to lint and validate code before pushing to git branches, it doesn't always happen. But it is optional, and as rule as we detect possible problems after launch test/publish commands only. Therefore, using of automated CI code validation can provided the following benefits:

  • Problem/vulnerability reports available when the PR was created. And developers would fix bugs and remove smells before code reviews.
  • Reviewers would be sure all standard checks were made and code changes satisfy the requirements.
  • Set of tools and their options can be changed anytime globally.
  • Progress of code changes are saved in SonarQube and this information helps to analyse quality of the product integrally and also its separate parts.

UML diagram

image

Used tools

Python

All Python tools use the common pyproject.toml file.

Common tools

Access to SonarQube

The Airbyte project uses a custom SonarQube instance. Access to it is explained here.

SonarQube settings

The SonarQube server uses default settings. All customisations are implemented into the Github WorkFlows. More details are here