ci: migrate golangci-lint to v2 (#1466)
- ci: migrate golangci-lint to v2
golangci-lint v1 is no longer maintained and cannot load modules that target Go 1.25, which the pending dependency updates need. Move to v2 first, on the current Go version, so the Go bump can follow separately.
- Use golangci-lint v2.14.0 with golangci-lint-action@v9.
- Migrate .golangci.yml to the v2 format and keep the v1 rule set: gosimple and stylecheck are now part of staticcheck, gofumpt moves to formatters, the QF* quick fixes and govet’s inline analyser stay off, and v1’s default exclusions are kept through presets.
- Skip prealloc in _test.go files, and match third_party, builtin and examples directories the way v1 did.
- make lint and lint-fix now install GOLINTER_VERSION when the golangci-lint on PATH is missing or a different version, and fail with a clear message if an older binary still shadows it.
Co-authored-by: Iamrushabhshahh rushabhshah842@gmail.com Signed-off-by: Iamrushabhshahh rushabhshah842@gmail.com
- style: fix findings reported by golangci-lint v2
The linters bundled with golangci-lint v2 report findings that v1 did not. All are small and do not change behaviour, except the slog calls, which logged the error as the message and produced a !BADKEY attribute.
- govet slog: logger.Error(err.Error(), “msg”, “error”, err) becomes logger.Error(“msg”, “error”, err).
- staticcheck SA1006: fmt.Errorf(s) becomes errors.New(s), and fmt.Printf(s) becomes fmt.Print(s).
- staticcheck S1009: drop nil checks that len() already covers.
- predeclared: rename local “max” variables, which shadow the Go 1.21 builtin, to “maxItems”.
- prealloc: preallocate slices in non-test code.
- gofumpt: reformat k8s_printer.go.
Co-authored-by: Iamrushabhshahh rushabhshah842@gmail.com Signed-off-by: Iamrushabhshahh rushabhshah842@gmail.com
Signed-off-by: Iamrushabhshahh rushabhshah842@gmail.com
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
Intent-Driven Platform Orchestrator
🌐 Website • ⚡️ Quick Start • 📚 Docs • 📚 Landing Page • 💬 Discussions
[English] [中文] [हिंदी]
What is Kusion?
Kusion is an intent-driven Platform Orchestrator, which sits at the core of an Internal Developer Platform (IDP). With Kusion you can enable app-centric development, your developers only need to write a single application specification - AppConfiguration. AppConfiguration defines the workload and all resource dependencies without needing to supply environment-specific values, Kusion ensures it provides everything needed for the application to run.
Kusion helps app developers who are responsible for creating applications and the platform engineers responsible for maintaining the infrastructure the applications run on. These roles may overlap or align differently in your organization, but Kusion is intended to ease the workload for any practitioner responsible for either set of tasks.
How does Kusion work?
As a Platform Orchestrator, Kusion enables you to address challenges often associated with Day 0 and Day 1. Both platform engineers and application engineers can benefit from Kusion.
There are two key workflows for Kusion:
Day 0 - Set up the modules and workspaces: Platform engineers create shared modules for deploying applications and their underlying infrastructure, and workspace definitions for the target landing zone. These standardized, shared modules codify the requirements of stakeholders across the organization including security, compliance, and finance.
Kusion modules abstract the complexity of underlying infrastructure tooling, enabling app developers to deploy their applications using a self-service model.
Day 1 - Set up the application: Application developers leverage the workspaces and modules created by the platform engineers to deploy applications and their supporting infrastructure. The platform team maintains the workspaces and modules, which allows application developers to focus on building applications using a repeatable process on standardized infrastructure.
Introducing Kusion Server with a Developer Portal
Starting With Kusion v0.14.0, we are officially introducing Kusion Server with a Developer Portal.
Kusion Server runs as a long-running service, providing the same set of functionalities as the Kusion CLI, with additional capabilities to manage application metadata and visualized application resource graphs.
Kusion Server manages instances of Projects, Stacks, Workspaces, Runs, etc. centrally via a Developer Portal and a set of RESTful APIs for other systems to integrate with.
https://github.com/user-attachments/assets/d4edac23-cc01-417f-b08d-de137253c9eb
Quick Start With Kusion Server with a Developer Portal
To get started with Kusion Server:
Quick Start With Kusion CLI
This guide will cover:
Install
Homebrew (macOS & Linux)
Powershell
Deploy
To deploy an application, you can run the
kusion applycommand.Case Studies
Check out these case studies on how Kusion can be useful in production:
Contact
If you have any questions, feel free to reach out to us in the following ways:
Slack | Join
DingTalk Group:
42753001(Chinese)WeChat Group (Chinese): Add the WeChat assistant to bring you into the user group.
Contributing
If you’re interested in contributing, please refer to the Contributing Guide before submitting a pull request.
License
Kusion is under the Apache 2.0 license. See the LICENSE file for details.
OpenSSF Best Practice Badge