Add support for stringlabels in Thanos Query #7645
Conversation
This commit finalizes support for the stringlabels build tag so that we can build the binary. I would assume that we will still get panics if we run a store since the Series call still relies on casting one pointer type to another. This will be fixed in a follow up PR. Signed-off-by: Filip Petkovski <[email protected]>
cmd/thanos/config.go
Outdated
| } | ||
| val, err := strconv.Unquote(parts[1]) | ||
| if err != nil { | ||
| return nil, errors.Wrap(err, "unquote label value") | ||
| return labels.Labels{}, errors.Wrap(err, "unquote label value") |
There was a problem hiding this comment.
labels.EmptyLabels() maybe?
There was a problem hiding this comment.
I had that first, but thought the empty struct is more idiomatic? I don't have a strong preference though
There was a problem hiding this comment.
IMHO labels.EmtpyLabels read better as well.
Signed-off-by: Filip Petkovski <[email protected]>
Signed-off-by: Filip Petkovski <[email protected]>
| } | ||
| // Compatibility label for Queriers pre 0.8.1. Filter it out now. | ||
| if ls[0].Name == store.CompatibilityTypeLabelName { | ||
| if ls.Len() == 0 { |
There was a problem hiding this comment.
This removes the ancient store.CompatibilityTypeLabelName which I think is okay given how old the supported version is.
|
The CI job should be there now. I wasn't sure how to add the build tag to promu so I just used |
Signed-off-by: Filip Petkovski <[email protected]>
fpetkovski
force-pushed
the
stringlabels
branch
from
97da9c7 to
b55845d
Compare
| ${{ runner.os }}-go- | ||
|
|
||
| - name: Cross build check | ||
| run: go build -tags=stringlabels ./cmd/thanos |
There was a problem hiding this comment.
Promu also supports this I think https://github.com/prometheus/prometheus/blob/main/.promu.yml#L17
There was a problem hiding this comment.
Let's maybe keep it simple for now and not introduce another build tool
This commit finalizes support for the stringlabels build tag so that we can build the binary.
I would assume that we will still get panics if we run a store since the Series call still relies on casting one pointer type to another. This will be fixed in a follow up PR.
Changes
Verification