|
…
|
||
|---|---|---|
| .. | ||
| create-ci-branch.sh | ||
| fuzzbug_count_badge.py | ||
| fuzzbug_date_badge.py | ||
| generated_README.md | ||
| not_implemented_badge.py | ||
| not_implemented_count.py | ||
| populate_fuzzbug.sh | ||
| populate_not_implemented.sh | ||
| README.md | ||
Metrics
This is the metrics directory. It follows the evolution of the repository separately from the
repostory. You can find the actual metrics in the
ci-results branch of the jsparagus project. This branch is automatically generated using the create-ci-branch.sh script found in this directory. If there are issues with your fork, you can remove the ci-results branch, and the ci will automatically rerun the create-ci-branch script to reset it. Do not push manula data to this repository, it will be lost.
If you find that the ci-results branch has disappeared or been corrupted somehow, you can reset it by deleting it and recreating it.
git branch -D ci-results
cd .metrics
./create-ci-branch.sh
The create-ci-branch.sh file creates the branch, prepares it, and populates it with data from the past.
Making your own metrics
Make sure you do not use data that can not be automatically recovered. We cannot rely on the ci-results branch always being present, therefore anything that you write must be recoverable on its own, either by relying on external APIs or through some other mechanism.
Please update this README if you make any changes.
Types of CI Actions
These actions are all found in the .github/workflows directory
Rust.yml- Run on Pull Request
- runs every time there is a push to master, use for any metrics that are development related. Examples include linting, testing, etc.
ci-push.yml- Run on Push tomaster
- runs on self contained metrics. An example is the number of
NotImplementederrors in the codebase. This does not depend on anything external
ci-daily.yml- Run Daily
- a cron task that runs daily. Useful for metrics that need daily updates
ci-issue.yml- Run on issue open
- runs each time an issue is opened. Good for tracking types of issues.
Types of data
These are the types of data that this metrics folder tracks.
-
Rust Passing
- Ensures our internal tests are passing
- Updates on every pull request to master. See this action
-
NotImplemented Count
- counts number of NotImplemented errors in the codebase. This should slowly rundown to zero
- Updates on every push to master. See this action
-
Days Since last Fuzzbug
- tracks the last fuzzbug we saw, if it does not exist, return ∞, otherwise return the last date regardless of state.
- Updates daily, regardless of push. See this action
-
Fuzzbug open count
- tracks the number of open fuzzbugs
- Updates on issue open. See this action
-
Percentage of tests passing with SmooshMonkey
- TODO: tracks the number of tests passing without fallback. We should use the try api for this.
- Updates daily, regardless of push. See this action
-
Percentage of JS compilable with SmooshMonkey
- TODO: see comment about writing bytes to a file in this repo
- implementation is dependant on how we get the data. We need a robust solution for importing this data.