influxdata / influxdata/telegraf
chore: Fail CI when test-only dependencies are linked into the shipped binary
- Dominant language
- Go
- Stars
- 17.8k
- Forks
- 5.8k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 161
Description
### Problem
#19315 removed `testcontainers-go` from the shipped binary, where its `init()` was costing up to two minutes of startup on machines with many processes (#17709). The part worth fixing separately is that nothing caught it.
`scripts/check-deps.sh` already computes the exact dependency list of the binary and runs on every PR. `testcontainers-go` was in that output the whole time and the check still passed, because all it verifies is that every dependency has a license entry, and `docs/LICENSE_OF_DEPENDENCIES.md` duly listed testcontainers too. So the leak was recorded in two places and flagged by neither.
### Proposal
Add a denylist of modules that must never appear in the binary's dependency graph, so a leak becomes a red build on the PR that introduces it rather than a startup mystery months later.
Candidates:
- `github.com/testcontainers/...`
- `github.com/stretchr/testify/...`
Reproduce the current state with:
```shell
go list -deps ./cmd/telegraf | grep -E 'testcontainers|stretchr/testify'
```
On master that still prints four testify packages. Those are tracked in #19374 (four files that only need renaming to `_test.go`) and #19375 (the psutil mock, which is shared across eight packages and needs a package move instead).
Either of those could land first. The guard is worth having regardless, since it is what turns the next occurrence into a failed build.
### Open question
Whether the denylist belongs in `check-deps.sh` or in a small standalone CI step. `check-deps.sh` is about license coverage and this is about layering, so folding it in may be overloading that script.
Contributor guide
Research direction
Start with scripts/check-deps.sh and reproduce the current dependency graph using go list -deps ./cmd/telegraf, filtering for testcontainers and testify. Decide whether the denylist belongs in that script or a standalone CI step, then verify the build fails when a listed module appears in the shipped binary while existing license checks still pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, shell
- Domain
- build-system, ci-cd
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 65/100