Sebastian Poxhofer
fbedd41e82
* test: replace manual process.env mutation with vi.stubEnv
Enable Vitest's `unstubEnvs` so env stubs are reverted automatically
before every test, and convert the manual `process.env.X = ...` /
`delete process.env.X` pairs in specs to `vi.stubEnv()`.
This removes the hand-written `afterEach` cleanup blocks and the
`const OLD_ENV = process.env` / `process.env = { ...OLD_ENV }`
save-restore dance, which silently leaked state between tests when a
test set a variable without a matching delete.
Left as-is (incompatible with `unstubEnvs`, which unstubs before each
test, not after):
- module top-level env writes (cocoapods, gomod, post-update, pip-compile
and bundler artifacts specs)
- `beforeAll` env writes -- the two in `util/http` moved to `beforeEach`
* test: stop asserting on ambient environment variables
Three specs asserted on values that the surrounding environment can
override, so they only passed on a machine that happened not to set them:
- `util/exec/env`: `getChildProcessEnv()` forwards every entry of
`basicEnvVars`, but the spec only seeded a subset. Any other forwarded
variable that was set ambiently (e.g. a lowercase `http_proxy`) leaked
into the `toEqual` assertion. Clear all of them first.
- `util/git/index`: `process.env.GIT_SSH_COMMAND` deliberately overrides
the default that the two env-inheritance tests assert on. Clear it.
- `logger/pretty-stdout`: the colorized level strings are built at import
time, so the `beforeEach` setting `FORCE_COLOR` could never affect them
-- it was dead code, and the test silently assumed a terminal without
colour support. Derive the expectation the same way the module does.
* test(datasource/nuget): use a throwaway cache dir for nupkg downloads
The `determine source URL from nupkg` tests do not mock the filesystem,
so they really wrote downloaded packages into a fixed `/tmp/cache` path.
That fails wherever the system tmpdir is not writable, and two checkouts
running the suite at once would share the same directory.
Use `tmp.dir({ unsafeCleanup: true })` and clean it up afterwards, which
is the pattern the other specs that touch disk already use.
* feat(lint): add renovate/prefer-stub-env rule
Enforces in specs what the migration to `vi.stubEnv` established:
- assigning to or deleting `process.env.X` inside `beforeEach`, `afterEach`,
`it` or `test` is reported, with a fixer that rewrites it to `vi.stubEnv()`
- module scope, `describe` bodies and `beforeAll` / `afterAll` are left alone:
`unstubEnvs` reverts stubs *before* each test, so a stub created there is
gone by the time the first test runs, and those must keep assigning directly
- replacing the `process.env` object is reported everywhere and never fixed.
`vi.stubEnv()` captures the original object when the worker starts, so after
a reassignment its deletes silently target the old object
The rule found 28 further violations in specs the earlier sweep missed, since
that one was anchored on `delete process.env`. Twelve were auto-fixed; the
rest replaced `process.env` wholesale and are now `clearEnv()` from test/util.
`util/exec/index.spec.ts` opts out with a comment: it asserts on the whole
child env, and `vi.stubEnv()` cannot express that because it maps `PROD`,
`DEV` and `SSR` onto '' instead of deleting them.
The best way to lookup Go Modules is using Go proxies.
GOPROXY settings
This datasource will use default GOPROXY settings of https://proxy.golang.org,direct if the environment variable is unset.
To override this default and use a different proxy in self-hosted environments, configure GOPROXY to an alternative setting in env.
To override this default and stop using any proxy at all, set GOPROXY to the value direct.
Pseudo versions
Go proxies return an empty list of versions when queried (@v/list) for a package which uses pseudo versions, but return the latest pseudo-version when queried for @latest.
If the @latest endpoint returns a pseudo-version, and the release list is empty, then this datasource will return the latest pseudo-version as the only release/version for the package.
Checking for new major releases
When a Go proxy is queried for @v/list it returns only versions for v0 or v1 of a package.
Therefore Renovate will also query @v2/list just in case there also exists a v2 of the package.
Similarly, if the dependency is already on a higher version such as v5, Renovate will check in case higher major versions exist.
You do not need to be worried about any 403/404 responses which result from such checks - they are the only way for Renovate to know if newer major releases exist.
Release timestamps
A Go proxy reports the commit time of the tagged commit as a version's Time, which can be different to when the release first existed.
This inconsistency can lead to minimumReleaseAge being applied incorrectly to the Go module's updates.
!!! note
For modules hosted on GitHub, Renovate will look up if there is a GitHub Release on the repository, and if so, use the Release's publication time, if it's later than the timestamp reported by the Go proxy.
This lookup needs a GitHub token to be configured, and is skipped if the lookup fails, leaving the timestamp reported by the Go proxy in place.
For example, this happens when:
- an infrequently updated repository prepares a GitHub Release by creating a draft release
- some time passes, and the maintainers publish the Release
- no new commits are pushed to the release branch (i.e.
main) in that time
Fallback to direct lookups
If no result is found from Go proxy lookups then Renovate will fall back to direct lookups.