Open EricByers opened 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.
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).
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
Is there anything I can do to help progress this?
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:
@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
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? 🤔
@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".
@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).
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.
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.
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 beengo 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.