Helm chart update for v1.4.0 (#886)

* update

* update

* update

.github/workflows/push-helm-chart.yaml

@@ -1,6 +1,6 @@
 name: Push Helm Chart
 
-# TODO: fix: workflows have a problem where only code owners' PRs get the actions running 
+# TODO: fix: workflows have a problem where only code owners' PRs get the actions running
 
 on:
   pull_request:
@@ -104,6 +104,13 @@ jobs:
           commit_username: stakater-user
           commit_email: stakater@gmail.com
 
+      - name: Push new chart tag
+        uses: anothrNick/github-tag-action@1.71.0
+        env:
+          GITHUB_TOKEN: ${{ secrets.PUBLISH_TOKEN }}
+          WITH_V: false
+          CUSTOM_TAG: chart-v${{ steps.new_chart_version.outputs.result }}
+
       - name: Notify Slack
         uses: 8398a7/action-slack@v3
         if: always() # Pick up events even if the job fails or is canceled.

.github/workflows/release-helm-chart.yaml

@@ -0,0 +1,41 @@
+name: Release Helm chart
+
+on:
+  push:
+    tags:
+      - "chart-v*"
+    tags-ignore:
+      - "v*"
+
+permissions:
+  contents: write
+
+jobs:
+  release-helm-chart:
+    name: Release Helm chart
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out code
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Create release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          tag: ${{ github.ref }}
+        run: |
+          gh release create "$tag" \
+              --repo="$GITHUB_REPOSITORY" \
+              --title="Helm chart ${tag#chart-}" \
+              --generate-notes
+
+      - name: Notify Slack
+        uses: 8398a7/action-slack@v3
+        if: always()
+        with:
+          status: ${{ job.status }}
+          fields: repo,author,action,eventName,ref,workflow
+        env:
+          SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}

.github/workflows/release.yaml

@@ -1,8 +1,11 @@
 name: Release Go project
 
 on:
-  release:
-    types: [published]
+  push:
+    tags:
+      - "v*"
+    tags-ignore:
+      - "chart-v*"
 
 env:
   DOCKER_FILE_PATH: Dockerfile
@@ -12,7 +15,7 @@ env:
   REGISTRY: ghcr.io
 
 jobs:
-  build:
+  release:
 
     permissions:
       contents: read
@@ -193,22 +196,6 @@ jobs:
       ## Add steps to generate required artifacts for a release here(helm chart, operator manifest etc.)
       ##############################
 
-      # # Generate tag for operator without "v"
-      # - name: Generate Operator Tag
-      #   id: generate_operator_tag
-      #   uses: anothrNick/github-tag-action@1.70.0
-      #   env:
-      #     GITHUB_TOKEN: ${{ secrets.STAKATER_GITHUB_TOKEN }}
-      #     WITH_V: false
-      #     DEFAULT_BUMP: patch
-      #     DRY_RUN: true
-
-      # # Update chart tag to the latest semver tag
-      # - name: Update Chart Version
-      #   env:
-      #     VERSION: ${{ steps.generate_operator_tag.outputs.RELEASE_VERSION }}
-      #   run: make bump-chart
-
       - name: Run GoReleaser
         uses: goreleaser/goreleaser-action@master
         with:

.goreleaser.yml

@@ -18,10 +18,7 @@ snapshot:
 checksum:
   name_template: "{{ .ProjectName }}_{{ .Version }}_checksums.txt"
 changelog:
-  sort: asc
-  filters:
-    exclude:
-    - '^docs:'
-    - '^test:'
+  # It will be generated manually as part of making a new GitHub release
+  disable: true
 env_files:
   github_token: /home/jenkins/.apitoken/hub

.markdownlint.yaml

@@ -3,4 +3,6 @@
   "MD013": false,
   "MD024": false,
   "MD029": { "style": one },
+  "MD033": false,
+  "MD041": false,
 }

.vale.ini

@@ -1,7 +1,7 @@
 StylesPath = styles
 MinAlertLevel = warning
 
-Packages = https://github.com/stakater/vale-package/releases/download/v0.0.57/Stakater.zip
+Packages = https://github.com/stakater/vale-package/releases/download/v0.0.60/Stakater.zip
 Vocab = Stakater
 
 # Only check MarkDown files

Dockerfile

@@ -2,7 +2,7 @@ ARG BUILDER_IMAGE
 ARG BASE_IMAGE
 
 # Build the manager binary
-FROM --platform=${BUILDPLATFORM} ${BUILDER_IMAGE:-golang:1.24.1} AS builder
+FROM --platform=${BUILDPLATFORM} ${BUILDER_IMAGE:-golang:1.24.2} AS builder
 
 ARG TARGETOS
 ARG TARGETARCH

Makefile

@@ -46,7 +46,6 @@ GOLANGCI_LINT_VERSION ?= v1.57.2
 YQ_VERSION ?= v4.27.5
 YQ_DOWNLOAD_URL = "https://github.com/mikefarah/yq/releases/download/$(YQ_VERSION)/yq_$(OS)_$(ARCH)"
 
-
 .PHONY: yq
 yq: $(YQ) ## Download YQ locally if needed
 $(YQ):
@@ -58,7 +57,6 @@ $(YQ):
 	@chmod +x $(YQ)
 	@echo "yq downloaded successfully to $(YQ)."
 
-
 .PHONY: kustomize
 kustomize: $(KUSTOMIZE) ## Download kustomize locally if necessary.
 $(KUSTOMIZE): $(LOCALBIN)
@@ -157,12 +155,6 @@ k8s-manifests: $(KUSTOMIZE) ## Generate k8s manifests using Kustomize from 'mani
 update-manifests-version: ## Generate k8s manifests using Kustomize from 'manifests' folder
 	sed -i 's/image:.*/image: \"ghcr.io\/stakater\/reloader:v$(VERSION)"/g' deployments/kubernetes/manifests/deployment.yaml
 
-# Bump Chart
-bump-chart: 
-	sed -i "s/^appVersion:.*/appVersion: v$(VERSION)/" deployments/kubernetes/chart/reloader/Chart.yaml
-	sed -i "s/tag:.*/tag: v$(VERSION)/" deployments/kubernetes/chart/reloader/values.yaml
-	sed -i "s/version:.*/version: v$(VERSION)/" deployments/kubernetes/chart/reloader/values.yaml
-
 YQ_VERSION = v4.42.1
 YQ_BIN = $(shell pwd)/yq
 CURRENT_ARCH := $(shell uname -m | sed 's/x86_64/amd64/' | sed 's/aarch64/arm64/')

README.md

