Tooling to accept payload size changes
- Lingua principale
- JavaScript
- Stelle
- 77
- Fork
- 83
- Merge medio
- 2g 5h
- PR unite (30g)
- 37
Descrizione
Currently in the angular/angular repo, when a change affects payload size for integration test app or AIO, an error is thrown on CI ([example CI failure](https://app.circleci.com/pipelines/github/angular/angular/43342/workflows/f4014ab1-aff3-4298-944b-f64c6a615e5f/jobs/1130977)):
```
FAIL: Commit undefined uncompressed main fell below expected size by 500 bytes or >1% (expected: 231381, actual: 230780).
If this is a desired change, please update the size limits in file '../.cache/bazel/_bazel_circleci/9ce5c2144ecf75d11717c0aa41e45a8d/execroot/angular/bazel-out/k8-fastbuild/bin/integration/cli-hello-world-lazy/test.sh.runfiles/angular/goldens/size-tracking/integration-payloads.json'.
```
We have a number of test apps (~10) for which we track payload size, thus it takes time to manually update everything. Also, minor payload size deltas between the main and a patch branches causes issues during the merge (when merge is requested to both main and patch branches), thus engineers end up creating a new PR and re-do all the manual updates to payload sizes once again.
It'd be great if we can have a tooling to update payload sizes, similar to what we have for tracking the symbols (via `yarn symbol-extractor:update`). That'd improve the quality of life for us, reduce CI reruns and save a bunch of time.
Also, I noticed that the payload size error for each app is present in [the CI output](https://app.circleci.com/pipelines/github/angular/angular/43342/workflows/f4014ab1-aff3-4298-944b-f64c6a615e5f/jobs/1130977) more than once. Do we run it multiple times for some reasons?
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Direzione di ricerca
Inizia dal golden file integration-payloads.json e dall’entry point esistente yarn symbol-extractor:update. Traccia il modo in cui CI confronta il payload di ogni app di test e perché l’errore appare più di una volta; il lavoro è completo quando un comando di tooling aggiorna le dimensioni tracciate per tutte le app interessate senza modifiche manuali ripetute.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- angular, javascript
- Ambito
- build-system, ci-cd, tooling
- Tipo di issue
- Funzionalità
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Ferma
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 38/100