Ecosystem metrics
- New Repos
- 17
- New
- Commits
- 566
- up 16.7%
- Releases
- 2
- down 71.4%
- Contributors
- 49
- up 8.9%
- Merges
- 16
- up 33.3%
Activity Overview
Commits and releases over time
- Commits
- Releases
- Authors
Repository Explorer
No repositories match that filter.
7259 commits in all time
Jun 19, 2026 18:14 – Sep 17, 2026 18:14 UTC
Merge 8c52c11cfbc1b38f02f1a956335d19bef09ce861 into 8cd5eb5f667c01ca6812e4d2f82930a793e23b18
eb9ca75a
pull/6740/merge
10/328 ++ 55 --
ci: share the unit test steps between the coverage workflows
pr-coverage.yml repeated the test invocation and coverage plumbing that ci-pr.yml and ci-nightly.yml already had. Move it into a composite action alongside setup-go and setup-test, parameterised by what actually differs between the three: -short, -p, where test results go, and whether coverage is measured. Nightly now measures coverage only on ubuntu-24.04. The other two platforms were paying for instrumentation whose output was never uploaded. Also shorten the comments added along with these workflows.
8c52c11c
pull/6740/head
7/117 ++ 132 --
codecov: report coverage of the change, not of the repository
Project coverage is the least trustworthy number in the comment: it compares against whichever commit last had an upload, and moves with the file set as readily as with the tests. Hide it and report patch coverage. Add components for the subsystems reviews are drawn around, so a ledger change is measured against ledger rather than against go-algorand. Wait for every partition before commenting, so a comment is never written from part of a run. Only pull requests are commented on, so push builds, which upload two reports rather than six, are unaffected.
6effb081
pull/6740/head
1/25 ++ 6 --
ci: add "/coverage" on-demand full coverage for pull requests
PR builds no longer measure coverage, so nothing reports the coverage of a change before it merges. Add a workflow that does it on request: commenting "/coverage" on a pull request runs the full -coverpkg suite against its head and uploads the result to Codecov attached to that pull request, where it can be compared against the baseline the push build publishes for the merge base. The run is measured the same way as the push build -- same tags, -race, no -short, CIRCLECI set -- so the two are comparable. Only the partitioning differs, 6 runners instead of 2, which changes how tests are spread but not which of them run. Codecov is given the head commit, branch and pull request number explicitly. issue_comment workflows run with the default branch checked out, so an upload left to infer its own context would be attributed to master and would overwrite the baseline. A fork's branch is named "owner:branch", matching Codecov's convention. Only OWNER, MEMBER and COLLABORATOR comments trigger it, since it builds and runs the pull request's code. The workflow itself always runs from the default branch, so a pull request cannot change what it does, and the job that checks the branch out holds only contents:read and no secrets; the write permission needed to acknowledge and report lives in separate jobs that never check out the branch. Extract the -coverpkg package list to scripts/coverpkg.sh rather than adding a fourth copy of it; the Makefile and both existing workflows now use it too. Verified to produce the same 112 packages as the pipeline it replaces. Move the coverage uploads to codecov-action@v7, which replaces "file" with "files", and drop scripts/travis/upload_coverage.sh, which nothing has referenced since CircleCI went away.
cad7383a
pull/6740/head
6/205 ++ 17 --
ci: only upload coverage from full-coverage runs
ci-nightly.yml is the push-to-master job and already measures coverage
with -coverpkg across all go-algorand packages. ci-pr.yml measured it
without -coverpkg -- counting only the lines each package's own tests
exercise -- and uploaded that too. Both kinds of report end up attached to
commits in master's history, so the coverage Codecov reports for a master
commit depends on which workflow happened to upload for it. Adjacent
commits alternate between ~47.9% (639 files, 6 sessions, PR runs) and
~63.8% (481 files, 2 sessions, push runs):
8cd5eb5f6 63.78% 481 files 2 sessions
288e1997e 47.90% 639 files 6 sessions
e8559cc9a 63.82% 481 files 2 sessions
7b9cb4d53 47.86% 639 files 6 sessions
3f8045596 63.83% 481 files 2 sessions
A PR's project-coverage delta was therefore decided mostly by which
regime its merge base happened to land in, roughly 16 points of noise
with nothing to do with the change under review.
Stop collecting and uploading coverage on PR runs unless the workflow was
dispatched with full_coverage, so every report Codecov holds is measured
the same way. Ordinary PR runs no longer pay for coverage instrumentation
at all.
Also drop flags.full_coverage.joined, which was meant to keep these
reports out of the project total but did not: on push commits the
full_coverage upload is the only session, so it became the total anyway.
24387b42
pull/6740/head
2/24 ++ 13 --
ci: merge raw coverage data with "go tool covdata" instead of -coverprofile
When -coverpkg is set, "go test -coverprofile" writes each instrumented
block once per test binary that links the package, and does not combine
them. "go tool cover" sums the duplicates and reads such a profile
correctly, but consumers that take the first or last occurrence instead do
not: on a two-binary run of ./config ./protocol the same profile reads as
58.8% (summed), 49.60% (last-wins) or 11.04% (first-wins).
Codecov appears to be one of those consumers. Comparing the nightly
full-coverage report against the cheaper PR report on adjacent master
commits, 118 of 373 comparable files report *lower* coverage under
-coverpkg, which attribution alone cannot cause: the nightly run executes
a superset of the PR run's tests. Individual files collapse while their
siblings in the same package are untouched --
data/transactions/logic/sourcemap.go 100% -> 0%,
ledger/eval/txntracer.go 92.85% -> 0%, util/metrics/prometheus.go
78.12% -> 0%.
Collect raw coverage data instead ("go test -cover ... -args
-test.gocoverdir=DIR") and merge it with "go tool covdata", which emits
each block exactly once with counts summed across every test binary that
exercised it. Across the whole repository that is 49,425 blocks with no
duplicates, and costs about 1.3s (20MB raw -> 644KB merged -> 3.7MB
profile).
The merge runs as its own step guarded by !cancelled(), matching the
upload step, so a failed test run still uploads the partial coverage it
produced.
One reporting change is not a correction: -coverprofile synthesized 0%
entries for packages that no test binary links, and covdata does not.
That drops daemon/kmd, netdeploy/remote/nodecfg and
ledger/store/trackerdb/testsuite -- 3 files, 431 lines, all at 0% --
raising the reported figure by 0.40pp for denominator reasons alone.
Also reference tool.mod by an absolute path in GOTESTCOMMAND so that
"make cover PACKAGE=X", which cds into the package directory, can find
it; that target has been failing with "go: open tool.mod: no such file or
directory" since it was added.
c56914ad
pull/6740/head
5/77 ++ 7 --
Merge e389bbd94d6ca2d2cb5117b9dd343479442f9104 into f599fe0b55ab4b2607da0e126e1c0209daed2f80
ba80593a
pull/667/merge
1/15 ++ 0 --
docs: note Homebrew tap trust requirement for AlgoKit brew commands
e389bbd9
chore/update-docs-homebrew-trust-steps
1/15 ++ 0 --
Merge bf079bc8e33c771f77e5dbf9d0121dc72c7e83c6 into 4ecf6d7dccc408e0117fc67b35f969f495dff07a
402ae586
pull/41/merge
15/837 ++ 107 --
Merge a4c24422fe65b26654df186c38dc97a1d90bc2eb into ec6c593a804c81f661cf4c003f17ff964d9cae95
4ecf6d7d
pull/36/merge
33/2,520 ++ 38 --