service config version [T1031]

[Lagovas]

• extend config generation and handle one parameter: folder where it should be generated
• add check on CI that config files in configs/ are up to date. it check by generating fresh configs to temporary folder and comparing it to configs/* files
• allow comparing versions by parts to provide a way to ignore patch part of version
• moved tests db independent to another workflow general_validation where run .circleci/check_[gofmt|golint|gotest]
• services check version from config that it equal with major + minor parts and ignore patch part of version
• synchronized error messages for all cmd/* binaries for incorrect config version case

[ilammy]

LGTM in general, but I have some (dumb) questions.

[ilammy]

This seems out-of-place here. Isn't this an error which should be reported accordingly?

I'd expect the comparison flags to be inlined at every call site. Therefore using an incorrect set of flags is definitely a programmer error and we can panic if the flags are invalid.

[Lagovas]

it's a bad pattern to decide what should do unknown program. To handle panics in golang programs programmer should to wrap this function which will defer function with `recover()`` call if he wants to handle an error in place where it has occurred

I added this flag for cases when wasn't used any flag (pass 0) or incorrect value. Function should compare two values and return any less/equal/greater. But in other cases with undefined (oh, maybe use undefined?) value used some value that will show it and allow to handle it.

Anyway programmer will test his code with comparisons and catch his mistakes. He can write if v1.CompareOnly(0, v2) <operator> <value where operator may be == or != (>, >=, <=, < is unexpected and not supported operators as any of other implementations of compare in golang/c/c++). If he expect that result == Equal or != Equal, he will take it anyway if pass incorrect flag : )

or we need +1 opinion how will be better in this case )

[vixentael]

this is very good move!!

[vixentael]

why this line is removed? is it a bug in yaml generator and on first line there should be a version num?

[vixentael]

@Lagovas I'm really concerned about this one

[Lagovas]

it's a mistake. nice catch. maybe removed locally and added via git add by mistake

[vixentael]

ok, thank you!

[vixentael]

this is massive! 😎