chore: enhance development workflow with unified linting and tool

[naveensrinivasan]

Description

In this pull request, I have introduced several updates and new configurations to enhance our project's development process, specifically focusing on linting and tool management. These changes aim to improve code quality, ensure consistency across development environments, and streamline our CI/CD pipeline. Here's a breakdown of the modifications and the rationale behind each:

1. Updated .github/workflows/scan-lint.yaml

I have modified the scan-lint.yaml file to dynamically set the version of golangci-lint based on the version specified in our project's src/tools/go.mod file. Previously, the workflow explicitly used a fixed version of golangci-lint installed via a curl command. This update ensures that the CI pipeline uses the same version of golangci-lint as our local development environments, fostering consistency and preventing potential compatibility issues. Additionally, the action version for golangci-lint has been updated to 4.0.0 to match the version specified in our environment variable, further aligning our tooling across different environments.

2. Added .gitignore Entry

To maintain a clean and focused repository, I've added the bin/ directory to our .gitignore file. This change prevents binary files and executables generated during local development from being tracked by version control, avoiding unnecessary conflicts and conserving repository space.

3. Introduced .golangci.yml

A new configuration file, .golangci.yml, has been added to specify settings for the golangci-lint tool. This configuration includes parameters such as concurrency level, timeout settings, issue count limits, and specific linter enablements (e.g., gofmt, goimports, gosec, govet). By defining these settings, we aim to uphold high code quality standards and adhere to best practices in our Go codebase.

4. Updated Makefile for Tool Installation

I've updated the Makefile to include a new section for installing required tools locally. This approach allows us to control the versions of tools the UDS CLI depends on, ensuring consistency across development environments without cluttering them with unnecessary installations. Additionally, a new lint target has been added to facilitate running golangci-lint directly from the src directory, reinforcing our commitment to maintaining code quality.

5. Added src/tools/go.mod, src/tools/go.sum, and src/tools/tools.go

To manage our development tools more effectively, I've introduced a go.mod and go.sum in the src/tools directory, along with a tools.go file. These additions are crucial for defining and tracking the dependencies of our development tools, including golangci-lint. Specifying these tools and their versions ensures that our development environment is reproducible and aligned with our project's requirements.

Conclusion

These changes collectively enhance the reliability, maintainability, and consistency of our development and CI/CD processes. By aligning the versions of critical tools like golangci-lint across all environments and streamlining tool management, we set a solid foundation for high-quality code and efficient development workflows.

Related Issue

Fixes ##448

Relates to #

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[UncleGedd]

This Makefile change and the new module in src/tools feels a bit heavy-handed. I understand the intent of not having devs install tools like golangci-lint on their machine, but I feel like it's a pretty small thing to ask folks to install basic Golang dev tooling

[naveensrinivasan]

This Makefile change and the new module in src/tools feels a bit heavy-handed. I understand the intent of not having devs install tools like golangci-lint on their machine, but I feel like a pretty small thing to ask folks to install basic Golang dev tooling

This Makefile change and the new module in src/tools feels a bit heavy-handed.
Do you see any drawbacks to doing this?

The version of the golangci has broken the previous builds (in a few of the OSS projects I contribute to), which is why it is pinned to a specific version.

• https://github.com/ossf/scorecard/blob/main/tools/tools.go
• https://github.com/sigstore/sigstore/blob/main/hack/tools/tools.go

Also, it enhances when the project could be including additional tools with the go ecosystem.
It also helps when we have external contributors who want to contribute.

[UncleGedd]

This Makefile change and the new module in src/tools feels a bit heavy-handed. I understand the intent of not having devs install tools like golangci-lint on their machine, but I feel like a pretty small thing to ask folks to install basic Golang dev tooling

This Makefile change and the new module in src/tools feels a bit heavy-handed.
Do you see any drawbacks to doing this?

The version of the golangci has broken the previous builds (in a few of the OSS projects I contribute to), which is why it is pinned to a specific version.