@@ -1,4 +1,6 @@
-# ![Reloader-logo](assets/web/reloader-round-100px.png) Reloader
+<p align="center">
+  <img src="assets/web/reloader.jpg" alt="Reloader" width="40%"/>
+</p>
 
 [![Go Report Card](https://goreportcard.com/badge/github.com/stakater/reloader?style=flat-square)](https://goreportcard.com/report/github.com/stakater/reloader)
 [![Go Doc](https://img.shields.io/badge/godoc-reference-blue.svg?style=flat-square)](https://godoc.org/github.com/stakater/reloader)
@@ -7,270 +9,232 @@
 [![Docker Pulls](https://img.shields.io/docker/pulls/stakater/reloader.svg?style=flat-square)](https://hub.docker.com/r/stakater/reloader/)
 [![Docker Stars](https://img.shields.io/docker/stars/stakater/reloader.svg?style=flat-square)](https://hub.docker.com/r/stakater/reloader/)
 [![license](https://img.shields.io/github/license/stakater/reloader.svg?style=flat-square)](LICENSE)
-[![Get started with Stakater](https://stakater.github.io/README/stakater-github-banner.png)](https://stakater.com/?utm_source=Reloader&utm_medium=github)
 
-## Problem
+## 🔁 What is Reloader?
 
-We would like to watch if some change happens in `ConfigMap` and/or `Secret`; then perform a rolling upgrade on relevant `DeploymentConfig`, `Deployment`, `Daemonset`, `Statefulset` and `Rollout`
+Reloader is a Kubernetes controller that automatically triggers rollouts of workloads (like Deployments, StatefulSets, and more) whenever referenced `Secrets` or `ConfigMaps` are updated.
 
-## Solution
+In a traditional Kubernetes setup, updating a `Secret` or `ConfigMap` does not automatically restart or redeploy your workloads. This can lead to stale configurations running in production, especially when dealing with dynamic values like credentials, feature flags, or environment configs.
 
-Reloader can watch changes in `ConfigMap` and `Secret` and do rolling upgrades on Pods with their associated `DeploymentConfigs`, `Deployments`, `Daemonsets` `Statefulsets` and `Rollouts`.
+Reloader bridges that gap by ensuring your workloads stay in sync with configuration changes — automatically and safely.
 
-## Enterprise Version
+## 🚀 Why Reloader?
 
-Reloader is available in two different versions:
+- ✅ **Zero manual restarts**: No need to manually rollout workloads after config/secret changes.
+- 🔒 **Secure by design**: Ensure your apps always use the most up-to-date credentials or tokens.
+- 🛠️ **Flexible**: Works with all major workload types — Deployment, StatefulSet, Daemonset, ArgoRollout, and more.
+- ⚡ **Fast feedback loop**: Ideal for CI/CD pipelines where secrets/configs change frequently.
+- 🔄 **Out-of-the-box integration**: Just label your workloads and let Reloader do the rest.
 
-1. Open Source Version
-1. Enterprise Version, which includes:
-   - SLA (Service Level Agreement) for support and unique requests
-   - Slack support
-   - Certified images
+## 🔧 How It Works?
 
-Contact [`sales@stakater.com`](mailto:sales@stakater.com) for info about Reloader Enterprise.
+```mermaid
+flowchart LR
+  ExternalSecret -->|Creates| Secret
+  SealedSecret -->|Creates| Secret
+  Secret -->|Watched by| Reloader
+  ConfigMap -->|Watched by| Reloader
 
-## Compatibility
+  Reloader -->|Triggers Rollout| Deployment
+  Reloader -->|Triggers Rollout| DeploymentConfig
+  Reloader -->|Triggers Rollout| Daemonset
+  Reloader -->|Triggers Rollout| Statefulset
+  Reloader -->|Triggers Rollout| ArgoRollout
+  Reloader -->|Triggers Job| CronJob
+  Reloader -->|Sends Notification| Slack,Teams,Webhook
+```
 
-Reloader is compatible with Kubernetes >= 1.19
+- Sources like `ExternalSecret` or `SealedSecret` create or manage your Kubernetes Secrets.
+- `Secrets` and `ConfigMaps` are watched by Reloader.
+- When changes are detected, Reloader automatically triggers a rollout of the associated workloads, ensuring your app always runs with the latest configuration.
 
-## How to use Reloader
+## ⚡ Quick Start
 
-You have a `Deployment` called `foo` and a `ConfigMap` and/or a `Secret` either mounted as a volume or defined as a environment variable. The `ConfigMap` and `Secret` can be named whatever, but for the sake of this example, lets refer to the `ConfigMap` as `foo-configmap` and the secret as `foo-secret`.
+### 1. Install Reloader
 
-Add the annotation to the main metadata of your `Deployment`. By default this would be `reloader.stakater.com/auto`.
+Follow any of this [installation options](#-installation).
+
+### 2. Annotate Your Workload
+
+To enable automatic reload for a Deployment:
 
 ```yaml
+apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: foo
+  name: my-app
   annotations:
     reloader.stakater.com/auto: "true"
 spec:
   template:
     metadata:
+      labels:
+        app: my-app
+    spec:
+      containers:
+        - name: app
+          image: your-image
+          envFrom:
+            - configMapRef:
+                name: my-config
+            - secretRef:
+                name: my-secret
 ```
 
-This will discover deploymentconfigs/deployments/daemonsets/statefulset/rollouts/cronjobs/jobs automatically where `foo-configmap` or `foo-secret` is being used either via environment variable or from volume mount. And it will perform rolling upgrade on related pods when `foo-configmap` or `foo-secret`are updated.
+This tells Reloader to watch the `ConfigMap` and `Secret` referenced in this deployment. When either is updated, it will trigger a rollout.
 
-You can filter it by the type of monitored resource and use typed versions of `auto` annotation. If you want to discover changes only in mounted `Secret`s and ignore changes in `ConfigMap`s, add `secret.reloader.stakater.com/auto` annotation instead. Analogously, you can use `configmap.reloader.stakater.com/auto` annotation to look for changes in mounted `ConfigMap`, changes in any of mounted `Secret`s will not trigger a rolling upgrade on related pods.
+## 🏢 Enterprise Version
 
-You can also restrict this discovery to only `ConfigMap` or `Secret` objects that
-are tagged with a special annotation. To take advantage of that, annotate
-your deploymentconfigs/deployments/daemonsets/statefulset/rollouts/cronjobs/jobs like this:
+Stakater offers an enterprise-grade version of Reloader with:
+
+1. SLA-backed support
+1. Certified images
+1. Private Slack support
+
+Contact [`sales@stakater.com`](mailto:sales@stakater.com) for info about Reloader Enterprise.
+
+## 🧩 Usage
+
+Reloader supports multiple annotation-based controls to let you **customize when and how your Kubernetes workloads are reloaded** upon changes in `Secrets` or `ConfigMaps`.
+
+Kubernetes does not trigger pod restarts when a referenced `Secret` or `ConfigMap` is updated. Reloader bridges this gap by watching for changes and automatically performing rollouts — but it gives you full control via annotations, so you can:
+
+- Reload **all** resources by default
+- Restrict reloads to only **Secrets** or only **ConfigMaps**
+- Watch only **specific resources**
+- Use **opt-in via tagging** (`search` + `match`)
+- Exclude workloads you don’t want to reload
+
+### 1. 🔁 Automatic Reload (Default)
+
+Use these annotations to automatically restart the workload when referenced `Secrets` or `ConfigMaps` change.
+
+| Annotation                                 | Description                                                          |
+|--------------------------------------------|----------------------------------------------------------------------|
+| `reloader.stakater.com/auto: "true"`       | Reloads workload when any referenced ConfigMap or Secret changes     |
+| `secret.reloader.stakater.com/auto: "true"`| Reloads only when referenced Secret(s) change                        |
+| `configmap.reloader.stakater.com/auto: "true"`| Reloads only when referenced ConfigMap(s) change                  |
+
+### 2. 📛 Named Resource Reload (Specific Resource Annotations)
+
+These annotations allow you to manually define which ConfigMaps or Secrets should trigger a reload, regardless of whether they're used in the pod spec.
+
+| Annotation                                          | Description                                                                          |
+|-----------------------------------------------------|--------------------------------------------------------------------------------------|
+| `secret.reloader.stakater.com/reload: "my-secret"`  | Reloads when specific Secret(s) change, regardless of how they're used              |
+| `configmap.reloader.stakater.com/reload: "my-config"`| Reloads when specific ConfigMap(s) change, regardless of how they're used         |
+
+#### Use when
+
+1. ✅ This is useful in tightly scoped scenarios where config is shared but reloads are only relevant in certain cases.
+1. ✅ Use this when you know exactly which resource(s) matter and want to avoid auto-discovery or searching altogether.
+
+### 3. 🎯 Targeted Reload (Match + Search Annotations)
+
+This pattern allows fine-grained reload control — workloads only restart if the Secret/ConfigMap is both:
+
+1. Referenced by the workload
+1. Explicitly annotated with `match: true`
+
+| Annotation                                | Applies To   | Description                                                                 |
+|-------------------------------------------|--------------|-----------------------------------------------------------------------------|
+| `reloader.stakater.com/search: "true"`    | Workload     | Enables search mode (only reloads if matching secrets/configMaps are found) |
+| `reloader.stakater.com/match: "true"`     | ConfigMap/Secret | Marks the config/secret as eligible for reload in search mode              |
+
+#### How it works
+
+1. The workload must have: `reloader.stakater.com/search: "true"`
+1. The ConfigMap or Secret must have: `reloader.stakater.com/match: "true"`
+1. The resource (ConfigMap or Secret) must also be referenced in the workload (via env, `volumeMount`, etc.)
+
+#### Use when
+
+1. ✅ You want to reload a workload only if it references a ConfigMap or Secret that has been explicitly tagged with `reloader.stakater.com/match: "true"`.
+1. ✅ Use this when you want full control over which shared or system-wide resources trigger reloads. Great in multi-tenant clusters or shared configs.
+
+### 4. ⚙️ Workload-Specific Rollout Strategy
+
+By default, Reloader uses the **rollout** strategy — it updates the pod template to trigger a new rollout. This works well in most cases, but it can cause problems if you're using GitOps tools like ArgoCD, which detect this as configuration drift.
+
+To avoid that, you can switch to the **restart** strategy, which simply restarts the pod without changing the pod template.
 
 ```yaml
-kind: Deployment
 metadata:
   annotations:
-    reloader.stakater.com/search: "true"
-spec:
-  template:
+    reloader.stakater.com/rollout-strategy: "restart"
 ```
 
-and Reloader will trigger the rolling upgrade upon modification of any
-`ConfigMap` or `Secret` annotated like this:
+| Value              | Behavior                                                        |
+|--------------------|-----------------------------------------------------------------|
+| `rollout` (default) | Updates pod template metadata to trigger a rollout             |
+| `restart`           | Deletes the pod to restart it without patching the template    |
+
+✅ Use `restart` if:
+
+1. You're using GitOps and want to avoid drift
+1. You want a quick restart without changing the workload spec
+1. Your platform restricts metadata changes
+
+### 5. ❗ Annotation Behavior Rules & Compatibility
+
+- `reloader.stakater.com/auto` and `reloader.stakater.com/search` **cannot be used together** — the `auto` annotation takes precedence.
+- If both `auto` and its typed versions (`secret.reloader.stakater.com/auto`, `configmap.reloader.stakater.com/auto`) are used, **only one needs to be true** to trigger a reload.
+- Setting `reloader.stakater.com/auto: "false"` explicitly disables reload for that workload.
+- If `--auto-reload-all` is enabled on the controller:
+    - All workloads are treated as if they have `auto: "true"` unless they explicitly set it to `"false"`.
+    - Missing or unrecognized annotation values are treated as `"false"`.
+
+### 6. 🔔 Alerting on Reload
+
+Reloader can optionally **send alerts** whenever it triggers a rolling upgrade for a workload (e.g., `Deployment`, `StatefulSet`, etc.).
+
+These alerts are sent to a configured **webhook endpoint**, which can be a generic receiver or services like Slack or Microsoft Teams.
+
+To enable this feature, update the `reloader.env.secret` section in your `values.yaml` (when installing via Helm):
 
 ```yaml
-kind: ConfigMap
-metadata:
-  annotations:
-    reloader.stakater.com/match: "true"
-data:
-  key: value
+reloader:
+  env:
+    secret:
+      ALERT_ON_RELOAD: "true"                    # Enable alerting (default: false)
+      ALERT_SINK: "slack"                        # Options: slack, teams, webhook (default: webhook)
+      ALERT_WEBHOOK_URL: "<your-webhook-url>"    # Required if ALERT_ON_RELOAD is true
+      ALERT_ADDITIONAL_INFO: "Triggered by Reloader in staging environment"
 ```
 
-provided the secret/configmap is being used in an environment variable, or a
-volume mount.
+## 🚀 Installation
 
-Please note that `reloader.stakater.com/search` and
-`reloader.stakater.com/auto` do not work together. If you have the
-`reloader.stakater.com/auto: "true"` annotation on your deployment, then it
-will always restart upon a change in configmaps or secrets it uses, regardless
-of whether they have the `reloader.stakater.com/match: "true"` annotation or
-not.
+### 1. 📦 Helm
 
-Similarly, `reloader.stakater.com/auto` and its typed version (`secret.reloader.stakater.com/auto` or `configmap.reloader.stakater.com/auto`) do not work together. If you have both annotations in your deployment, then only one of them needs to be true to trigger the restart. For example, having both `reloader.stakater.com/auto: "true"` and `secret.reloader.stakater.com/auto: "false"` or both `reloader.stakater.com/auto: "false"` and `secret.reloader.stakater.com/auto: "true"` will restart upon a change in a secret it uses.
+Reloader can be installed in multiple ways depending on your Kubernetes setup and preference. Below are the supported methods:
 
-We can also specify a specific configmap or secret which would trigger rolling upgrade only upon change in our specified configmap or secret, this way, it will not trigger rolling upgrade upon changes in all configmaps or secrets used in a `deploymentconfig`, `deployment`, `daemonset`, `statefulset`, `rollout`, `cronJob` or `job`.
-To do this either set the auto annotation to `"false"` (`reloader.stakater.com/auto: "false"`) or remove it altogether, and use annotations for [Configmap](.#Configmap) or [Secret](.#Secret).
-
-It's also possible to enable auto reloading for all resources, by setting the `--auto-reload-all` flag.
-In this case, all resources that do not have the auto annotation (or its typed version) set to `"false"`, will be reloaded automatically when their Configmaps or Secrets are updated.
-Notice that setting the auto annotation to an undefined value counts as false as-well.
-
-### Configmap
-
-To perform rolling upgrade when change happens only on specific configmaps use below annotation.
-
-For a `Deployment` called `foo` have a `ConfigMap` called `foo-configmap`. Then add this annotation to main metadata of your `Deployment`
-
-```yaml
-kind: Deployment
-metadata:
-  annotations:
-    configmap.reloader.stakater.com/reload: "foo-configmap"
-spec:
-  template:
-    metadata:
+```bash
+helm repo add stakater https://stakater.github.io/stakater-charts
+helm repo update
+helm install reloader stakater/reloader
 ```
 
-Use comma separated list to define multiple configmaps.
+➡️ See full Helm configuration in the [chart README](./deployments/kubernetes/chart/reloader/README.md).
 
-```yaml
-kind: Deployment
-metadata:
-  annotations:
-    configmap.reloader.stakater.com/reload: "foo-configmap,bar-configmap,baz-configmap"
-spec:
-  template:
-    metadata:
-```
+### 2. 📄 Vanilla Manifests
 
-### Secret
-
-To perform rolling upgrade when change happens only on specific secrets use below annotation.
-
-For a `Deployment` called `foo` have a `Secret` called `foo-secret`. Then add this annotation to main metadata of your `Deployment`
-
-```yaml
-kind: Deployment
-metadata:
-  annotations:
-    secret.reloader.stakater.com/reload: "foo-secret"
-spec:
-  template:
-    metadata:
-```
-
-Use comma separated list to define multiple secrets.
-
-```yaml
-kind: Deployment
-metadata:
-  annotations:
-    secret.reloader.stakater.com/reload: "foo-secret,bar-secret,baz-secret"
-spec:
-  template:
-    metadata:
-```
-
-### NOTES
-
-- Reloader also supports [sealed-secrets](https://github.com/bitnami-labs/sealed-secrets). [Here](docs/Reloader-with-Sealed-Secrets.md) are the steps to use sealed-secrets with Reloader.
-- For [`rollouts`](https://github.com/argoproj/argo-rollouts/) Reloader simply triggers a change is up to you how you configure the `rollout` strategy.
-- `reloader.stakater.com/auto: "true"` will only reload the pod, if the configmap or secret is used (as a volume mount or as an env) in `DeploymentConfigs/Deployment/Daemonsets/Statefulsets/CronJobs/Jobs`
-- `secret.reloader.stakater.com/reload` or `configmap.reloader.stakater.com/reload` annotation will reload the pod upon changes in specified configmap or secret, irrespective of the usage of configmap or secret.
-- you may override the auto annotation with the `--auto-annotation` flag
-- you may override the secret typed auto annotation with the `--secret-auto-annotation` flag
-- you may override the configmap typed auto annotation with the `--configmap-auto-annotation` flag
-- you may override the search annotation with the `--auto-search-annotation` flag
-  and the match annotation with the `--search-match-annotation` flag
-- you may override the configmap annotation with the `--configmap-annotation` flag
-- you may override the secret annotation with the `--secret-annotation` flag
-- you may want to prevent watching certain namespaces with the `--namespaces-to-ignore` flag
-- you may want to watch only a set of namespaces with certain labels by using the `--namespace-selector` flag
-- you may want to watch only a set of secrets/configmaps with certain labels by using the `--resource-label-selector` flag
-- you may want to prevent watching certain resources with the `--resources-to-ignore` flag
-- you can configure logging in JSON format with the `--log-format=json` option
-- you can configure the "reload strategy" with the `--reload-strategy=<strategy-name>` option (details below)
-- you can configure rollout reload strategy with `reloader.stakater.com/rollout-strategy` annotation, `restart` or `rollout` values are available (defaults to `rollout`)
-
-## Reload Strategies
-
-Reloader supports multiple "reload" strategies for performing rolling upgrades to resources. The following list describes them:
-
-- **env-vars**: When a tracked `configMap`/`secret` is updated, this strategy attaches a Reloader specific environment variable to any containers referencing the changed `configMap` or `secret` on the owning resource (e.g., `Deployment`, `StatefulSet`, etc.). This strategy can be specified with the `--reload-strategy=env-vars` argument. Note: This is the default reload strategy.
-- **annotations**: When a tracked `configMap`/`secret` is updated, this strategy attaches a `reloader.stakater.com/last-reloaded-from` pod template annotation on the owning resource (e.g., `Deployment`, `StatefulSet`, etc.). This strategy is useful when using resource syncing tools like ArgoCD, since it will not cause these tools to detect configuration drift after a resource is reloaded. Note: Since the attached pod template annotation only tracks the last reload source, this strategy will reload any tracked resource should its `configMap` or `secret` be deleted and recreated. This strategy can be specified with the `--reload-strategy=annotations` argument.
-
-## Deploying to Kubernetes
-
-You can deploy Reloader by following methods:
-
-### Vanilla Manifests
-
-You can apply vanilla manifests by changing `RELEASE-NAME` placeholder provided in manifest with a proper value and apply it by running the command given below:
+Apply raw Kubernetes manifests directly:
 
 ```bash
 kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml
 ```
 
-By default, Reloader gets deployed in `default` namespace and watches changes `secrets` and `configmaps` in all namespaces. Additionally, in the default Reloader deployment, the following resource limits and requests are set:
+### 3. 🧱 Vanilla Kustomize
 
-```yaml
-resources:
-  limits:
-    cpu: 150m
-    memory: 512Mi
-  requests:
-    cpu: 10m
-    memory: 128Mi
-```
-
-Reloader can be configured to ignore the resources `secrets` and `configmaps` by passing the following arguments (`spec.template.spec.containers.args`) to its container:
-
-| Argument                           | Description          |
-| ---------------------------------- | -------------------- |
-| `--resources-to-ignore=configMaps` | To ignore configmaps |
-| `--resources-to-ignore=secrets`    | To ignore secrets    |
-
-**Note:** At one time only one of these resource can be ignored, trying to do it will cause error in Reloader. Workaround for ignoring both resources is by scaling down the Reloader pods to `0`.
-
-Reloader can be configured to only watch secrets/configmaps with one or more labels using the `--resource-label-selector` parameter. Supported operators are `!, in, notin, ==, =, !=`, if no operator is found the 'exists' operator is inferred (i.e. key only). Additional examples of these selectors can be found in the [Kubernetes Docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors).
-
-**Note:** The old `:` delimited key value mappings are deprecated and if provided will be translated to `key=value`. Likewise, if a wildcard value is provided (e.g. `key:*`) it will be translated to the standalone `key` which checks for key existence.
-
-These selectors can be combined, for example with:
-
-```yaml
---resource-label-selector=reloader=enabled,key-exists,another-label in (value1,value2,value3)
-```
-
-Only configmaps or secrets labeled like the following will be watched:
-
-```yaml
-kind: ConfigMap
-apiVersion: v1
-metadata:
-  labels:
-    reloader: enabled
-    key-exists: yes
-    another-label: value1
-```
-
-Reloader can be configured to only watch namespaces labeled with one or more labels using the `--namespace-selector` parameter. Supported operators are `!, in, notin, ==, =, !=`, if no operator is found the 'exists' operator is inferred (i.e. key only). Additional examples of these selectors can be found in the [Kubernetes Docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors).
-
-**Note:** The old `:` delimited key value mappings are deprecated and if provided will be translated to `key=value`. Likewise, if a wildcard value is provided (e.g. `key:*`) it will be translated to the standalone `key` which checks for key existence.
-
-These selectors can be combined, for example with:
-
-```yaml
---namespace-selector=reloader=enabled,test=true
-```
-
-Only namespaces labeled as below would be watched and eligible for reloads:
-
-```yaml
-kind: Namespace
-apiVersion: v1
-metadata:
-  labels:
-    reloader: enabled
-    test: true
-```
-
-### Vanilla Kustomize
-
-You can also apply the vanilla manifests by running the following command
+Use the built-in Kustomize support:
 
 ```bash
 kubectl apply -k https://github.com/stakater/Reloader/deployments/kubernetes
 ```
 
-Similarly to vanilla manifests get deployed in `default` namespace and watches changes `secrets` and `configmaps` in all namespaces.
+### 4. 🛠️ Custom Kustomize Setup
 
-### Kustomize
-
-You can write your own `kustomization.yaml` using ours as a 'base' and write patches to tweak the configuration.
+You can create your own `kustomization.yaml` and use Reloader’s as a base:
 
 ```yaml
 apiVersion: kustomize.config.k8s.io/v1beta1
@@ -282,29 +246,84 @@ resources:
 namespace: reloader
 ```
 
-### Helm Chart
+### 5. ⚖️ Default Resource Requests and Limits
 
-The Reloader Helm chart is documented in the [chart README](./deployments/kubernetes/chart/reloader/README.md).
+By default, Reloader is deployed with the following resource requests and limits:
 
-#### Additional Remarks
+```yaml
+resources:
+  limits:
+    cpu: 150m
+    memory: 512Mi
+  requests:
+    cpu: 10m
+    memory: 128Mi
+```
 
-- Both `namespaceSelector` & `resourceLabelSelector` can be used together. If they are then both conditions must be met for the configmap or secret to be eligible to trigger reload events. (e.g. If a configmap matches `resourceLabelSelector` but `namespaceSelector` does not match the namespace the configmap is in, it will be ignored).
-- At one time only one of the resources `ignoreConfigMaps` or `ignoreSecrets` can be ignored, trying to do both will cause error in helm template compilation
-- Reloading of OpenShift (DeploymentConfig) and/or Argo `Rollouts` has to be enabled explicitly because it might not be always possible to use it on a cluster with restricted permissions
-- `isOpenShift` Recent versions of OpenShift (tested on 4.13.3) require the specified user to be in an `uid` range which is dynamically assigned by the namespace. The solution is to unset the runAsUser variable via `deployment.securityContext.runAsUser=null` and let OpenShift assign it at install
-- `reloadOnCreate` controls how Reloader handles secrets being added to the cache for the first time. If `reloadOnCreate` is set to true:
-  1. Configmaps/secrets being added to the cache will cause Reloader to perform a rolling update of the associated workload
-  1. When applications are deployed for the first time, Reloader will perform a rolling update of the associated workload
-  1. If you are running Reloader in HA mode all workloads will have a rolling update performed when a new leader is elected
-- `reloadOnDelete` controls how Reloader handles secrets being deleted. If `reloadOnDelete` is set to true:
-  1. Configmaps/secrets being deleted will cause Reloader to perform a rolling update of the associated workload
-- `serviceMonitor` will be removed in future releases of Reloader in favour of Pod monitor
-- If `reloadOnCreate` is set to false:
-  1. Updates to configmaps/secrets that occur while there is no leader will not be picked up by the new leader until a subsequent update of the configmap/secret occurs
-  1. In the worst case the window in which there can be no leader is 15s as this is the LeaseDuration
-- If `reloadOnDelete` is set to false:
-  1. Deleting of configmaps/secrets has no effect to pods that references these resources.
-- By default, `reloadOnCreate`, `reloadOnDelete` and `syncAfterRestart` are all set to false. All need to be enabled explicitly
+### 6. ⚙️ Optional runtime configurations
+
+These flags let you customize Reloader's behavior globally, at the Reloader controller level.
+
+#### 1. 🔁 Reload Behavior
+
+| Flag | Description |
+|------|-------------|
+| `--reload-on-create=true` | Reload workloads when a watched ConfigMap or Secret is created |
+| `--reload-on-delete=true` | Reload workloads when a watched ConfigMap or Secret is deleted |
+| `--auto-reload-all=true` | Automatically reload all workloads unless opted out (`auto: "false"`) |
+| `--reload-strategy=env-vars` | Strategy to use for triggering reload (`env-vars` or `annotations`) |
+| `--log-format=json` | Enable JSON-formatted logs for better machine readability |
+
+##### Reload Strategies
+
+Reloader supports multiple strategies for triggering rolling updates when a watched `ConfigMap` or `Secret` changes. You can configure the strategy using the `--reload-strategy` flag.
+
+| Strategy     | Description |
+|--------------|-------------|
+| `env-vars` (default) | Adds a dummy environment variable to any container referencing the changed resource (e.g., `Deployment`, `StatefulSet`, etc.). This forces Kubernetes to perform a rolling update. |
+| `annotations` | Adds a `reloader.stakater.com/last-reloaded-from` annotation to the pod template metadata. Ideal for GitOps tools like ArgoCD, as it avoids triggering unwanted sync diffs. |
+
+- The `env-vars` strategy is the default and works in most setups.
+- The `annotations` strategy is preferred in **GitOps environments** to prevent config drift in tools like ArgoCD or Flux.
+- In `annotations` mode, a `ConfigMap` or `Secret` that is deleted and re-created will still trigger a reload (since previous state is not tracked).
+
+#### 2. 🚫 Resource Filtering
+
+| Flag | Description |
+|------|-------------|
+| `--resources-to-ignore=configmaps` | Ignore ConfigMaps (only one type can be ignored at a time) |
+| `--resources-to-ignore=secrets` | Ignore Secrets (cannot combine with configMaps) |
+| `--resource-label-selector=key=value` | Only watch ConfigMaps/Secrets with matching labels |
+
+> **⚠️ Note:**  
+> Only **one** resource type can be ignored at a time.  
+> Trying to ignore **both `configmaps` and `secrets`** will cause an error in Reloader.  
+> ✅ **Workaround:** Scale the Reloader deployment to `0` replicas if you want to disable it completely.
+
+#### 3. 🧩 Namespace Filtering
+
+| Flag | Description |
+|------|-------------|
+| `--namespace-selector=key=value` | Watch only namespaces with matching labels |
+| `--namespaces-to-ignore=ns1,ns2` | Skip specific namespaces from being watched |
+
+#### 4. 📝 Annotation Key Overrides
+
+These flags allow you to redefine annotation keys used in your workloads or resources:
+
+| Flag | Overrides |
+|------|-----------|
+| `--auto-annotation` | Overrides `reloader.stakater.com/auto` |
+| `--secret-auto-annotation` | Overrides `secret.reloader.stakater.com/auto` |
+| `--configmap-auto-annotation` | Overrides `configmap.reloader.stakater.com/auto` |
+| `--auto-search-annotation` | Overrides `reloader.stakater.com/search` |
+| `--search-match-annotation` | Overrides `reloader.stakater.com/match` |
+| `--secret-annotation` | Overrides `secret.reloader.stakater.com/reload` |
+| `--configmap-annotation` | Overrides `configmap.reloader.stakater.com/reload` |
+
+## Compatibility
+
+Reloader is compatible with Kubernetes >= 1.19
 
 ## Help
 
@@ -368,15 +387,12 @@ View the [releases page](https://github.com/stakater/Reloader/releases) to see w
 
 Apache2 © [Stakater][website]
 
-## About
+## About Stakater
+
+[![Get started with Stakater](https://stakater.github.io/README/stakater-github-banner.png)](https://stakater.com/?utm_source=Reloader&utm_medium=github)
 
 `Reloader` is maintained by [Stakater][website]. Like it? Please let us know at [hello@stakater.com](hello@stakater.com)
 
-See [our other projects](https://github.com/stakater)
-or contact us in case of professional services and queries on [hello@stakater.com](hello@stakater.com)
+See [our other projects](https://github.com/stakater) or contact us in case of professional services and queries on [hello@stakater.com](hello@stakater.com)
 
 [website]: https://stakater.com
-
-## Acknowledgements
-
-- [ConfigmapController](https://github.com/fabric8io/configmapcontroller); We documented [here](docs/Reloader-vs-ConfigmapController.md) why we re-created Reloader

deployments/kubernetes/chart/reloader/Chart.yaml

@@ -1,8 +1,8 @@
 apiVersion: v1
 name: reloader
 description: Reloader chart that runs on kubernetes
-version: 2.0.0
-appVersion: v1.3.0
+version: 2.1.0
+appVersion: v1.4.0
 keywords:
   - Reloader
   - kubernetes

deployments/kubernetes/chart/reloader/README.md

@@ -99,6 +99,56 @@ helm uninstall {{RELEASE_NAME}} -n {{NAMESPACE}}
 | `reloader.volumes`                     | Add volume to a pod                                             | array   | `[]`    |
 | `reloader.webhookUrl`                  | Add webhook to Reloader                                         | string  | `""`    |
 
+## ⚙️ Helm Chart Configuration Notes
+
+### Selector Behavior
+- Both `namespaceSelector` & `resourceLabelSelector` can be used together
+- **Both conditions must be met** for a ConfigMap/Secret to trigger reloads
+  - Example: If a ConfigMap matches `resourceLabelSelector` but not `namespaceSelector`, it will be ignored
+
+### Important Limitations
+- Only one of these resources can be ignored at a time:
+  - `ignoreConfigMaps` **or** `ignoreSecrets`
+  - Trying to ignore both will cause Helm template compilation errors
+
+### Special Integrations
+- OpenShift (`DeploymentConfig`) and Argo Rollouts support must be **explicitly enabled**
+  - Required due to potential permission restrictions on clusters
+
+### OpenShift Considerations
+- Recent OpenShift versions (tested on 4.13.3) require:
+  - Users to be in a dynamically assigned UID range
+  - **Solution**: Unset `runAsUser` via `deployment.securityContext.runAsUser=null`
+  - Let OpenShift assign UID automatically during installation
+
+### Core Functionality Flags
+
+#### 🔄 `reloadOnCreate` Behavior
+**When true:**
+✅ New ConfigMaps/Secrets trigger rolling updates  
+✅ New deployments referencing existing resources reload  
+✅ In HA mode, new leader reloads all tracked workloads  
+
+**When false:**
+❌ Updates during leader downtime are missed  
+⏳ Potential 15s delay window (default `LeaseDuration`)  
+
+#### 🗑️ `reloadOnDelete` Behavior
+**When true:**
+✅ Deleted resources trigger rolling updates of referencing workloads  
+
+**When false:**
+❌ Deletions have no effect on referencing pods  
+
+#### Default Settings
+⚠️ All flags default to `false` (must be enabled explicitly):
+- `reloadOnCreate`
+- `reloadOnDelete` 
+- `syncAfterRestart`
+
+### Deprecation Notice
+- `serviceMonitor` will be removed in future releases in favor of `PodMonitor`
+
 ## Release Process
 
 _Helm chart versioning_: The Reloader Helm chart is maintained in this repository. The Helm chart has its own semantic versioning. Helm charts and code releases are separate artifacts and separately versioned. Manifest making strategy relies on Kustomize. The Reloader Helm chart manages the two artifacts with these two fields:
@@ -108,4 +158,8 @@ _Helm chart versioning_: The Reloader Helm chart is maintained in this repositor
 
 Helm chart will be released to the chart registry whenever files in `deployments/kubernetes/chart/reloader/**` change on the main branch.
 
-Helm Chart will be released by the maintainers, on labelling a PR with `release/helm-chart` and pre-maturely updating the `version` field in `Chart.yaml` file.
+### To release the Helm chart
+
+1. Create a new branch and update the Helm chart `appVersion` and `version`, example pull-request: [PR-846](https://github.com/stakater/Reloader/pull/846)
+1. Label the PR with `release/helm-chart`
+1. After approval and just before squash, make sure the squash commit message represents all changes, because it will be used to autogenerate the changelog message

deployments/kubernetes/chart/reloader/templates/deployment.yaml

@@ -25,8 +25,8 @@ spec:
   revisionHistoryLimit: {{ .Values.reloader.deployment.revisionHistoryLimit }}
   selector:
     matchLabels:
-      app: {{ template "reloader-fullname" . }}
-      release: {{ .Release.Name | quote }}
+      app.kubernetes.io/name: {{ template "reloader-fullname" . }}
+      app.kubernetes.io/instance: {{ .Release.Name | quote }}
 {{- if .Values.reloader.matchLabels }}
 {{ toYaml .Values.reloader.matchLabels | indent 6 }}
 {{- end }}

deployments/kubernetes/chart/reloader/templates/networkpolicy.yaml

@@ -14,8 +14,8 @@ metadata:
 spec:
   podSelector:
     matchLabels:
-      app: {{ template "reloader-fullname" . }}
-      release: {{ .Release.Name | quote }}
+      app.kubernetes.io/name: {{ template "reloader-fullname" . }}
+      app.kubernetes.io/instance: {{ .Release.Name | quote }}
 {{- if .Values.reloader.matchLabels }}
 {{ toYaml .Values.reloader.matchLabels | indent 6 }}
 {{- end }}

deployments/kubernetes/chart/reloader/templates/poddisruptionbudget.yaml

@@ -13,5 +13,5 @@ spec:
 {{- end }}
   selector:
     matchLabels:
-      app: {{ template "reloader-fullname" . }}
+      app.kubernetes.io/name: {{ template "reloader-fullname" . }}
 {{- end }}

deployments/kubernetes/chart/reloader/values.yaml

@@ -17,7 +17,7 @@ fullnameOverride: ""
 image:
   name: stakater/reloader
   repository: ghcr.io/stakater/reloader
-  tag: v1.3.0
+  tag: v1.4.0
   # digest: sha256:1234567
   pullPolicy: IfNotPresent
 
@@ -106,7 +106,7 @@ reloader:
     labels:
       provider: stakater
       group: com.stakater.platform
-      version: v1.3.0
+      version: v1.4.0
     # Support for extra environment variables.
     env:
       # Open supports Key value pair as environment variables.

docs/How-it-works.md

@@ -15,18 +15,18 @@ flowchart LR
 
 ## How Does Change Detection Work?
 
-Reloader watches changes in `configmaps` and `secrets` data. As soon as it detects a change in these. It forwards these objects to an update handler which decides if and how to perform the rolling upgrade.
+Reloader watches changes in `ConfigMaps` and `Secrets` data. As soon as it detects a change in these. It forwards these objects to an update handler which decides if and how to perform the rolling upgrade.
 
 ## Requirements for Rolling Upgrade
 
 To perform rolling upgrade a `deployment`, `daemonset` or `statefulset` must have
 
 - support for rolling upgrade strategy
-- specific annotation for `configmaps` or `secrets`
+- specific annotation for `ConfigMaps` or `Secrets`
 
-The annotation value is comma separated list of `configmaps` or `secrets`. If a change is detected in data of these `configmaps` or `secrets`, Reloader will perform rolling upgrades on their associated `deployments`, `daemonsets` or `statefulsets`.
+The annotation value is comma separated list of `ConfigMaps` or `Secrets`. If a change is detected in data of these `ConfigMaps` or `Secrets`, Reloader will perform rolling upgrades on their associated `deployments`, `daemonsets` or `statefulsets`.
 
-### Annotation for Configmap
+### Annotation for ConfigMap
 
 For a `Deployment` called `foo` have a `ConfigMap` called `foo`. Then add this annotation* to your `Deployment`, where the default annotation can be changed with the `--configmap-annotation` flag:
 
@@ -50,13 +50,13 @@ Above mentioned annotation are also work for `Daemonsets` `Statefulsets` and `Ro
 
 ## How Does Rolling Upgrade Work?
 
-When Reloader detects changes in configmap. It gets two objects of configmap. First object is an old configmap object which has a state before the latest change. Second object is new configmap object which contains latest changes. Reloader compares both objects and see whether any change in data occurred or not. If Reloader finds any change in new configmap object, only then, it moves forward with rolling upgrade.
+When Reloader detects changes in `ConfigMap`. It gets two objects of `ConfigMap`. First object is an old `ConfigMap` object which has a state before the latest change. Second object is new `ConfigMap` object which contains latest changes. Reloader compares both objects and see whether any change in data occurred or not. If Reloader finds any change in new `ConfigMap` object, only then, it moves forward with rolling upgrade.
 
-After that, Reloader gets the list of all `deployments`, `daemonsets` and `statefulset` and looks for above mentioned annotation for configmap. If the annotation value contains the configmap name, it then looks for an environment variable which can contain the configmap or secret data change hash.
+After that, Reloader gets the list of all `deployments`, `daemonsets` and `statefulset` and looks for above mentioned annotation for `ConfigMap`. If the annotation value contains the `ConfigMap` name, it then looks for an environment variable which can contain the `ConfigMap` or secret data change hash.
 
-### Environment Variable for Configmap
+### Environment Variable for ConfigMap
 
-If configmap name is foo then
+If `ConfigMap` name is foo then
 
 ```yaml
 STAKATER_FOO_CONFIGMAP
@@ -70,7 +70,7 @@ If Secret name is foo then
 STAKATER_FOO_SECRET
 ```
 
-If the environment variable is found then it gets its value and compares it with new configmap hash value. If old value in environment variable is different from new hash value then Reloader updates the environment variable. If the environment variable does not exist then it creates a new environment variable with latest hash value from configmap and updates the relevant `deployment`, `daemonset` or `statefulset`
+If the environment variable is found then it gets its value and compares it with new `ConfigMap` hash value. If old value in environment variable is different from new hash value then Reloader updates the environment variable. If the environment variable does not exist then it creates a new environment variable with latest hash value from `ConfigMap` and updates the relevant `deployment`, `daemonset` or `statefulset`
 
 Note: Rolling upgrade also works in the same way for secrets.
 
@@ -90,4 +90,4 @@ The output file can then be used to deploy Reloader in specific namespace.
 
 ## Compatibility With Helm Install and Upgrade
 
-Reloader has no impact on helm deployment cycle. Reloader only injects an environment variable in  `deployment`, `daemonset` or `statefulset`. The environment variable contains the SHA1 value of configmap's or secret's data. So  if a deployment is created using Helm and Reloader updates the deployment, then next time you upgrade the helm release, Reloader will do nothing except changing that environment variable value in `deployment` , `daemonset` or `statefulset`.
+Reloader has no impact on helm deployment cycle. Reloader only injects an environment variable in  `deployment`, `daemonset` or `statefulset`. The environment variable contains the SHA1 value of `ConfigMaps` or `Secrets` data. So  if a deployment is created using Helm and Reloader updates the deployment, then next time you upgrade the helm release, Reloader will do nothing except changing that environment variable value in `deployment` , `daemonset` or `statefulset`.

docs/Reloader-vs-ConfigmapController.md

@@ -1,11 +1,11 @@
 # Reloader vs ConfigmapController
 
-Reloader is inspired from [`Configmapcontroller`](https://github.com/fabric8io/configmapcontroller) but there are many ways in which it differs from `configmapController`. Below is the small comparison between these two controllers.
+Reloader is inspired from [`configmapcontroller`](https://github.com/fabric8io/configmapcontroller) but there are many ways in which it differs from `configmapcontroller`. Below is the small comparison between these two controllers.
 
-| Reloader                                                                                                                                                                                                                                                                                                                 | Configmap                                                                                                                                                                                                                                                          |
+| Reloader                                                                                                                                                                                                                                                                                                                 | ConfigMap                                                                                                                                                                                                                                                          |
 |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Reloader can watch both `secrets` and `configmaps`.                                                                                                                                                                                                                                                    | ConfigmapController can only watch changes in `configmaps`. It cannot detect changes in other resources like `secrets`.                                                                                                                                        |
-| Reloader can perform rolling upgrades on `deployments` as well as on `statefulsets` and `daemonsets`                                                                                                                                                                                                   | ConfigmapController can only perform rolling upgrades on `deployments`. It currently does not support rolling upgrades on `statefulsets` and `daemonsets`                                                                                                          |
-| Reloader provides both unit test cases and end to end integration test cases for future updates. So one can make sure that new changes do not break any old functionality.                                                                                                                                               | Currently there are not any unit test cases or end to end integration test cases in configmap controller. It add difficulties for any additional updates in configmap controller and one can not know for sure whether new changes breaks any old functionality or not. |
-| Reloader uses SHA1 to encode the change in configmap or secret. It then saves the SHA1 value in `STAKATER_FOO_CONFIGMAP` or `STAKATER_FOO_SECRET` environment variable depending upon where the change has happened. The use of SHA1 provides a concise 40 characters encoded value that is very less prone to collision. | Configmap controller uses `FABRICB_FOO_REVISION` environment variable to store any change in configmap controller. It does not encode it or convert it in suitable hash value to avoid data pollution in deployment.                                               |
-| Reloader allows you to customize your own annotation (for both Secrets and Configmaps) using command line flags | Configmap controller restricts you to only their provided annotation |
+| Reloader can watch both `Secrets` and `ConfigMaps`.                                                                                                                                                                                                                                                    | `configmapcontroller` can only watch changes in `ConfigMaps`. It cannot detect changes in other resources like `Secrets`.                                                                                                                                        |
+| Reloader can perform rolling upgrades on `deployments` as well as on `statefulsets` and `daemonsets`                                                                                                                                                                                                   | `configmapcontroller` can only perform rolling upgrades on `deployments`. It currently does not support rolling upgrades on `statefulsets` and `daemonsets`                                                                                                          |
+| Reloader provides both unit test cases and end to end integration test cases for future updates. So one can make sure that new changes do not break any old functionality.                                                                                                                                               | Currently there are not any unit test cases or end to end integration test cases in `configmap-controller`. It add difficulties for any additional updates in `configmap-controller` and one can not know for sure whether new changes breaks any old functionality or not. |
+| Reloader uses SHA1 to encode the change in `ConfigMap` or `Secret`. It then saves the SHA1 value in `STAKATER_FOO_CONFIGMAP` or `STAKATER_FOO_SECRET` environment variable depending upon where the change has happened. The use of SHA1 provides a concise 40 characters encoded value that is very less prone to collision. |  `configmap-controller` uses `FABRICB_FOO_REVISION` environment variable to store any change in `ConfigMap` controller. It does not encode it or convert it in suitable hash value to avoid data pollution in deployment.                                               |
+| Reloader allows you to customize your own annotation (for both `Secrets` and `ConfigMaps`) using command line flags | `configmap-controller` restricts you to only their provided annotation |

docs/Reloader-vs-k8s-trigger-controller.md

@@ -4,7 +4,7 @@ Reloader and k8s-trigger-controller are both built for same purpose. So there ar
 
 ## Similarities
 
-- Both controllers support change detection in configmap and secrets
+- Both controllers support change detection in `ConfigMaps` and `Secrets`
 - Both controllers support deployment `rollout`
 - Both controllers use SHA1 for hashing
 - Both controllers have end to end as well as unit test cases.

docs/index.md

@@ -4,9 +4,9 @@ Reloader can watch changes in `ConfigMap` and `Secret` and do rolling upgrades o
 
 These are the key features of Reloader:
 
-1. Restart pod in a `deployment` on change in linked/related configmap's or secret's
-1. Restart pod in a `daemonset` on change in linked/related configmap's or secret's
-1. Restart pod in a `statefulset` on change in linked/related configmap's or secret's
-1. Restart pod in a `rollout` on change in linked/related configmap's or secret's
+1. Restart pod in a `deployment` on change in linked/related `ConfigMaps` or `Secrets`
+1. Restart pod in a `daemonset` on change in linked/related `ConfigMaps` or `Secrets`
+1. Restart pod in a `statefulset` on change in linked/related `ConfigMaps` or `Secrets`
+1. Restart pod in a `rollout` on change in linked/related `ConfigMaps` or `Secrets`
 
 This site contains more details on how Reloader works. For an overview, please see the repository's [README file](https://github.com/stakater/Reloader/blob/master/README.md).

go.mod

@@ -1,13 +1,13 @@
 module github.com/stakater/Reloader
 
-go 1.24.1
+go 1.24.2
 
 require (
 	github.com/argoproj/argo-rollouts v1.8.2
-	github.com/openshift/api v0.0.0-20250331192611-6179881b782d
-	github.com/openshift/client-go v0.0.0-20250330132942-bc2e3c2af6e1
+	github.com/openshift/api v0.0.0-20250411135543-10a8fa583797
+	github.com/openshift/client-go v0.0.0-20250402181141-b3bad3b645f2
 	github.com/parnurzeal/gorequest v0.3.0
-	github.com/prometheus/client_golang v1.21.1
+	github.com/prometheus/client_golang v1.22.0
 	github.com/sirupsen/logrus v1.9.3
 	github.com/spf13/cobra v1.9.1
 	github.com/stretchr/testify v1.10.0
@@ -47,17 +47,17 @@ require (
 	github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect
 	github.com/pkg/errors v0.9.1 // indirect
 	github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 // indirect
-	github.com/prometheus/client_model v0.6.1 // indirect
+	github.com/prometheus/client_model v0.6.2 // indirect
 	github.com/prometheus/common v0.63.0 // indirect
 	github.com/prometheus/procfs v0.16.0 // indirect
 	github.com/smartystreets/goconvey v1.7.2 // indirect
 	github.com/spf13/pflag v1.0.6 // indirect
 	github.com/x448/float16 v0.8.4 // indirect
-	golang.org/x/net v0.38.0 // indirect
-	golang.org/x/oauth2 v0.28.0 // indirect
-	golang.org/x/sys v0.31.0 // indirect
-	golang.org/x/term v0.30.0 // indirect
-	golang.org/x/text v0.23.0 // indirect
+	golang.org/x/net v0.39.0 // indirect
+	golang.org/x/oauth2 v0.29.0 // indirect
+	golang.org/x/sys v0.32.0 // indirect
+	golang.org/x/term v0.31.0 // indirect
+	golang.org/x/text v0.24.0 // indirect
 	golang.org/x/time v0.11.0 // indirect
 	google.golang.org/protobuf v1.36.6 // indirect
 	gopkg.in/evanphx/json-patch.v4 v4.12.0 // indirect

go.sum

@@ -78,8 +78,12 @@ github.com/onsi/gomega v1.35.1 h1:Cwbd75ZBPxFSuZ6T+rN/WCb/gOc6YgFBXLlZLhC7Ds4=
 github.com/onsi/gomega v1.35.1/go.mod h1:PvZbdDc8J6XJEpDK4HCuRBm8a6Fzp9/DmhC9C7yFlog=
 github.com/openshift/api v0.0.0-20250331192611-6179881b782d h1:Vadr+xFmNi6RzWRTJtqMQJv1hiUe7as1rV2svKQffoY=
 github.com/openshift/api v0.0.0-20250331192611-6179881b782d/go.mod h1:yk60tHAmHhtVpJQo3TwVYq2zpuP70iJIFDCmeKMIzPw=
+github.com/openshift/api v0.0.0-20250411135543-10a8fa583797 h1:8x3G8QOZqo2bRAL8JFlPz/odqQECI/XmlZeRwnFxJ8I=
+github.com/openshift/api v0.0.0-20250411135543-10a8fa583797/go.mod h1:yk60tHAmHhtVpJQo3TwVYq2zpuP70iJIFDCmeKMIzPw=
 github.com/openshift/client-go v0.0.0-20250330132942-bc2e3c2af6e1 h1:9SaT0p5FsRDvz4STV1VnxMyfXXzAXv1PubZ0nczzDYk=
 github.com/openshift/client-go v0.0.0-20250330132942-bc2e3c2af6e1/go.mod h1:6a0Hj32FrkokKMeTck1uStmNV0wHYv46dHWAWER5iis=
+github.com/openshift/client-go v0.0.0-20250402181141-b3bad3b645f2 h1:bPXR0R8zp1o12nSUphN26hSM+OKYq5pMorbDCpApzDQ=
+github.com/openshift/client-go v0.0.0-20250402181141-b3bad3b645f2/go.mod h1:dT1cJyVTperQ53GvVRa+GZ27r02fDZy2k5j+9QoQsCo=
 github.com/parnurzeal/gorequest v0.3.0 h1:SoFyqCDC9COr1xuS6VA8fC8RU7XyrJZN2ona1kEX7FI=
 github.com/parnurzeal/gorequest v0.3.0/go.mod h1:3Kh2QUMJoqw3icWAecsyzkpY7UzRfDhbRdTjtNwNiUE=
 github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=
@@ -89,8 +93,12 @@ github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 h1:Jamvg5psRI
 github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
 github.com/prometheus/client_golang v1.21.1 h1:DOvXXTqVzvkIewV/CDPFdejpMCGeMcbGCQ8YOmu+Ibk=
 github.com/prometheus/client_golang v1.21.1/go.mod h1:U9NM32ykUErtVBxdvD3zfi+EuFkkaBvMb09mIfe0Zgg=
+github.com/prometheus/client_golang v1.22.0 h1:rb93p9lokFEsctTys46VnV1kLCDpVZ0a/Y92Vm0Zc6Q=
+github.com/prometheus/client_golang v1.22.0/go.mod h1:R7ljNsLXhuQXYZYtw6GAE9AZg8Y7vEW5scdCXrWRXC0=
 github.com/prometheus/client_model v0.6.1 h1:ZKSh/rekM+n3CeS952MLRAdFwIKqeY8b62p8ais2e9E=
 github.com/prometheus/client_model v0.6.1/go.mod h1:OrxVMOVHjw3lKMa8+x6HeMGkHMQyHDk9E3jmP2AmGiY=
+github.com/prometheus/client_model v0.6.2 h1:oBsgwpGs7iVziMvrGhE53c/GrLUsZdHnqNwqPLxwZyk=
+github.com/prometheus/client_model v0.6.2/go.mod h1:y3m2F6Gdpfy6Ut/GBsUqTWZqCUvMVzSfMLjcu6wAwpE=
 github.com/prometheus/common v0.63.0 h1:YR/EIY1o3mEFP/kZCD7iDMnLPlGyuU2Gb3HIcXnA98k=
 github.com/prometheus/common v0.63.0/go.mod h1:VVFF/fBIoToEnWRVkYoXEkq3R3paCoxG9PXP74SnV18=
 github.com/prometheus/procfs v0.16.0 h1:xh6oHhKwnOJKMYiYBDWmkHqQPyiY40sny36Cmx2bbsM=
@@ -131,8 +139,12 @@ golang.org/x/net v0.0.0-20200226121028-0de0cce0169b/go.mod h1:z5CRVTTTmAJ677TzLL
 golang.org/x/net v0.0.0-20201021035429-f5854403a974/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
 golang.org/x/net v0.38.0 h1:vRMAPTMaeGqVhG5QyLJHqNDwecKTomGeqbnfZyKlBI8=
 golang.org/x/net v0.38.0/go.mod h1:ivrbrMbzFq5J41QOQh0siUuly180yBYtLp+CKbEaFx8=
+golang.org/x/net v0.39.0 h1:ZCu7HMWDxpXpaiKdhzIfaltL9Lp31x/3fCP11bc6/fY=
+golang.org/x/net v0.39.0/go.mod h1:X7NRbYVEA+ewNkCNyJ513WmMdQ3BineSwVtN2zD/d+E=
 golang.org/x/oauth2 v0.28.0 h1:CrgCKl8PPAVtLnU3c+EDw6x11699EWlsDeWNWKdIOkc=
 golang.org/x/oauth2 v0.28.0/go.mod h1:onh5ek6nERTohokkhCD/y2cV4Do3fxFHFuAejCkRWT8=
+golang.org/x/oauth2 v0.29.0 h1:WdYw2tdTK1S8olAzWHdgeqfy+Mtm9XNhv/xJsY65d98=
+golang.org/x/oauth2 v0.29.0/go.mod h1:onh5ek6nERTohokkhCD/y2cV4Do3fxFHFuAejCkRWT8=
 golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
@@ -142,12 +154,18 @@ golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7w
 golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.31.0 h1:ioabZlmFYtWhL+TRYpcnNlLwhyxaM9kWTDEmfnprqik=
 golang.org/x/sys v0.31.0/go.mod h1:BJP2sWEmIv4KK5OTEluFJCKSidICx8ciO85XgH3Ak8k=
+golang.org/x/sys v0.32.0 h1:s77OFDvIQeibCmezSnk/q6iAfkdiQaJi4VzroCFrN20=
+golang.org/x/sys v0.32.0/go.mod h1:BJP2sWEmIv4KK5OTEluFJCKSidICx8ciO85XgH3Ak8k=
 golang.org/x/term v0.30.0 h1:PQ39fJZ+mfadBm0y5WlL4vlM7Sx1Hgf13sMIY2+QS9Y=
 golang.org/x/term v0.30.0/go.mod h1:NYYFdzHoI5wRh/h5tDMdMqCqPJZEuNqVR5xJLd/n67g=
+golang.org/x/term v0.31.0 h1:erwDkOK1Msy6offm1mOgvspSkslFnIGsFnxOKoufg3o=
+golang.org/x/term v0.31.0/go.mod h1:R4BeIy7D95HzImkxGkTW1UQTtP54tio2RyHz7PwK0aw=
 golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
 golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
 golang.org/x/text v0.23.0 h1:D71I7dUrlY+VX0gQShAThNGHFxZ13dGLBHQLVl1mJlY=
 golang.org/x/text v0.23.0/go.mod h1:/BLNzu4aZCJ1+kcD0DNRotWKage4q2rGVAg4o22unh4=
+golang.org/x/text v0.24.0 h1:dd5Bzh4yt5KYA8f9CJHCP4FB4D51c2c6JvN37xJJkJ0=
+golang.org/x/text v0.24.0/go.mod h1:L8rBsPeo2pSS+xqN0d5u2ikmjtmoJbDBT1b7nHvFCdU=
 golang.org/x/time v0.11.0 h1:/bpjEDfN9tkoN/ryeYHnv5hcMlc8ncjMcM4XBk5NWV0=
 golang.org/x/time v0.11.0/go.mod h1:CDIdPxbZBQxdj6cxyCIdrNogrJKMJ7pr37NYpMcMDSg=
 golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=