ci: release workflow that attaches kne_cli binaries to GitHub Releases

[msupinodn]

Summary

Currently the drivenets fork of kne has no gh release artifacts — users have to clone + go build to get a working kne binary. Adds a release workflow + a make dist target so:

• pushing a v* git tag automatically produces a GitHub Release with cross-compiled binaries for linux/{amd64,arm64} and darwin/{amd64,arm64}
• the same packaging can be reproduced locally with TAG=v0.4.0-dn make dist

What's in each release

Per platform ({os}_{arch}):

kne_<TAG>_<os>_<arch>.tar.gz
  ├── kne                     # statically linked, stripped, trimpath
  ├── LICENSE
  └── README.md
SHA256SUMS                    # one line per tarball

Binaries are built with:

CGO_ENABLED=0 GOOS=<os> GOARCH=<arch> \
  go build -trimpath \
           -ldflags='-s -w -X main.version=<TAG> -X main.commit=<sha> -X main.date=<iso>' \
           ./kne_cli

Trigger model

• push of any tag matching v* → creates / updates the release with that tag
• workflow_dispatch with a tag input → rebuilds for an existing tag (useful for re-issuing assets without retagging)

generate_release_notes: true so GitHub auto-fills the body from PR titles since the previous tag.

Test plan

• TAG=v0.4.0-dn make dist locally → 4 tarballs produced (~14–16 MB each)
• Extracted kne_v0.4.0-dn_linux_amd64.tar.gz, ran the embedded kne help — output is the standard help text
• file dist/.../kne confirms statically linked, stripped x86-64 ELF
• SHA256SUMS contains all 4 tarballs

Follow-up

Once merged, tagging v0.4.0-dn on main will produce the first drivenets-fork release. That tag is suggested because the fork has accumulated breaking-ish changes vs upstream v0.3.1 (CVE deps bumps, narrowed RBAC equivalents, empty-ConfigMap fix, skip-empty-Topology fix).

Made with Cursor