docs: add language specifiers to fenced code blocks

code-samples/eventing/bookstore-sample-app/solution/slack-sink/README.md

@@ -16,7 +16,7 @@ When a CloudEvent with the type `new-review-comment` is sent to the Knative Even
 
 Install Apache Camel K operator on your cluster using any of the methods listed in [the official installation docs](https://camel.apache.org/camel-k/2.8.x/installation/installation.html). We will use the installation via Kustomize:
 
-```sh
+```bash
 kubectl create ns camel-k && \
 kubectl apply -k github.com/apache/camel-k/install/overlays/kubernetes/descoped?ref=v2.8.0 --server-side
 ```
@@ -38,7 +38,7 @@ spec:
 
 Install it with one command:
 
-```sh
+```bash
 cat <<EOF | kubectl apply -f -
 apiVersion: camel.apache.org/v1
 kind: IntegrationPlatform
@@ -63,13 +63,13 @@ This Broker is created solely for testing purposes and is intended for temporary
 
 **Method 1**: Initialize a Broker within your Kubernetes cluster using the Knative CLI:
 
-```sh
+```bash
 kn broker create book-review-broker
 ```
 
 You will see this message if the Broker is created successfully:
 
-```sh
+```bash
 Broker 'book-review-broker' successfully created in namespace 'default'.
 ```
 
@@ -87,13 +87,13 @@ metadata:
 
 After you saved the file, you can apply the configuration to your Kubernetes cluster:
 
-```sh
+```bash
  kubectl apply -f book-review-broker.yaml
 ```
 
 You will see this message if the Broker is created successfully:
 
-```sh
+```bash
 broker.eventing.knative.dev/book-review-broker created
 ```
 
@@ -136,13 +136,13 @@ Make sure to replace the `webhookUrl` with your actual Slack channel name and we
 
 3. Apply the configuration to your Kubernetes cluster:
 
-```sh
+```bash
 kubectl apply -f slack-sink.yaml
 ```
 
 You will see this message if the configuration is created successfully:
 
-```sh
+```bash
 pipe.camel.apache.org/bookstore-notification-service created
 ```
 
@@ -163,21 +163,21 @@ Directly sending CloudEvents to a Broker using curl from an external machine (li
 
 Therefore, you need to create a new pod in your Kubernetes cluster to send a CloudEvent to the Broker. You can use the following command to create a new pod:
 
-```sh
+```bash
 kubectl run curler --image=radial/busyboxplus:curl -it --restart=Never
 ```
 
 You will see this message if you successfully entered the pod's shell
 
-```sh
+```bash
 [root@curler:/]$ 
 ```
 
 If you don't see a command prompt, try pressing enter.
 
 Using curl command to send a CloudEvent to the Broker:
 
-```sh
+```bash
 [root@curler:/]$ curl -v "<The URI to your Broker>" \
 -X POST \
 -H "Ce-Id: review1" \

code-samples/serving/knative-routing-go/README.md

@@ -27,15 +27,15 @@ the Login service.
      will refer to it as <YOUR_DOMAIN_NAME> in the rest of this document
 4. Check out the code:
 
-```
+```bash
 go get -d github.com/knative/docs/code-samples/serving/knative-routing-go
 ```
 
 ## Setup
 
 To check the domain name, run the following command:
 
-```
+```bash
 kubectl get cm  -n knative-serving config-domain -o yaml
 ```
 
@@ -69,7 +69,7 @@ export REPO="docker.io/<username>"
 
 3. Use Docker to build and push your application container:
 
-```
+```bash
 # Build and push the container on your local machine.
 docker buildx build --platform linux/arm64,linux/amd64 -t "${REPO}/knative-routing-go" --push . -f code-samples/serving/knative-routing-go/Dockerfile
 ```
@@ -87,15 +87,15 @@ docker buildx build --platform linux/arm64,linux/amd64 -t "${REPO}/knative-routi
 
    - Run this command:
 
-   ```
+   ```bash
    perl -pi -e "s@github.com/knative/docs/code-samples/serving@${REPO}@g" code-samples/serving/knative-routing-go/sample.yaml
    ```
 
 ## Deploy the Service
 
 Deploy the Knative Serving sample:
 
-```
+```bash
 kubectl apply --filename code-samples/serving/knative-routing-go/sample.yaml
 ```
 
@@ -107,21 +107,21 @@ Kubernetes service with:
 
 - Check the shared Gateway:
 
-```
+```bash
 kubectl get Gateway --namespace knative-serving --output yaml
 ```
 
 - Check the corresponding Kubernetes service for the shared Gateway:
 
-```
+```bash
 INGRESSGATEWAY=istio-ingressgateway
 
 kubectl get svc $INGRESSGATEWAY --namespace istio-system --output yaml
 ```
 
 - Inspect the deployed Knative services with:
 
-```
+```bash
 kubectl get ksvc
 ```
 
@@ -141,7 +141,12 @@ export GATEWAY_IP=`kubectl get svc $INGRESSGATEWAY --namespace istio-system \
 2. Find the `Search` service URL with:
 
 ```bash
-# kubectl get route search-service  --output=custom-columns=NAME:.metadata.name,URL:.status.url
+kubectl get route search-service  --output=custom-columns=NAME:.metadata.name,URL:.status.url
+```
+
+Example output:
+
+```text
 NAME              URL
 search-service    http://search-service.default.example.com
 ```
@@ -166,7 +171,7 @@ You should see: `Login Service is called !`
 
 1. Apply the custom routing rules defined in `routing.yaml` file with:
 
-```
+```bash
 kubectl apply --filename code-samples/serving/knative-routing-go/routing.yaml
 ```
 
@@ -182,7 +187,7 @@ like {{.Name}}-{{.Namespace}}. You can find out the format by running the
 command:
 {% endraw %}
 
-```
+```bash
 kubectl get cm  -n knative-serving config-network -o yaml
 ```
 
@@ -196,7 +201,7 @@ Then look for the value for `domain-template`. If it is
 2. The `routing.yaml` file will generate a new VirtualService `entry-route` for
    domain `example.com` or your own domain name. View the VirtualService:
 
-```
+```bash
 kubectl get VirtualService entry-route --output yaml
 ```
 
@@ -268,15 +273,15 @@ with a destination address of an externally available service.
 
 Using
 
-```
+```bash
 kubectl label kservice search-service login-service networking.knative.dev/visibility=cluster-local
 ```
 
 you label the services as an cluster-local services, removing access via `search-service.default.example.com`
 and `login-service.default.example.com`. After doing so, your previous routing rule will not be routable anymore.
 Running
 
-```
+```bash
 kubectl apply --filename code-samples/serving/knative-routing-go/routing-internal.yaml
 ```
 

code-samples/serving/tag-header-based-routing/README.md

@@ -25,7 +25,7 @@ with Knative v0.16 and later.
 
 This feature is disabled by default. To enable this feature, run the following command:
 
-```
+```bash
 kubectl patch cm config-features -n knative-serving -p '{"data":{"tag-header-based-routing":"Enabled"}}'
 ```
 
@@ -48,14 +48,14 @@ routed to the second Revision.
 
 Run the following command to set up the Knative Service and Revisions.
 
-```
+```bash
 kubectl apply -f code-samples/serving/tag-header-based-routing/sample.yaml
 ```
 
 ## Check the created resources
 
 Check the two created Revisions using the following command
-```
+```bash
 kubectl get revisions
 ```
 
@@ -65,13 +65,13 @@ for the Revisions to become ready.
 
 Check the Knative Service using the following command
 
-```
+```bash
 kubectl get ksvc tag-header -oyaml
 ```
 
 You should see the following block which indicates the tag `rev1` is successfully added to the first Revision.
 
-```
+```yaml
   - revisionName: tag-header-revision-1
     percent: 0
     tag: rev1
@@ -84,37 +84,37 @@ You should see the following block which indicates the tag `rev1` is successfull
 
 1.  Run the following command to send a request to the first Revision.
 
-    ```
+    ```bash
     curl ${INGRESS_IP} -H "Host:tag-header.default.example.com" -H "Knative-Serving-Tag:rev1"
     ```
     where `${INGRESS_IP}` is the IP of your ingress.
 
     You should get the following response:
 
-    ```
+    ```text
     Hello First Revision!
     ```
 
 1.  Run the following command to send requests without the `Knative-Serving-Tag` header:
 
-    ```
+    ```bash
     curl ${INGRESS_IP} -H "Host:tag-header.default.example.com"
     ```
 
     You should get the response from the second Revision:
 
-    ```
+    ```text
     Hello Second Revision!
     ```
 
 1.  Run the following command to send requests with an incorrect `Knative-Serving-Tag` header:
 
-    ```
+    ```bash
     curl ${INGRESS_IP} -H "Host:tag-header.default.example.com" -H "Knative-Serving-Tag:wrongHeader"
     ```
 
     You should get the response from the second Revision:
 
-    ```
+    ```text
     Hello Second Revision!
     ```

docs/blog/articles/Building-Stateful-applications-with-Knative-and-Restate.md

@@ -203,27 +203,27 @@ func main() {
 
 You can now build the container image using your tools, e.g. with `ko`:
 
-```shell
+```bash
 $ ko build main.go -B
 ```
 
 And deploy it with `kn`:
 
-```shell
+```bash
 $ kn service create signup \
   --image $MY_IMAGE_REGISTRY/main.go \
   --port h2c:8080
 ```
 
 Before sending requests, you need to tell Restate about your new service deployment:
 
-```shell
+```bash
 $ restate deployments register http://signup.default.svc
 ```
 
 And this is it! You're now ready to send requests:
 
-```shell
+```bash
 $ curl http://localhost:8080/Signup/Signup --json '{"username": "slinkydeveloper", "name": "Francesco", "surname": "Guardiani", "password": "Pizza-without-pineapple"}'
 ```
 

docs/blog/articles/ai_functions_llama_stack.md

@@ -31,13 +31,13 @@ For convenience I have created a Github repository that contains scripts for an
 
 For local development it is recommended to enable port-forwarding for the Llama Stack server:
 
-```shell
+```bash
 kubectl port-forward service/llamastackdistribution-sample-service 8321:8321 
 ```
 
 Now your scripts can access it via `localhost:8321`:
 
-```shell
+```bash
 http localhost:8321/v1/version
 
 HTTP/1.1 200 OK
@@ -58,7 +58,7 @@ _**Note:** The APIs of Llama Stack are fast evolving, but it supports a docs end
 
 Once all of the above is running you need to create your [Knative Functions](https://knative.dev/docs/functions/){:target="_blank"} project. We are using the CloudEvent template for the new [functions runtime for Python](https://github.com/knative-extensions/func-python){:target="_blank"}.
 
-```shell
+```bash
 func create -l python -t cloudevents inference-func
 ```
 
@@ -207,7 +207,7 @@ _**NOTE:** the docstrings were remove to keep the program compact._
 
 We can now run our function locally by issuing `func run` on the command line. Once it is running there will a system log like below:
 
-```shell
+```bash
 INFO:root:Functions middleware invoking user function
 INFO:root:Connecting to LLama Stack
 INFO:httpx:HTTP Request: GET http://localhost:8321/v1/models "HTTP/1.1 200 OK"
@@ -221,7 +221,7 @@ Running on host port 8080
 
 Now we can send a CloudEvent to the function, which contains our query for the AI model inference. In a new terminal of the function project we use `func invoke` for this:
 
-```shell
+```bash
 func invoke -f=cloudevent --data='{"query":"Tell me a dad joke!"}'   
 Context Attributes,
   specversion: 1.0
@@ -239,13 +239,13 @@ We see that the function was returning a different CloudEvent, which contains th
 
 To deploy the function to our `kind` cluster you need to install Knative Serving. The [Llama Stack Stack repo](https://github.com/matzew/llama-stack-stack){:target="_blank"} has a script for this as well. Once it is installed simply run:
 
-```shell
+```bash
 func deploy --builder=host --build
 ```
 
 This builds the function, using the `host` builder, pushes it to the container registry and eventually deploys it as a Knative Serving Service on Kubernetes:
 
-```shell
+```bash
 🙌 Function built: quay.io/<my-func-org>/inference-func:latest
 pushing 100% |████████████████████████████████████████| (175/121 MB, 24 MB/s) [7s]
 ✅ Function deployed in namespace "default" and exposed at URL: