[Bug][Build] go mod tidy fails on a fresh clone because backend/mocks/ is gitignored but imported by tracked sources
- Dominant language
- Go
- Stars
- 3.1k
- Forks
- 808
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 49
Description
### Search before asking
- [X] I had searched in the [issues](https://github.com/apache/incubator-devlake/issues?q=is%3Aissue) 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
```bash
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:
```bash
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?
- [X] Yes I am willing to submit a PR!
### Code of Conduct
- [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with .gitignore, Makefile:101, backend/Makefile:85, and the imports named in helpers/unithelper and helpers/pluginhelper/api. Reproduce the failure from a fresh clone with go mod tidy, then compare it with the tree after make mock. Done means the maintainers’ chosen approach lets go mod tidy, go build ./..., and go vet ./... work without an uncommitted mock-generation step.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, go
- Domain
- backend, build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100