Merge branch 'hyperspace' into release-buoy-pinger-app

This commit is contained in:
Axel Uhl committed 2026-10-04 20:49:46 +02:00
commit cfebe787bb
4 files changed
+18 -3

No files matched your search

+15
View File
@@ -45,6 +45,21 @@ platform :android do
gradle(task: "assembleRelease") # Build .apk
#gradle(task: "bundleRelease") # Build .aab
strip_build_type_from_apk_names(build_type: "release")
end
# Central Signing only signs APK file names allow-listed by Non-ABAP Assembly, as listed in each
# app's files2sign.json (<module>-unsigned.apk). AGP 8 names release APKs <module>-release-unsigned.apk,
# and its new Variant API no longer supports renaming outputs, so we rename them here.
def strip_build_type_from_apk_names(build_type:)
suffix = "-#{build_type}-unsigned.apk"
apks = (lane_context[SharedValues::GRADLE_ALL_APK_OUTPUT_PATHS] || []).select { |apk| apk.end_with?(suffix) }
UI.user_error!("No APK ending in #{suffix} found after Gradle build") if apks.empty?
apks.each do |apk|
target = apk.delete_suffix(suffix) + "-unsigned.apk"
UI.message("Renaming #{apk} to #{File.basename(target)}")
File.rename(apk, target)
end
end
desc "Call Kotlin Lint"
@@ -3,7 +3,7 @@
{
"version": "1.4.126",
"groupid": "com.sap.sailing",
"file": "com.sap.sailing.android.buoy.positioning.app-release-unsigned.apk",
"file": "com.sap.sailing.android.buoy.positioning.app-unsigned.apk",
"artifactid": "com.sap.sailing.android.buoy.positioning.app"
}
]
@@ -3,7 +3,7 @@
{
"version": "1.4.126",
"groupid": "com.sap.sailing",
"file": "com.sap.sailing.racecommittee.app-release-unsigned.apk",
"file": "com.sap.sailing.racecommittee.app-unsigned.apk",
"artifactid": "com.sap.sailing.racecommittee.app"
}
]
@@ -91,7 +91,7 @@ When working with Hyperspace to prepare the creation of the actual Azure Pipelin
The pipeline configuration is produced as a [Github pull request](https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/pull/1) for the Git repository used for Hyperspace onboarding. In particular, it contains a "Fastlane" configuration under ``fastlane/Fastfile`` and the actual pipeline configuration in ``azure-pipelines/mail.yml``. The fastlane config in ``fastlane/Fastfile`` we could slighly adjust and simplify because we only build ``.apk`` files, no ``.aab`` libraries. Furthermore, we need adjustments for the location of the ``gradle.properties`` file into which a git-based technical version identifier shall be generated during the build process. Later more on the details of this.
In the ``azure-pipelines/main.yml`` file under the ``trigger:`` property we configure which Git branches and/or tags shall trigger a pipeline execution. The core part then is defined by a reference to the pipeline's template, and specific adjustments can then be made to the template pipeline in the ``extends:`` section. The ``isRelease`` boolean property controls whether the build shall be a release build that triggers code signing, in particular. The ``productiveBranchName`` property controls for buils of which branch all scanning and test tasks shall be performed. We required special adjustments of the ``jdkVersion`` property to ``21`` and the ``androidVersion`` to ``35`` for our Gradle 8 / AGP 8 app build to work. Furthermore, the MoMa Assembly ID must be configured in the ``momaAssemblyId`` property. Each app folder now has its own ``files2sign.json`` file in its app folder under ``mobile/`` because this allows us to limit the build output to files under the app's own folder. The ``file`` property in ``files2sign.json`` must exactly match the name of the unsigned ``.apk`` produced by the Gradle build, because the "Call Central Signing Service" step of the pipeline template's central signing stage signs ``Binaries/Android/{file}`` literally. Since the migration to AGP 8 we no longer rename the build output, so this is the AGP default name ``{module-directory}-release-unsigned.apk``, e.g., ``com.sap.sailing.racecommittee.app-release-unsigned.apk``. (The "Find and Export Binaries" step finding an ``.apk`` does not imply that the name in ``files2sign.json`` matches.)
In the ``azure-pipelines/main.yml`` file under the ``trigger:`` property we configure which Git branches and/or tags shall trigger a pipeline execution. The core part then is defined by a reference to the pipeline's template, and specific adjustments can then be made to the template pipeline in the ``extends:`` section. The ``isRelease`` boolean property controls whether the build shall be a release build that triggers code signing, in particular. The ``productiveBranchName`` property controls for buils of which branch all scanning and test tasks shall be performed. We required special adjustments of the ``jdkVersion`` property to ``21`` and the ``androidVersion`` to ``35`` for our Gradle 8 / AGP 8 app build to work. Furthermore, the MoMa Assembly ID must be configured in the ``momaAssemblyId`` property. Each app folder now has its own ``files2sign.json`` file in its app folder under ``mobile/`` because this allows us to limit the build output to files under the app's own folder. The ``file`` property in ``files2sign.json`` must exactly match the name of the unsigned ``.apk`` staged by the build, because the "Call Central Signing Service" step of the pipeline template's central signing stage signs ``Binaries/Android/{file}`` literally. Furthermore, this file name is allow-listed by Non-ABAP Assembly (NAAS) for the MoMa assembly, together with group ID and artifact ID; a name not allow-listed yields an HTTP 406 "The requested list doesn't exist in the library files" from the SignServer. Our allow-listed names are ``{module-directory}-unsigned.apk``, e.g., ``com.sap.sailing.racecommittee.app-unsigned.apk``. Since AGP 8 names release APKs ``{module-directory}-release-unsigned.apk`` and its new Variant API no longer supports renaming outputs, the ``releaseBuild`` lane in ``fastlane/Fastfile`` renames them after ``assembleRelease``. (The "Find and Export Binaries" step finding an ``.apk`` does not imply that the name in ``files2sign.json`` matches.)
Since we want to build and release two apps out of one Git repo and ideally with one pipeline, we work with Git branches, one per app that we want to release, as follows: