tag sort dedup #147
tag sort dedup #147
Conversation
extemporalgenome
force-pushed
the
tag-sort-dedup
branch
7 times, most recently
from
86a89ed
to
bdb182c
Compare
It looks like functions had been renamed in some files but not others, breaking tests for darwin (though it's unclear why darwin tests are valuable for this package).
extemporalgenome
force-pushed
the
tag-sort-dedup
branch
from
bdb182c
to
e39de71
Compare
extemporalgenome
force-pushed
the
tag-sort-dedup
branch
from
ee08732
to
93c6f83
Compare
Add golang.org/x/exp/slices dependency. This is allocation-free and has comparable speed to prior approach. stdlib and slices package Sort functions also use insertion sort for small inputs, and as such a local insertion sort optimization has not been needed since at least 1.18.
golang.org/x/exp/slices has comparable allocation-free sorting, which we can use while reducing our code. Neither Datadog nor Prometheus appear to retain or handle multiple tags with the same name on the same metric, so this package deduplicates at time of sort (latest tag wins). If any metric systems we use do tolerate and provide useful behavior when provided duplicate tag/label names, and the practice is justified, that would be a reason to revert or adjust this deduplication behavior.
| return out | ||
| } | ||
|
|
||
| // mergeTags returns the sorted, deduplicated-by-name union of t1 and t2. |
There was a problem hiding this comment.
Can you explain in the comment what strategy we use to deduplicate (last write wins).
There was a problem hiding this comment.
The latest commit has hopefully addressed this. Please re-review.
| - name: Run Tests | ||
| run: go test -race -tags=${{ matrix.tags }} ./... | ||
| - name: Identify Go Version | ||
| run: go version |
There was a problem hiding this comment.
I believe each step starts a new container per command so there's a fair amount of overhead. How about e.g.
name: Identify Host
run: |
uname -a
go versionThere was a problem hiding this comment.
For BuildKite that'd definitely be the case, but for Github Actions, it looks like jobs create their own container/VM/whatever, but steps are just separate OS processes in that same container.
As such, steps look like they're no more expensive than running separate commands in a single shell. By making them separate steps, they do create nice UI sections though, and the above info was useful for debugging the especially stale workflow config.
|
|
||
| - uses: actions/checkout@v3 | ||
|
|
||
| - name: golangci-lint | ||
| uses: golangci/golangci-lint-action@v3.1.0 | ||
| with: | ||
| version: v1.45.2 | ||
| version: v1.53 |
There was a problem hiding this comment.
Thanks for updating this.
This is meant to be read commit-by-commit.