Search before asking
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:
- 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.
- 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.
- 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?
Code of Conduct
Search before asking
What happened
On a fresh clone of the repository, any Go tooling that loads the whole module fails, because
backend/mocks/is listed in.gitignorewhile tracked, non-test sources import it.backend/helpers/unithelperimportsmocks/core/context,mocks/core/dal,mocks/core/logandmocks/core/plugin; thehelpers/pluginhelper/apitests importmocks/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:
This affects
go mod tidy,go build ./...,go vet ./...and editors/IDEs loading the module. It goes unnoticed in day-to-day work becausemake unit-testdepends onmock(Makefile:101,backend/Makefile:85), which runsmockeryfirst.It also blocks automated dependency tooling. While preparing a Dependabot configuration I hit exactly this error in the
gomodecosystem — Dependabot runsgo mod tidyafter every version bump and aborts:What do you expect to happen
A fresh clone should load with standard Go tooling without a mandatory code-generation step.
How to reproduce
Counter-check — after generating the mocks the very same tree is clean:
go.modandgo.sumremain byte-identical afterwards, so the module itself is consistent — the only defect is the missing directory.Anything else
backend/mocks/has been gitignored since243cc8a80("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:
.gitignoreentry). 65 files, ~644 KB. A fresh clone would then work with plain Go tooling. Staleness can be guarded by a CI step runningmake mockfollowed bygit diff --exit-code.helpers/unithelper. Larger change, but keeps generated code out of the tree.make mockbefore 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 tidyconsiders all build tags exceptignore, and anignoretag would also drop the package from regular builds.Version
main (
c8288c0cd)Are you willing to submit PR?
Code of Conduct