### Run Bazel Tests

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Commands to build and test the rules_gitops project and the examples project using Bazel. Execute from the project root directory to run all tests, or from the examples directory to run example tests.

```bash
bazel test //...
```

```bash
cd examples
bazel test //...
```

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

### Kubernetes Integration Testing Setup with k8s_test_setup

Source: https://context7.com/adobe/rules_gitops/llms.txt

The k8s_test_setup rule facilitates integration testing by creating temporary Kubernetes namespaces, deploying services, and forwarding ports. It outputs a shell script to manage the setup and monitor pod readiness. This is configured within a BUILD file and typically used with a Java test.

```starlark
# BUILD file for integration test
load("@com_adobe_rules_gitops//gitops:defs.bzl", "k8s_test_setup")

k8s_test_setup(
    name = "service_it.setup",
    kubeconfig = "@k8s_test//:kubeconfig",
    objects = [
        "//service:mynamespace",
    ],
    setup_timeout = "10m",
    portforward_services = ["my-service"],
)

java_test(
    name = "service_it",
    srcs = ["ServiceIT.java"],
    data = [
        ":service_it.setup",
    ],
    jvm_flags = [
        "-Dk8s.setup=$(location :service_it.setup)",
    ],
    deps = [
        "@maven//:junit_junit",
        # ... other deps
    ],
)

# WORKSPACE configuration for kubeconfig
# load("@com_adobe_rules_gitops//gitops:defs.bzl", "kubeconfig")
#
# kubeconfig(
#     name = "k8s_test",
#     cluster = "dev",
# )

# The test launches the setup script which:
# 1. Creates temporary namespace: username-12345
# 2. Generates kubeconfig with default context set to new namespace
# 3. Deploys all objects
# 4. Forwards service ports
# 5. Waits for pods to be ready

```

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

### Define Kubernetes Integration Test Setup with Bazel

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Defines a Bazel BUILD file configuration for integration testing with Kubernetes. Uses k8s_test_setup rule to manage Kubernetes setup and java_test rule to execute tests. The k8s_test_setup creates a temporary namespace and kubeconfig, while java_test references the setup script via the location function and passes it as a JVM flag.

```starlark
k8s_test_setup(
    name = "service_it.setup",
    kubeconfig = "@k8s_test//:kubeconfig",
    objects = [
        "//service:mynamespace",
    ],
)

java_test(
    name = "service_it",
    srcs = [
        "ServiceIT.java",
    ],
    data = [
        ":service_it.setup",
    ],
    jvm_flags = [
        "-Dk8s.setup=$(location :service_it.setup)",
    ],
)
```

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

### Generate Multiple k8s_deploy Targets with ConfigMaps in Starlark

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Creates multiple Kubernetes deployment targets using Bazel's Starlark language, each with ConfigMap source files globbed from cluster-specific directories. The k8s_deploy rule accepts configmaps_srcs to specify file patterns and configmaps_renaming to define the naming policy (hash or None). This example generates two targets: one for development and one for production, demonstrating how to template deployment configurations across environments.

```starlark
[
    k8s_deploy(
        name = NAME,
        cluster = CLUSTER,
        configmaps_srcs = glob([
            "configmaps/%s/**/*" % CLUSTER
        ]),
        configmaps_renaming = 'hash',
        ...
    )
    for NAME, CLUSTER, NAMESPACE in [
        ("mynamespace", "dev", "{BUILD_USER}"),
        ("prod-grafana", "prod", "prod"),
    ]
]
```

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

### Run create_gitops_prs Tool

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Shows how to execute the create_gitops_prs command-line tool provided by rules_gitops. This tool automates the creation of pull requests as part of a GitOps CI pipeline. Run this command to see all available command-line options.

```bash
bazel run @com_adobe_rules_gitops//gitops/prer:create_gitops_prs
```

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

### Rendered Kubernetes Manifest with Image Substitution (YAML)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

This YAML shows the result of Bazel processing the `k8s_deploy` target. The placeholder `//examples:helloworld_image` in the manifest has been replaced with the fully qualified image URL and its SHA256 digest from the private registry.

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: helloworld
spec:
  containers:
    - image: registry.example.com/examples/helloworld_image@sha256:c94d75d68f4c1b436f545729bbce82774fda07
