@leverege/build-tools 2.113.1 → 2.113.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leverege/build-tools",
-  "version": "2.113.1",
+  "version": "2.113.4",
   "description": "A collection of build / support tools for Leverege developers",
   "main": "index.js",
   "repository": {
@@ -97,18 +97,18 @@
     "glob": "^13.0.6",
     "googleapis": "^173.0.0",
     "handlebars": "^4.7.9",
-    "ignore": "^7.0.5",
+    "ignore": "^7.0.6",
     "inquirer": "^14.0.2",
     "js-yaml": "^4.2.0",
     "jsdoc": "^4.0.5",
     "ms": "^2.1.3",
     "npm-registry-fetch": "^20.0.1",
     "ora": "^9.4.1",
-    "p-limit": "^7.3.0",
+    "p-limit": "^7.3.1",
     "package-up": "^5.0.0",
     "readline-sync": "^1.4.10",
     "semver": "^7.8.5",
-    "shell-quote": "^1.9.0",
+    "shell-quote": "^1.10.0",
     "simple-git": "^3.36.0",
     "sloc": "^0.3.2",
     "superstruct": "^2.0.2",

package/src/Utils.mjs

@@ -599,9 +599,12 @@ export const parseHelmChart = async ( helmroot = './helm' ) => {
     
     depsOutOfSync = mismatches.length > 0
 
-    // One final check - if the helm/charts dir is missing then we also need to update dependencies
+    // Check if the helm/charts dir is missing or tarballs don't match locked versions
     if ( hasDependencies && !chartFiles.includes( 'charts' ) ) {
       depsOutOfSync = true
+    } else if ( !depsOutOfSync ) {
+      const lockedTarballs = chartLock.dependencies.map( d => `charts/${d.name}-${d.version}.tgz` )
+      depsOutOfSync = lockedTarballs.some( t => !chartFiles.includes( t ) )
     }
   }
   /* eslint-enable security/detect-non-literal-fs-filename */

package/src/circle-orb-it/circle-npm.yml

@@ -1,7 +1,7 @@
 version: 2.1
 
 orbs:
-  leverege: leverege/circle-nodejs-ci@2.2.1
+  leverege: leverege/circle-nodejs-ci@2.2.2
 
 workflows:
   build-and-verify:

package/src/circle-orb-it/circle-orb-it.mjs

@@ -18,7 +18,7 @@ import {
   warning,
 } from '../Utils.mjs'
 
-const ORB_VERSION = '2.2.1' // Keep this in sync with the versions in circle-npm.yml and circle-yarn.yml
+const ORB_VERSION = '2.2.2' // Keep this in sync with the versions in circle-npm.yml and circle-yarn.yml
 const CIRCLE_DIR = '.circleci'
 const CIRCLE_YML = `${CIRCLE_DIR}/config.yml`
 const CIRCLE_NPM_TEMPLATE = path.join( BUILD_TOOLS_ROOT, 'circle-orb-it', 'circle-npm.yml' )

package/src/circle-orb-it/circle-yarn.yml

@@ -1,7 +1,7 @@
 version: 2.1
 
 orbs:
-  leverege: leverege/circle-nodejs-ci@2.2.1
+  leverege: leverege/circle-nodejs-ci@2.2.2
 
 workflows:
   build-and-verify:

package/src/helm-charts/cnpg-operator/helmup.plugin

@@ -5,6 +5,8 @@
 OPVER="1.26.1"      # 10/08/2025
 BARMAN_VER="0.11.0"
 
+createNamespaceIfNeeded cnpg-system
+
 # --- CNPG operator ---
 kubectl apply --server-side -f \
   "https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-${OPVER%.*}/releases/cnpg-${OPVER}.yaml" \

package/src/helm-charts/elasticsearch8/elasticsearch-local.yaml

@@ -69,63 +69,67 @@ x-esSchduling: &esScheduling
     value: "true"
     effect: "NoSchedule"
 
-# coord nodes needed a heapSize and memory boost
+# Always set explicit heapSize for all node types. Bitnami defaults to 128m
+# which is too small for any real workload and will cause circuit breaker trips
+# under load. Scale these up per-cluster based on node pool size and workload.
+# Rule of thumb: memory limit >= 2x heapSize to cover off-heap overhead (metaspace,
+# code cache, thread stacks). Setting limit == heapSize will pin the container at 100%.
+#
 coordinating:
   <<: *esScheduling
   replicaCount: 3
-  heapSize: 384m
+  heapSize: 512m
   resources:
     limits:
       cpu: 750m
-      memory: 2Gi
+      memory: 1Gi
       ephemeral-storage: 2Gi
     requests:
-      cpu: 500m
-      memory: 512Mi
+      cpu: 250m
+      memory: 768Mi
       ephemeral-storage: 50Mi
 
 data:
   <<: *esScheduling
   replicaCount: 3
+  heapSize: 1024m
   resources:
     limits:
       cpu: 750m
       ephemeral-storage: 2Gi
-      memory: 8Gi # def was 1536Mi
+      memory: 2Gi
     requests:
       cpu: 500m
       ephemeral-storage: 50Mi
-      memory: 4Gi
+      memory: 1536Mi
   persistence:
     enabled: true
-    size: 64Gi
+    size: 20Gi # scale up based on expected data volume
 
 ingest:
   <<: *esScheduling
   replicaCount: 3
-  #resourcesPreset: "medium"
+  heapSize: 256m
   resources:
     limits:
       cpu: 750m
-      ephemeral-storage: 4Gi
-      memory: 1536Mi
+      ephemeral-storage: 2Gi
+      memory: 512Mi
     requests:
-      cpu: 500m
-      ephemeral-storage: 100Mi
-      memory: 1024Mi
-  # no default resources specified
+      cpu: 250m
+      ephemeral-storage: 50Mi
+      memory: 384Mi
 
 master:
   <<: *esScheduling
   replicaCount: 3
-# resources: # example from the bitnami chart
-#   ## Example:
-#   ## limits:
-#   ##    cpu: 500m
-#   ##    memory: 1Gi
-#   limits: {}
-#   ## Examples:
-#   ## requests:
-#   ##    cpu: 250m
-#   ##    memory: 256Mi
-#   requests: {}
+  heapSize: 256m
+  resources:
+    limits:
+      cpu: 500m
+      ephemeral-storage: 2Gi
+      memory: 768Mi
+    requests:
+      cpu: 250m
+      ephemeral-storage: 50Mi
+      memory: 512Mi

package/src/helm-charts/prom-operator/README-HPA.md

@@ -0,0 +1,46 @@
+# 📌 Optional HPA Metrics
+
+## 🎯 Why we do this
+We maintain a **single, consistent Prometheus baseline** for all clusters. Certain metrics — like GPU duty cycle percent or PubSub subscription backlog — **do not exist in every cluster**. If we deploy scrape configs or custom adapter rules for optional metrics globally, we risk:
+
+- Empty series queries → scrape flapping.
+- Duplicate or rejected samples.
+- Confusing "phantom target down" or noisy alerts.
+
+## ✅ How we solve it
+- **Baseline:**  
+  Our base `prom-operator` Helm chart and Prometheus Adapter configs **do not contain cluster-specific custom metrics** by default.
+  - running _helmup prom-operator_ will deploy prometheus with the standard exporters
+
+- **Specialized clusters:**  
+  When clusters require optional HPA metrics (e.g., GPU nodes, PubSub-based scaling), we deploy those configs with a separate, explicit step:
+  - post helmup run _./prom-operator/hpa-metrics.sh_ to apply the prometheus-adapter.yaml and any cluster-specific PrometheusRules
+
+## 🔐 Benefits
+- Zero config drift: our core charts stay generic and versioned.
+- No surprise scrape issues or prometheus TSDB rejects in clusters that don’t expose those metrics.
+- Clusters only carry the scrape configs they can actually fulfill.
+
+## 🛠️ Operational tips
+- **Add custom metrics only when a cluster truly provides them.**
+- Keep custom metric configs organized in a clear, dedicated folder alongside `hpa-metrics.sh`.
+- When adding new clusters, verify whether specialized metrics are needed and apply them if so.
+- When a metric type becomes universal, promote it to the baseline and gate it behind a feature flag.
+
+## ⚙️ Metric types
+
+**Custom metrics** (`custom.metrics.k8s.io`) — metrics tied to a Kubernetes object (pod, namespace).
+Used with `type: Pods` or `type: Object` in HPA specs. Example: `gpu_duty_cycle_percent`.
+
+**External metrics** (`external.metrics.k8s.io`) — metrics from outside Kubernetes (GCP, cloud services).
+Used with `type: External` in HPA specs. Example: PubSub subscription backlog.
+
+## ⚙️ Example
+> Optional HPA metrics are installed by running:
+>
+> ```bash
+> ./prom-operator/hpa-metrics.sh
+> ```
+>
+> after the base Prometheus stack is installed. Cluster-specific rules (e.g., PubSub
+> subscription IDs) are added to `prometheus-adapter.yaml` in the cluster’s branch.

package/src/helm-charts/prom-operator/{gpu-hpa-metrics.sh → hpa-metrics.sh}

@@ -1,9 +1,17 @@
 #!/bin/bash
 
+set -euo pipefail
+
+# When sourced by helmup these are already set; provide standalone defaults.
+NS="${NS:---namespace prometheus}"
+HELM_WHAT="${HELM_WHAT:-}"
+command -v showInstalling >/dev/null 2>&1 || showInstalling() { echo "==> Installing: $*"; }
+
 # https://artifacthub.io/packages/helm/prometheus-community/prometheus-adapter
 showInstalling "The Prometheus Adapter (prom-operator custom HPA metrics)"
-[ -z "$PROMETHEUS_ADAPTER_CHART_VERSION" ] && PROMETHEUS_ADAPTER_CHART_VERSION="4"
-helm upgrade $NS --install prometheus-adapter prometheus-community/prometheus-adapter \
+[ -z "${PROMETHEUS_ADAPTER_CHART_VERSION:-}" ] && PROMETHEUS_ADAPTER_CHART_VERSION="5.3.0"
+OCI_CHART="oci://ghcr.io/prometheus-community/charts/prometheus-adapter"
+helm upgrade $NS --install prometheus-adapter $OCI_CHART \
                  --values prom-operator/prometheus-adapter.yaml \
                  --version $PROMETHEUS_ADAPTER_CHART_VERSION $HELM_WHAT
 

package/src/helm-charts/prom-operator/prometheus-adapter.yaml

@@ -4,7 +4,19 @@ prometheus:
   url: "http://prometheus-operated.prometheus.svc"
   port: 9090
 
+# Stackdriver-exporter samples carry Cloud Monitoring's delayed timestamps
+# (80-200s behind wall clock). With the chart default of 1m the series
+# fall outside the discovery window intermittently, leaving the external
+# metrics registry empty. 10m covers the lag with margin.
+metricsRelistInterval: 10m
+
 rules:
+  # The chart's upstream default rule set matches ~100k+ series on a
+  # Prometheus loaded with stackdriver metrics. The 1m relist crawling
+  # that index wedges the adapter registry (empty listings, handler
+  # timeouts, high idle CPU). Nothing here consumes those custom metrics —
+  # resource HPAs use metrics-server. Only the explicit rules below are served.
+  default: false
   custom:
     - seriesQuery: 'gpu_duty_cycle_percent{namespace!="",pod!=""}'
       resources:

package/src/helm-charts/prom-operator/rules/cnpg-rules.yaml

@@ -117,7 +117,7 @@ spec:
 #       severity: critical
 #     annotations:
 #       summary: Postgresql commit rate low (instance {{ $labels.instance }})
-#       description: "Postgresql seems to be processing very few transactions\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"    - alert: PostgresqlCommitRateLow
+#       description: "Postgresql seems to be processing very few transactions\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"
 #     expr: rate(cnpg_pg_stat_database_xact_commit[1m]) < 10
 #     for: 2m
 #     labels:

package/src/helm-charts/velero/helmup.plugin

@@ -6,7 +6,7 @@ showInstalling "Velero Backup System"
 # the version of the locally installed velero client application.
 #
 VELERO_CHART_VERSION="12.0.3"
-EXPECTED_CLIENT_VERSION="v1.18.1"
+EXPECTED_CLIENT_VERSION="v1.18.2"
 
 addHelmRepo vmware-tanzu https://vmware-tanzu.github.io/helm-charts
 

package/src/helmup.sh

@@ -52,6 +52,9 @@ for arg in "$@"; do
     --mutate)
       MUTATE_DEPLOYMENT=1
       ;;
