test(tools): two testkit cache tests fail unless GOCACHE and GOMODCACHE are in the environment

Open Beginner friendly
  • Is something wrong?
#2,385 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
testing

Research direction

Start with tools/internal/testkit/env_test.go, focusing on TestEnvKeepsTheGoBuildAndModuleCachesOfTheCaller and TestEnvAtAsksTheGoItIsGivenForCachesTheCallerDoesNotSet. Reproduce the failures with GOCACHE and GOMODCACHE unset, then make the tests' expected cache values independent of the caller's Go configuration. Done means both tests pass with the variables unset and set.

Written by the indexing model from the issue text.

Description

backlog

Evidence at 362d5bb49

Two tests in tools/internal/testkit/env_test.go fail on a machine whose environment sets neither GOCACHE nor GOMODCACHE and whose Go configuration (go env -w) sets neither:

  • TestEnvKeepsTheGoBuildAndModuleCachesOfTheCaller (line 253)
  • TestEnvAtAsksTheGoItIsGivenForCachesTheCallerDoesNotSet (line 330)

Seen during a full cd tools && go test -count=1 ./... and just test-tools run on a second build machine (a fresh account, no Go configuration). Both passed once GOCACHE and GOMODCACHE were exported in the run's environment. Both pass on the main development machine, where the caches are set.

Both tests compare the kit's GOCACHE and GOMODCACHE with go env's answer (goEnv, env_test.go:245-248). The kit runs go env with the hermetic HOME it builds, so a machine whose caches come from the default location under the real HOME gets a different answer from the one goEnv returns for the test process.

Not shown

  • The mechanism: the cause above is the run's own diagnosis, from reading the two tests; the failing output was not kept.
  • That any test other than these two depends on the caller's cache variables.
  • That just test-tools fails the same way (it passed there once the variables were exported).

Falsifier

On a machine with no GOCACHE or GOMODCACHE in the environment and no go env -w value for either, cd tools && go test -count=1 ./internal/testkit/ passes. If it does, this issue is wrong.

Work

  1. Run the two tests with both variables unset (env -u GOCACHE -u GOMODCACHE) and keep the failing output. It must show which line fails.
  2. Make the tests independent of the caller's configuration: derive the expected value the way the kit does, or have the test set both variables itself with t.Setenv.
  3. Rerun with the variables unset and set. Both must pass.
Dominant language
C++
Stars
2
Forks
5
Avg merge
4h 21m
Merged PRs (30d)
801

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EchoTools/nevr-runtime

All issues in EchoTools/nevr-runtime

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.