```

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

### K8s Deploy Rule Configuration (Starlark)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Demonstrates the configuration of the k8s_deploy rule, focusing on the 'manifests' and 'patches' attributes. It shows how glob patterns are used to include base manifests and environment-specific overlays based on CLOUD, NAMESPACE, and CLUSTER variables.

```starlark
k8s_deploy(
    ...
    manifests = glob([
      "manifests/*.yaml",
      "manifests/%s/*.yaml" % (CLOUD),
    ]),
    patches = glob([
      "overlays/*.yaml",
      "overlays/%s/*.yaml" % (CLOUD),
      "overlays/%s/%s/*.yaml" % (CLOUD, NAMESPACE),
      "overlays/%s/%s/%s/*.yaml" % (CLOUD, NAMESPACE, CLUSTER),
    ]),
    ...
)
```

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

### Apply Kustomize Overlays with Strategic Merge Patches in Bazel

Source: https://context7.com/adobe/rules_gitops/llms.txt

Uses Bazel's k8s_deploy with multi-level Kustomize overlay structure for cloud-specific, environment-specific, and region-specific configurations. Combines base manifests with strategic merge patches across multiple overlay directories, enabling fine-grained control over deployments across AWS, production, and regional variations without duplicating base configurations.

```starlark
k8s_deploy(
    cluster = "aws-prod-us-east-1",
    namespace = "prod",
    manifests = glob([
        "manifests/*.yaml",
        "manifests/%s/*.yaml" % ("aws"),
    ]),
    patches = glob([
        "overlays/*.yaml",
        "overlays/%s/*.yaml" % ("aws"),
        "overlays/%s/%s/*.yaml" % ("aws", "prod"),
        "overlays/%s/%s/%s/*.yaml" % ("aws", "prod", "us-east-1"),
    ]),
)
```

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

### Automate GitOps PR Creation in CI Pipeline with Bash

Source: https://context7.com/adobe/rules_gitops/llms.txt

Bash script that integrates into CI/CD pipelines to automate GitOps pull request creation. Queries Bazel targets, renders Kubernetes manifests, and creates pull requests to deployment branches using the create_gitops_prs tool. Supports GitHub, GitLab, and Bitbucket APIs with trunk-based workflows triggered on master branch commits.

```bash
#!/bin/bash
# CI pipeline script for trunk-based GitOps workflow

GIT_ROOT_DIR=$(git rev-parse --show-toplevel)
GIT_COMMIT_ID=$(git rev-parse HEAD)
GIT_BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)

if [ "${GIT_BRANCH_NAME}" == "master" ]; then
    bazel run @com_adobe_rules_gitops//gitops/prer:create_gitops_prs -- \
        --workspace $GIT_ROOT_DIR \
        --git_repo https://github.com/example/repo.git \
        --git_mirror $GIT_ROOT_DIR/.git \
        --git_server github \
        --release_branch master \
        --gitops_pr_into master \
        --gitops_pr_title "Deploy services to production" \
        --gitops_pr_body "Automated deployment from master branch" \
        --branch_name ${GIT_BRANCH_NAME} \
        --git_commit ${GIT_COMMIT_ID} \
        --stamp
