Could you say more about your project's structure? Does go mod tidy make any changes to your go.mod file? Do you have any replace or exclude directives? If you have a minimal reproducible example, that would be helpful.

gorelease loads all the packages in the module as if it were not the main module (ignoring replace or exclude directives). If something imports a package that is not provided by any module in the build list, gorelease will report this error.

Unfortunately the specific module is closed source and a little complex, happy to debug things manually till I can extract a reproducer.

The affected module is a submodule, and it contins a number of packages including an internal, and _examples. It is currently tagged at sub/v2.0.1. go mod tidy does not make any changes and exits with status 0. It does not contain any replace or exclude directives.

It might have something to do with the _examples directory, though I'm not sure what. That would be ignored by go list ./..., which is close to what gorelease uses to build a package list. It should also be ignored by go mod tidy though.

I have narrowed down the root cause, but still cannot reproduce it outside the repo. It appears to relate to a single test import that only exists in one xxx_test.go file. When that import statement is removed (along with the references) gorelease works.

Is there some debugging I can do to diff the list that go mod tidy does with gorelease?

Further investigation suggests that it is an interaction between this dependency and a previous release of the current module, both of which were untidy (missing h1s from go.sum). This would explain why go mod tidy does nothing, the real ask is to mod tidy a previous release.

What is the general recovery strategy for "gorelease cannot process of the previous release"? It would be nice to be able to diff the old api, but I get that some failures are too systemic.

It appears to relate to a single test import that only exists in one xxx_test.go file.

Very strange. I don't think gorelease loads tests, so this shouldn't cause new requirements to be added to go.mod.

There's not a direct way to debug this, but the relevant function in gorelease is loadPackages.

Further investigation suggests that it is an interaction between this dependency and a previous release of the current module, both of which were untidy (missing h1s from go.sum). This would explain why go mod tidy does nothing, the real ask is to mod tidy a previous release.

This shouldn't cause an issue. Only the go.sum file for the main module matters; the go command ignores other go.sum files. And in any case, this error is only shown if a require line is added to go.mod during the loading process, and only for the release version (the checked out code).

Clearly a needed improvement is that gorelease should say which requirements are added or updated.

But it still sounds like since go mod tidy doesn't make any change to go.mod, this error shouldn't be happening at all.

Change https://golang.org/cl/253039 mentions this issue: x/exp/cmd/gorelease: specify which incomplete requirements were missing