Il a un aspect fort en tant que dossier de travail, mais j'ai créé une procédure de travail pour le contenu du titre, je vais donc le poster.
Il s'agit de la procédure de validation des résultats de mesure de couverture dans Codecov via la phase de construction de Wercker dans le référentiel GitHub des applications Java à l'aide de Gradle.
Codecov
URL
https://codecov.io/gh
Je me demandais lequel utiliser avec une combinaison, mais j'étais d'accord avec Article de référence et j'ai décidé d'utiliser Codecov.
Jacoco
Utilisé pour la mesure de la couverture. Courez de Gradle.
Diverses options ont été ajoutées à la nouvelle syntaxe Java, telles que la couverture ou non. Article de référence
Pour les constructeurs implicites pour lesquels aucun constructeur n'a été déclaré, si le code de test du constructeur (instanciation) n'est pas écrit, Jacoco le traitera comme non passant et le taux de couverture diminuera. Par exemple, cela peut se produire dans une classe utilitaire avec des méthodes statiques. Pour les classes qui ne sont pas instanciées, le constructeur doit être soigneusement privé, bien qu'il puisse être un peu redondant. Jacoco traitera alors le constructeur comme étant hors de couverture et la couverture de couverture ne diminuera pas inutilement. Si vous déclarez explicitement le constructeur, il doit être utilisé à partir du code produit, assurez-vous donc d'écrire correctement le code de test.
Il semble qu'il ait été pris en charge depuis Jacoco 0.8.0
Ajoutez ce qui suit à build.gradle.
//Spécifier le plug-in jacoco pour codecov
apply plugin: 'jacoco'
jacoco {
//Les informations de version sont http://www.eclemma.org/jacoco/Voir
toolVersion = "0.8.1"
}
jacocoTestReport {
reports {
xml.enabled = true
html.enabled = true
}
}
//Lorsque vous exécutez gradle build, vous exécutez également la mesure de la couverture dans Jacoco
build.dependsOn jacocoTestReport
Dans l'exemple de référence, la version Java de targetCompatibility a également été décrite, j'ai donc ajouté ce qui suit également.
targetCompatibility = 10
Rétrospective, y compris l'accumulation jusqu'à présent.
//Spécifiez le plug-in java pour construire respectivement le main et le test
apply plugin: 'java'
//Spécifiez un plug-in de guerre pour l'empaquetage en guerre
apply plugin: 'war'
//Spécifiez le plug-in d'application pour spécifier la classe exécutable et la classe contenant la méthode principale exécutable.
apply plugin: 'application'
//Spécifiez la classe cible d'exécution
mainClassName = 'kentfordevgithub.helloworld.HelloWorld'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = 10
targetCompatibility = 10
//Spécifiez le référentiel à utiliser
repositories {
//Utiliser le référentiel Maven
mavenCentral()
}
dependencies {
// JUnit
// https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-api
testCompile group: 'org.junit.jupiter', name: 'junit-jupiter-api', version: '5.2.0'
// https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-engine
testCompile group: 'org.junit.jupiter', name: 'junit-jupiter-engine', version: '5.2.0'
// https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-params
testCompile group: 'org.junit.jupiter', name: 'junit-jupiter-params', version: '5.2.0'
}
//Paramètres d'exécution de test dans Gradle
test {
//Paramètres pour exécuter Junit5 avec Gradle, Gradle4.Peut être décrit car Gradle prend en charge nativement Junit 5 à partir de 6
useJUnitPlatform()
//Nombre de fils de test parallèles(Nombre d'exécutions simultanées)L'ensemble(1 fil pour chaque classe de test)
maxParallelForks = 4
}
//Spécifiez le plug-in IDE pour prendre en charge chaque IDE
apply plugin: 'eclipse'
apply plugin: 'idea'
//Spécifier le plug-in jacoco pour codecov
apply plugin: 'jacoco'
jacoco {
//Les informations de version sont http://www.eclemma.org/jacoco/Voir
toolVersion = "0.8.1"
}
jacocoTestReport {
reports {
xml.enabled = true
html.enabled = true
}
}
//Lorsque vous exécutez gradle build, vous exécutez également la mesure de la couverture dans Jacoco
build.dependsOn jacocoTestReport
Ajout d'une commande pour envoyer les résultats de mesure de couverture à Codecov après la construction avec Gradle
$ CODECOV_TOKEN est une variable d'environnement pour faire référence au token affiché ci-dessus dans Codecov
Le nom de la variable d'environnement peut être modifié si un autre nom de variable d'environnement est acceptable.
- script:
name: post coverage to codecov
code: |
bash <(curl -s https://codecov.io/bash) -t $CODECOV_TOKEN
Rétrospective, y compris l'accumulation jusqu'à présent.
# This references an OpenJDK container from the
# Docker Hub https://hub.docker.com/_/openjdk/
# Read more about containers on our dev center
# http://devcenter.wercker.com/docs/containers/index.html
box: openjdk:10.0.1-jdk
# defining the dev pipeline
dev:
steps:
# A step that executes `gradle bootRun` command
- script:
name: run gradle
code: |
./gradlew bootRun
# Build definition
build:
# The steps that will be executed on build
steps:
# A step that executes `gradle build` command
- script:
name: run gradle
code: |
./gradlew --full-stacktrace -q --project-cache-dir=$WERCKER_CACHE_DIR build
- script:
name: post coverage to codecov
code: |
bash <(curl -s https://codecov.io/bash) -t $CODECOV_TOKEN
Créez codecov.yml dans le répertoire racine du référentiel
Décrivez ce qui suit. --Pour le seuil, etc., reportez-vous à celui défini dans RxJava. --Si vous avez un objectif, définissez-le en vous référant aux Spécifications. --Si le résultat de la mesure de couverture est inférieur aux valeurs cible et seuil, il est traité comme NG.
codecov:
notify:
require_ci_to_pass: yes
coverage:
status:
project:
default:
target: 95%
threshold: 1%
patch:
default:
target: 95%
threshold: 1%
changes: no
Le résultat de l'exécution Worflow de Wercker est immédiatement reflété, mais il faut un certain temps pour que le résultat de la vérification de Codecov soit reflété. Dans ce cas, vous pouvez exécuter manuellement la notification à partir de l'onglet Build de l'écran des détails de validation de Codecov.
Recommended Posts