CircleCI er et veldig enkelt verktøy som er godt konfigurert som veileder for prosjektene våre. Men er selve konfigurasjonen enkel? Dette avhenger selvfølgelig av prosjektets kompleksitet. I vårt tilfelle (mono repo) viste det seg å være vanskeligere enn forventet.
Konfigurasjonen for Ruby on Rails-prosjekter er ikke komplisert, og dokumentasjon beskriver nøyaktig hvert element i config.yml. Jeg vil imidlertid fokusere på circleci-verktøyene som brukes til å hjelpe oss med å holde kode rent og sikre god praksis.
RuboCope trenger sannsynligvis ingen introduksjon, men for de som ikke er kjent med det, er det en statisk Ruby-kodeanalysator og formaterer. Hvis du allerede bruker rubocop i din prosjektlegger du ganske enkelt til CircleCI i konfigurasjonsfilen:
ESLint er et verktøy for å identifisere og rapportere mønstre som finnes i ECMAScript- eller JavaScript koden, for å gjøre koden mer konsistent og unngå feil.
I RSpec er tester ikke bare skript som verifiserer programkoden, de er også detaljerte forklaringer på hvordan programmet skal oppføre seg, uttrykt på enkelt engelsk:
I tilfellet RSpec lagrer vi testresultatet i en tidligere opprettet katalog /tmp/test-results i filen rspec.xml, og deretter bruker vi butikktestresultater nøkkelen vi lagrer en gitt katalog. Nå gir fanen Innsikt oss tilgang til informasjon som median kompileringstid, tidspunktet for den siste kompileringen eller suksessraten. Du kan lese mer om fanen Innsikt her. Hvis vi ønsker å lagre rspec.xml-filen som en "artefakt", må vi legge til store_artifacts nøkkelen i konfigurasjonsfilen vår.
Brakeman er et statisk analyseverktøy som sjekker Ruby on Rails-applikasjoner for sikkerhetshull. Som standard returnerer Brakeman en utgangskode som ikke er null, hvis det oppdages sikkerhetsadvarsler eller skannefeil. Derfor fokuserte vi bare på kritiske feil, og advarslene ble slått av.
Hvis vi også ønsker å lagre skanneresultatet på samme måte som RSpec, vil konfigurasjonen vår se slik ut, og vi vil ha tilgang til filen vår i fanen Artifacts.
RubyCritic er en perle som bruker perler for statisk analyse, for eksempel Reek, Flay og Flog, for å gi en rapport om kvaliteten på koden din. Rapporten inneholder en A / B / C / D / F-vurdering, hver fil i prosjektet vårt som vi vil ha skannet og nøyaktige steder som trenger forbedring, og dokumentasjon med hvert varsel (f.eks: ForMangeMetoder). Dette verktøyet fungerer som en konsulent i prosjektet. På grunnlag av den mottatte rapporten er det utvikleren som tar den endelige avgjørelsen om koden vår faktisk må korrigeres. I vår circleci-konfigurasjon er det tilordnet en egen jobb som er ansvarlig for å utarbeide rapporten og sende en spesiell kommentar med resultatet på github.
Den grunnleggende konfigurasjonen av rubycritic er ikke forskjellig fra de foregående.
Som standard kjører vi gjennom pakken med informasjon om hvilken katalog vi vil skanne ./app, hvor vi vil lagre resultatet -p /tmp/rubycritic (rubycritic oppretter automatisk en katalog der vi vil lagre rapporten vår), i hvilket format -f json og alternativet -no- browser. Vi bruker også perlen circleci-coverage_reportersom etter skanningen legger en kommentar på github i vår pull-forespørsel med en lenke til rapporten og en prosentvis vurdering av de skannede filene.
For at den ovennevnte perlen skal fungere ordentlig sammen med circleci, må vi legge den til i prosjektet vårt og generere to nøkler (en av dem er circleci, den andre er github).
Standard installasjon:
Gemfile gem 'circleci-coverage_reporter'
Rakefile require 'circleci/coverage_reporter/rake_task' if ENV['CIRCLECI']
Seksjon "innstillinger" i prosjektet vårt. Når du har valgt "Create Token", endrer du scope for "all" og fyller ut Token label. Token til API vil bli generert etter å ha klikket på
COVERAGE_REPORTER_VCS_TOKEN
Omfang for nøkkel til repo
Etter at vi har generert nøklene, må vi legge dem til i miljøvariablene våre i Innstillinger: