Usamos activamente a plataforma no noso traballo soundQube para manter a calidade do código a un alto nivel. Ao integrar un dos proxectos escritos en VueJs+Typescript, xurdiron problemas. Por iso, gustaríame contarvos con máis detalle como conseguimos resolvelos.

Neste artigo falaremos, como escribín anteriormente, da plataforma SonarQube. Unha pequena teoría - o que é en xeral, para aqueles que están a escoitar falar dela por primeira vez:

soundQube (antigo Sonar) é unha plataforma de código aberto para a inspección continua e a medición da calidade do código.
Admite análise de código e detección de erros segundo as regras dos estándares de programación MISRA C, MISRA C++, MITRE/CWE e CERT Secure Coding Standards. Tamén pode recoñecer erros das listas de erros de programación OWASP Top 10 e CWE/SANS Top 25.
A pesar do feito de que a plataforma utiliza varias ferramentas preparadas, SonarQube reduce os resultados a un único panel, mantendo un historial de execucións e, polo tanto, permítelle ver a tendencia xeral dos cambios na calidade do software durante o desenvolvemento.

Podes atopar máis detalles en sitio web oficial

Admítense un gran número de linguaxes de programación. A xulgar pola información da ligazón anterior, son máis de 25 idiomas. Para admitir un idioma específico, debes instalar o complemento adecuado. A versión da comunidade inclúe un complemento para traballar Javascript (incluíndo typesсript), aínda que a wiki di o contrario. Detrás Javascript respostas do complemento SonarJS, para Typescript SonarTS respectivamente.

O cliente oficial úsase para enviar información de cobertura sonarqube-escáner, que, usando a configuración de configuración-file, envía estes datos ao servidor soundQube para unha maior consolidación e agregación.

Para Javascript ten envoltorio npm. Entón, imos comezar a implementación paso a paso soundQube в Vue- Uso do proxecto Mecanoscrito.

Para implantar un servidor soundQube aproveitemos atracador-compoñer.

sonar.yaml:

version: '1'
    services:
        simplesample-sonar:
            image: sonarqube:lts
            ports:
                - 9001:9000
                - 9092:9092
            network_mode: bridge

Lanzamento:

docker-compose -f sonar.yml up

Despois diso soundQube estará dispoñible en: http://localhost:9001 .

Aínda non hai proxectos nel e é xusto. Imos corrixir esta situación. Tomei o proxecto de exemplo oficial para VueJS+TS+Jest. Dobremolo cara a nós mesmos:

git clone https://github.com/vuejs/vue-test-utils-typescript-example.git

Primeiro necesitamos instalar o cliente soundQube, que se chama sonar-escánerpor npm hai un envoltorio:

yarn add sonarqube-scanner

E inmediatamente engade o comando a scripts para traballar con el.

package.json:

{
 … 
   scripts: {
      ...
      "sonar": "sonar-scanner"
      ...
   },
 …
}

A continuación, para que o escáner funcione, cómpre configurar a configuración do proxecto nun ficheiro especial. Comecemos polo básico.

sonar-proxecto.propiedades:

sonar.host.url=http://localhost:9001

sonar.projectKey=test-project-vuejs-ts
sonar.projectName=Test Application (VueJS+TS)