• https://github.com/ossf/scorecard/blob/main/tools/tools.go
• https://github.com/sigstore/sigstore/blob/main/hack/tools/tools.go

Also, it enhances when the project could be including additional tools with the go ecosystem. It also helps when we have external contributors who want to contribute.

The main drawback I see is the ratio of complexity to added value. Yes, it's neat to have an auto-installer for dependencies but:

1. it adds a lot of gnarly Makefile code
2. adding another Go module just to install a single dep (golangci-lint) feels heavy

Instead I think the same or similar functionality can be baked into the pre-commit

[naveensrinivasan]

This Makefile change and the new module in src/tools feels a bit heavy-handed. I understand the intent of not having devs install tools like golangci-lint on their machine, but I feel like a pretty small thing to ask folks to install basic Golang dev tooling

This Makefile change and the new module in src/tools feels a bit heavy-handed.
Do you see any drawbacks to doing this?

The version of the golangci has broken the previous builds (in a few of the OSS projects I contribute to), which is why it is pinned to a specific version.

• https://github.com/ossf/scorecard/blob/main/tools/tools.go
• https://github.com/sigstore/sigstore/blob/main/hack/tools/tools.go

Also, it enhances when the project could be including additional tools with the go ecosystem. It also helps when we have external contributors who want to contribute.

The main drawback I see is the ratio of complexity to added value. Yes, it's neat to have an auto-installer for dependencies but:

1. it adds a lot gnarly Makefile code
2. adding another Go module just to install a single dep (golangci-lint) feels heavy

Instead I think the same or similar functionality can be baked into the pre-commit

Sounds good. I'll update the PR to make it simpler.

Thank you!

[naveensrinivasan]

This Makefile change and the new module in src/tools feels a bit heavy-handed. I understand the intent of not having devs install tools like golangci-lint on their machine, but I feel like a pretty small thing to ask folks to install basic Golang dev tooling

This Makefile change and the new module in src/tools feels a bit heavy-handed.
Do you see any drawbacks to doing this?

The version of the golangci has broken the previous builds (in a few of the OSS projects I contribute to), which is why it is pinned to a specific version.

• https://github.com/ossf/scorecard/blob/main/tools/tools.go
• https://github.com/sigstore/sigstore/blob/main/hack/tools/tools.go

Also, it enhances when the project could be including additional tools with the go ecosystem. It also helps when we have external contributors who want to contribute.

The main drawback I see is the ratio of complexity to added value. Yes, it's neat to have an auto-installer for dependencies but:

1. it adds a lot gnarly Makefile code
2. adding another Go module just to install a single dep (golangci-lint) feels heavy

Instead I think the same or similar functionality can be baked into the pre-commit

Sounds good. I'll update the PR to make it simpler.

Thank you!

@UncleGedd 👀

[UncleGedd]

Hey @naveensrinivasan quick question. When we run gosec by itself using gosec ./..., we get 24 MEDIUM severity issues. Some of these are surely false positives, but do you know why running make lint doesn't show us the same output?

[naveensrinivasan]

Hey @naveensrinivasan quick question. When we run gosec by itself using gosec ./..., we get 24 MEDIUM severity issues. Some of these are surely false positives, but do you know why running make lint doesn't show us the same output?

AFAIK it has to be the version differences.

[naveensrinivasan]

Hey @naveensrinivasan quick question. When we run gosec by itself using gosec ./..., we get 24 MEDIUM severity issues. Some of these are surely false positives, but do you know why running make lint doesn't show us the same output?

AFAIK it has to be the version differences.

A friendly ping.

[UncleGedd]

Thanks for the ping @naveensrinivasan , I'd like to do a bit more investigating with the version differences. We will def get to it this week

[naveensrinivasan]

Thanks for the ping @naveensrinivasan , I'd like to do a bit more investigating with the version differences. We will def get to it this week

Thank you!

[UncleGedd]

Thanks for this, I couldn't figure out why running gosec ./... produced different results than make lint but we'll keep an eye on it