web-dev-qa-db-fra.com

Utiliser PyLint dans Jenkins avec le plug-in et le pipeline des avertissements

Je veux utiliser PyLint sur Jenkins avec Plugin Warnings et Pipleine , car le plugin Violations est obsolète.

Il n'y a pas de documents ou d'exemples complets.

Il y a quelques informations :

timeout(time: 5, unit: 'MINUTES') {
  sh 'npm run lint:ci'
  step([$class: 'WarningsPublisher',
    parserConfigurations: [[
      parserName: 'JSLint',
      pattern: 'pmd.xml'
    ]],
    unstableTotalAll: '0',
    usePreviousBuildAsReference: true
  ])
}

et solutions de contournement :

pylint || exit 0

Mais cela ne suffit pas.

18
Paweł Prażak

J'ai réussi à le faire fonctionner:

sh 'pylint --disable=W1202 --output-format=parseable --reports=no module > pylint.log || echo "pylint exited with $?")'
sh 'cat render/pylint.log'

step([
        $class                     : 'WarningsPublisher',
        parserConfigurations       : [[
                                              parserName: 'PYLint',
                                              pattern   : 'pylint.log'
                                      ]],
        unstableTotalAll           : '0',
        usePreviousBuildAsReference: true
])

Je ne sais toujours pas comment le configurer.

D'après ce que j'ai pu lire dans code source et tests , ce sont peut-être les paramètres possibles car ce sont les paramètres du constructeur:

  • healthy - Rapporte la santé à 100% lorsque le nombre d'annotations est inférieur à cette valeur
  • unHealthy - Rapporte la santé à 0% lorsque le nombre d'annotations est supérieur à cette valeur
  • thresholdLimit - détermine quelles priorités d'avertissement doivent être prises en compte lors de l'évaluation de la stabilité et de l'intégrité du build
  • defaultEncoding - l'encodage par défaut à utiliser lors de la lecture et de l'analyse des fichiers
  • useDeltaValues - détermine si le delta d'annotations absolu ou la différence de jeu d'annotations réelle doit être utilisé pour évaluer la stabilité de la construction
  • unstableTotalAll - seuil d'annotation
  • unstableTotalHigh - seuil d'annotation
  • unstableTotalNormal - seuil d'annotation
  • unstableTotalLow - seuil d'annotation
  • unstableNewAll - seuil d'annotation
  • unstableNewHigh - seuil d'annotation
  • unstableNewNormal - seuil d'annotation
  • unstableNewLow - seuil d'annotation
  • failedTotalAll - seuil d'annotation
  • failedTotalHigh - seuil d'annotation
  • failedTotalNormal - seuil d'annotation
  • failedTotalLow - seuil d'annotation
  • failedNewAll - seuil d'annotation
  • failedNewHigh - seuil d'annotation
  • failedNewNormal - seuil d'annotation
  • failedNewLow - seuil d'annotation
  • canRunOnFailed - détermine si le plug-in peut également s'exécuter pour les builds ayant échoué
  • usePreviousBuildAsReference - détermine s'il faut toujours utiliser la build précédente comme build de référence
  • useStableBuildAsReference - détermine si seules les versions stables doivent être utilisées comme versions de référence ou non
  • canComputeNew - détermine si de nouveaux avertissements doivent être calculés (par rapport à la ligne de base)
  • shouldDetectModules - détermine si les noms de module doivent être dérivés des fichiers de build Maven POM ou Ant
  • includePattern - Modèle de jeu de fichiers Ant à inclure dans le rapport
  • excludePattern - Modèle de jeu de fichiers Ant à exclure du rapport
  • canResolveRelativePaths - détermine si les chemins relatifs dans les avertissements doivent être résolus à l'aide d'une opération coûteuse en temps qui analyse tout l'espace de travail pour rechercher les fichiers correspondants.
  • parserConfigurations - les configurations de l'analyseur pour analyser les fichiers
  • consoleParsers - les analyseurs pour scanner la console

Et le parserConfigurationsjavadoc dit seulement:

  • pattern - le motif des fichiers à analyser
  • parserName - le nom de l'analyseur à utiliser

la liste des coutures des analyseurs doit être ici .

Si vous avez plus d'informations ou quelque chose à corriger, n'hésitez pas à modifier ou à déposer un commentaire.

26
Paweł Prażak

Notez qu'une alternative à || exit 0 ou || echo "failed" (ce qui est bien) consiste à utiliser pylint --exit-zero:

--exit-zero         Always return a 0 (non-error) status code, even if
                    lint errors are found. This is primarily useful in
                    continuous integration scripts.
5
javabrett