dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.
https://docs.github.com/en/code-security/dependabot
MIT License
4.73k stars 1.02k forks source link

Major version updates for Go modules #2213

Open EricByers opened 5 years ago

EricByers commented 5 years ago

Add support for upgrading Go modules across major versions by rewriting import paths across the Go project.


Original issue description:

A few vendor libraries we use, make use of gopkg (for instance launch darkly says to use go get gopkg.in/launchdarkly/go-client.v4). In these cases, because the URL itself changes based on major packages, we're never alerted to the changes on dependabot (specifically because the last package would have been go get gopkg.in/launchdarkly/go-client.v3)

Was wondering if there could be specific support for gopkg, which would allow dependabot to open PR's for the update.

EricByers commented 5 years ago

After writing this I realized that we do not have to use gopkg, and can just use GitHub directly avoiding this issue.

greysteil commented 5 years ago

This is one for @hmarr, but we are planning to support major version update for Go in future. The tricky thing is that Dependabot will need to learn to update import statements to do so, which will likely mean cloning your repo (rather than just fetching the dependency files).

thepwagner commented 3 years ago

There's an implementation of this in https://github.com/thepwagner/action-update-go/ that may be inspiration. It works for me: https://github.com/thepwagner/action-update/pull/77

jmalloc commented 1 year ago

Is there anything I can do to help progress this?

jeffwidman commented 1 year ago

I'd rather see this land upstream in go mod tooling, and then we leverage that. That will be far less brittle/easier to maintain than us trying to maintain it ourselves, regardless of whether it uses a native helper or (even more brittle) doing it in ruby/regex.

Here's some related upstream issues:

gaby commented 4 months ago

@jeffwidman A proposal was accepted to allow golang toolchain to notify of updates to major versions. Dependabot could use this to notify users.

https://github.com/golang/go/issues/67420#issuecomment-2150584249

jeffwidman commented 4 months ago

Oh nice I hadn't seen that!

Given it's a major version update, it'll have breaking changes beyond just the rewritten import paths.

Since :dependabot: opens PRs, we'll need to account for those changes in the PR body... I wonder if we could leverage Copilot for that? 🤔

gaby commented 4 months ago

@jeffwidman Maybe for something like this it would be better for dependabot to Open an Issue on the repo or Notify the Repo, instead of creating a PR?

I highly doubt an automatic upgrade of major version would work at all, since it's supposed to be a "breaking change".

billinghamj commented 4 months ago

@jeffwidman I'd much rather it just update the import paths and do absolutely nothing with the remaining code, just as it does with all other ecosystems. If there's been a breaking change, that's for our developers to consider - we would not want Dependabot adding its own opinion on top

If you do want to make code suggestions, that could be a cool feature, but should really be entirely separate from this. It's also applicable to breaking changes in any ecosystem, potentially with any version changes - not just Go, and not just major versions (e.g. Go packages often don't strictly follow semver).

jmalloc commented 4 months ago

I highly doubt an automatic upgrade of major version would work at all, since it's supposed to be a "breaking change".

In my experience there are plenty of situations where this works just fine. For a "classic" example, see http://github.com/google/go-github. The major version of this module is bumped on every release, but it has a large API surface area, much of which is unused by any single dependant module.

gaby commented 4 months ago

I highly doubt an automatic upgrade of major version would work at all, since it's supposed to be a "breaking change".

In my experience there are plenty of situations where this works just fine. For a "classic" example, see http://github.com/google/go-github. The major version of this module is bumped on every release, but it has a large API surface area, much of which is unused by any single dependant module.

That's true, there some edge cases. So yes, updating the path on each file makes sense, it's up to the dev to fix any issues from the major upgrade.