* feat: add support for go:generate directives in gomod
This change adds a `goGenerate` postUpdateOption which enables
running `go generate ./...` after a dependency update.
Frequently when dependencies are brought in via tools or using
vendored code, and those dependencies are used for go:generate
instructions, we want to update the generated code after the dependency
has been updated.
Adding this as a postUpdateCommand wasn't really satisfactory since that
necessarily requires making a change in two spots (one in the allowed
commands, one in the postUpdateCommand). The other reason this was
undesirable was it would cause generate to run after every dependency
update, regardless of language.
* Updates
* Update fixes
* Self PR
* Fix docs link
* Trying to find the right path
* Fix
* Add deleted
* Fix
* And fix test...
* docs: tweak wording for `goGenerate`
* fix(types): don't default GlobalConfig
In a future change, `GlobalConfig.get` will correctly pull in the
defaults.
---------
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
When working with Go modules, the `golang.org/x` need to be treated
slightly differently, as they're hosted on Google's
`cs.opensource.google` infrastructure.
This adapts changes from [0] to:
- provide a linked `depName`, through to `pkg.go.dev` for the package
- provide a link through to `cs.opensource.google` for the given
changelog
We also wire this in by default for `config:recommended` users.
[0]: https://code.forgejo.org/forgejo/renovate-config/src/commit/42f4672021ac9907141d34966f38f735be401734/go.json#L59-L73
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
As noted in #39610 and #39736, folks using Bun aren't having the
`minimumReleaseAgeNpm` applying to them.
Although the use of the top-level should work, it doesn't seem to be.
To be super explicit, we can migrate this to a `packageRule` instead.
As part of #39685, we can start by making it clear that this type is
deprecated.
We'll also rename this to make it clear that it's not to be used any
more.
As part of future changes to add an OpenTelemetry attribute for the
splits, we should make sure that we have a common type for the splits,
which can be used with `addSplit`.
This refactors - with some help from GPT-4.1 - to use Vitest's timer
mocking.
This also requires a slight refactor of the implementation to test more
appropriately, without duplicate calls to `Date.now`.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
As noted in #39540, this would be a better option to have inbuilt to
Renovate.
Given the fact that the packages have different versioning, this may
lead to Immortal PRs.
Since rolling out the v42 Renovate release to the Mend Developer
Platform, we've been watching out for user reports for issues following
the addition of `security:minimumReleaseAgeNpm` in
`config:best-practices`.
In particular, two Discussions #39525 and #39477 are interesting cases
where a change from #39066 around `prCreation` has inadvertently caused
impact to PRs being created, as the CI needs to pass on the branch
before a PR is created (as intended by `prCreation=not-pending`).
However, these branches do not get CI running until there is a PR, which
means PRs will never be raised.
This partially reverts changes from #39066, #39116 and #38873, which
have been re-investigated since the reports.
Slightly surprising is the fact that the changes from #39066 have been
live on the Mend Developer Platform for a few weeks, but it wasn't
noticed until now, after the full rollout of v42.
Otherwise this will apply to all usages of `minimumReleaseAge` across
all datasources.
This also wasn't actually opting out of the `minimumReleaseAge`, too.
Similar to changes in c1469ab79c, we also
need to make sure that `minimumReleaseAge` checks are not applying to
`replacement`s, given we do not set a release timestamp (#39400) on
replacement suggestions.
This will be in place until #39400, when we should be able to remove
this workaround.
As noted in #39352, with Renovate 42's default enforcement of all npm
datasource package updates requiring `minimumReleaseAge` checks to
succeed, we're seeing that lock file maintenance updates are also being
blocked by this, despite Renovate itself delegating the logic to the
package manager.
We can opt-out the `lockFileMaintenance` updates from Minimum Release
Age checks, but make sure that we warn users of the risks.
* test: add failing test for reading configFileNames from env
* fix: move configFileNames handling to shared config parsing
* feat: allow configFileNames to be set through env
* fix: move unit test from file to index
* test: add test for setting configFileNames through cli
* fix: fix merge
* test: use multiple config file names in tests
* test: add a length check after adding custom filenames
Right now, the `global:safeEnv` preset is the only "global" preset we
have, which allows providing a means to share common used global
self-hosting configuration.
In the future, we will introduce some new global presets, which will
have more (possibly dangerous) configuration that administrators will
need to make sure they are informed of the pros and cons before
enabling.
Before we make this available, we should make sure that there is no
possibility for a repo configuration to extend from `global:`, ensuring
that this can only be set in global configuration's `extends` or
`globalExtends`.
There is currently no gap in security allowing this to be bypassed, or a
way to leverage this right now without making a number of code changes
(to remove other sets of validation).
We mark this as an error to make sure that the repo cannot proceed.
As we removed the only preset for npm in #38310, it's been noted that
the autogenerated docs page for this preset is now blank.
The simpler change is to remove the wiring in of the `npm:` presets.
Mike Glazer