mozilla-releng / mozilla-releng/scriptworker-scripts

coveralls support

Aperta
#450 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Lingua principale
Python
Stelle
16
Fork
38
Merge medio
1g 7h
PR unite (30g)
14

Descrizione

Support for coveralls needs attention.

We generate coverage data for each script via tox and then call coveralls to submit coverage data to coverage.io, but that's all legacy code that doesn't quite work currently. It appears that this was originally set up when each script was in a separate github repo, and using TravisCI. Each script's README points to coveralls.io badges for the old repos (like mozilla-releng/balrogscript, rather than mozilla-releng/scriptworker-scripts/balrogscript); of course those are all dormant currently.

As far as I can tell, coveralls.io assumes a one-to-one correspondence between a coverage project and a github repo: We can monitor coverage for mozilla-releng/scriptworker-scripts, but not mozilla-releng/scriptworker-scripts/balrogscript on its own.

Currently each scriptworker-scripts 'coveralls' command fails with the error message:

coveralls.exception.CoverallsException: Not on TravisCI. You have to provide either repo_token in .coveralls.yml or set the COVERALLS_REPO_TOKEN env var.

This does not cause a job failure (because of the leading hyphens in the main tox.ini), but you can see the tox taskcluster logs for details. The repo token can be found on coveralls.io. The Balrog project provides an example of specifying COVERALLS_REPO_TOKEN in a taskcluster project:

https://github.com/mozilla-releng/balrog/blob/main/.taskcluster.yml

Open questions:

  • Can we continue to call coveralls for each script, or do we need to call coveralls just once for scriptworker-scripts after each script has updated its coverage data?

  • Is there a way to track coverage per script, or do we just get one badge and report per repo? Can we live with that?

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia con il comando coveralls e le relative voci con trattini in tox.ini, poi esamina i log di Taskcluster e l’esempio .taskcluster.yml di Balrog. Controlla il README di ogni script per individuare i badge obsoleti. Il lavoro è completato quando l’invio della coverage funziona e il progetto ha preso una decisione chiara tra la reportistica a livello di repository e quella per script.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
python
Ambito
ci-cd, testing-qa
Tipo di issue
Bug
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Ferma
Chiarezza
Da chiarire
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.