sonar.sources=src
# sonar.tests=
sonar.test.inclusions=src/**/*tests*/**
sonar.sourceEncoding=UTF-8

sonar.host.url - enderezo Sonar'A;
sonar.projectKey – identificador único do proxecto no servidor Sonar'A;
sonar.projectName – o seu nome, pódese cambiar en calquera momento, xa que o proxecto está identificado por projectKey;
sonar.fontes – cartafol con fontes, normalmente esta src, pero pode ser calquera cousa. Este cartafol establécese en relación ao cartafol raíz, que é o cartafol desde o que se inicia o escáner;
sonar.probas – un parámetro que vai en paralelo co anterior. Este é o cartafol onde se atopan as probas. Neste proxecto, non hai un cartafol deste tipo e a proba sitúase xunto ao compoñente que se está a probar no cartafol 'proba', polo que ignorarémolo polo momento e usaremos o seguinte parámetro;
sonar.proba.inclusións – camiño para probas usando unha máscara, pode haber varios elementos listados separados por comas;
codificación sonar.source - codificación de ficheiros fonte.

Para o primeiro lanzamento do escáner, todo está listo, agás a principal acción anterior: lanzar o propio motor de proba, para que poida xerar información sobre a cobertura, que o escáner utilizará posteriormente.

Pero para iso, cómpre configurar o motor de proba para xerar esta información. Neste proxecto, o motor de proba é ten. E a súa configuración está na sección correspondente do ficheiro paquete.json.

Engademos estas opcións:

"collectCoverage": true,
"collectCoverageFrom": [
      "src/**/*",
      "!src/main.ts",
      "!src/App.vue",
      "!src/**/*.d.*",
      "!src/**/*__tests__*"
],

É dicir, establecemos a propia bandeira para a necesidade de calcular a cobertura e a fonte (xunto con excepcións) en base á que se formará.

Agora imos realizar a proba:

yarn test

Veremos o seguinte:

O motivo é que non hai código no propio compoñente. Imos arranxar isto.

HelloWorld.vue:

...
methods: {
    calc(n) {
      return n + 1;
    }
  },
mounted() {
  this.msg1 = this.msg + this.calc(1);
},
...

Isto será suficiente para calcular a cobertura.

Despois de reiniciar a proba, asegurarémonos diso:

Na pantalla deberiamos ver información sobre a cobertura, e crearase un cartafol no cartafol do proxecto cobertura con información de cobertura das probas nun formato universal LCOV (extensión LTP GCOV).

Gcov é unha utilidade distribuída libremente para examinar a cobertura do código. Gcov xera o número exacto de execucións para cada instrución dun programa e permítelle engadir anotacións ao código fonte. Gcov vén como unha utilidade estándar como parte do paquete GCC.
Lcov - interface gráfica para gcov. Reúne ficheiros gcov para varios ficheiros fonte e produce un conxunto de páxinas HTML con información de código e cobertura. Tamén se xeran páxinas para facilitar a navegación. Lcov admite a cobertura de cadeas, funcións e ramas.

Despois de completar as probas, atoparase a información de cobertura cobertura/lcov.info.
Hai que dicir Sonar'De onde podo conseguilo? Polo tanto, imos engadir as seguintes liñas ao seu ficheiro de configuración. Pero hai un punto: os proxectos poden ser multilingües, é dicir, no cartafol src existen códigos fonte para varias linguaxes de programación e afiliación a un ou outro, e á súa vez, o uso dun ou outro complemento está determinado pola súa extensión. E a información de cobertura pódese almacenar en diferentes lugares para diferentes linguaxes de programación, polo que cada lingua ten a súa propia sección para configuralo. O noso proxecto utiliza Mecanoscrito, polo que necesitamos unha sección de configuración só para iso:

sonar-proxecto.propiedades:

sonar.typescript.coveragePlugin=lcov
sonar.typescript.lcov.reportPaths=coverage/lcov.info

Todo está listo para o primeiro lanzamento do escáner. Gustaríame sinalar que o proxecto é Sonar'e créase automaticamente a primeira vez que executa o escáner para un proxecto determinado. En tempos posteriores acumularase información para poder ver a dinámica dos cambios nos parámetros do proxecto ao longo do tempo.

Entón, imos usar o comando creado anteriormente paquete.json:

yarn run sonar

Nota: tamén pode usar o parámetro -X para un rexistro máis detallado.

Se o escáner se iniciou por primeira vez, primeiro descargarase o binario do propio escáner. Despois diso, comeza e comeza a dixitalizar o servidor Sonar'a para os complementos instalados, calculando así o idioma admitido. Tamén se cargan outros parámetros para o seu funcionamento: perfís de calidade, regras activas, repositorio de métricas, regras de servidor.

Nota: Non nos deteremos sobre eles en detalle no marco deste artigo, pero sempre podes contactar con fontes oficiais.

A continuación, comeza a análise do cartafol src para a dispoñibilidade de ficheiros fonte para todos os idiomas admitidos (se non se especifica un específico), coa súa indexación posterior.

A continuación veñen varias outras análises, nas que non nos centramos neste artigo (por exemplo, como listing, detección de duplicación de código, etc.).

Ao final do traballo do escáner, toda a información recollida é agregada, arquivada e enviada ao servidor.

Despois disto, xa podemos ver o que pasou na interface web:

Como podemos ver, algo funcionou, e mesmo amosa algún tipo de cobertura, pero non coincide coa nosa ten-informe.

Imos descubrir. Vexamos o proxecto con máis detalle, faga clic no valor de cobertura e "caiga" nun informe de arquivo detallado:

Aquí vemos, ademais do ficheiro principal, examinado OlaWorld.vue, tamén hai un arquivo principais.ts, o que estraga toda a imaxe da cobertura. Pero como é que o excluímos do cálculo da cobertura. Si, todo é correcto, pero estaba ao nivel ten, pero o escáner indexouno, polo que acabou nos seus cálculos.

Imos arranxar isto:

sonar-proxecto.propiedades:

...
sonar.exclusions=src/main.ts
...

Gustaríame facer unha aclaración: ademais dos cartafoles que se especifican neste parámetro, tamén se engaden todos os cartafoles indicados no parámetro sonar.proba.inclusións.

Despois de iniciar o escáner, vemos a información correcta:

Vexamos o seguinte punto - Perfís de calidade. Falei arriba do apoio Sonarde varias linguas ao mesmo tempo. Isto é exactamente o que estamos a ver. Pero sabemos que o noso proxecto está escrito TS, entón por que esforzar o escáner con manipulacións e comprobacións innecesarias. Estableceremos o idioma para a análise engadindo un parámetro máis ao ficheiro de configuración Sonar'A:

sonar-proxecto.propiedades:

...
sonar.language=ts
...

Volvemos a executar o escáner e vexamos o resultado:

A cobertura desapareceu por completo.

Se observamos o rexistro do escáner, podemos ver a seguinte liña:

É dicir, os nosos ficheiros de proxecto simplemente non estaban indexados.

A situación é a seguinte: con apoio oficial VueJs está no complemento SonarJSde quen é responsable Javascript.

Pero este soporte non está no complemento SonarTS para TS, sobre o que se abriu un ticket oficial no rastreador de erros Sonar'A:

Aquí tes algunhas respostas dun dos representantes dos desenvolvedores de SonarQube, que confirman este feito.

Pero todo funcionou para nós, obxeccións. Si o é, probemos un pouco "hackear".
Se hai apoio .vista-arquivos Sonar'Oh, entón imos tentar dicirlle que os considere como Mecanoscrito.

Engadimos un parámetro:

sonar-proxecto.propiedades:

...
sonar.typescript.file.suffixes=.ts,.tsx,.vue
...

Imos lanzar o escáner:

E, listo, todo volve á normalidade, e cun perfil só para Mecanoscrito. É dicir, conseguimos solucionar o problema no soporte VueJs+TS para soundQube.

Intentemos ir máis aló e mellorar un pouco a información de cobertura.

O que fixemos ata agora:

engadido ao proxecto Sonar- escáner;
montar ten para xerar información de cobertura;
configurado Sonar- escáner;
resolveu o problema de soporte .vista-arquivos + Mecanoscrito.

Ademais da cobertura das probas, hai outros criterios útiles interesantes para a calidade do código, por exemplo, a duplicación do código e o número de liñas (implicadas no cálculo dos coeficientes relacionados coa complexidade do código) do proxecto.

Na implementación actual do complemento para traballar TS (SonarTS) non funcionará CPD (Detector de copiar pegar) e contando liñas de código .vista-arquivos.

