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.
Keeps Git submodules updated within a repository.
You can customize the per-submodule checks of the git-submodules manager like this:
{
"ignoreDeps": ["path/to/submodule", "path/to/submodule2"],
"git-submodules": {
"enabled": true
}
}
Updating to Specific Tag Values
If you want to update your Git submodules to a specific tag, you can set the desired tag as the branch in your .gitmodules file.
Renovate will then automatically update this version to the latest Git branch or tag which satisfies your versioning scheme.
[submodule "renovate"]
path = deps/renovate
url = https://github.com/renovatebot/renovate.git
branch = v0.0.1
Note: Using this approach will disrupt the native git submodule update experience when using git submodule update --remote. You may encounter an error like fatal: Unable to find refs/remotes/origin/v0.0.1 revision in submodule path... because Git can only update submodules when tracking a branch.
To manually update the submodule, navigate to the submodule directory and run the following commands: git fetch && git checkout <new tag>.
Private Modules Authentication
Before running the git commands to update the submodules, Renovate exports git insteadOf directives in environment variables.
The following logic is executed prior to "submodules" updating:
The token from the hostRules entry matching hostType=github and matchHost=api.github.com is added as the default authentication for github.com.
For those running against github.com, this token will be the default platform token.
Next, all hostRules with both a token or username/password and matchHost will be fetched, except for any github.com one from above.
Rules from this list are converted to environment variable directives if they match any of the following characteristics:
- No
hostTypeis defined, or hostTypeisgit-tagsorgit-refs, orhostTypeis a platform (github,gitlab,azure, etc.)