Skip to content

[Bug][Build] go mod tidy fails on a fresh clone because backend/mocks/ is gitignored but imported by tracked sources #9088

Description

@DoDiODev

Search before asking

  • I had searched in the issues and found no similar issues.

What happened

On a fresh clone of the repository, any Go tooling that loads the whole module fails, because backend/mocks/ is listed in .gitignore while tracked, non-test sources import it.

backend/helpers/unithelper imports mocks/core/context, mocks/core/dal, mocks/core/log and mocks/core/plugin; the helpers/pluginhelper/api tests import mocks/helpers/pluginhelper/api.

Since the directory does not exist in a clean checkout, Go cannot resolve these paths inside the module and tries to fetch them as external modules:

go: finding module for package github.com/apache/incubator-devlake/mocks/core/context
go: github.com/apache/incubator-devlake/helpers/unithelper imports
        github.com/apache/incubator-devlake/mocks/core/context: no matching versions for query "latest"
go: github.com/apache/incubator-devlake/helpers/unithelper imports
        github.com/apache/incubator-devlake/mocks/core/dal: no matching versions for query "latest"
go: github.com/apache/incubator-devlake/helpers/unithelper imports
        github.com/apache/incubator-devlake/mocks/core/log: no matching versions for query "latest"
go: github.com/apache/incubator-devlake/helpers/unithelper imports
        github.com/apache/incubator-devlake/mocks/core/plugin: no matching versions for query "latest"
go: github.com/apache/incubator-devlake/helpers/pluginhelper/api tested by
        github.com/apache/incubator-devlake/helpers/pluginhelper/api.test imports
        github.com/apache/incubator-devlake/mocks/helpers/pluginhelper/api: no matching versions for query "latest"

This affects go mod tidy, go build ./..., go vet ./... and editors/IDEs loading the module. It goes unnoticed in day-to-day work because make unit-test depends on mock (Makefile:101, backend/Makefile:85), which runs mockery first.

It also blocks automated dependency tooling. While preparing a Dependabot configuration I hit exactly this error in the gomod ecosystem — Dependabot runs go mod tidy after every version bump and aborts:

ERROR Error processing github.com/gin-gonic/gin (Dependabot::DependabotError)
/home/dependabot/go_modules/lib/dependabot/go_modules/file_updater/go_mod_updater.rb:350
  :in 'GoModUpdater#run_go_mod_tidy'

What do you expect to happen

A fresh clone should load with standard Go tooling without a mandatory code-generation step.

How to reproduce

git clone https://github.com/apache/devlake.git
cd devlake/backend
go mod tidy   # fails with the output above

Counter-check — after generating the mocks the very same tree is clean:

cd ..           # repo root
make mock       # delegates to `make mock -C backend`
cd backend
go mod tidy     # exit 0, no output

go.mod and go.sum remain byte-identical afterwards, so the module itself is consistent — the only defect is the missing directory.

Anything else

backend/mocks/ has been gitignored since 243cc8a80 ("refactor: refactor files/dirs of the whole repo for better organization", #3884, Jan 2023).

Possible directions — happy to send a PR for whichever the maintainers prefer:

  1. Commit the generated mocks (remove the .gitignore entry). 65 files, ~644 KB. A fresh clone would then work with plain Go tooling. Staleness can be guarded by a CI step running make mock followed by git diff --exit-code.
  2. Stop importing generated packages from tracked non-test sources, e.g. by reworking helpers/unithelper. Larger change, but keeps generated code out of the tree.
  3. Document it as intended and require make mock before any Go tooling. This keeps the status quo but leaves automated dependency updates for the Go ecosystem unavailable.

Note that a build tag does not help here: go mod tidy considers all build tags except ignore, and an ignore tag would also drop the package from regular builds.

Version

main (c8288c0cd)

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions