### Install BuildBuddy Helm Chart

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/buildbuddy/README.md

Installs the BuildBuddy Enterprise Helm chart into the 'buildbuddy' namespace, using the configuration provided in the config.yaml file.

```shell
helm install --namespace buildbuddy buildbuddy buildbuddy/buildbuddy-enterprise -f config.yaml
```

--------------------------------

### Example Redis Failover Pods Output - Shell

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/protocols/redis/README.md

Shows example output from `kubectl get pods` after deploying the Redis failover cluster. Illustrates the expected pods (operator, failover replicas, sentinel replicas) and their statuses. This is example output, not executable code.

```shell
redisoperator-57975fb5c-tkcfs        1/1     Running   0          20m
rfr-redisfailover-0                  1/1     Running   0          11m
rfr-redisfailover-1                  0/1     Pending   0          11m
rfr-redisfailover-2                  0/1     Pending   0          11m
rfs-redisfailover-5d49fd878f-89lbj   1/1     Running   0          11m
rfs-redisfailover-5d49fd878f-mdr9x   1/1     Running   0          11m
rfs-redisfailover-5d49fd878f-sxb2m   1/1     Running   0          11m
```

--------------------------------

### Example Redis Event Record - Shell

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/protocols/redis/README.md

Provides an example data record from the `redis_events.beta` table, likely captured by the tracing pipeline. Shows details of a Redis Sentinel `PUBLISH` command related to failover communication. This is example data output, not executable code.

```shell
{
time_: 1613604049816,
remote_addr: 10.245.35.240,
remote_port: 46810,
cmd: PUBLISH,
cmd_args: {
channel: __sentinel__:hello,
message: 10.245.35.240,26379,3f48dc18038d92582815433648b5eed5ddd4ae22,0,mymaster,10.245.35.243,6379,0
 },
resp: 3,
latency_ns: 186550,
pod: default/rfr-redisfailover-0
 }
```

--------------------------------

### Add and Update Helm Repo (BuildBuddy)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/buildbuddy/README.md

Adds the official BuildBuddy Helm repository to your local Helm configuration and updates the list of available charts from all configured repositories.

```shell
helm repo add buildbuddy https://helm.buildbuddy.io
helm repo update
```

--------------------------------

### Running Webpack Development Server (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/ui/README.md

Navigates to the UI source directory, installs dependencies using `yarn install`, and starts the webpack development server using `yarn dev` to run the UI locally.

```Shell
cd src/ui
yarn install
yarn dev
```

--------------------------------

### Create Namespace and Apply Secrets (BuildBuddy)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/buildbuddy/README.md

Creates the dedicated 'buildbuddy' Kubernetes namespace if it doesn't exist and applies secrets decrypted from a sops-encrypted file using kubectl.

```shell
kubectl create namespace buildbuddy
sops -d $(git rev-parse --show-toplevel)/private/credentials/dev_infra/buildbuddy/sa_secret.yaml | kubectl apply -n buildbuddy -f -
```

--------------------------------

### Build/Prepare Go HTTPS Server with Bazel

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/testing/demo_apps/go_https/README.md

Builds or prepares the Go HTTPS server demo application using Bazel, but does not execute it immediately due to the --norun flag.

```bash
bazel run //src/stirling/testing/demo_apps/go_https/server:golang_1_23_https_server -- --norun
```

--------------------------------

### Build/Prepare Go HTTPS Client with Bazel

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/testing/demo_apps/go_https/README.md

Builds or prepares the Go HTTPS client demo application using Bazel, but does not execute it immediately due to the --norun flag.

```bash
bazel run //src/stirling/testing/demo_apps/go_https/client:golang_1_23_https_client -- --norun
```

--------------------------------

### Setup Docker Buildx for Multi-Arch (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/src/experimental/multi_arch/README.md

Downloads and installs the Docker Buildx plugin, sets up binfmt support for multiple architectures, and creates/uses a new Buildx builder instance for multi-platform builds.

```bash
wget https://github.com/docker/buildx/releases/download/v0.10.0/buildx-v0.10.0.linux-amd64
mkdir -p ~/.docker/cli-plugins/
mv buildx-v0.10.0.linux-amd64 ~/.docker/cli-plugins/docker-buildx
chmod +x ~/.docker/cli-plugins/docker-buildx

docker run --privileged --rm tonistiigi/binfmt --install all

docker buildx create --name mybuilder --driver docker-container --bootstrap
docker buildx use mybuilder
```

--------------------------------

### Deploying and Load Testing on Kubernetes (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/demo_apps/go_http/README.md

Builds and deploys the application to a Kubernetes cluster using a script, then retrieves the service IP and runs a load test against it using wrk.

```shell
# Build and deploy
./deploy.sh
# Run load test
IP=$(kubectl get service -l name=simple-service -o json | jq -r '.items[0].status.loadBalancer.ingress[0].ip')
wrk -c 2 -d 10m "http://${IP}/bm?latency=50" --latency
```

--------------------------------

### Install k3sup (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/equinix_k3s/README.md

Downloads and installs the k3sup tool using curl. It pipes the script to sh and then attempts to install k3sup into the ~/bin directory.

```bash
curl -sLS https://get.k3sup.dev | sh
install k3sup ~/bin
```

--------------------------------

### Run Go HTTPS Client in Docker

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/testing/demo_apps/go_https/README.md

Starts the built Go HTTPS client application within a Docker container, connecting it to the go_https_server container's network and configuring it to run 3 iterations with 3 sub-iterations each. This command should be executed in a separate terminal.

```bash
docker run --name=go_https_client --network=container:go_https_server bazel/src/stirling/testing/demo_apps/go_https/client:golang_1_23_https_client --iters 3 --sub_iters 3
```

