Open krsna-m opened 2 years ago
I think we should stop development of shell hacks. Recent code signing issues (see: knative/hack#272, knative/hack#240) clearly shows writing such tools in shell is short-sighted - the code is cryptic, hard to maintain, and often contains bugs. Although we have now a unit test framework, still testing isn't easy.
I think we should freeze this repo, and try to rewrite scripts one by one as Golang native tools. Those tools could be executed in Make files or simple scripts, as CLI, like:
go run knative.dev/tool/releaser@latest \
--dot-release \
--release-gcs knative-releases/kn-plugin-event \
--release-gcr gcr.io/knative-releases \
--github-token /etc/hub-token/token \
--apple-codesign-key /etc/notary/cert.p12 \
--apple-notary-api-key /etc/notary/key.json \
--apple-codesign-password-file /etc/notary/password \
--branch release-1.9
Or you could embed such innovations directly in Go-native build tools like Mage or goyek.
A good starting point for such rewrite is https://github.com/wavesoftware/go-magetasks/ which I would like to donate to Knative tools, and disconnect it from Mage, so it would be a general tooling.
It misses some things like:
This might help: https://github.com/bitfield/script
/assign
/assign
I'll assign myself to foster this epic.
/triage accepted
The productivity consensus is to deprecate the hacks repository and shift away from using shell scripts in Knative. Instead, the well-defined functionality should be re-implemented using Go-native tools. This will make it easier for Knative contributors to maintain, allow for testing with ease, and ultimately improve the overall solution's quality.
The default target for this rewrite is the knative/toolbox repository. Some code, which is reusable and might be used by direct code import, might be rewritten to specific sub-package withing the knative.dev/pkg.
Task list
Original issue by @kvmware: