DoDiODev opened a new issue, #9088:
URL: https://github.com/apache/devlake/issues/9088

   ### 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)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to