--------------------------------

### Running Go HTTP Server with Bazel (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/demo_apps/go_http/README.md

Executes the simple HTTP server application using the Bazel build tool. This command compiles and runs the specified target.

```shell
bazel run //demos/client_server_apps/go_http/server:simple_http_server
```

--------------------------------

### Installing Ingress-Nginx Controller with Helm (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/slackin/README.md

This snippet outlines the steps to install the Ingress-Nginx controller using Helm. It adds the official Helm repository, updates it, and then installs the controller into a dedicated namespace, which is a prerequisite for exposing services externally.

```shell
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace
```

--------------------------------

### Running Pixie CLI Commands via Bazel (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Demonstrates how to execute standard Pixie CLI commands using bazel run targeting the development CLI binary. Examples show how to run the deploy command and the run px/cluster script.

```bash
bazel run //src/pixie_cli:px -- deploy
```

```bash
bazel run //src/pixie_cli:px -- run px/cluster
```

--------------------------------

### Installing Pixie Go API

Source: https://github.com/pixie-io/pixie/blob/main/src/api/go/pxapi/README.md

This command uses the Go package manager to fetch and install the px.dev/pxapi library, making it available for use in Go projects.

```Shell
go get px.dev/pxapi
```

--------------------------------

### Proof of Concept Cross-Compilation (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/src/experimental/multi_arch/README.md

Demonstrates cross-compiling a simple C++ program for aarch64 using the installed tools and running it via QEMU user-mode emulation.

```bash
aarch64-linux-gnu-g++-12 -static -o aarch64_hello hello.cc
qemu-aarch64 ./aarch64_hello
```

--------------------------------

### Run Go HTTPS Server in Docker

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/testing/demo_apps/go_https/README.md

Starts the built Go HTTPS server application within a Docker container named go_https_server. This command should be executed in a terminal.

```bash
docker run --name=go_https_server bazel/src/stirling/testing/demo_apps/go_https/server:golang_1_23_https_server
```

--------------------------------

### Install Multi-Arch Build Tools (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/src/experimental/multi_arch/README.md

Installs necessary cross-compilation tools (binutils, g++, gcc for aarch64) and QEMU for user-mode emulation required for building and testing multi-platform images.

```bash
sudo apt install binutils-aarch64-linux-gnu g++-12-aarch64-linux-gnu gcc-12-aarch64-linux-gnu
sudo apt install qemu-user qemu-user-static
```

--------------------------------

### Upgrade BuildBuddy Helm Chart

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/buildbuddy/README.md

Upgrades an existing BuildBuddy Enterprise Helm release named 'buildbuddy' in the 'buildbuddy' namespace, applying the configuration from config.yaml.

```shell
helm upgrade --namespace buildbuddy buildbuddy buildbuddy/buildbuddy-enterprise -f config.yaml
```

--------------------------------

### Testing HTTP Server with Curl (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/demo_apps/go_http/README.md

Sends an HTTP GET request to the running server's ping endpoint using the curl command-line tool. This verifies the server is responsive.

```shell
curl localhost:9090/ping
```

--------------------------------

### Clean Up Configuration File

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/buildbuddy/README.md

Removes the temporary config.yaml file that was used for installation or upgrade.

```shell
rm -f config.yaml
```

--------------------------------

### Show Global Installation Directory Structure

Source: https://github.com/pixie-io/pixie/blob/main/tools/arc_addons/clang_format/README.md

Illustrates the required directory structure for a global installation where the clang-format-linter repository is cloned into the same parent directory as arcanist and libphutil.

```sh
> ls
arcanist
clang-format-linter
libphutil
```

--------------------------------

### Run Pixie Development Docker Container

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Executes the script to start the Docker container for the Pixie development environment. This script sets up the necessary tools and environment inside the container.

```Bash
./scripts/run_docker.sh
```

--------------------------------

### Decrypt and Save BuildBuddy Config

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/buildbuddy/README.md

Decrypts the sops-encrypted BuildBuddy configuration file from a specified path and redirects the output to a local file named config.yaml.

```shell
sops -d $(git rev-parse --show-toplevel)/private/credentials/dev_infra/buildbuddy/config.yaml > config.yaml
```

--------------------------------

### Adding Helm Repo and Installing ARC Chart (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/action-runners/README.md

Adds the actions-runner-controller Helm repository and then installs or upgrades the chart into the `actions-runner-system` namespace. It creates the namespace if it doesn't exist, enables secret creation for authentication, sets a placeholder for the GitHub token, and waits for the deployment to complete. Requires Helm and a GitHub token.

```Shell
helm repo add actions-runner-controller https://actions-runner-controller.github.io/actions-runner-controller

helm upgrade --install --namespace actions-runner-system --create-namespace\
  --set=authSecret.create=true\
  --set=authSecret.github_token="REPLACE_YOUR_TOKEN_HERE"\
  --wait actions-runner-controller actions-runner-controller/actions-runner-controller
```

--------------------------------

### Setup RAID on Server (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/equinix_k3s/README.md

Runs the setup_raid.sh script on a specific server IP address. This script should be executed only once per server as part of the initial setup.

```bash
./setup_raid.sh <SERVER_IP>
```

--------------------------------

### Install pxapi Python Client

Source: https://github.com/pixie-io/pixie/blob/main/src/api/python/README.rst

This snippet shows the command to install the pxapi Python client library using pip, the standard package installer for Python.

```shell
pip install pxapi
```

--------------------------------

### Installing Cert-Manager with Helm (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/slackin/README.md

This snippet provides the commands to install Cert-Manager using Helm. It adds the Jetstack Helm repository, applies the necessary Custom Resource Definitions (CRDs), and then installs Cert-Manager into its own namespace, enabling automated TLS certificate management.

```shell
helm repo add jetstack https://charts.jetstack.io
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.12.0/cert-manager.crds.yaml
helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.12.0
```

--------------------------------

### Generating Self-Signed SSL Certificates (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/ui/README.md

Uses `mkcert` to generate self-signed SSL certificates for `prod.withpixie.ai`, `*.prod.withpixie.ai`, `localhost`, `127.0.0.1`, and `::1`, storing them in the paths specified by the environment variables. Requires `mkcert` to be installed.

```Shell
mkcert -install
mkcert \
    -cert-file $SELFSIGN_CERT_FILE \
    -key-file $SELFSIGN_CERT_KEY \
    prod.withpixie.ai "*.prod.withpixie.ai" localhost 127.0.0.1 ::1
```

--------------------------------

### Documenting Go Functions with Comments

Source: https://github.com/pixie-io/pixie/blob/main/styleguide/go_style.md

Illustrates the standard format for documentation comments in Go. Doc comments should be complete sentences, beginning with the name of the thing being described and ending in a period, as shown for a function signature.

```Go
// Compile parses a regular expression and returns, if successful,
// a Regexp that can be used to match against text.
func Compile(str string) (*Regexp, error) {
```

--------------------------------

### Install Buildbuddy Executor with Helm

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/buildbuddy-executor/README.md

This script installs or upgrades the Buildbuddy executor Helm chart on a Kubernetes cluster. It requires `helm`, `kubectl`, and `envsubst` to be installed. It first sets environment variables for the API key and namespace, adds the Buildbuddy Helm repository, creates the namespace and a Kubernetes secret for the API key, and then uses `envsubst` to inject the Docker image tag into the values file before deploying the chart.

```bash
export BB_EXECUTOR_API_KEY=""
export NAMESPACE=""

helm repo add buildbuddy https://helm.buildbuddy.io

kubectl create namespace "${NAMESPACE}" || true
kubectl create secret -n "${NAMESPACE}" generic buildbuddy-executor-api-key --from-literal=api-key="${BB_EXECUTOR_API_KEY}" || true

IMAGE_TAG="$(grep DOCKER_IMAGE_TAG "docker.properties" | cut -d= -f2)" \
envsubst '$IMAGE_TAG' < k8s/devinfra/buildbuddy-executor/values.yaml | \
helm upgrade --install -f - buildbuddy buildbuddy/buildbuddy-executor -n "${NAMESPACE}"
```

--------------------------------

### Creating Kubernetes Namespace for Runners (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/action-runners/README.md

Creates a new Kubernetes namespace named `action-runners`. This namespace will be used to deploy the actual runner pods. Requires `kubectl`.

```Shell
kubectl create namespace action-runners
```

--------------------------------

### Deploying Runners with Kustomize (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/action-runners/README.md

Uses `kustomize build` to generate the final YAML configuration for the runners from the specified directory and pipes the output to `kubectl apply` to deploy the runners into the Kubernetes cluster. Requires `kubectl` and `kustomize`.

```Shell
kustomize build k8s/devinfra/action-runners/runners | kubectl apply -f -
```

--------------------------------

### Assembly: Function Entry Frame Setup

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/perf_profiler/notes.md

Shows the standard x86-64 assembly instructions used at the beginning of a function to set up the frame pointer (%rbp) based on the stack pointer (%rsp). This is part of the frame pointer convention required for this stack walking method.

```Assembly
push   %rbp
mov    %rsp, %rbp
```

--------------------------------

### Apply Cert-Manager CRDs

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/buildbuddy/README.md

Applies the Custom Resource Definitions (CRDs) required for Cert-Manager from a specific release URL. The --validate=false flag is used to bypass schema validation which might fail on some Kubernetes versions.

```shell
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.crds.yaml
```

--------------------------------

### Deploy Redis Failover Cluster - Shell

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/protocols/redis/README.md

Deploys a simple Redis failover cluster on Kubernetes using the spotahome/redis-operator. Requires kubectl and a running Kubernetes cluster. Executes two `kubectl create` commands to apply operator and failover manifests.

```shell
kubectl create -f https://raw.githubusercontent.com/spotahome/redis-operator/master/example/operator/all-redis-operator-resources.yaml
kubectl create -f https://raw.githubusercontent.com/spotahome/redis-operator/master/example/redisfailover/basic.yaml
```

--------------------------------

### Provision K3s Cluster (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/equinix_k3s/README.md

Runs the setup_k3s.sh script to provision a K3s cluster. Requires several environment variables to be set, including Equinix API key, project ID, metro, EIP details, and server/agent IPs. The script outputs the kubeconfig file to the specified path.

```bash
EQUINIX_API_KEY=<api_key> \
EQUINIX_PROJECT_ID=<project_id> \
EQUINIX_METRO=<equinix metro of machines, eg. la> \
EIP=<eip> \
EIP_TAG=<eip_tag> \
SERVER_IPS=<comma separated list of IPS> \
AGENT_IPS=<optional comma separated list of IPS> \
./setup_k3s.sh <path/to/output/kubeconfig>
```

--------------------------------

### Clone Linter to Fixed Location

Source: https://github.com/pixie-io/pixie/blob/main/tools/arc_addons/clang_format/README.md

Provides shell commands to clone the clang-format-linter repository to a specific, fixed location on the system for global installation.

```sh
cd ~/.dev-tools
git clone https://github.com/vhbit/clang-format-linter
```

--------------------------------

### Running Tshark on a Docker Container (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/protocols/test_output_generator/README.md

Provides a multi-terminal example of running a MySQL server, attaching tshark to its network namespace using `nsenter` to capture traffic, and running a MySQL client in the same network namespace to generate traffic.

```Shell
# Terminal 1 - Run mysql server
docker run --pid=host --env=MYSQL_ALLOW_EMPTY_PASSWORD=1 --env=MYSQL_ROOT_HOST=% --name mysql_server_749245969612081 mysql/mysql-server:8.0.13

# Terminal 2 - Run tshark
ps -ef | grep mysqld
sudo nsenter -t 3269640 -n
tshark -i any -O mysql -Y mysql

# Terminal 3 - Run mysql client
docker run --rm --pid=host --network=container:mysql_server_749245969612081 -v/home/oazizi/src/px.dev/pixie/src/stirling/source_connectors/socket_tracer/protocols/mysql/testing:/scripts --name mysql_client_749286353166542 bazel/src/stirling/testing/app_containers/mysql:mysql_connector_image /scripts/script.py
```

--------------------------------

### Using absl::Substitute for String Formatting (C++)

Source: https://github.com/pixie-io/pixie/blob/main/styleguide/cc_style.md

Demonstrates the use of absl::Substitute to format a string by substituting placeholder values ($0, $1) with provided arguments (pid, msg). This is the preferred method for template-based string formatting in Pixie's C++ style guide.

```C++
absl::Substitute("[PID=$0] Unexpected event. Message: msg=$1.", pid, msg);
```

--------------------------------

### Creating BuildBuddy Secret in Kubernetes (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/action-runners/README.md

Uses `envsubst` to substitute the `BB_API_KEY` environment variable into a YAML file and then applies the resulting YAML to Kubernetes using `kubectl apply`. This creates a secret containing the BuildBuddy configuration. Requires `kubectl`, `envsubst`, and the `bb_bazelrc_secret.yaml` file.

```Shell
BB_API_KEY=<BUILDBUDDY-API-KEY> envsubst < k8s/devinfra/action-runners/bb_bazelrc_secret.yaml | kubectl apply -f -
```

--------------------------------

### Pseudo-code: Kernel Stack Walking Algorithm

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/perf_profiler/notes.md

Provides the complete pseudo-code loop for walking the stack using frame pointers. It starts from the current frame, adds the current RIP, then iteratively follows saved frame pointers and adds return addresses until an invalid stack address is encountered.

```Pseudo-code
fp = *rbp;
stack_trace.push_back(rip);
while(true) {
  fn_return_address = *(fp + 8);
  stack_trace.push_back(fn_return_address);
  fp = *fp;
  if(!valid_stack_address(fp)) {
    break;
  }
}
```

--------------------------------

### Configure Arcanist Load Path (Relative Global)

Source: https://github.com/pixie-io/pixie/blob/main/tools/arc_addons/clang_format/README.md

Provides the .arcconfig configuration needed when the linter is installed globally by cloning it into the same parent directory as arcanist and libphutil, allowing a relative path in the load configuration.

```json
{
  "load": [
    "clang-format-linter"
  ]
  // ...
}
```

--------------------------------

### Enable Connection Trace Logging (stirling_wrapper Flags)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/README.md

Configure the stirling_wrapper to enable debug trace logging for connection processing by specifying the target process ID and optionally the file descriptor. These flags automatically set the debug trace logging level to 2 for detailed processing steps.

```shell
--stirling_conn_trace_pid=<target_pid>
--stirling_conn_trace_fd=<target_fd>
```

--------------------------------

### Example Signed Git Log Output

Source: https://github.com/pixie-io/pixie/blob/main/CONTRIBUTING.md

This snippet shows the expected output format when viewing the log of a signed commit using `git log`. It highlights the presence and format of the `Signed-off-by` line, which should match the `Author` line for automated DCO checks to pass.

```Text
Author: Joe Smith <joe.smith@example.com>
Date:   Thu Feb 2 11:41:15 2018 -0800

    Update README

    Signed-off-by: Joe Smith <joe.smith@example.com>
```

--------------------------------

### Run Product Catalog Service Client (Bazel)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/testing/demo_apps/hipster_shop/productcatalogservice_client/README.md

Command to build and run the product catalog service client using Bazel.

```shell
# Run the client
bazel run //src/stirling/testing/demo_apps/hipster_shop/productcatalogservice_client:productcatalogservice_client_image
```

--------------------------------

### Teardown K3s Cluster (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/equinix_k3s/README.md

Runs the teardown.sh script to remove the K3s cluster. Requires environment variables for the EIP and server/agent IPs to identify the cluster resources.

```bash
EIP=<eip> \
SERVER_IPS=<comma separated list of IPS> \
AGENT_IPS=<optional comma separated list of IPS> \
./teardown.sh
```

--------------------------------

### Trace Syscalls with strace (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/README.md

Use the strace command to verify that expected syscalls are being invoked and that the raw data arguments match the protocol. The -f flag is critical for tracing all threads of a process, -v provides verbose output, -s limits string length, -e filters by syscall, and -p specifies the process ID.

```shell
sudo strace -f -v -s 100 -e write -p PID 2>&1 | grep PATTERN
```

--------------------------------

### Run HTTP Demo using Skaffold

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/testing/demo_apps/go_http/README.md

These commands create a Kubernetes namespace for the demo and then use Skaffold to build and deploy the Go HTTP demo application.

```Shell
kubectl create ns px-http-test
skaffold run -f src/stirling/testing/demo_apps/go_http/skaffold.yaml
```

--------------------------------

### Defining Intermediate FetchResp Struct in C++

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/protocol_contribution_guide.md

Defines an example intermediate structure (FetchResp) used for full-body tracing and JSON serialization. It includes fields specific to a Kafka Fetch Response and a ToJSON method using a JSONObjectBuilder.

```C++
struct FetchResp {
  int32_t throttle_time_ms;
  int16_t error_code = 0;
  int32_t session_id = 0;
  std::vector<FetchRespTopic> topics;

  void ToJSON(utils::JSONObjectBuilder* builder) const {
		...
  }
};
```

--------------------------------

### Deploy Public Dependencies for Pixie Cloud

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Uses Kustomize to build the configuration for public dependencies required by Pixie Cloud and applies them to the Kubernetes cluster using kubectl.

```Bash
kustomize build k8s/cloud_deps/public | kubectl apply -f -
```

--------------------------------

### Deploying Development Vizier with Skaffold (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Runs Skaffold to build and deploy a local development version of Pixie Vizier using the specified configuration file. The --default-repo flag is required to specify your image registry. This command needs to be re-run after each code change.

```bash
skaffold run -f skaffold/skaffold_vizier.yaml --default-repo=<your own image registry>
```

--------------------------------

### Deploy Pixie Cloud Services with Skaffold

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Runs Skaffold using the specified configuration file to build and deploy the Pixie Cloud services and deployments to the Kubernetes cluster.

```Bash
skaffold run -f skaffold/skaffold_cloud.yaml (-p public)
```

--------------------------------

### Deploying Prow with Tackle (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/devinfra/prow/README.md

This command uses the 'tackle' tool to deploy Prow. It specifies the target repository, the path to the GitHub token (decrypted using sops), and the starter configuration file.

```shell
tackle --repo pixie-io/pixie -github-token-path $(sops -d <api_key_file>) -starter prow-setup-starter.yaml
```

--------------------------------

### Running the Golang GRPC Demo with Skaffold

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/testing/demo_apps/go_grpc_tls_pl/README.md

These commands demonstrate how to deploy and run the Golang GRPC demo application using Skaffold. It first creates a Kubernetes namespace for the test and then uses Skaffold to build and deploy the application defined in the specified skaffold.yaml file.

```shell
kubectl create ns px-grpc-test
skaffold run -f src/stirling/testing/demo_apps/go_grpc_tls_pl/skaffold.yaml
```

--------------------------------

### Documenting Literal Function Arguments (C++)

Source: https://github.com/pixie-io/pixie/blob/main/styleguide/cc_style.md

Shows the style rule for documenting literal values passed as function arguments. A comment (/* opt_level */) is placed before the literal value (0) to clarify its purpose, improving code readability according to the Pixie C++ style guide.

```C++
Compile(code, /* opt_level */ 0);
```

--------------------------------

### Run Pixie Vizier Unit Test with Bazel

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Executes a specific unit test for the Pixie Vizier module using Bazel, outputting errors and utilizing multiple processes for speed.

```Bash
bazel test //src/<path to unit test file> --test_output=errors -j $(nproc)
```

--------------------------------

### Build and Push Online Boutique Adservice Image - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Changes the directory to src/adservice, builds the Docker image for the adservice with a specific tag, and then pushes the built image to the specified Google Container Registry path.

```Shell
cd src/adservice
docker build -t gcr.io/pixie-prod/demos/microservices-demo-app/adservice:1.0 .
docker push gcr.io/pixie-prod/demos/microservices-demo-app/adservice:1.0
```

--------------------------------

### Spacing Before Entities in Namespaces (C++)

Source: https://github.com/pixie-io/pixie/blob/main/styleguide/cc_style.md

Presents two options (Option 1 and Option 2) for managing vertical spacing before the first entity (struct/class) within a namespace and between subsequent entities. This section discusses the preferred style for structuring code within namespaces in the Pixie C++ style guide.

```C++
//OPTION 1
namespace pl {
namespace einstein {
struct Energy {
  int a;
  int b;
}

struct Mass {
  double m;
  double exp;
}
}
}

//OPTION 2
namespace pl {
namespace einstein {

struct Energy {
  int a;
  int b;
}

struct Mass {
  double m;
  double exp;
}

}
}
```

--------------------------------

### Run Thriftmux Server (Default)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/testing/containers/thriftmux/README.md

Runs the Thriftmux server using Bazel. This is the default entrypoint for the container.

```Shell
$ bazel run src/stirling/source_connectors/socket_tracer/testing/containers/thriftmux:server_image
```

--------------------------------

### Run Product Catalog Service Server (Docker)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/testing/demo_apps/hipster_shop/productcatalogservice_client/README.md

Command to run the product catalog service server using Docker, disabling profiler and tracing, and mapping port 3550.

```shell
# Run the server
docker run -e DISABLE_PROFILER=1 -e DISABLE_TRACING=1 -p 3550:3550 gcr.io/google-samples/microservices-demo/productcatalogservice:v0.2.0
```

--------------------------------

### Deploying Slackin App with Kustomize and SOPS (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/slackin/README.md

This snippet provides the bash commands required to deploy the Slackin application to a Kubernetes cluster. It involves creating a namespace, applying secrets and configuration using SOPS for decryption, and applying the final manifests built by Kustomize.

```bash
kubectl create namespace slackin
sops -d private/credentials/k8s/slackin/slackin_secrets.yaml | kubectl apply -f -
sops -d private/credentials/k8s/slackin/slackin_config.yaml | kubectl apply -f -
kustomize build k8s/slackin | kubectl apply -f -
```

--------------------------------

### Build Finagle Demo Manifest - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Uses Kustomize to build the Kubernetes manifests for the Finagle demo from the current directory and redirects the output to a file named finagle.yaml.

```Shell
kustomize . > finagle.yaml
```

--------------------------------

### Build Kafka Demo Manifest - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Uses Kustomize to build the Kubernetes manifests for the Kafka demo from the current directory and redirects the output to a file named kafka.yaml.

```Shell
kustomize build . >  kafka.yaml
```

--------------------------------

### Build Petclinic Demo Manifest - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Uses Kustomize to build the Kubernetes manifests for the Spring Petclinic Reactive demo from the current directory and redirects the output to a file named petclinic.yaml.

```Shell
kustomize build . > petclinic.yaml
```

--------------------------------

### List Demos with Development Artifacts - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Uses the px demo list command to list available demos, specifying the development artifact URL to ensure the CLI uses the newly uploaded artifacts for testing.

```Shell
px demo list --artifacts "${DEV_DEMO_ARTIFACTS_URL}"
```

--------------------------------

### Deploy Elastic Operator Dependency for Pixie Cloud

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Uses Kustomize to build the configuration for the Elastic operator dependency and applies it to the Kubernetes cluster using kubectl.

```Bash
kustomize build k8s/cloud_deps/base/elastic/operator | kubectl apply -f -
```

--------------------------------

### Load ShellCheck Linter in .arcconfig (Global)

Source: https://github.com/pixie-io/pixie/blob/main/tools/arc_addons/shellcheck/README.md

Configures Arcanist's `.arcconfig` file to load the shellcheck linter library by its registered name, assuming it's installed in a standard location accessible to Arcanist.

```json
  "load": [
    "shellcheck-linter"
  ]
```

--------------------------------

### Build MongoDB Demo Manifest - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Uses Kustomize to build the Kubernetes manifests for the MongoDB demo from the current directory and redirects the output to a file named mongodb.yaml.

```Shell
kustomize build . > mongodb.yaml
```

--------------------------------

### Update DNS for Dev Pixie Cloud Instance

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Runs the Bazel target for the development DNS updater utility to configure `/etc/hosts` to point `dev.withpixie.dev` to the running local Pixie Cloud instance.

```Bash
bazel run //src/utils/dev_dns_updater:dev_dns_updater -- --domain-name "dev.withpixie.dev"
```

--------------------------------

### Create Kubernetes Namespace for Pixie Cloud

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Creates the 'plc' Kubernetes namespace, which is required for deploying Pixie Cloud components.

```Bash
kubectl create namespace plc
```

--------------------------------

### Provisioning Machine with Chef Solo (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/tools/chef/README.md

This command executes Chef Solo to provision a machine. It uses `solo.rb` as the Chef Solo configuration file and `node_workstation.json` as the run list and node attributes file.

```bash
sudo chef-solo -c solo.rb -j node_workstation.json
```

--------------------------------

### Load ShellCheck Linter in .arcconfig (Relative Path)

Source: https://github.com/pixie-io/pixie/blob/main/tools/arc_addons/shellcheck/README.md

Configures Arcanist's `.arcconfig` file to load the shellcheck linter library using a relative path from the `.arcconfig` file's location, useful when the library is not installed in a global or standard Arcanist library directory.

```json
  "load": [
    "./vendor/shellcheck-linter"
  ]
```

--------------------------------

### Deploy Demo with Development Artifacts - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Uses the px demo deploy command to deploy a specific demo, <DEMO_NAME>, using the artifacts from the development GCS bucket specified by DEV_DEMO_ARTIFACTS_URL.

```Shell
px demo deploy <DEMO_NAME> --artifacts "${DEV_DEMO_ARTIFACTS_URL}"
```

--------------------------------

### Building All Licenses with Bazel (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/tools/licenses/README.md

This command uses Bazel to build the complete license notice document. The output file contains all collected licenses and should be copied to the desired location. Note that this process might interact with the GitHub API and could benefit from setting the GH_API_KEY environment variable to avoid rate limiting.

```Shell
bazel build //tools/licenses:all_licenses
```

--------------------------------

### Verify Network Traffic with tshark (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/README.md

Employ tshark, potentially within a Docker container, to verify network traffic when strace does not show the expected data. This command filters traffic by source port and network IP, outputs in JSON format, and includes IP, TCP, and data fields.

```shell
sudo docker run -it --rm --net container:CONTAINER_ID --privileged nicolaka/netshoot tshark -f "src port 6379" -f "net IP" -Tjson -e ip -e tcp -e data
```

--------------------------------

### Load Pixie Cloud Config Maps and Secrets

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Runs the script to create and load necessary configuration maps and secrets into the Kubernetes cluster for the Pixie Cloud deployment.

```Bash
./scripts/create_cloud_secrets.sh
```

--------------------------------

### Adding Production Domain to Hosts File (Hosts)

Source: https://github.com/pixie-io/pixie/blob/main/src/ui/README.md

Adds an entry to the local hosts file (`/etc/hosts` or `/private/etc/hosts`) to map `prod.withpixie.ai`, a site-specific subdomain, and `id.prod.withpixie.ai` to the local loopback address (`127.0.0.1`), allowing the browser to resolve these domains locally.

```Hosts
127.0.0.1 prod.withpixie.ai <site-name>.prod.withpixie.ai id.prod.withpixie.ai
```

--------------------------------

### Defining Function with Default Primitive Argument (C++)

Source: https://github.com/pixie-io/pixie/blob/main/styleguide/cc_style.md

Illustrates the acceptable use of a default argument (= 0) for a primitive type parameter (int level) in a function declaration (Init). This adheres to the Pixie C++ style rule allowing default arguments on primitive types when readability is maintained.

```C++
void Init(int level = 0);
```

--------------------------------

### Upload Development Demo Artifacts - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Runs the Bazel target //demos:upload_dev_demo to upload the demo application artifacts to the development GCS bucket specified by DEV_DEMO_ARTIFACTS_URL.

```Shell
bazel run //demos:upload_dev_demo
```

--------------------------------

### Inferring HTTP Protocol in C++

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/protocol_contribution_guide_part2.md

This C++ function implements the rule-based logic for inferring if a given byte buffer contains an HTTP request or response. It checks the initial bytes against common HTTP patterns (e.g., 'HTTP', 'GET', 'POST') to classify the message type. It takes a buffer and its size as input and returns a message type enum.

```cpp
static __inline enum message_type_t infer_http_message(const char* buf, size_t count) {
// Smallest HTTP response is 17 characters:
// HTTP/1.1 200 OK\r\n
// Smallest HTTP response is 16 characters:
// GET x HTTP/1.1\r\n
if (count < 16) {
return kUnknown;
}

if (buf[0] == 'H' && buf[1] == 'T' && buf[2] == 'T' && buf[3] == 'P') {
return kResponse;
}
if (buf[0] == 'G' && buf[1] == 'E' && buf[2] == 'T') {
return kRequest;
}
if (buf[0] == 'H' && buf[1] == 'E' && buf[2] == 'A' && buf[3] == 'D') {
return kRequest;
}
if (buf[0] == 'P' && buf[1] == 'O' && buf[2] == 'S' && buf[3] == 'T') {
return kRequest;
}
if (buf[0] == 'P' && buf[1] == 'U' && buf[2] == 'T') {
return kRequest;
}
if (buf[0] == 'D' && buf[1] == 'E' && buf[2] == 'L' && buf[3] == 'E' && buf[4] == 'T' &&
buf[5] == 'E') {
return kRequest;
}
return kUnknown;
}
```

--------------------------------

### Upload Production Demo Artifacts - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Runs the Bazel target //demos:upload_prod_demo to upload the demo application artifacts to the production GCS bucket after a PR is merged.

```Shell
bazel run //demos:upload_prod_demo
```

--------------------------------

### Comparing CHECK(false) and LOG(FATAL) in C++ Switch

Source: https://github.com/pixie-io/pixie/blob/main/styleguide/cc_style.md

This C++ snippet illustrates two alternative approaches for handling an unexpected default case within a switch statement: using `CHECK(false)` or `LOG(FATAL)`. Both options are used to indicate a critical, unrecoverable error state, typically leading to program termination, but they represent different conventions or macro implementations.

```cpp
switch (direction) {
  case kRequest:
    // Do something.
    break;
  case kResponse:
    // Do something.
    break;
  default:
    // Option 1:
    CHECK(false) << "Unexpected direction";

    // Option 2:
    LOG(FATAL) << "Unexpected direction"
}
```

--------------------------------

### Set Skaffold Default Image Repository

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Configures Skaffold to use a specified image registry as the default location for pushing built images during development.

```Bash
skaffold config set default-repo <your registry>
```

--------------------------------

### Build and Push Multi-Arch Docker Image (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/src/experimental/multi_arch/README.md

Builds a multi-platform Docker image using Buildx, tags it, and pushes the resulting manifest list and images to a container registry.

```bash
docker buildx build --platform linux/amd64,linux/arm64 -t gcr.io/pl-dev-infra/multi-arch-hello:latest --push .
```

--------------------------------

### Verify gRPC Server Reflection using grpc_cli

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/protocols/http2/testing/cc_grpc_service/README.md

This script clones the gRPC repository, builds the `grpc_cli` command-line tool, and then uses it to list the services exposed by a gRPC server running locally on port 50051. This verifies that server reflection is enabled and working correctly.

```shell
git clone https://github.com/grpc/grpc.git
cd grpc
make grpc_cli
bins/opt/grpc_cli ls -l localhost:50051
```

--------------------------------

### Modify Kustomization Image Name for Skaffold (prod to dev)

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Uses Perl to modify the `kustomization.yaml` file, replacing the `pixie-prod` image name with `pixie-dev` for development deployment.

```Bash
perl -pi -e "s|pixie-prod|pixie-dev|g" k8s/cloud/public/kustomization.yaml
```

--------------------------------

### Directory Structure for Kustomize/Skaffold

Source: https://github.com/pixie-io/pixie/blob/main/k8s/README.md

This snippet illustrates the hierarchical directory structure used to organize Kustomize and Skaffold configuration files for different deployment targets and environments within the project.

```text
  directory_per_deploy/   (vizier, pixie_cloud, stirling_wrapper)
    directory_per_env/    (base, dev, prod)
```

--------------------------------

### Deploy Multi-Arch Image to Kubernetes (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/src/experimental/multi_arch/README.md

Retrieves credentials for a GKE cluster, creates a Kubernetes namespace, and applies a YAML configuration file to deploy an application using the multi-arch image.

```bash
gcloud container clusters get-credentials multi-arch --zone us-central1-a --project pl-pixies
kubectl create ns hello
kubectl apply -f hello.yaml
```

--------------------------------

### Building MySQL BPF Test and Running Tshark Capture (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/protocols/test_output_generator/README.md

Builds the MySQL container BPF test using Bazel and then executes the `mysql_tshark.sh` script to capture traffic, which is saved to a JSON file.

```Shell
bazel build //src/stirling:mysql_container_bpf_test
mysql_tshark.sh
```

--------------------------------

### Build K8ssandra Control Plane Manifest - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Changes the directory to config/deployments/control-plane/cluster-scope within the k8ssandra-operator root, builds the control plane manifests using Kustomize, and saves the output to k8ssandra-control-plane.yaml. Requires Kustomize v4.5.7 or newer.

```Shell
cd config/deployments/control-plane/cluster-scope
kustomize build . > k8ssandra-control-plane.yaml
```

--------------------------------

### Exporting gperftools Profile to PDF

Source: https://github.com/pixie-io/pixie/blob/main/src/common/perf/README.md

Use the pprof tool to convert the profiling data file into a human-readable PDF call graph. This requires the executable to be compiled with symbols.

```shell
pprof -pdf <executable path> <pprof>
```

--------------------------------

### Generating AMQP Protocol Code with Bazel

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/protocols/amqp/amqp_code_generator/README.md

These Bazel commands are used to download the AMQP specification XML, run the code generator, and copy the generated header and C++ files to their respective locations within the project.

```Shell
  wget "https://www.rabbitmq.com/resources/specs/amqp0-9-1.xml"
  bazel run //src/stirling/source_connectors/socket_tracer/protocols/amqp/amqp_code_generator:amqp_code_gen_main -- run
  cp generated_files/{decode.h,decode.cc,types_gen.h} ../
  cp generated_files/amqp.h src/carnot/funcs/protocols/amqp.h
  arc lint
```

--------------------------------

### Build K8ssandra CRD Manifest - Shell

Source: https://github.com/pixie-io/pixie/blob/main/demos/README.md

Changes the directory to config/crd within the k8ssandra-operator root, builds the CRD manifests using Kustomize, and saves the output to crd.yaml. Requires Kustomize v4.5.7 or newer.

```Shell
cd config/crd
kustomize build . > crd.yaml
```

--------------------------------

### Running Python gRPC Client and Server with Docker

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/testing/demo_apps/py_grpc/README.md

These commands demonstrate how to run the gRPC server and client applications within Docker containers using the pre-built image. The client container is configured to use the server's network namespace to allow communication.

```Shell
docker run --name=server --rm gcr.io/pixie-oss/pixie-dev-public/python_grpc_1_19_0_helloworld:1.0 python helloworld/greeter_server.py
docker run --network=container:server --rm gcr.io/pixie-oss/pixie-dev-public/python_grpc_1_19_0_helloworld:1.0 python helloworld/greeter_client.py
```

--------------------------------

### Modify Kustomization Tag for Skaffold (latest)

Source: https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md

Uses Perl to modify the `kustomization.yaml` file, replacing the `newTag: latest` entry with an empty string to allow Skaffold to manage image tags.

```Bash
perl -pi -e "s|newTag: latest|newTag: \"\"|g" k8s/cloud/public/kustomization.yaml
```

--------------------------------

### Sample AMQP Specification XML Structure

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/protocols/amqp/amqp_code_generator/README.md

This XML snippet illustrates the structure of the AMQP specification file, showing how classes, methods, and fields are defined, which is used as input for the code generation process.

```XML
<amqp major="0" minor="9" revision="1" port="5672">
<class name="connection" handler="connection" index="10">
    <method name="start" synchronous="1" index="10">
      <chassis name="client" implement="MUST"/>
      <response name="start-ok"/>
      <field name="version-major" domain="octet"/>
```

--------------------------------

### Deploying Slackin Ingress with TLS (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/k8s/slackin/README.md

This command applies the final Kubernetes ingress manifest for Slackin, which includes the necessary annotations and configuration for TLS. After applying this, Cert-Manager is expected to automatically provision and manage the TLS certificates for the specified domain.

```shell
kubectl apply -f k8s/slackin/ingress.yaml
```

--------------------------------

### Build Multi-Arch Docker Image (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/src/experimental/multi_arch/README.md

Uses Docker Buildx to build a Docker image for multiple specified platforms (linux/amd64, linux/arm64) from the current directory's Dockerfile.

```bash
docker buildx build --platform linux/amd64,linux/arm64 .
```

--------------------------------

### Configure Go Build Linker Flags (Shell)

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/protocols/http2/README.md

When using `go build` with `-ldflags`, ensure that the `-s` (strip symbols) and `-w` (strip dwarf) flags are *not* included, as they remove debugging information essential for Pixie tracing.

```Shell
go build -ldflags
```

--------------------------------

### Inspect Multi-Arch Docker Image Manifest (Bash)

Source: https://github.com/pixie-io/pixie/blob/main/src/experimental/multi_arch/README.md

Uses Docker Buildx imagetools to inspect the manifest list of a multi-platform image in a registry, showing the different architecture variants available.

```bash
docker buildx imagetools inspect gcr.io/pl-dev-infra/multi-arch-hello:latest
```

--------------------------------

### Run Thriftmux Server with TLS

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/source_connectors/socket_tracer/testing/containers/thriftmux/README.md

Runs the Thriftmux server using Bazel with TLS enabled. The `--use-tls true` flag activates TLS.

```Shell
$ bazel run src/stirling/source_connectors/socket_tracer/testing/containers/thriftmux:server_image -- --use-tls true
```

--------------------------------

### Run Stirling Wrapper Standalone

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/README.md

Executes the standalone Stirling wrapper script. This script builds the wrapper and runs the executable, typically prompting for sudo permissions to collect data.

```Shell
$PIXIE_ROOT/src/stirling/scripts/stirling_wrapper.sh
```

--------------------------------

### Run BPF Test Suite in Docker Container

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/README.md

Provides commands to run the full BPF test suite locally within a Docker container. The first command launches the container, and the second runs the tests inside it with the appropriate configuration.

```Shell
$PIXIE_ROOT/scripts/run_docker.sh

bazel test --config=bpf //path/to:test
```

--------------------------------

### Build Stirling with Bazel

Source: https://github.com/pixie-io/pixie/blob/main/src/stirling/README.md

This command builds the entire Stirling codebase using the Bazel build tool. It compiles all necessary components within the specified directory.

```Bazel
bazel build //src/stirling/...
```