knative / serving

Kubernetes-based, scale-to-zero, request-driven compute
https://knative.dev/docs/serving/
Apache License 2.0
5.56k stars 1.16k forks source link

Remove the symlinks to vendor directory #14326

Open cardil opened 1 year ago

cardil commented 1 year ago

Expected Behavior

The symlinks used in this repo that targets the vendor directroy should be removed.

Actual Behavior

Serving use symlinks to refer YAML files from networking repo:

$ find . -type l -printf '%p -> ' -exec readlink {} ';' | grep vendor
./config/core/configmaps/network.yaml -> ../../../vendor/knative.dev/networking/config/config-network.yaml
./config/core/300-imagecache.yaml -> ../../vendor/knative.dev/caching/config/image.yaml
./config/core/300-resources/certificate.yaml -> ../../../vendor/knative.dev/networking/config/certificate.yaml
./config/core/300-resources/domain-claim.yaml -> ../../../vendor/knative.dev/networking/config/domain-claim.yaml
./config/core/300-resources/ingress.yaml -> ../../../vendor/knative.dev/networking/config/ingress.yaml
./config/core/300-resources/serverlessservice.yaml -> ../../../vendor/knative.dev/networking/config/serverlessservice.yaml

Ideas

Fold the Networking onto Serving

By folding the networking repo onto Serving repo we would remove the need for symlinks across repos.

Unpack networking YAML files during build

The networking YAML files could be embedded in Go files, and unpacked in Serving in a build process.

dprotaso commented 1 year ago

The networking YAML files could be embedded in Go files, and unpacked in Serving in a build process.

I think when we update deps we can just do a curl to fetch the resources

we do this in contour - https://github.com/knative-extensions/net-contour/blob/27833509e18d357b74ef42a53d86ae311ffd6692/hack/update-deps.sh#L34

dprotaso commented 1 year ago

/triage accepted

dprotaso commented 1 year ago

/assign @cardil

Priyansurout commented 1 year ago

/assign