Туториалы
28 октября 2021
Туториалы
28 октября 2021
Интеграция detekt в рабочий процесс

Изучите, как интегрировать мощный инструмент detekt в разработку приложений для Android, чтобы помочь обнаружить и предотвратить потенциально проблемный код (так называемый «код с душком») в процессе разработки.

Существует несколько способов снизить "технический долг" на протяжении всего процесса разработки. Выявление потенциальных проблем на раннем этапе и их минимизация очень важны. Также неплохо поддерживать стиль кода и соглашения, принятые в вашей команде разработчиков.

detekt – это инструмент статического анализа кода для Kotlin, который поможет вам в этом. Он поставляется с широким набором установок. Он предоставляет вам возможности для их настройки, а также возможность добавлять свои собственные правила. Таким образом, добавление CI может оказаться полезным. CI (Continuous Integration) означает непрерывную интеграцию, процесс обеспечения регулярного добавления функций и исправления ошибок в приложении.

В этом туториале вы создадите DetektSampleApp, приложение, которое детально показывает работу detekt. В течение этого процесса вы изучите:

  • detekt и его особенности
  • добавление detekt в ваш проект
  • доступные наборы установок в detekt
  • написание собственных правил и процессоров
  • интеграция detekt в вашу IDE
  • добавление detekt при работе в GitHub

 

Приступим

Загрузите стартовый проект, нажав на кнопку Download Materials.

Запустите Android Studio 4.2.1 или более поздней версии и импортируйте стартовый проект. Затем сделайте сборку и запуск проекта. На вашем экране должно появиться окно:

Приложение показывает список установок detekt. Каждая установка имеет краткое описание. Щелкнув на любой из установок, вы увидите обзор официальной документации, которая загружается с веб-сайта detekt:

Возможности detekt

detekt – это инструмент статического анализа для языка программирования Kotlin. Он помогает улучшить вашу кодовую базу, применяя набор правил. Вы можете интегрировать его, чтобы избежать проблемного кода в вашей кодовой базе. Это полезно, особенно при работе в команде разработчиков.

У detekt есть несколько функций, которые делают его полезным дополнением к вашему проекту:

  • detekt предлагает анализ кода для проектов на Kotlin
  • detekt легко настраивается – вы можете настроить его в соответствии с вашими потребностями
  • вы можете скрывать предупреждения по мере необходимости
  • интеграция в IDE, SonarQube* и GitHub
  • вы можете указать порог несоответствия кода, чтобы останавливать сборку или выводить соответствующие сообщения
  • вы можете добавить базовый уровень кода и исключения для так называемых legacy проектов

Вы узнаете обо всех этих в функциях в данном туториале. Пришло время добавить detekt в ваш проект.

Добавление detekt в ваш проект

Вы можете легко добавить detekt в новый или уже существующий проект на Kotlin. Для существующих проектов вы добавите еще несколько настроек, чтобы предотвратить множество ошибок.

Добавление в новый проект

detekt доступен как плагин Gradle. Для новых проектов вам необходимо добавить плагин в файлы Gradle.

Перейдите к файлу build.gradle на уровне проекта. Добавьте соответствующий путь в блоке dependencies (зависимостей):


classpath "io.gitlab.arturbosch.detekt:detekt-gradle-plugin:1.17.1"

Здесь вы определяете путь, который Gradle будет использовать для загрузки плагина.

Далее, вам нужно добавить плагин в свой проект.

Ниже блока dependencies добавьте следующую строку:

apply plugin: "io.gitlab.arturbosch.detekt"

Таким образом, вы добавили плагин detekt в свой проект. Финальным шагом добавления плагина является его применение к файлу Gradle на уровне приложения.

Перейдите к файлу build.gradle на уровне приложения. Добавьте следующую строку:

apply plugin: "io.gitlab.arturbosch.detekt"

Это также позволяет использовать плагин в модуле приложения. После этого добавления сделайте синхронизацию Gradle. После завершения синхронизации ваш плагин установлен и готов к использованию!

Заметка

Для detekt требуется Gradle 6.1 или выше. Вы можете проверить поддерживаемую версию в документации на совместимость.

 

Запуск detekt в терминале

Теперь, когда у вас настроен плагин detekt, выполните следующую команду на своем терминале:

./gradlew detekt

После завершения задачи сборка завершится ошибкой со следующими результатами:

Следует отметить несколько моментов:

  • В самом верху detekt показывает предупреждения от Gradle. В настоящее время отображается предупреждение: Gradle plugin is deprecated (плагин Gradle устарел).
  • Далее вы увидите красный текст сообщения: Task :app:detekt FAILED. Ниже находится список установок в detekt. В данном случае у вас есть наборы правил naming и style. В каждом наборе правил вы можете увидеть правило, которое было нарушено, и имя файла в строке. Это упрощает определение того, где в коде нужно провести рефакторинг. В конце каждой строки цифрами указано время технического долга (жёлтым цветом).
  • Далее следует строка: Overall debt: 1h 25min. detekt оценивает общее время, которое потребуется, чтобы исправить все недостатки кода в вашем проекте. Представьте, что это новый проект, и у вас уже есть 1 час 25 минут долга. А если бы это был существующий проект, у вас могли бы быть дни и даже месяцы долга. Это уже «код с душком»!

Поздравляю! Вы успешно настроили detekt в своем новом проекте. Довольно просто, правда?

Теперь вы сосредоточитесь на том, чтобы узнать, как добавить его в текущий проект.

Добавление в текущие проекты

Интеграция detekt в текущий проект может привести к множеству предупреждений и нарушению правил. Долг может исчисляться часами, и у вас может не быть времени на его решение.

Один из вариантов - игнорировать устаревший код и вместо этого сосредоточиться на коде, который вы добавляете после интеграции detekt. Для этого detekt позволяет вам определить свойство baseline, которое генерирует список каждого нарушенного правила, которое будет игнорироваться detekt. Запустите команду ./gradlew detektBaseline, которая сгенерирует для вас базовый файл. Теперь при запуске ./gradlew detekt, detekt игнорирует предупреждения, перечисленные в базовом файле. Чтобы узнать больше о настройке baseline, ознакомьтесь с официальной документацией:

Заметка

Вы можете удалить baseline в любое время и снова увидите предупреждения. Для этого удалите сгенерированный файл app/detekt-baseline.xml.

В следующем разделе вы углубитесь в настройки detekt, чтобы узнать, что они из себя представляют.

 

Обзор наборов правил в detekt

DetektSampleApp уже включает в себя список наборов правил и их описания. Наборы правил содержат группу правил, которые проверяют соответствие вашему коду, чтобы улучшить его качество. Правила не влияют на функциональность вашего приложения. Вот общие наборы правил, которые существуют:

  • Comments: решают проблемы в комментариях и документации кода. Проверяют файлы заголовков, комментарии к приватным методам и недокументированным классам, свойствам или методам.
  • Complexity: этот набор содержит правила, сообщающие о сложном коде. Он проверяет сложные условия, методы, выражения и классы, а также сообщает о длинных методах и длинных списках параметров.
  • Coroutines: набор правил анализирует код на предмет потенциальных проблем с корутинами (сопрограммами).
  • Empty-Blocks: содержит правила, сообщающие о пустых блоках кода. Примеры включают пустые блоки catch, пустые блоки классов, пустые функциональные и условные функциональные блоки.
  • Exceptions: сообщает о проблемах, связанных с тем, как код генерирует и обрабатывает исключения. Например, есть правила, если вы обнаруживаете общие исключения среди других проблем, связанных с обработкой исключений.
  • Formatting: проверяет, соответствует ли ваша кодовая база определенному набору правил форматирования. Помимо прочего, позволяет проверять отступы, интервалы, точки с запятой или даже порядок импорта.
  • Naming: содержит правила, которые утверждают именование различных частей кодовой базы. Проверяет, как вы называете свои классы, пакеты, функции и переменные. Сообщает об ошибках, если вы не следуете установленным соглашениям.
  • Performance: анализирует код на предмет потенциальных проблем с производительностью. Некоторые из проблем, о которых следует сообщение, включают, например, использование ArrayPrimitives или неправильное использование цикла forEach.
  • Potential-Bugs: набор правил для обнаружения потенциальных ошибок.
  • Style: предоставляет правила, которые подтверждают стиль кода. Это поможет сохранить код в соответствии с указанными рекомендациями по оформлению стиля кода.

