Merge sapsailing_main into main

Author: axeluhl

wiki/info/landscape/building-and-deploying.md

@@ -98,7 +98,7 @@ Since we want to build and release two apps out of one Git repo and ideally with
 - ``release-buoy-pinger-app`` to release the SAP Sailing Buoy Pinger app with MoMa assembly ID 188
 - ``release-race-manager-app`` to release the SAP Sailing Race Manager app with MoMa assembly ID 189
 
-Both these branches derive from the branch ``hyperspace`` which is more like a proxy branch as its original changes with the pipeline / fastlane definition and a few changes to the top-level README and .gitignore files have now been merged fully into the main branch where they have no averse effects. However, pushing onto the ``hyperspace`` branch will trigger the Azure DevOps pipeline for a full build including "tests" and "scans." However, since we don't have any app-specific UI tests and instead focus on unit tests for the logic shared also with the back-end and GWT UI ("common" and "shared" bundle projects), we "simulate" successful tests to satisfy the build pipeline's requirement for tests to be present. See files ``dummy/TEST-dummy.xml`` and ``dummy/jacoco/jacocoTestReport.xml``. This lets the "quality" stage of the Azure Pipeline pass without complaints. The two app-specific branches each make four important adjustments compared to the ``hyperspace``/``master`` branch:
+Both these branches derive from the branch ``hyperspace`` which is more like a proxy branch as its original changes with the pipeline / fastlane definition and a few changes to the top-level README and .gitignore files have now been merged fully into the main branch where they have no averse effects. However, pushing onto the ``hyperspace`` branch will trigger the Azure DevOps pipeline for a full build including "tests" and "scans." However, since we don't have any app-specific UI tests and instead focus on unit tests for the logic shared also with the back-end and GWT UI ("common" and "shared" bundle projects), we "simulate" successful tests to satisfy the build pipeline's requirement for tests to be present. See files ``dummy/TEST-dummy.xml`` and ``dummy/jacoco/jacocoTestReport.xml``. This lets the "quality" stage of the Azure Pipeline pass without complaints. The two app-specific branches each make four important adjustments compared to the ``hyperspace``/``main`` branch:
 
 - The ``isRelease`` property is set to ``true`` for both app release branches to force the signing / releasing process
 - The ``buildOutputPath`` is set to ``mobile/{app-directory}`` for the respective app to limit the number of files staged (artifacts staged are the unsigned .apk file, the files2sign.json and the zipped archive of all sources that went into the app)