janhoy opened a new pull request, #896: URL: https://github.com/apache/solr-operator/pull/896
🤖 AI assisted 🤖 **Problem.** `make lint` and the smoke test fail at random on `check-licenses`, with a diff like this and no dependency change to explain it: ``` < gomodules.xyz/jsonpatch/v2,https://github.com/gomodules/jsonpatch/blob/v2.5.0/v2/LICENSE,Apache-2.0 --- > gomodules.xyz/jsonpatch/v2,https://github.com/gomodules/jsonpatch/blob/v2.5.0/LICENSE,Apache-2.0 ``` `go-licenses report` resolves the second column, the link to each license file, over the network: it builds a client with a 20 second timeout and calls `FileURL` per dependency, which fetches `go-get` meta tags to work out whether a module's major version directory is part of its repository. The answer decides where the license file is said to live, so the same inputs give different output depending on whether that lookup succeeds: | Conditions | Second column for `gomodules.xyz/jsonpatch/v2` | | --- | --- | | Lookup succeeds | `.../blob/v2.5.0/v2/LICENSE` | | Lookup fails | `Unknown` | And for `github.com/evanphx/json-patch/v5`, a failing lookup gives the repository root form `.../blob/v5.9.11/LICENSE` instead. Only the two nested major version modules can flip, because they are the ones whose license file sits at the repository root rather than beside the `go.mod`. CI compares byte for byte, so a throttled shared runner fails whichever PR happens to be running. #889 is the current casualty; it passed at 00:30 and failed at 08:07 with no dependency change in between, and an unrelated branch failed in the same window on the same two lines. Worth noting the form a *successful* lookup produces is the wrong one. Both URLs the committed file carries today return 404: ``` 404 https://github.com/gomodules/jsonpatch/blob/v2.5.0/v2/LICENSE 200 https://github.com/gomodules/jsonpatch/blob/v2.5.0/LICENSE 404 https://github.com/evanphx/json-patch/blob/v5.9.11/v5/LICENSE 200 https://github.com/evanphx/json-patch/blob/v5.9.11/LICENSE ``` That is [google/go-licenses#131](https://github.com/google/go-licenses/issues/131), open, with the proposed fix unmerged. v2.0.1 is the latest release, so there is no version to bump to. **Solution.** Render the report through `--template`, a documented go-licenses flag, and put the module version in that column instead of the link. go-licenses takes the version from the module graph, so it needs no network and cannot drift. ``` gomodules.xyz/jsonpatch/v2,v2.5.0,Apache-2.0 ``` The module and license columns are byte-identical to before, so no license data changes; `diff <(cut -d, -f1,3 old) <(cut -d, -f1,3 new)` is empty, and the row count is the same 78. The version seemed the better replacement over dropping the column: it is information the file did not record before and it matters for license review, whereas a link that 404s does not. I also tried building a `pkg.go.dev` link, but the template exposes the package path rather than the module path, so three entries under `k8s.io/kube-openapi` came out as 404s. **Verification.** The report is byte-identical across repeated runs, and with the network blocked: ``` 59358f63d6f5c942d15e594c5d200f5b with network, run 1 59358f63d6f5c942d15e594c5d200f5b with network, run 2 59358f63d6f5c942d15e594c5d200f5b lookup blocked, run 1 59358f63d6f5c942d15e594c5d200f5b lookup blocked, run 2 59358f63d6f5c942d15e594c5d200f5b committed file ``` The same four runs against the current default report give three different answers for those two modules. `make lint` passes, both normally and with the network blocked, which is the case CI was hitting. The `GOOS=linux GOARCH=amd64` prefix on both invocations is unchanged, so the list still reflects the Linux build graph. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