Para crear unha situación sintética de duplicación de código, simplemente duplique o ficheiro de compoñente cun nome diferente e engádeo tamén ao código principais.ts unha función ficticia e duplícaa cun nome diferente. Para comprobar a duplicación como en .vistae en .ts -arquivos.

main.ts:

...
function name(params:string): void {
  console.log(params);
}
...

Para iso, debes comentar temporalmente a liña de configuración:

sonar-proxecto.propiedades:

...
sonar.exclusions=src/main.ts
...

Reiniciemos o escáner xunto coa proba:

yarn test && yarn run sonar

Por suposto, a nosa cobertura caerá, pero agora non nos interesa.

En termos de duplicar liñas de código, veremos:

Para comprobar imos utilizar CPD-utilidade- jscpd:

npx jscpd src

Para liñas de código:

Quizais isto se resolva en futuras versións do complemento SonarJS(TS). Gustaríame sinalar que pouco a pouco están empezando a fusionar estes dous complementos nun só SonarJS, o que creo que é correcto.

Agora quería considerar a opción de mellorar a información de cobertura.

Ata agora podemos ver a cobertura das probas en termos porcentuais para todo o proxecto, e para os ficheiros en particular. Pero é posible ampliar este indicador con información sobre a cantidade unidade-probas para o proxecto, así como no contexto de expedientes.

Hai unha biblioteca que pode ten- converter o informe en formato para Sonar'A:
datos xenéricos de proba - https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Imos instalar esta biblioteca no noso proxecto:

yarn add jest-sonar-reporter

E engádeo á configuración ten:

package.json:

…
"testResultsProcessor": "jest-sonar-reporter"
…

Agora imos realizar a proba:

yarn test

Despois diso, crearase un ficheiro na raíz do proxecto informe-test.xml.

Imos usalo na configuración Sonar'A:

sonar-proxecto.propiedades:

…
sonar.testExecutionReportPaths=test-report.xml
…

E reinicia o escáner:

yarn run sonar

Vexamos que cambiou na interface Sonar'A:

E nada cambiou. O caso é que Sonar non considera os ficheiros descritos no informe de Jest como ficheiros unidade-probas. Para corrixir esta situación, utilizamos o parámetro de configuración Sonar sonar.probas, no que indicaremos explícitamente os cartafoles con probas (só temos un polo momento):

sonar-proxecto.propiedades:

…
sonar.tests=src/components/__tests__
…

Reiniciemos o escáner:

yarn run sonar

Vexamos o que cambiou na interface:

Agora vimos o número do noso unidade-probas e, tras fallar facendo clic dentro, podemos ver a distribución deste número entre os ficheiros do proxecto:

Conclusión

Entón, miramos unha ferramenta para a análise continua soundQube. Integramos con éxito nel un proxecto escrito VueJs+TS. Solucionáronse algúns problemas de compatibilidade. Aumentamos o contido de información do indicador de cobertura da proba. Neste artigo examinamos só un dos criterios de calidade do código (quizais un dos principais), pero soundQube admite outros criterios de calidade, incluíndo as probas de seguridade. Pero non todas estas funcións están totalmente dispoñibles comunidade-versións. Unha das características interesantes e útiles é a integración soundQube con varios sistemas de xestión de repositorios de código, como GitLab e BitBucket. Para evitar combinación de solicitude de extracción (fusión).'a á rama principal do repositorio cando a cobertura se degrada. Pero esta é unha historia para un artigo completamente diferente.

PS: Todo o que se describe no artigo en forma de código está dispoñible en o meu garfo.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Usas a plataforma SonarQube:

26,3%Si 5
15,8%No 3
15,8%Oín falar desta plataforma e quero usar3
10,5%Oín falar desta plataforma e non quero usala2
0,0%Estou usando unha plataforma diferente0
31,6%A primeira vez que escoito falar dela6

Votaron 19 usuarios. 3 usuarios abstivéronse.

Fonte: www.habr.com

Integración do proxecto VueJS+TS con SonarQube

Conclusión

Usas a plataforma SonarQube:

Engadir un comentario Cancelar resposta