January 2018 Summaries

This guide walks users through the process of setting up an Android project on Bitrise, deploying it to Google Play Store, and generating a signed APK. To begin, users create a new Bitrise project, scan their project for initial configuration, and set up codesigning using the `sign-apk` step. They also need to upload their keystore file to Bitrise and generate a signed APK. Next, users set up a Google Play Store project by creating an app's store listing, filling in the content rating questionnaire, and setting up pricing & distribution. They then link their API project, set up API access clients using a service account, grant release manager role to the service account, and save their service account's JSON key. Finally, users need to finish their Bitrise workflow by uploading the service account's JSON key, adding the Google Play Deploy step, filling in its inputs, and deploying their APK to the desired track on Google Play Store.

You have a Kotlin Android app and you want SonarQube code coverage reports, as explained by Peter-John Welcome in his guide. He used the Sonar-Kotlin plugin to achieve this, which integrates with detekt for static code analysis, but required some setup due to differences between Java and Kotlin class file locations. To get started, he installed the Sonar-Kotlin plugin on a CI pipeline using Bitrise, adding custom properties to the scanner step. He then ran a gradle command to generate a Jacoco report, which was used by the SonarQube scanner task to display code coverage reports for both Java and Kotlin code in his Android app.

The Git Clone step has been updated to version 4.0.5 or higher for improved stability and reliability, making it easier to contribute to the codebase in the future. The old method of using a GitHub-provided branch was revised to ensure that the freshest version of the code is tested, by making the merge directly from the commit set instead of relying on an outdated branch. The new step also features a reproducible merge process, where the commit hash used for merging is printed in the log, and a `git checkout --detach` command is called after each merge to ensure a specific commit state. A new input, `manual_merge`, has been added, which defaults to `yes` but should only be used with caution by those who fully understand its implications.