Use any instead of interface{}

[candiduslynx]

Summary

Go 1.18 (that is targeted by go.mod) introduced a handy any alias for interface{}, so use it for reading & dev simplicity.

Checklist

Delete items not relevant to your PR:

• Unit and integration tests covering the common scenarios were added
• A human-readable description of the changes was provided to include in CHANGELOG
• For significant changes, documentation in https://github.com/ClickHouse/clickhouse-docs was updated with further explanations or tutorials

[candiduslynx]

Hi @alexey-milovidov!
Is there any chance to get this reviewed?

[jkaflik]

@candiduslynx I will review it once have checks green.

[candiduslynx]

@jkaflik It seems that the failing test is flaky (failed to dial?) Could you trigger the rerun of failed jobs?

[jkaflik]

@candiduslynx given our workflow setup, it's expected to fail on the fork run. Please do not worry about it.

[candiduslynx]

@jkaflik
Ah, great. All others are green, so I presume you'll be taking this onto review, right?

[jkaflik]

LGTM. Staging for a release

[candiduslynx]

BTW, I didn't include a lot of the linters (like, errcheck) because it highlights a lot of issues, and I feel like you'll need to address those specifically (remove the disable all, add other linters. Example cfg we have in CQ SDK: https://github.com/cloudquery/plugin-sdk/blob/main/.golangci.yml)

[candiduslynx]

@jkaflik could you point me to some doc or walk through the RC process for SDK? Are you performing some internal testing to ensure consistency and then merge manually? Or is there something you tweak and then the -cloud jobs should pass?

(just curios)

[jkaflik]

@candiduslynx, we don't have (yet) a formalized release process for SDKs. Currently, I stage non-critical PRs with a label and merge them before major/minor release.

Issue with running tests against cloud on fork PRs can be tracked here.

[candiduslynx]

Currently, I stage non-critical PRs with a label and merge them before major/minor release.

@jkaflik thanks for explaining!

Would you consider merging this earlier, as this includes linter rules to ensure any instead of interface{} and postponing might introduce conflicts to be resolved (basically, someone adding more code with interface{})?