Каждый набор правил содержит огромное количество правил. В этом туториале рассматриваются наиболее распространенные правила. Чтобы узнать больше, не стесняйтесь проверять официальную документацию.

Некоторые правила по умолчанию неактивны. Вы должны активировать их самостоятельно. Как это сделать? Вы изучите это в следующем разделе.

 

Настройка detekt

Одна из особенностей detekt – это широкая возможность настроить его под свои нужды. Более того, это дает вам возможность легко включать или отключать правила в вашем проекте.

detekt использует файл конфигурации в стиле YAML для настройки отчетов, процессоров, ошибок сборки, набора правил и свойств правил.

В стартовом приложении переключитесь в режим просмотра проекта, и вы увидите файл detekt.yml, как показано ниже:

Откройте файл detekt.yml. Этот файл содержит набор правил и свойств, например, раздел comments:

comments:
  active: true
  excludes: "**/test/**,**/androidTest/**,**/*.Test.kt,**/*.Spec.kt,**/*.Spek.kt"
  CommentOverPrivateFunction:
    active: false
  CommentOverPrivateProperty:
    active: false
  EndOfSentenceFormat:
    active: false
    endOfSentenceFormat: ([.?!][ \t\n\r\f

Как видите, чтобы включить или отключить данное правило, вам просто нужно установить логическое значение active: true/false (вторая строка в коде сверху).

В приведенном выше коде у вас есть конфигурации для раздела comments, который установлен как активный. Есть дополнительное свойство для перечисления файлов, которые вы хотите исключить при сообщении о проблемах. В этом примере вы исключаете каталоги test и androidTest. Ниже вы дополнительно устанавливаете свойства для отдельных настроек в наборах правил. Например, UndocumentedPublicFunction не активен. detekt не сообщает об этом в вашей кодовой базе.

Вы можете настроить detekt.yml в соответствии с требованиями вашего проекта.

Чтобы эта конкретная конфигурация была прочитана detekt, вам необходимо добавить этот файл в конфигурацию вашего плагина. Для этого перейдите к файлу build.gradle на уровне проекта. Добавьте этот фрагмент под строкой apply:

subprojects {
 apply plugin: "io.gitlab.arturbosch.detekt"
 detekt {
   config = files("${project.rootDir}/detekt.yml")
   parallel = true
 }
}

Здесь вы указываете файл конфигурации для detekt. Он больше не будет использовать конфигурацию по умолчанию. Вы можете включить или отключить правила в файле detekt.yml. Эта конфигурация применяется ко всем подпроектам в вашем проекте.

Вы ознакомились с доступными вариантами конфигурации для detekt. Затем вы добавите больше методов, нарушающих наборы правил. Вы увидите, как detekt сообщает об этих нарушениях.

Добавление набора правил

Откройте класс MainActivity. Добавьте следующую функцию coroutineTestRules ниже метода onCreate:

import kotlinx.coroutines.GlobalScope
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch

private suspend fun coroutineTestRules() {
  GlobalScope.launch {
    delay(2000)
  }
}

Убедитесь, что вы импортировали пакеты, указанные сверху, или добавьте их, когда ваша IDE предложит вам подтвердить импорт этих пакетов. Этот метод тестирует корутины (сопрограммы).

Использовать GlobalScope в activity – это плохая практика. detekt вам напомнит об этом.

Окончательно, вызовите эту функцию в конце метода onCreate:

runBlocking { coroutineTestRules() }

Разрешите импорт, как только IDE предложит вам сделать это. Здесь вы вызываете свой метод coroutineTestRules() внутри runBlocking. Вы должны вызывать методы suspend внутри сопрограмм или других методов прерывания.

Заметка

Некоторые правила сопрограмм по умолчанию неактивны. Чтобы активировать это правило, добавьте следующий код в файл detekt.yml над разделом comments:

coroutines:
  active: true
  GlobalCoroutineUsage:
    active: true

Здесь вы устанавливаете для coroutine активный набор правил. Вы также активируете правило GlobalCoroutineUsage в процессе. Теперь выполните команду ./gradlew detekt на своем терминале. Ваши результаты будут следующими:

На изображении вы можете видеть, что отчет из терминала теперь включает набор правил coroutines. Он показывает долг и файл с расширением GlobalCoroutineUsage. Внизу отчета есть дополнительные сведения, как показано ниже:

В файле detekt.yml есть дополнительная конфигурация вверху. Эти настройки определяют отчеты, которые вы будете получать, и отчет о сложности проекта от detekt. Вы узнаете об этом позже в этом туториале.

 

Превышение установок

Добавьте следующий код под своей функцией coroutineTestRules в классе MainActivity:

// 1
private fun complexMethod(name: String, email: String, phone: String,
    address: String, zipCode: String, city: String, country: String): String {
  return name
}

// 2
private fun emptyMethod() {}

// 3
override fun toString(): String {
  throw IllegalStateException()
}

// 4
fun performanceIssues() {
  (1..19).forEach {
    print(it.toString())
  }
}

// 5
fun potentialBugs() {
  val test = when ("type") {
    "main" -> 1
    "main" -> 2
    else -> 3
  }
}

Вот описание приведенного выше кода:

  1. Это пример сложного метода. Метод имеет семь параметров, которые превышают максимальные шесть параметров, установленных detekt. Вы также можете изменить это количество в файле конфигурации.
  2. Это пустой метод. Подпадает под набор правил empty-blocks.
  3. Этот набор правил представляет собой exceptions. Этот метод вызывает исключение без причины. Исключение также возникло из непредвиденного местоположения.
  4. У вас есть цикл forEach в диапазоне, который приводит к проблемам с производительностью. detekt сообщает об этом в соответствии набором правил performance.
  5. У вас есть условие when, которое имеет два похожих состояния. Это может привести к ошибке в вашем приложении. detekt сообщает о таких случаях, «кода с душком» в соответствии с установленными правилами potential-bugs.

Выполните команду ./gradlew detekt на терминале, и вы увидите:

Вы узнали о наборах правил в разных сценариях. А как насчет случаев, когда detekt обнаруживает слишком много? Иногда вам может потребоваться отключить определенное правило для определенного метода, а не для всего проекта. В таких случаях вам нужно подавить проблемы. В следующем разделе вы узнаете, как устранить проблемы.

 

Исключение проблем

Чтобы detekt не отображал проблему для определенного метода, вы можете использовать аннотацию @Suppress. Выше функции complexMethod() добавьте следующую аннотацию:

@Suppress("LongParameterList")

В терминале выполните команду ./gradlew detekt и вы увидите:

На изображении видно, что detekt больше не жалуется на правило LongParameterList. Это применимо только к этому методу. Если у вас есть другой файл или класс со сложным методом, detekt все равно сообщит о проблеме.

Чтобы увидеть это в действии, добавьте этот новый метод ниже potentialBugs():

@Suppress("EmptyFunctionBlock")
private fun suppressedWarning() {
}

В этом методе вы исключаете правило EmptyFunctionBlock. В терминале выполните команду ./gradlew detekt и вы увидите:

В отчете нет проблем EmptyFunctionBlock в suppressedWarning(), но в emptyMethod() он все еще отображается.

Итак, вы узнали, как использовать правила, доступные в плагине detekt. В ваших проектах вам может потребоваться обнаруживать больше проблемного кода, который не является частью detekt. Вы узнаете, как это сделать дальше.

Написание собственных правил

Как упоминалось ранее, detekt позволяет расширять его функциональные возможности, добавляя собственные правила. Недавно был объявлен устаревшим плагин Kotlin Android Extensions. Это означает, что использование Kotlin Synthetic больше не рекомендуется. До появления ViewBinding это был стандартный способ доступа к представлениям в приложениях Android. Это устаревание затрагивает очень много проектов. Используя detekt, вы можете написать определенное правило, чтобы проверить его и остановить вашу сборку, если присутствует synthetic import.

Заметка

Вам больше не следует использовать Kotlin Android Extentions в своих проектах. Здесь он используется, чтобы продемонстрировать, как вы можете создавать собственные правила detekt.

Сначала перейдите в модуль customRules и добавьте эти зависимости в build.gradle:

// 1
compileOnly "io.gitlab.arturbosch.detekt:detekt-api:1.17.1"
// 2
testImplementation "io.gitlab.arturbosch.detekt:detekt-api:1.17.1"
testImplementation "io.gitlab.arturbosch.detekt:detekt-test:1.17.1"
testImplementation "org.assertj:assertj-core:3.19.0"
testImplementation 'junit:junit:4.13.2'

Фрагмент этого кода выполняет следующее:

  1. Добавляет зависимость от detekt API. Это необходимо для написания пользовательских правил.
  2. Добавляет тестовые зависимости. Для проверки ваших правил вам нужно detekt-test. Также требуется зависимость assertj-core.

Сделайте синхронизацию Gradle, чтобы добавить эти зависимости. Затем внутри пакета com.raywenderlich.android.customrules.rules в модуле customRules добавьте новый файл. Назовите его NoSyntheticImportRule.kt и добавьте следующее:

package com.raywenderlich.android.customrules.rules

import io.gitlab.arturbosch.detekt.api.*
import org.jetbrains.kotlin.psi.KtImportDirective
//1
class NoSyntheticImportRule : Rule() {
  //2
  override val issue = Issue("NoSyntheticImport",
      Severity.Maintainability, "Don’t import Kotlin Synthetics "
      + "as it is already deprecated.", Debt.TWENTY_MINS)
  //3
  override fun visitImportDirective(
      importDirective: KtImportDirective
  ) {
    val import = importDirective.importPath?.pathStr
    if (import?.contains("kotlinx.android.synthetic") == true) {
      report(CodeSmell(issue, Entity.from(importDirective),
          "Importing '$import' which is a Kotlin Synthetics import."))
    }
  }
}

Здесь происходит следующее:

  1. Класс NonSyntheticImportRule является наследником Rule из detekt API.
  2. Это метод Rule, который определяет вашу проблему. В этом случае вы создаете задачу с именем NoSyntheticImport. Вы указываете долг по проблеме, серьезность проблемы и сообщение, которое должен показать detekt. Долг представляет собой время, необходимое для устранения проблемы.
  3. Этот метод проверяет импорт в ваших файлах и классах. Здесь вы можете проверить, не содержит ли какой-либо импорт Kotlin synthetics. Если это так, вы сообщаете о проблемном коде сообщением.

 

Добавление собственного правила в detekt

После выполнения вашего класса правил вам необходимо создать класс RuleSetProvider. Этот класс позволяет detekt узнать о вашем правиле. Вы создаете его, реализуя интерфейс RuleSetProvider.

В том же пакете, что и указанный выше файл, создайте еще один новый файл.  Назовите его CustomRuleSetProvider.kt и добавьте следующий код:

package com.raywenderlich.android.customrules.rules

import io.gitlab.arturbosch.detekt.api.Config
import io.gitlab.arturbosch.detekt.api.RuleSet
import io.gitlab.arturbosch.detekt.api.RuleSetProvider

class CustomRuleSetProvider : RuleSetProvider {
  override val ruleSetId: String = "synthetic-import-rule"
  override fun instance(config: Config): RuleSet = RuleSet(ruleSetId, listOf(NoSyntheticImportRule()))
}

Реализация этого интерфейса предоставляет detekt набор правил, содержащий ваше новое правило. Вы также предоставляете id для своего набора правил. Вы можете сгруппировать любое количество правил в этом наборе правил, если у вас есть другие связанные правила.

Затем вам нужно сообщить detekt о вашем CustomRuleSetProvider. Перейдите в модуль customRules. Откройте src/main/resources/META-INF/services, и вы найдете io.gitlab.arturbosch.detekt.api.RuleSetProvider. Внутри этого файла добавьте:

com.raywenderlich.android.customrules.rules.CustomRuleSetProvider

Здесь вы добавляете полное квалифицированное имя для своего пакета CustomRuleSetProvider. Теперь detekt может найти класс, создать его экземпляр и получить ваш набор правил. Этот файл уведомляет detekt о вашем CustomRuleSetProvider.

Ура! Вы создали свое первое настраиваемое правило. Пришло время проверить, работает ли ваше правило.

 

Тестирование кастомного правила

Внутри каталога test в модуле customRules добавьте в пакет новый файл Kotlin и назовите его NoSyntheticImportTest.kt. Добавьте следующий код:

package com.raywenderlich.android.customrules.rules

import io.gitlab.arturbosch.detekt.test.lint
import org.assertj.core.api.Assertions.assertThat
import org.junit.Test

class NoSyntheticImportTest {
  @Test
  fun noSyntheticImports() {
    // 1
    val findings = NoSyntheticImportRule().lint("""
       import a.b.c
       import kotlinx.android.synthetic.main.activity_synthetic_rule.*
       """.trimIndent())
    // 2
    assertThat(findings).hasSize(1)
    assertThat(findings[0].message).isEqualTo("Importing " +
        "'kotlinx.android.synthetic.main.activity_synthetic_rule.*' which is a Kotlin Synthetics import.")
  }
}

В приведенном выше коде:

  1. Вы используете функцию расширения lint(), которая выполняет проверки и возвращает результаты. Внутри функций вы добавили два импорта. Один соответствует требованиям, а другой – нет.
  2. Используя приведенные выше результаты, вы выполняете утверждение, чтобы проверить,  имеет ли findings размер единицы. Это потому, что у вас есть один несоответствующий импорт. Вы также делаете утверждение, чтобы проверить наличие сообщения в вашем findings.

Щелкните значок Run в левой части noSyntheticImports(). Вы увидите, что ваши тесты пройдены, как показано ниже:

Вы можете увидеть, как проходит ваш тест. Это означает, что вы можете использовать свое правило в реальном проекте. Вы узнаете, как это сделать дальше.

Заметка

Не беспокойтесь о сообщении WARNING:An illegal reflective access operation has occurred.  Это относится к этому тесту, запущенному на самом себе. Этого не произойдет при использовании этого правила для модуля приложения.

 

Использование пользовательского правила в вашем проекте

Чтобы использовать это новое правило в своем проекте, вам необходимо применить модуль customRules в своем модуле приложения. Перейдите к файлу build.gradle на уровне приложения и добавьте в раздел dependensies следующее:

detekt "io.gitlab.arturbosch.detekt:detekt-cli:1.17.1"
detekt project(":customRules")

Первая строка относится к зависимости detekt-cli. detekt требует, чтобы он запускал ваше настраиваемое правило. Вторая строка указывает detekt использовать ваш модуль в качестве зависимости, чтобы иметь возможность использовать ваше настраиваемое правило.

Взгляните на класс SyntheticRuleActivity. Как видите, в нем есть Kotlin Synthetic Import. Вы будете использовать этот класс, чтобы проверить, работает ли правило.

import kotlinx.android.synthetic.main.activity_synthetic_rule.*

Наконец, вам нужно активировать свой набор правил и включить свое правило в файл конфигурации. Для этого добавьте следующий код в файл detekt.yml прямо над разделом comments:

synthetic-import-rule:
  active: true
  NoSyntheticImportRule:
    active: true

Выполните команду ./gradlew detekt в вашем терминале. Вы увидите следующие результаты:

Теперь detekt сообщает о проблеме под synthetic-import-rule. Он показывает долг в 20 минут и указывает на класс, который имеет импорт.

Поздравляю! Вы создали свое первое собственное правило. Далее вы узнаете о процессорах.

Обзор пользовательских процессоров в detekt

detekt использует процессоры для расчета показателей (метрик) проекта. Например, если вы включите процессоры подсчета, ваш отчет будет выглядеть следующим образом:

detekt настраивается, поэтому вы можете создать свой собственный процессор для статистики, которую хотите видеть в своем проекте. Создание настраиваемого процессора очень похоже на создание настраиваемого правила.

Чтобы создать собственный процессор, ваш класс должен реализовать FileProcessListener, который вызывается, когда начинается обработка файла. Вам также понадобится класс visitor, который зависит от статистики, которую вы хотите получить для показателей. visitor может быть для методов, циклов и так далее. Наконец, вам необходимо зарегистрировать полное имя вашего пользовательского процессора в файле с именем io.gitlab.arturbosch.detekt.api.FileProcessListener внутри src/main/resources/META-INF/services, чтобы проинформировать detekt о вашем процессоре. Это все, что вам нужно сделать. Вы не будете создавать процессор в этом туториале, но если вы хотите узнать больше о пользовательских процессорах, ознакомьтесь с документацией по пользовательским процессорам:

Вы видели, как добавить в проект собственные процессоры. Далее вы узнаете, как добавить detekt в GitHub Actions.

 

Интеграция detekt с GitHub Actions

GitHub Actions – это платформа GitHub для автоматизации рабочих процессов. С помощью действий GitHub вы можете добавить detekt action. Вы можете настроить его так, чтобы он запускался, когда кто-то загружает код (пушит) или предлагает изменить код в указанных ветвях.
Чтобы включить actions, перейдите в любой из ваших проектов GitHub и перейдите на вкладку Actions, как показано ниже:

Нажмите set up a workflow yourself. Вы увидите редактор рабочего процесса. Внутри редактора добавьте:

## 1
name: detekt
## 2
on:
 push:
   branches:
   - main
 pull_request:
   branches:
   - main
## 3
jobs:
 detekt:
   ## 4
   runs-on: ubuntu-latest
   steps:
      - name: "checkout"
        uses: actions/checkout@v2
      - name: "detekt"
        uses: natiginfo/action-detekt-all@1.17.0

Вот что выполняет приведенный выше код:

  1. Создает рабочий процесс с именем detekt.
  2. Указывает, когда будет запущен ваш рабочий процесс. В этом случае рабочий процесс запускается, когда в основной ветке есть запрос push или pull.
  3. Определяет задания, которые должен выполнить рабочий процесс. У вас есть только detekt.
  4. Указывает исполнителя и шаги для вашей работы. Вы также добавляете стороннее действие, называемое detekt action. Перед слиянием с основной ветвью он запускает проверки detekt, чтобы убедиться, что ваш код соответствует установленным методикам.

Сохраните рабочий процесс и создайте pull request. Для этого примера проекта pull request завершается следующей ошибкой:

Из Github Actions вы увидите:

Рабочий процесс завершается ошибкой, и отображается тот же отчет, который вы видели на своем терминале. Это очень полезная функция для detekt, так как она гарантирует, что любые изменения, добавленные в основную ветку, не имеют проблем. Создатель pull request должен сначала решить проблемы перед объединением pull request.

Вы видели, как добавить detekt в GitHub Actions. Далее вы узнаете, как добавить detekt в Android Studio.

 

Интеграция detekt в вашу IDE

Чтобы добавить плагин detekt в Android Studio, перейдите в Preferences/Settings ▸ Plugins ▸ Search detekt. Вы увидите плагин, как на изображении ниже:

Нажмите Install, чтобы установить плагин. После завершения установки выйдите из этого окна. Перейдите в Preferences/Settings ▸ Tools ▸ detekt и отметьте Enable Detekt.

Плагин detekt IDE также имеет следующие дополнительные параметры конфигурации:

  • Путь к файлу конфигурации: это ваш файл detekt.yml.
  • Базовый файл: путь к вашему пользовательскому baseline.xml.
  • Плагин Jars: путь к файлу jar, в котором есть ваши собственные правила, если вы хотите, чтобы detekt сообщал о них.

Благодаря этому IDE будет обнаруживать ошибки на ходу во время написания кода!

Поздравляю! Вы так много узнали о detekt и его возможностях. Теперь вы знаете, как добавить его в свой проект, создать собственные правила или даже интегрировать его в рабочий процесс в GitHub Actions или вашу IDE.

Оригинал статьи


Оцените статью
0
0
0
0
0

Чтобы добавить комментарий, авторизуйтесь
Войти
Акулов Иван Борисович
Пишет и переводит статьи для SwiftBook