-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: go list
prints the wrong Origin
data for the version resolved from a non-semver query
#61423
Comments
(Found while investigating #61415.) |
Origin
information for a version resolved from a non-semver querygo list
should avoid printing a cacheable Origin
for a version resolved from a non-semver query
go list
should avoid printing a cacheable Origin
for a version resolved from a non-semver querygo list
prints the wrong Origin
data for the version resolved from a non-semver query
if the Version field prints the resolved version, why shouldn't the Origin field print the origin data corresponding to that version? |
Perhaps it should? But in that case, the |
Change https://go.dev/cl/543155 mentions this issue: |
Change https://go.dev/cl/543216 mentions this issue: |
Previously, we used the presence of individual origin fields to decide whether an Origin could be checked for staleness, with a nil Origin representing “use whatever you have”. However, that turns out to be fairly bug-prone: if we forget to populate an Origin somewhere, we end up with an incomplete check instead of a non-reusable origin (see #61415, #61423). As of CL 543155, the reusability check for a given query now depends on what is needed by the query more than what is populated in the origin. With that in place, we can simplify the handling of the Origin struct by using a nil pointer to represent inconsistent or unavailable origin data, and otherwise always reporting whatever origin information we have regardless of whether we expect it to be reused. Updates #61415. Updates #61423. Change-Id: I97c51063d6c2afa394a05bf304a80c72c08f82cf Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/543216 Auto-Submit: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
A result with either a non-cacheable
Origin
(currently, an emptyHash
,TagSum
, andRepoSum
), or anOrigin
with aRef
matching the one we would need to re-resolve in the upstream repo.What did you see instead?
When a proxy is used, the result may include a cacheable
Origin
, as if the command had requested the fully-resolved version instead of a query:The text was updated successfully, but these errors were encountered: