Fix outdated documentation: broken links, wrong paths, stale claims (#9087)

- Update Go version requirement from 1.18 to 1.25 to match go.mod
- Fix broken links to knative/docs (repo restructured), traces docs, and working groups
- Fix incorrect YAML file paths in debugging examples
- Update CEL description to reflect its current widespread adoption
- Correct OPA/Rego characterization (OPA never replaced Rego with CEL)
- Fix CloudEvents spec links from v1.0-rc1 to v1.0.2
- Remove broken link to deleted interfaces.md, fix empty Source link
- Fix eventing.kantive.dev typo to eventing.knative.dev
- Remove stale TODOs in bug triage doc
- Update master branch refs to main
- Replace deprecated K8s scheduling policies link
- Fix test/e2e README link to config.go

Author: creydr

DEVELOPMENT.md

@@ -31,7 +31,7 @@ Before submitting a PR, see also [contribution guidelines](./CONTRIBUTING.md).
 You must install these tools:
 
 1. [`go`](https://golang.org/doc/install): The language `Knative Eventing` is
-   developed with (version 1.18 or higher)
+   developed with (version 1.25 or higher)
 1. [`git`](https://help.github.com/articles/set-up-git/): For source control
 1. [`ko`](https://github.com/google/ko): For building and deploying container
    images to Kubernetes in a single command.
@@ -160,14 +160,14 @@ kubectl -n knative-eventing logs $(kubectl -n knative-eventing get pods -l app=e
 Install the
 [In-Memory-Channel](https://github.com/knative/eventing/tree/main/config/channels/in-memory-channel)
 since this is the
-[default channel](https://github.com/knative/docs/blob/main/docs/eventing/channels/default-channels.md).
+[default channel](https://knative.dev/docs/eventing/configuration/channel-configuration/).
 
 ```shell
 ko apply -Rf config/channels/in-memory-channel/
 ```
 
 Depending on your needs you might want to install other
-[channel implementations](https://github.com/knative/docs/blob/main/docs/eventing/channels/channels-crds.md).
+[channel implementations](https://knative.dev/docs/eventing/channels/).
 
 ## Install Broker
 
@@ -284,7 +284,7 @@ To access Telemetry see:
 
 - [Accessing Metrics](https://knative.dev/docs/eventing/observability/metrics/collecting-metrics/)
 - [Accessing Logs](https://knative.dev/docs/eventing/observability/logging/collecting-logs/)
-- [Accessing Traces](https://www.knative.dev/docs/eventing/accessing-traces/)
+- [Accessing Traces](https://knative.dev/docs/eventing/observability/metrics/collecting-metrics/#traces)
 
 ## Packet sniffing
 
@@ -431,11 +431,11 @@ You can debug any component by applying its config with `--debug`:
 
 ```shell
 # Debug the in-memory channel dispatcher
-ko apply -f config/channels/in-memory-channel/300-dispatcher.yaml --debug
+ko apply -f config/channels/in-memory-channel/deployments/dispatcher.yaml --debug
 kubectl -n knative-eventing port-forward deploy/imc-dispatcher 40000:40000
 
 # Debug the MT broker ingress
-ko apply -f config/brokers/mt-channel-broker/500-ingress.yaml --debug
+ko apply -f config/brokers/mt-channel-broker/500-broker-ingress.yaml --debug
 kubectl -n knative-eventing port-forward deploy/mt-broker-ingress 40000:40000
 ```
 

README.md

@@ -51,7 +51,7 @@ For complete Knative Eventing documentation, see
 
 If you are interested in contributing, see [the ready to work issues](https://clotributor.dev/search?ts_query_web=knative+eventing&page=1), [CONTRIBUTING.md](./CONTRIBUTING.md),
 [DEVELOPMENT.md](./DEVELOPMENT.md) and
-[Knative working groups](https://knative.dev/community/contributing/working-groups/working-groups/#eventing).
+[Knative working groups](https://github.com/knative/community/blob/main/working-groups/WORKING-GROUPS.md#eventing).
 
 Interested users should join
 [knative-users](https://groups.google.com/forum/#!forum/knative-users).

docs/broker/filtering.md

@@ -387,17 +387,9 @@ spec:
 
 The main caveat is the choice of CEL as expression language.
 
-CEL is new and the language is not officially supported by Google. Participation
-by non-Google contributors is low. OPA is planning to replace their policy
-language Rego with CEL, but
-[no timeline has been announced for this migration](https://github.com/open-policy-agent/opa/issues/811#issuecomment-401844999).
-The KrakenD API Gateway has announced support for CEL
-[here](https://medium.com/devops-faith/krakend-api-gateway-0-9-released-9427c249dbcd).
-
-The CEL language is new and has limited exposure, despite being informed by
-experience and research at Google. We may discover issues that make it less
-suitable for Trigger filtering (e.g.
-[google/cel-go#203](https://github.com/google/cel-go/issues/203).
+CEL has since become widely adopted across the cloud-native ecosystem, including
+Kubernetes (e.g. validation rules, admission policies), Istio, and other
+projects. It is officially supported by Google.
 
 If CEL turns out to be a liability, a new expression language could be added
 alongside CEL without breaking existing triggers, allowing for an orderly
@@ -496,12 +488,10 @@ been judged less suitable for Trigger filtering than CEL.
 already as a policy expression language by
 [Open Policy Agent](https://www.openpolicyagent.org/). It could be an attractive
 choice, but
-[OPA has indicated a desire to replace Rego with CEL](https://github.com/open-policy-agent/opa/issues/811#issuecomment-401844999).
-Since Rego doesn't seem to be used outside OPA, choosing Rego for Trigger
-filters would likely make Triggers the only remaining use of Rego.
-
-The possible maintenance burden of being the only Rego user makes Rego less
-suitable for Trigger filtering than CEL.
+OPA has continued to develop Rego as its policy language. Since Rego is
+primarily used within the OPA ecosystem, choosing Rego for Trigger filters
+would add an additional dependency without broad ecosystem benefits, making
+Rego less suitable for Trigger filtering than CEL.
 
 #### Custom expression language
 

docs/mt-channel-based-broker/README.md

@@ -33,7 +33,7 @@ The `mt-broker-controller` is kind of the heart of the MTChannelBasedBroker cont
       name: config-br-default-channel
       namespace: knative-eventing
   ```
-* Updates the status on `Broker` resources with the `eventing.kantive.dev/broker.class: MTChannelBasedBroker` annotation with the address for the broker ingress.
+* Updates the status on `Broker` resources with the `eventing.knative.dev/broker.class: MTChannelBasedBroker` annotation with the address for the broker ingress.
 
 ### Channel specific controllers (e.g. `imc-controller`)
 

docs/planning/bug_triage.md

@@ -42,7 +42,7 @@ process.
 
 ## Bug Triage
 
-- WG lead will form a bug triage team (TODO: Ville)
+- WG lead will form a bug triage team.
 - There will be one bug triage champion each week to triage incoming bugs and
   assign them correct priority. This role will be rotated among engineers in the
   bug triage team.
@@ -59,8 +59,9 @@ process.
     we should close the bug upon triaging. [Remember the goal](#Goal).
   - Bugs with priority/critical-urgent and priority/important-soon bugs should
     have an assigned owner who has acknowledged the ownership of the bug.
-  - TODO: Update these guidelines based on learning from triage meetings. Triage
-    team will own and update this document and WG lead will approve the changes.
+  - These guidelines should be updated based on learnings from triage meetings.
+    Triage team will own and update this document and WG lead will approve the
+    changes.
 - In case of conflict, final decision will be taken by WG lead.
 - WG lead will periodically monitor bug count and trend to make sure we meet our
   [goal](#Goal).

docs/spec/sources.md

@@ -5,7 +5,7 @@ relays that event to another endpoint on the cluster via
 [CloudEvents](https://cloudevents.io). Sourcing events is critical to developing
 a distributed system that reacts to events.
 
-A **Sink** is an [_addressable_](./interfaces.md#addressable) resource that
+A **Sink** is an _addressable_ resource that
 takes responsibility for the event. A **Sink** could be a consumer of events, or
 middleware. A **Sink** will respond with 2xx when it has accepted and processed
 the event.
@@ -42,7 +42,7 @@ For operators of a Kubernetes cluster, there are two states to sources:
    for that source for the current situation. While this resource is running, a
    cluster operator would like to inspect the resource without needing to be
    fully aware of the implementation. This is done by conforming to the
-   [Source]() ducktype. This topic is expanded upon in the
+   Source ducktype. This topic is expanded upon in the
    [Source Custom Objects](#source-custom-objects) section.
 
 The goal of requiring CRD labels and running resource shapes is to enable
@@ -230,10 +230,10 @@ unmarshalled by tooling (e.g., a CLI). In particular, each object in the array
 MUST contain the following fields:
 
 - type: String. Refers to the
-  [CloudEvents type](https://github.com/cloudevents/spec/blob/v1.0-rc1/spec.md#type)
+  [CloudEvents type](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md#type)
   attribute. Mandatory.
 - schema: String. Refers to the
-  [CloudEvents dataschema](https://github.com/cloudevents/spec/blob/v1.0-rc1/spec.md#dataschema)
+  [CloudEvents dataschema](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md#dataschema)
   attribute. Optional.
 - description: String describing the event. Optional.
 

pkg/scheduler/README.md

@@ -87,10 +87,9 @@ changes.)
 
 * https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/
 * https://github.com/kubernetes-sigs/descheduler
-* https://kubernetes.io/docs/reference/scheduling/policies/
-* https://kubernetes.io/docs/reference/config-api/kube-scheduler-policy-config.v1
+* https://kubernetes.io/docs/reference/config-api/kube-scheduler-config.v1/
 * https://github.com/virtual-kubelet/virtual-kubelet#how-it-works
-* https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/624-scheduling-framework
+* https://github.com/kubernetes/enhancements/tree/main/keps/sig-scheduling/624-scheduling-framework
 * https://medium.com/tailwinds-navigator/kubernetes-tip-how-statefulsets-behave-differently-than-deployments-when-node-fails-d29e36bca7d5
 * https://kubernetes.io/docs/concepts/architecture/nodes/#node-controller
 
@@ -100,4 +99,4 @@ To learn more about Knative, please visit the
 [/docs](https://github.com/knative/docs) repository.
 
 This repo falls under the
-[Knative Code of Conduct](https://github.com/knative/community/blob/master/CODE-OF-CONDUCT.md)
+[Knative Code of Conduct](https://github.com/knative/community/blob/main/CODE-OF-CONDUCT.md)

test/e2e/README.md

@@ -9,7 +9,7 @@ Knative Eventing e2e tests
 to verify the behavior of this specific implementation.
 
 If you want to add tests for a new `channel` and reuse existing tests for it,
-please look into [config.go](../common/config.go) and make corresponding
+please look into [config.go](../lib/config.go) and make corresponding
 changes.
 
 If you want to add a new test case, please add one new test file under [e2e](.)