fi
```

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

### Create GitOps PRs for Release Branches (Bash)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

This bash script demonstrates how to execute the create_gitops_prs tool for a release branch workflow. It extracts branch information and passes it as arguments to the bazel run command, specifying the target master branch for the GitOps pull requests.

```bash
GIT_ROOT_DIR=$(git rev-parse --show-toplevel)
GIT_COMMIT_ID=$(git rev-parse HEAD)
GIT_BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)          # => release/team-20200101
RELEASE_BRANCH_SUFFIX=${GIT_BRANCH_NAME#"release/team"}     # => -20200101
RELEASE_BRANCH=${GIT_BRANCH_NAME%${RELEASE_BRANCH_SUFFIX}}  # => release/team
if [ "${RELEASE_BRANCH}" == "release/team"]; then
    bazel run @com_adobe_rules_gitops//gitops/prer:create_gitops_prs -- \
        --workspace $GIT_ROOT_DIR \
        --git_repo https://github.com/example/repo.git \
        --git_mirror $GIT_ROOT_DIR/.git \
        --git_server github \
        --release_branch ${RELEASE_BRANCH} \
        --deployment_branch_suffix=${RELEASE_BRANCH_SUFFIX} \
        --gitops_pr_into master \
        --gitops_pr_title "This is my pull request title" \
        --gitops_pr_body "This is my pull request body message" \
        --branch_name ${GIT_BRANCH_NAME} \
        --git_commit ${GIT_COMMIT_ID} \
fi

```

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

### Docker Image Injection into Kubernetes Manifests

Source: https://context7.com/adobe/rules_gitops/llms.txt

Demonstrates automatic injection of Bazel-built Docker images into Kubernetes manifests using target references. Image URLs are replaced with registry paths and content digests during manifest rendering, enabling reproducible deployments with exact image references.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloworld
  template:
    metadata:
      labels:
        app: helloworld
        app_label_image_short_digest: "{{//helloworld:image.short-digest}}"
    spec:
      containers:
        - name: helloworld
          image: //helloworld:image
          args:
            - --port=8080
          ports:
            - containerPort: 8080
              name: web
          resources:
            requests:
              memory: 2Mi
```

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

### Dependency Chaining for Orchestrated Deployments

Source: https://context7.com/adobe/rules_gitops/llms.txt

Demonstrates how to chain multiple Kubernetes deployments using the `objects` attribute in `k8s_deploy` targets. Running `.apply` on a target automatically deploys all its declared dependencies in the correct order. This is useful for multi-service applications where order matters.

```starlark
# Database deployment
k8s_deploy(
    name = "database",
    cluster = "dev",
    namespace = "{BUILD_USER}",
    manifests = ["postgres.yaml"],
)

# Cache deployment
k8s_deploy(
    name = "cache",
    cluster = "dev",
    namespace = "{BUILD_USER}",
    manifests = ["redis.yaml"],
)

# Application deployment with dependencies
k8s_deploy(
    name = "mynamespace",
    cluster = "dev",
    namespace = "{BUILD_USER}",
    objects = [
        ":database",
        ":cache",
    ],
    images = {
        "app-image": ":app_image",
    },
    manifests = ["deployment.yaml"],
)

# Running: bazel run //:mynamespace.apply
# Deploys in order:
# 1. database
# 2. cache
# 3. mynamespace

# Note: objects attribute is ignored by .gitops targets

```

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

### k8s_deploy Rule Configuration for Kubernetes Deployment

Source: https://context7.com/adobe/rules_gitops/llms.txt

Defines a Bazel rule for creating GitOps-enabled Kubernetes deployment targets. The rule combines Docker images, manifests, patches, and configmaps into a single rendered YAML file with support for namespace isolation and cluster configuration. Exposes targets for viewing rendered manifests (.show), applying to clusters (.apply), and generating GitOps files (.gitops).

```starlark
load("@com_adobe_rules_gitops//gitops:defs.bzl", "k8s_deploy")
load("@io_bazel_rules_docker//go:image.bzl", "go_image")

go_image(
    name = "helloworld_image",
    embed = [":go_default_library"],
    goarch = "amd64",
    goos = "linux",
)

k8s_deploy(
    name = "mynamespace",
    cluster = "kind-kind",
    namespace = "{BUILD_USER}",
    user = "kind-kind",
    image_registry = "localhost:15000",
    images = {
        "helloworld-image": ":helloworld_image",
    },
    manifests = [
        "deployment.yaml",
        "service.yaml",
    ],
)
```

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

### Kubernetes Custom Resource with Image Digest Substitution (YAML)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

This YAML defines a Custom Resource (CRD) that uses Bazel's string substitution to inject image digests. It shows how to use `{{//examples:helloworld_image.digest}}` and `{{//examples:helloworld_image.short-digest}}` for labels and the image URL directly in the `spec`.

```yaml
apiVersion: v1
kind: MyCrd
metadata:
  name: my_crd
  labels:
    app_label_image_digest: "{{//examples:helloworld_image.digest}}"
    app_label_image_short_digest: "{{//examples:helloworld_image.short-digest}}"
spec:
  image: "{{//examples:helloworld_image}}"
```

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

### Configure Kubernetes Tools for Testing with kubeconfig Rule

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Configures Kubernetes tools for testing by defining a kubeconfig repository rule in the WORKSPACE file. Specifies the Kubernetes cluster name and loads the kubeconfig rule from com_adobe_rules_gitops. This makes Kubernetes configuration available in the test sandbox.

```starlark
load("@com_adobe_rules_gitops//gitops:defs.bzl", "kubeconfig")

kubeconfig(
    name = "k8s_test",
    cluster = "dev",
)
```

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

### Kubernetes Manifest with Direct Image Name Reference (YAML)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

This YAML demonstrates an alternative way to reference an image in a Kubernetes manifest by using the image name directly. While supported, this method is not recommended as it might be removed in future versions. The `k8s_deploy` configuration is assumed to handle the substitution.

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: helloworld
spec:
  containers:
    - image: helloworld_image
```

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

### Kustomize Strategic Merge Patch for Production Deployment

Source: https://context7.com/adobe/rules_gitops/llms.txt

Demonstrates a strategic merge patch applied to deployment manifests for production environments. Specifies production-level resource requests for memory and CPU on container specifications, modifying the base deployment without replacing the entire manifest.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
  template:
    spec:
      containers:
      - name: helloworld
        resources:
          requests:
            memory: 4Gi
            cpu: 2000m
```

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

### Configure k8s_deploy with Multi-Environment Loop in Bazel

Source: https://context7.com/adobe/rules_gitops/llms.txt

Uses Bazel's k8s_deploy rule to generate multiple deployment configurations for different environments and clusters in a single loop. Automatically globs manifest files, secrets, and container images, applying environment-specific configurations like namespace and cluster assignment. Supports configmap hashing and dynamic secret injection from directory structures.

```starlark
load("@com_adobe_rules_gitops//gitops:defs.bzl", "k8s_deploy")

[
    k8s_deploy(
        name = ENV + "-server",
        cluster = CLUSTER,
        namespace = ENV,
        configmaps_renaming = "hash",
        secrets_srcs = glob([ENV + "/secrets/**/*"]),
        manifests = glob(["*.yaml"]),
        images = [
            "//helloworld:image",
        ],
    )
    for (ENV, CLUSTER) in [
        ("it", "it-cluster"),
        ("mynamespace", "dev-cluster"),
    ]
]
```

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

### Kubernetes Deployment Configuration - Starlark Rules

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Starlark configuration demonstrating k8s_deploy rule usage for defining multiple deployments grouped by namespace. Creates deployment targets for Grafana and Prometheus across stage and production environments, with each deployment specifying deploy_branch and other configuration attributes. Shows how deployments sharing the same namespace are grouped together.

```starlark
[
    k8s_deploy(
        name = NAME,
        deploy_branch = NAMESPACE,
        ...
    )
    for NAME, CLUSTER, NAMESPACE in [
        ...
        ("stage-grafana", "stage", "monitoring-stage"),
        ("prod-grafana", "prod", "monitoring-prod"),
    ]
]
[
    k8s_deploy(
        name = NAME,
        deploy_branch = NAMESPACE,
        ...
    )
    for NAME, CLUSTER, NAMESPACE in [
        ...
        ("stage-prometheus", "stage", "monitoring-stage"),
        ("prod-prometheus", "prod", "monitoring-prod"),
    ]
]
```

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

### Template Variable Substitution in Kubernetes Manifests

Source: https://context7.com/adobe/rules_gitops/llms.txt

The `substitutions` attribute in `k8s_deploy` allows for dynamic value injection into Kubernetes manifests. This feature, combined with `deps_aliases`, enables the injection of file contents into template variables for flexible configuration management.

```starlark
# BUILD file
k8s_deploy(
    name = "myapp",
    cluster = "prod",
    namespace = "production",
    manifests = ["deployment.yaml"],
    substitutions = {
        "CLUSTER": "prod",
        "NAMESPACE": "production",
        "REPLICAS": "3",
    },
    deps = [":config.json"],
    deps_aliases = {
        "config": ":config.json",
    },
)

# deployment.yaml with template variables
# apiVersion: apps/v1
# kind: Deployment
# metadata:
#   name: myapp
#   namespace: {{NAMESPACE}}
#   labels:
#     cluster: {{CLUSTER}}
# spec:
#   replicas: {{REPLICAS}}
#   template:
#     spec:
#       containers:
#       - name: myapp
#         env:
#         - name: CONFIG
#           value: |
#             {{imports.config}}

# Rendered output replaces {{CLUSTER}}, {{NAMESPACE}}, {{REPLICAS}}
# and {{imports.config}} with actual values

```

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

### Create GitOps PRs Bazel Command - Trunk Based Workflow

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Shell script that executes the create_gitops_prs Bazel target for trunk-based GitOps workflow. It extracts Git repository state information and conditionally runs on master branch changes, passing repository details and PR metadata to the GitOps tool. The script uses git commands to determine current branch, commit, and repository root.

```bash
GIT_ROOT_DIR=$(git rev-parse --show-toplevel)
GIT_COMMIT_ID=$(git rev-parse HEAD)
GIT_BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)
if [ "${GIT_BRANCH_NAME}" == "master"]; then
    bazel run @com_adobe_rules_gitops//gitops/prer:create_gitops_prs -- \
        --workspace $GIT_ROOT_DIR \
        --git_repo https://github.com/example/repo.git \
        --git_mirror $GIT_ROOT_DIR/.git \
        --git_server github \
        --release_branch master \
        --gitops_pr_into master \
        --gitops_pr_title "This is my pull request title" \
        --gitops_pr_body "This is my pull request body message" \
        --branch_name ${GIT_BRANCH_NAME} \
        --git_commit ${GIT_COMMIT_ID} 
fi
```

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

### ConfigMap Generation with Hash-Based Renaming

Source: https://context7.com/adobe/rules_gitops/llms.txt

Generates Kubernetes ConfigMaps from directory structures with automatic content hashing. ConfigMap names include content digests, and all references are automatically updated to enable rolling updates when configuration changes. Supports per-cluster configuration overlays.

```starlark
k8s_deploy(
    name = "prod-grafana",
    cluster = "prod",
    namespace = "prod",
    configmaps_srcs = glob([
        "configmaps/prod/**/*"
    ]),
    configmaps_renaming = 'hash',
    manifests = ["deployment.yaml"],
)
```

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

### Define Java Docker Image and Kubernetes Deployment (Starlark)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

This Starlark code defines a Docker image for a Java application using `java_image` and a Kubernetes deployment using `k8s_deploy`. The `images` attribute in `k8s_deploy` maps a named image to its Bazel target, enabling substitution in the Kubernetes manifest.

```starlark
java_image(
    name = "helloworld_image",
    srcs = glob(["*.java"]),
    ...
)
k8s_deploy(
    name = "helloworld",
    manifests = ["helloworld.yaml"],
    images = {
        "helloworld_image": ":helloworld_image",  # (1)
    }
)
```

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

### Reference Docker Image in Kubernetes Pod Manifest (YAML)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

This YAML defines a Kubernetes Pod manifest. The `image` field directly references the Bazel target `//examples:helloworld_image`, which will be substituted with the actual image location during the Bazel build process.

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: helloworld
spec:
  containers:
    - image: //examples:helloworld_image  # (2)
```

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

### Stamping GitOps Manifests with Build-Time Metadata

Source: https://context7.com/adobe/rules_gitops/llms.txt

The `--stamp` parameter allows for the injection of volatile metadata, such as Git revision and build dates, into manifests without triggering unnecessary deployments. Digests are computed from unstamped content, ensuring that deployments only occur when essential manifest content changes.

```yaml
# deployment.yaml with stamp placeholders
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  annotations:
    git-revision: "{{GIT_REVISION}}"
    deploy-date: "{{UTC_DATE}}"
    source-branch: "{{GIT_BRANCH}}"
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: //myapp:image

# After stamping with --stamp flag:
# metadata:
#   annotations:
#     git-revision: "a1b2c3d4e5f6"
#     deploy-date: "Mon Jan 15 14:30:22 UTC 2024"
#     source-branch: "master"

# Digest is saved in deployment.yaml.digest based on unstamped content

```

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

### Mirror External Docker Image for Kubernetes Deployment (Starlark)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

This Starlark code uses `rules_mirror` to mirror an external Docker image (`e2e-test-images/agnhost`) into a local registry. The `k8s_deploy` rule then uses `image_pushes` to reference this mirrored image, allowing it to be used in Kubernetes deployments.

```starlark
load("@com_fasterci_rules_mirror//mirror:defs.bzl", "mirror_image")
mirror_image(
    name = "agnhost_image",
    digest = "sha256:93c166faf53dba3c9c4227e2663ec1247e2a9a193d7b59eddd15244a3e331c3e",
    dst_prefix = "gcr.io/myregistry/mirror",
    src_image = "registry.k8s.io/e2e-test-images/agnhost:2.39",
)
k8s_deploy(
    name = "agnhost",
    manifests = ["agnhost.yaml"],
    image_pushes = [
        ":agnhost_image",
    ]
)
```

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

### Add k8s_deploy Dependencies in Starlark

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Demonstrates how to declare dependencies between k8s_deploy instances using the 'objects' attribute in Starlark. This ensures that dependent deployments are applied when the main deployment is applied. The 'objects' attribute is ignored by '.gitops' targets.

```starlark
k8s_deploy(
    name = "mynamespace",
    objects = [
        "//other:mynamespace",
    ],
    ...
)
```

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

### Generated ConfigMap with Content Hash

Source: https://context7.com/adobe/rules_gitops/llms.txt

Shows the output format of a ConfigMap generated from source files with hash-based renaming. The ConfigMap name includes a content digest suffix, enabling Kubernetes to automatically roll out updates when configuration content changes.

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-k75h878g4f
  namespace: ops-prod
data:
  ldap.toml: |
    [[servers]]
    host = "ldap.example.com"
```

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

### Group Multiple Services into Single GitOps Deployment PR

Source: https://context7.com/adobe/rules_gitops/llms.txt

Demonstrates using the deploy_branch attribute to group multiple k8s_deploy targets (Grafana and Prometheus) into single pull requests per namespace. Services sharing the same deploy_branch are combined into one PR, enabling related services to be deployed together while maintaining separate configurations per environment.

```starlark
# Grafana deployment
[
    k8s_deploy(
        name = NAME,
        cluster = CLUSTER,
        namespace = NAMESPACE,
        deploy_branch = NAMESPACE,  # Group by namespace
        release_branch_prefix = "master",
        manifests = ["grafana.yaml"],
    )
    for NAME, CLUSTER, NAMESPACE in [
        ("stage-grafana", "stage", "monitoring-stage"),
        ("prod-grafana", "prod", "monitoring-prod"),
    ]
]

# Prometheus deployment
[
    k8s_deploy(
        name = NAME,
        cluster = CLUSTER,
        namespace = NAMESPACE,
        deploy_branch = NAMESPACE,  # Same grouping
        release_branch_prefix = "master",
        manifests = ["prometheus.yaml"],
    )
    for NAME, CLUSTER, NAMESPACE in [
        ("stage-prometheus", "stage", "monitoring-stage"),
        ("prod-prometheus", "prod", "monitoring-prod"),
    ]
]
```

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

### Configure k8s_deploy for Release Branches (Starlark)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

This Starlark code configures k8s_deploy rules to selectively apply based on the release branch prefix. The 'release_branch_prefix' ensures that these deployments are only considered when the '--release_branch' parameter matches the specified prefix, facilitating environment-specific deployments from release branches.

```starlark
[k8s_deploy(
    name = NAME,
    deploy_branch = NAMESPACE,
    release_branch_prefix = "release/team",  # will be selected only when --release_branch=release/team
    ...
) for NAME, CLUSTER, NAMESPACE in [
    ...("stage-grafana", "stage", "monitoring-stage"),
    ("prod-grafana", "prod", "monitoring-prod"),
]]
[k8s_deploy(
    name = NAME,
    deploy_branch = NAMESPACE,
    release_branch_prefix = "release/team",  # will be selected only when --release_branch=release/team
    ...
) for NAME, CLUSTER, NAMESPACE in [
    ...("stage-prometheus", "stage", "monitoring-stage"),
    ("prod-prometheus", "prod", "monitoring-prod"),
]]

```

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

### Multi-Branch Release Workflow with Deployment Branch Suffixes

Source: https://context7.com/adobe/rules_gitops/llms.txt

This feature supports non-trunk-based workflows by allowing multiple release branches to coexist. The `create_gitops_prs` rule, when used with the `--deployment_branch_suffix` parameter, isolates deployments per release branch, enabling concurrent development and release cycles.

```bash
#!/bin/bash
# CI script for release branch workflow

GIT_ROOT_DIR=$(git rev-parse --show-toplevel)
GIT_COMMIT_ID=$(git rev-parse HEAD)
GIT_BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)  # release/team-20200101
RELEASE_BRANCH_SUFFIX=${GIT_BRANCH_NAME#"release/team"}  # -20200101
RELEASE_BRANCH=${GIT_BRANCH_NAME%${RELEASE_BRANCH_SUFFIX}}  # release/team

if [ "${RELEASE_BRANCH}" == "release/team" ]; then
    bazel run @com_adobe_rules_gitops//gitops/prer:create_gitops_prs -- \
        --workspace $GIT_ROOT_DIR \
        --git_repo https://github.com/example/repo.git \
        --release_branch ${RELEASE_BRANCH} \
        --deployment_branch_suffix=${RELEASE_BRANCH_SUFFIX} \
        --gitops_pr_into master \
        --branch_name ${GIT_BRANCH_NAME} \
        --git_commit ${GIT_COMMIT_ID}
fi

# With k8s_deploy configured:
# k8s_deploy(
#     name = "stage-grafana",
#     deploy_branch = "monitoring-stage",
#     release_branch_prefix = "release/team",
#     ...
# )

# Creates PR from: deploy/monitoring-stage-20200101 → master
# Multiple release branches can coexist:
# - release/team-20200101 → deploy/monitoring-stage-20200101
# - release/team-20200115 → deploy/monitoring-stage-20200115

```

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

### Rendered Custom Resource with Image Digest Substitution (YAML)

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

This YAML represents the rendered output of the CRD manifest after Bazel substitution. The placeholders for image digest and image URL have been replaced with the actual values, including the registry path and SHA256 digest.

```yaml
apiVersion: v1
kind: MyCrd
metadata:
  name: my_crd
  labels:
    app_label_image_digest: "e6d465223da74519ba3e2b38179d1268b71a72f"
    app_label_image_short_digest: "e6d465223d"
spec:
  image: "registry.example.com/examples/helloworld_image@sha256:e6d465223da74519ba3e2b38179d1268b71a72f"
```

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

### Kubernetes Secret Generation with Hash Suffix

Source: https://context7.com/adobe/rules_gitops/llms.txt

Demonstrates how k8s_deploy automatically generates Kubernetes Secret objects from directory structures with base64-encoded data. The generated secrets include hash suffixes in their names for cache invalidation and track secret file changes across environments. Requires secrets to be organized in environment-specific directories with subdirectories for each secret object.

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: secret-object-name-abcdef123
  namespace: mynamespace
data:
  username: <base64-encoded>
  password: <base64-encoded>
```

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

### Kubernetes Deployment Referencing Hashed ConfigMap

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Demonstrates how Kubernetes Deployment manifests automatically reference the generated hashed ConfigMap name. All references to the original ConfigMap name (grafana) are replaced with the generated name (grafana-k75h878g4f). The volumes section mounts the ConfigMap, specifying which keys (files) to mount and their target paths within containers.

```yaml
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      volumes:
      ...
      - configMap:
          items:
          - key: ldap.toml
            path: ldap.toml
          name: grafana-k75h878g4f
        name: grafana-ldap
```

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

### Rendered Kubernetes ConfigMap Manifest with Hash Naming

Source: https://github.com/adobe/rules_gitops/blob/main/README.md

Shows the output YAML manifest after rendering a ConfigMap with hash-based renaming policy. The directory name from the glob pattern becomes the ConfigMap base name, and files within are embedded as key-value pairs in the data section. The configmap_renaming='hash' policy generates a unique hash suffix (e.g., grafana-k75h878g4f) to ensure immutability and proper cache invalidation.

```yaml
apiVersion: v1
data:
  ldap.toml: |
    [[servers]]
    ...
kind: ConfigMap
metadata:
  name: grafana-k75h878g4f
  namespace: ops-prod
```

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

### Conditional Deployment Trigger

Source: https://context7.com/adobe/rules_gitops/llms.txt

Ensures deployments are triggered only when application code changes, ignoring mere timestamp updates. This is a core feature for efficient GitOps workflows.

```starlark
# Only triggers deployment when actual application changes occur,
# not when timestamps change

```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.