Fix: read the TLS secret given as namespace/name in vela/http

SA
3d ago
+90-8

Description of your changes

getTransport in the vela/http provider (and the legacy op.#HTTPDo provider) accepts a tls_config.secret given as <namespace>/<name>, but the split was off by one:

objectKey.Namespace = secretName[:index-1] // "vela-system/certs" -> "vela-syste"
objectKey.Name = secretName[index:]        // -> "/certs"

So the secret lookup always failed for that form. The caller drops the error from getTransport, so the request then went out with the default transport, without the configured CA and client certificate, and usually failed later with a TLS error that didn't mention the secret.

This splits on the first / with strings.Cut in both providers. A plain secret name still uses the namespace from tls_config.namespace (or the workflow namespace), and a leading / is still ignored as before.

I found this while reading the code. I couldn't find an existing issue or PR for it.

I have:

  • Read and followed KubeVela's contribution process.
  • Related Docs updated properly. No docs change is needed: this makes the existing behaviour work.
  • Run make reviewable to ensure this PR is ready for review. (I ran gofmt, go vet and golangci-lint on the changed packages instead, see below.)
  • Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

  • New TestGetTransportSecretKey in both pkg/providers/http and pkg/providers/legacy/http. It checks the secret key used for certs + namespace default and for vela-system/certs. On the current main the second case fails with Namespace:"vela-syste", Name:"/certs".
  • go test ./pkg/providers/http/ ./pkg/providers/legacy/http/... passes.
  • gofmt, go vet and golangci-lint run --new-from-rev=HEAD on the changed packages are clean.

Special notes for your reviewer

getTransport errors are still ignored by the callers (err == nil && tr != nil). I left that as is, since returning the error would change behaviour for workflows that set a tls_config with a missing secret today.

I used an AI assistant to help with this change (see the Assisted-by trailer). I reviewed and tested the change.

Summary by cubic

Fixes parsing of tls_config.secret given as <namespace>/<name> in the vela/http and legacy op.#HTTPDo providers. Previously vela-system/certs was split off by one, looking up secret /certs in namespace vela-syste; the lookup failed and, because the caller dropped the error, requests went out with the default transport, without the configured CA and client certificate.

  • Splits on the first / with strings.Cut in both providers.
  • Plain secret names still use the namespace from tls_config.namespace or the workflow namespace; a leading / is still ignored.
  • Adds TestGetTransportSecretKey in both providers covering plain and <namespace>/<name> secret references.