Move .golangci.yaml out of top level directory to reduce clutter

[jmhbnz]

What would you like to be added?

Sub issue under #15951.

We've recently made efforts to simplify the etcd project top level directory by removing or shifting some configuration files, refer #15778 and #15966 (comment).

The scope of this issue is to move the .golangci.yaml configuration file under the tools/ directory.

Once moved we then need to update our Makefile so it will pass the --config parameter when invoking golangci-lint run, i.e:

.PHONY: verify-lint
verify-lint:
-	golangci-lint run
+	golangci-lint --config tools/.golangci.yaml run

.PHONY: update-lint
fix-lint:
-	golangci-lint run --fix
+	golangci-lint --config tools/.golangci.yaml run --fix

Why is this needed?

Reduce the noise in the top level etcd project directory.

[tao12345666333]

Please assign this to me, thanks!

[serathius]

Would be good to confirm the file directory structure, how I understand the current state:

• hack - contains various configs/makefile/scripts used by etcd contributions. Example https://github.com/etcd-io/etcd/tree/main/hack/patch for cherrypicking PRs
• scripts - dump of remaining bash scripts used to build/release/test etcd. Example https://github.com/etcd-io/etcd/blob/main/scripts/test.sh
• tools - contains different Go binaries used etcd development. Example https://github.com/etcd-io/etcd/tree/main/tools/benchmark
• tools/mod - Go package used to freeze versions all Go tools.

I'm mentioning this to avoid misunderstanding that because yamllint is a Go binary which version is defined in tools/mod it doesn't mean that it's configuration should be in tools/.yamllint.yaml. I would rather suggest hack directory.

Still I think we need to rethink our whole script/tools/makefile structure as it will get only more complicated.

[jmhbnz]

Fair point - I'm happy for either hack or tools to be used so if there is broader consensus that hack is the better place then we can use this issue to move all three at once.

Will wait a day or two to see if anyone has different views before I update this issue description in favor of hack.

[tao12345666333]

Here are some examples for reference.

• Kubernetes

The hack directory contains many scripts that ensure continuous development of kubernetes, enhance the robustness of the code, improve development efficiency, etc. The explanations and descriptions of these scripts are helpful for contributors. For details, refer to the following guidelines.

• Docker

This directory contains a collection of scripts used to build and manage this repository. If there are any issues regarding the intention of a particular script (or even part of a certain script), please reach out to us. It may help us either refine our current scripts, or add on new ones that are appropriate for a given use case.

Overall, the hack directory contains some content that is useful for development projects and can be used to enhance the developer experience.

I agree with @serathius 's opinion to move these configuration files to the hack directory.

[ahrtr]

It isn't a big deal, but it makes more sense to get .golangci.yaml, .yamllint and .yamlfmt and included in tools/config, because golangci-lint, yamlfmt and yamllint are tools being used by etcd, and are configured (version) under tools, it's natural to put the related configuration files for the tools under tools, e.g. tools/config.

[tao12345666333]

The current disagreement between us is whether to move these configuration files to the tools directory or the hack directory.

In addition to the above comments, @ahrtr also provided additional comments in another PR review. #15966 (comment)

Just as I mentioned in #15987 (comment), I don't think it's good to put the config files under hack. The utilities & scripts under hack are various hacks which are used by developers (just for developers reference); while all tools under tools are used by etcd itself. Removing anything under tools will break the etcd (e.g. build, workflow check etc), but removing anything under hack will not impact etcd itself at all.

I think as long as we reach an agreement and write it down in the document, we can follow this plan for the rest of the process.

[jmhbnz]

Hey @tao12345666333 - For now can you please proceed with moving file to tools/<filename>. This is a good starting point and I see no issue with getting an initial pull request merged because we can always revisit it later if necessary.

Thanks again for your help getting this work done! 🙏🏻

[tao12345666333]

sure