Skip to content

thesohelshaikh/android-ci

Repository files navigation

android-ci

Android Build Danger Checks ktlint

Tools used

  • GitHub Actions
  • Danger
  • Static Analysis
    • Detekt
    • ktlint
  • Pre commit hooks (TODO)

GitHub Actions

This project has GitHub Actions workflows to validate our code for us automatically. The project currently uses two workflows.

1. Android Build: The Android Build workflow automates the core checks for the repository: compile, unit tests. This is set to run on every push.

2. Danger Checks: This workflow runs general checks and performs general house keeping on pull requests. This is set to run on every pull request.

Danger

Danger runs during your CI process, and gives teams the chance to automate common code review chores.

This provides another logical step in your build, through this Danger can help lint your rote tasks in daily code review.

You can use Danger to codify your teams norms. Leaving humans to think about harder problems.

She does this by leaving messages inside your PRs based on rules that you create with the Ruby scripting language.

Over time, as rules are adhered to, the message is amended to reflect the current state of the code review.

Static Analysis

This project leverages static analysis to ensure that the codebase meets certain standards that can be verified through automation. Two of these libraries are Detekt and Ktlint.

Detekt

Detekt is a static analysis tool that checks for code smells. Examples include magic numbers, complicated conditionals, long methods, long parameter lists, and so much more. It is highly configurable, and if you choose to turn off any checks or customize thresholds you can do so in the config file.

To run a detekt validation, use the following Gradle command:

./gradlew detekt

Ktlint

Ktlint is a static analysis tool from Pinterest that prevents bike shedding when it comes to code formatting. It also comes with a Gradle task to automatically format your entire codebase, if it can. The benefit of a tool like this is to ensure everyone on the team will have code formatted the same way, and there's no debating around white spaces, indentation, imports, etc.

We use the JLLeitschuh Ktlint Gradle plugin in this project.

The following Gradle commands can be helpful:

// Will format the codebase
./gradlew ktlintFormat

// Will check if everything is formatted correctly
./gradlew ktlintCheck

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published