apache / apache/devlake

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

Open
#9,088 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.