go_modules update fails with local replaces

[sysradium]

Is there an existing issue for this?

• [X] I have searched the existing issues

Package ecosystem

go

Package manager version

No response

Language version

No response

Manifest location and content before the Dependabot update

No response

dependabot.yml content

No response

Updated dependency

No response

What you expected to see, versus what you actually saw

We have a following line in go.mod:

replace protogo v0.0.0-replace => ../../../dev/protodev/proto/protogo

• dependabot detects local replace and stubs it out with a folder 1c61b09cbe7c268a16b568954aff06d86f959ba8578b6f0e1c9afe5dd14e0489 and 2 empty files go.mod and main.go

• executes go get for each dependency

• executes go get without any parameters (https://github.com/dependabot/dependabot-core/blob/v0.225.0/go_modules/lib/dependabot/go_modules/file_updater/go_mod_updater.rb#L122C1-L122C1)

That go get fails with:

protogo/lead/legacy: package protogo/lead/legacy is not in GOROOT (/opt/go/src/protogo/lead/legacy)

I guess because stubbed does not contain any structure.

Commenting that line fixed the problem:

dependabot-core on  main [!] on 🐳 v24.0.2
➜ git diff

b/go_modules/lib/dependabot/go_modules/file_updater/go_mod_updater.rb
index 50c1883ec..18c535917 100644
--- a/go_modules/lib/dependabot/go_modules/file_updater/go_mod_updater.rb
+++ b/go_modules/lib/dependabot/go_modules/file_updater/go_mod_updater.rb
@@ -119,7 +119,7 @@ module Dependabot
             # Run `go get`'s internal validation checks against _each_ module in `go.mod`
             # by running `go get` w/o specifying any library. It finds problems like when a
             # module declares itself using a different name than specified in our `go.mod` etc.
-            run_go_get
+            # run_go_get

             # If we stubbed modules, don't run `go mod {tidy,vendor}` as
             # dependencies are incomplete

dependabot-core on  main [!] on 🐳 v24.0.2
➜ script/build go_modules
....

dependabot-core on  main [!] on 🐳 v24.0.2
➜  /usr/local/bin/dependabot update go_modules  -d /src  --updater-image=ghcr.io/dependabot/dependabot-updater-gomod:latest --pull=false our_company/our_repo

...
  proxy | 2023/08/04 12:36:18 [426] 200 http://host.docker.internal:57063/update_jobs/cli/mark_as_processed
updater | 2023/08/04 12:36:18 INFO Finished job processing
updater | 2023/08/04 12:36:18 INFO Results:
updater | +-------------------------------------------------------------------------------------------------------+
updater | |                                  Changes to Dependabot Pull Requests                                  |
updater | +---------+---------------------------------------------------------------------------------------------+
....

Maybe we should not execute go get if ANY local replaces were detected? I.e.:

# Bump the deps we want to upgrade using `go get lib@version`
run_go_get(dependencies)

# Run `go get`'s internal validation checks against _each_ module in `go.mod`
# by running `go get` w/o specifying any library. It finds problems like when a
# module declares itself using a different name than specified in our `go.mod` etc.
if substitutions.empty?
  run_go_get

# If we stubbed modules, don't run `go mod {tidy,vendor}` as
# dependencies are incomplete
if substitutions.empty?
  # go mod tidy should run before go mod vendor to ensure any
  # dependencies removed by go mod tidy are also removed from vendors.
  run_go_mod_tidy
  run_go_vendor
else
  substitute_all(substitutions.invert)
end

Native package manager behavior

No response

Images of the diff or a link to the PR, issue, or logs

No response

Smallest manifest that reproduces the issue

No response

[sysradium]

If it is not a priority to fix, is it possible to configure dependabot in github to use our custom docker image?

[sysradium]

For those reading this today, we were able to fix that by moving away code which contains replaced imports into a subpackage.

Specifically we had a main.go file in a root of a repository which in some cases directly in some indirectly imported a package containing a replaced import. After moving into into a cmd/server package and having no go code in the root of a repository the problem went away.

I still think dependabot could have handled this situation itself, but it's no longer critical given this workaround.