Presubmit Go-native runner

[cardil]

Rewrite presubmit-tests.sh script (https://github.com/knative/hack/blob/main/README.md#using-the-presubmit-testssh-helper-script) into a Golang tool knative.dev/toolbox/presubmit.

Invent new Go-native extension interface, for example:

# will look for Go files with `presubmit` build constraints, that register configuration
go run knative.dev/toolbox/presubmit@latest --unit-tests

An example configuration might look like:

//go:build presubmit
package eventing

import (
  "fmt"
  "os"

  "github.com/bitfield/script"
  "knative.dev/toolbox/presubmit/pkg/config"
)

init {
  config.Configure(config.Hooks{
    PostBuildTests: function(ctx config.Context) error {
      return os.RemoveAll("build-cache")
    },
    UnitTests: function(ctx config.Context) error {
      p := script.Exec("make -C tests test")
      _, _ = pp.Stdout()
      return p.Error()
    },
    PreIntegrationTests: function(ctx config.Context) error {
      return os.RemoveAll("staging-area")
    },
  })
}

[mgencur]

will look for Go files with presubmit build constraints, that register configuration
go run knative.dev/toolbox/presubmit@latest --unit-tests

Where will the binary look for the configuration? Do we want to pass the path as an argument like in #17 where the first argument is the path (i.e. go run knative.dev/toolbox/presubmit@latest ./ --unit-tests)

Or possibly pass the configuration as an argument: go run knative.dev/toolbox/presubmit@latest --config=/path/to/config --unit-tests
I'm curious if beeing more explicit about the passed config would make it more clear and easy to use.

[cardil]

@mgencur Where will the binary look for the configuration?

I was thinking we can have this as an optional argument, which by default will take the information from the current module (see the modscope tool)

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[cardil]

/reopen
/remove-lifecycle stale
/triage accepted

[knative-prow]

@cardil: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle stale
/triage accepted

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.