Porting promlint from prometheus/prometheus

[RainbowMango]

Refer prometheus/prometheus#5317.

I split this work into two commits:

• Porting : Just simply copy promlint in.
• Minor Improvement: Fix static check warning by some IDE, such as Goland. More Deatils

I wish it will be easier for the reviewer to catch what has been changed during porting.

[RainbowMango]

cc @beorn7 @brancz

[RainbowMango]

I can't see the Travis build log, travis-ci.org always say Under Maintenance when access the Details link. I will check it later.

[brancz]

lgtm but leaving last call to @beorn7

[bwplotka]

LGTM 👍

[beorn7]

Just some nits here. I'll ask a more fundamental question separately in the conversation.

[beorn7]

It doesn't matter a lot, but we use to fill in the current year if we create a new file.

[beorn7]

🤣

[beorn7]

Perhaps "Only the Prometheus text exposition format is supported." so that people don't get confused with OpenMetrics?

[beorn7]

Many thanks 🌈🥭, 🇧🇱🐟, and ☮️.

I have a question: Do you feel this should in its own promlint package? I'm a bit concerned the package structure gets a bit nested. On the other hand, it's a nice and clean separation. If we keep it in a sub-package, I'd like to add testutil.CollectAndLint and testutil.GatherAndLint to make it easier to include the linting in metrics testing. Do you think that's a good idea?

[RainbowMango]

I have a question: Do you feel this should in its own promlint package? I'm a bit concerned the package structure gets a bit nested.

I'm glad you ask this.

Yes, I think if we put it in client_golang/prometheus/promlint would be much better.
But I'm not worried about the nest, I think promlint not just test util. It could be more significant in the future.

Indeed, we can take promlint as test util for now, because it can only check the gathered metrics.
I have a thought to extend promlint, making it possible to check a metric before register to a registry. So, we can take promlint as a tool for metric conformance. From this point of view, even we put promlint to a separated repo could be acceptable.

[RainbowMango]

Actually, I started a program to run my thought months ago.

I don't want to disrupt the Prometheus community, I just want the best practice cloud spread to more projects.

Would you mind I continue working on my program? If it really works, I will be happy to donate it to the Prometheus community.

[beorn7]

We already arrived at the conclusion that having the promlint package here in client_golang is a good idea. A stand-alone program would than simply import the package and do the boilerplate around it to turn it into e.g. a command line tool or whatever else.

My question was more about having the moving parts directly in client_golang/prometheus/testutil or in its own sub-package client_golang/prometheus/testutil/promlint as it is now in this PR. I'd find client_golang/prometheus/promlint confusing as I see the linting as part of testing from the perspective of an instrumentation library.

Let's go with client_golang/prometheus/testutil/promlint as in this PR for now. I'll sand a PR for those helpers in testutil I mentioned above.

Thanks everyone and in particular @RainbowMango .