The repositories form a hierarchy.
-
The hierarchy starts from the code-only repository that contains the flawed code and the common boilerplate files.
-
The second level of hierarchy are OS\build-system repositories, such as windows-msbuild or linux-cmake. They take the code from the code-only repository as is and add the build configuration files for the corresponding OS and build system.
-
The last level of hierarchy are the CI-enabled repositoroes (for example, linux-cmake-azure-sc). These repositories build upon the repositories with configured builds and add a CI configuration for popular CI services. In the CI config they set up a SonarCloud (repository name ending in
-sc) or a SonarQube (repository name ending in-sq) connection.
Here is an example dependency path: code → linux-cmake → linux-cmake-azure-sc.
Since GitHub disallows forking of a repository within the same organization, here is the equivalent in git commands (on the example of linux-cmake):
Clone the newly created repository:
git clone [email protected]:sonarsource-cfamily-examples/linux-cmake cd linux-cmake
Add the code repository as a second remote named code:
git remote add code [email protected]:sonarsource-cfamily-examples/code
Get the code:
git pull code main
If the contents of the code repository changes, you can pull the changes with the last command.
Push the changes to the custom repository:
git push origin main
This will enable the flow of changes from the code repository to the linux-cmake repository (the first arrow in the example above).
To make the changes flow further to the linux-cmake-azure-sc repository:
git clone [email protected]:sonarsource-cfamily-examples/linux-cmake-azure-sc cd linux-cmake-azure-sc git remote add code [email protected]:sonarsource-cfamily-examples/linux-cmake git pull code main git push origin main