+    --conflicts)
+      export FORCE_CONFLICTS=1
+      ;;
     --help|-h)
       giveHelp && exit 0
       ;;

package/src/hook-and-release/Config.mjs

@@ -235,7 +235,9 @@ export default class Config {
     fs.writeFileSync( `${harDir}/config.json`, JSON.stringify( CONFIG_CONTENT, null, 2 ), 'utf8' )
 
     const makeHarHookScript = async ( harScript ) => {
-      const SCRIPT_CONTENT = 'hook-and-release'
+      const SCRIPT_CONTENT = `#!/bin/sh
+PATH="$(git rev-parse --show-toplevel)/node_modules/.bin:$PATH"
+hook-and-release`
 
       fs.writeFileSync( harScript, SCRIPT_CONTENT, 'utf8' )
       fs.chmodSync( harScript, 0o750 )

package/src/init-my-chart/Chart.yaml.hbs

@@ -6,5 +6,5 @@ apiVersion: v2
 icon: https://raw.githubusercontent.com/kubernetes/kubernetes/master/logo/logo.svg
 dependencies:
   - name: leverege
-    version: "^1.3.0"
+    version: "^1.3.1"
     repository: "oci://us-docker.pkg.dev/leverege-registry/base-charts"

package/src/init-my-chart/values.yaml.hbs

@@ -39,7 +39,6 @@ partOf: {{hbsPartOf}} # leverege-stack or project-x - OPTIONAL
 # name, http + metrics) and a companion <fullname>-loadbalancer service is rendered
 # to handle external traffic (http only, no metrics exposure).
 service:
-  project_id: set-in-values-yaml
   preemptible: {{hbsServicePreemptible}} # true or false - OPTIONAL
   type: ClusterIP
 

package/src/push-my-chart.mjs

@@ -6,6 +6,7 @@ import { Command } from 'commander'
 import {
   debug,
   errorExit,
+  establishOauthAccess,
   log,
   parseHelmChart,
   proceed,
@@ -47,6 +48,7 @@ if ( !chartAppVersion.startsWith( 'v' ) ) {
 if ( depsOutOfSync || opts.refreshDeps ) {
   try {
     log( chalk.yellow.bold( '\nChart dependedencies are out of sync - updating...\n' ) )
+    await establishOauthAccess()
     await shellCmd( 'helm dependency update ./helm', { stdio : 'inherit' } )
   } catch ( error ) {
     errorExit( error )

package/src/refresh-npm-token.mjs

@@ -75,6 +75,19 @@ ${chalk.bold( 'Secret Manager Secrets (required)' )}
 ${chalk.bold( 'Environment Variables (optional)' )}
 
   ${chalk.bold( 'REFRESH_NPM_PROJECT' )}  ${chalk.green( 'may be used in lieu of --project' )}
+
+${chalk.bold( 'Manually Bootstraping the Token' )}
+  ${chalk.green( `
+  There may be times when a token is expired, lost or a new developer needs
+  to seed their ~/.npmrc file for the first time. Help a brother out and let
+  them know to run this command to fetch the current npmrc file:
+
+    gcloud secrets versions access latest \\
+         --secret=REFRESH_NPM_NPMRC       \\
+         --project=leverege-registry > ~/.npmrc
+
+  Note, ^^that command will need a different --project name for non-leverege
+  developers.` )}
 ` )
   .parse()
 

package/src/service-man/config/iam-roles/leveregeStorageObjectAdmin.json

@@ -2,6 +2,7 @@
   "description": "Leverege read / write access to Storage Objects",
   "includedPermissions": [
     "storage.buckets.create",
+    "storage.buckets.delete",
     "storage.buckets.get",
     "storage.buckets.getIamPolicy",
     "storage.buckets.list",

package/src/helm-charts/prom-operator/README-GPU.md

@@ -1,42 +0,0 @@
-# 📌 Optional Prometheus Custom Metrics
-
-## 🎯 Why we do this
-We maintain a **single, consistent Prometheus baseline** for all clusters. Certain metrics — like GPU duty cycle percent or other node-type-specific stats — **do not exist in every cluster**. If we deploy scrape configs or custom adapter rules for optional metrics globally, we risk:
-
-- Empty series queries → scrape flapping.
-- Duplicate or rejected samples.
-- Confusing "phantom target down" or noisy alerts.
-
-## ✅ How we solve it
-- **Baseline:**  
-  Our base `prom-operator` Helm chart and Prometheus Adapter configs **do not contain cluster-specific custom metrics** by default.
-  - running _helmup prom-operator_ will deploy prometheus with the standard exporters
-
-- **Specialized nodes:**  
-  When clusters require optional metrics (e.g., GPU nodes, special sensors, vendor-specific exporters), we deploy those configs with a separate, explicit step:
-  - post helmup run _./prom-operator/gpu-hpa-metrics.sh_ to apply the prometheus-adapter.yaml which contains the GPU scraper
-
-## 🔐 Benefits
-- Zero config drift: our core charts stay generic and versioned.
-- No surprise scrape issues or prometheus TSDB rejects in clusters that don’t expose those metrics.
-- Clusters only carry the scrape configs they can actually fulfill.
-
-## 🛠️ Operational tips
-- **Add custom metrics only when a cluster’s node pool truly provides them.**
-- Keep custom metric configs organized in a clear, dedicated folder (`gpu-adapter-values.yaml`, `gpu-metrics.yaml`, etc.)
-- When adding new clusters, verify whether specialized nodes are present and apply the custom metrics if needed.
-- When GPU adoption grows, we can promote the configs to the baseline and gate them behind a `gpuEnabled` flag.
-
-## ⚙️ Example
-> Our `gpu_duty_cycle_percent` metric is installed *only* on clusters with GPU node pools.  
-> This is done by running:
->
-> ```bash
-> ./prom-operator/gpu-hpa-metrics.sh
-> ```
-> or directly with helm:
-> ```bash
-> helm upgrade prometheus-adapter -f gpu-adapter-values.yaml
-> ```
->
-> after the base Prometheus stack is installed.