feat: add support for go:generate directives in gomod

[mglazer]

Changes

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.

Context

Please select one of the below:

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

The public repository: n/a (is private)

[CLAassistant]

All committers have signed the CLA.

[viceice]

LGTM besides some security concerns 🤔

[jamietanna]

Yeah this does technically have some very valid risks, because we are now executing arbitrary commands

Note that this does have similar risks to https://docs.renovatebot.com/modules/manager/gradle/#dependency-verification where running ./gradlew ... can effectively execute arbitrary code as part of any of the buildscripts

The code being executed (to generate code) could be maliciously attacked, similar to what we see with npm install's postinstall scripts

[mglazer]

@jamietanna : What is the generally accepted practice for dealing with these types of issues in renovate dependency bumps?

Possible options I can come up with:

1. Add a configuration option which only runs go:generate when a specific allowlist of dependencies is updated. This would minimize the attack possibilities since it allows me to control which dependencies get this behavior and which dependencies don't.
2. Run in a sandbox? Honestly unsure if this remotely feasible.

If you think 1 is viable, I suspect the right spot to insert it would be similar to where goGetDirs is currently configured:

https://docs.renovatebot.com/configuration-options/#gogetdirs

and add an option such as:

goGenerateAllowedDeps: [
  "github.com/trusted/dependency"
]

Where the valid config would be:

if empty: run go generate after updating any dependency
if set: only run go generate after updating the dependencies specified in the allowed list

Thoughts?

[jamietanna]

(Haven't forgotten about this - will get back to it this week - need to have a think)

[mglazer]

@jamietanna wanted to see if you had a chance to think through this? I'm happy to implement any solution you deem appropriate.

[jamietanna]

Apologies, will try to take a look today 🙇

Out of interest, would you be hoping to run this on the Mend hosted Renovate app? Or are you self-hosting?

(We'll probably not allow this by default on the Mend hosted Renovate app due to security risks)

[jamietanna]

Given go:generate commands may run a newly updated dependency (for instance, now including a version bump to a malicious version), I'd like to be more cautious around this functionality being enabled.

I'm wondering if we should instead "gate this" behind an opt-in flag.

This would then - in the next breaking change - include all unsafe executions, and require self-hosting administrators to enable them after they've considered the implications.

(I'm further documenting some of these risks in #39456)

What that means for this PR is that I'd request that we create a PR before this goes in to create this global self-hosting configuration option to allowlist these unsafe options (which can start empty).

Then, we'd tweak this PR to only execute this if it's in the allowlist.

@viceice do you agree with this suggested path forwards?

---

As mentioned, it's likely that we won't be enabling this by default with the Mend Developer Platform, for this reason.

(But as noted in https://docs.renovatebot.com/configuration-options/#postupgradetasks, we'll allow trusted OSS repos + paying customers to enable this)

But for folks self-hosting, it's completely fine for them to enable this.

[viceice]

sounds good

[jamietanna]

I've raised #39458 to get the feature refined - if you've not got capacity to look into starting this, @mglazer that's OK! We can pick it up on our side, and then once that's done, this PR can go in on top of that (outside of the allowlist)

[mglazer]

Thanks for the very detailed look into this. Just to answer some of the questions:

1. Yes, we self host renovate. Historically we've had a few commands that we've had to allow at the server layer. I wanted to add go generate support mostly to consolidate this down to a single command rather than having to add to an ever growing list of commands that could be run post-upgrade.
2. I'm happy to look into this. The one part I'm not sure about though is how this relates to allowedCommands. Under what conditions would you expect this to be different from that list?

[jamietanna]

I'm happy to look into this.

Awesome!

The one part I'm not sure about though is how this relates to allowedCommands. Under what conditions would you expect this to be different from that list?

The use of allowedCommands allows a self-hosted administrator to tune the commands that repositories can define in their postUpgradeTasks to execute. These are commands that are controlled by contributors in a repository, and they may/may not call unsafe code.

By default, that list is empty, so no commands are usable.

However, Renovate has a number of cases where Renovate will invoke commands that could contain unsafe code (as noted in #39456). These are controlled by the Renovate CLI maintainers, who will add commands (such as in this PR) and add them into i.e. postUpdateOptions

These commands aren't allowlisted by an administrator, and by upgrading the Renovate CLI version, you're potentially including new commands that could be executed, and introduce risks of supply chain attacks

However, the intent is that allowedUnsafeExecutions will make it possible to control these, giving self-hosted administrators control over any commands the Renovate maintainers have allowlisted

So to rephrase:

• allowedCommands: allow self-hosted administrators to control what user-controlled commands can be executed
• allowedUnsafeExecutions: allow self-hosted administrators to control what Renovate-maintainer-controlled commands can be executed

[jamietanna]

Thanks for #39573 - mind integrating this PR in with it, so this is now an option (but not allowed by default)?

[mglazer]

Thanks @jamietanna . I'm having trouble figuring out how to make the code coverage...higher. I think I have coverage for everything that I added.

[mglazer]

It also seems I'm missing something else, since this isn't working locally with these changes.

Even when logging my config:

DEBUG: CLI config
       "config": {
         "repositories": ["test-org/test-repo"],
         "allowedUnsafeExecutions": ["goGenerate"]
       }

I'm seeing:

 INFO: go generate command requested as a post update action, but goGenerate is not permitted in the allowedUnsafeExecutions

So there must be something else that I'm missing.

[mglazer]

Found the issue, it was the fact that the stage was set to global instead of repository....that was fun to find.

#39704

[mglazer]

@jamietanna : wondering if there's anything else that can help push this through? I'm having trouble figuring out how to get the test coverage higher given I believe my tests are covering the code paths.

[RahulGautamSingh]

Update the branch once, and see if it helps

[mglazer]

Thanks @RahulGautamSingh that wasn't quite it. I had to update a test to catch one code path that wasn't being tested (unfortunately, and I commented about this above, it required modifying some possibly questionable code logic).

[jamietanna]

OK, I've updated this PR, and given it a go against JamieTanna-Mend-testing/go-generate#3 - but it doesn't seem to have any changes committed for my generated changes - any idea?

Logs:

DEBUG: Updating all modified files since generated files were added (repository=JamieTanna-Mend-testing/go-generate, branch=renovate/golang.org-x-tools-0.x)
DEBUG: Updated 1 package files (repository=JamieTanna-Mend-testing/go-generate, branch=renovate/golang.org-x-tools-0.x)
DEBUG: Updated 3 lock files (repository=JamieTanna-Mend-testing/go-generate, branch=renovate/golang.org-x-tools-0.x)
       "updatedArtifacts": ["go.sum", "go.mod", "go.sum"],

[jamietanna]

Ignore ☝️ stringer wasn't quite set up - this now works 🚀

[github-actions]

🎉 This PR is included in version 42.50.0 🎉

The release is available on:

• GitHub release
• 42.50.0

Your semantic-release bot 📦🚀

[mglazer]

@jamietanna thank you so much for your help and support getting this change through. Really appreciate the help.

[jamietanna]

Thanks for the great work on this (and relevant prefactor changes) to get it in 🚀