@checkstack/gitops-common 0.4.2 → 0.6.0

package/CHANGELOG.md

@@ -1,5 +1,81 @@
 # @checkstack/gitops-common
 
+## 0.6.0
+
+### Minor Changes
+
+- 9dcc848: Align workspace dependency versions and migrate React Router to v7.
+
+  BREAKING CHANGES (React Router v7): All frontend packages now depend on `react-router-dom@^7.16.0`. Previously the workspace declared four divergent ranges (`^6.20.0`, `^6.22.0`, `^7.1.1`, `^7.14.2`), which resolved both `react-router@6` and `react-router@7` into a single bundle. Everything is now unified on v7. The public imports the app uses (`BrowserRouter`, `Routes`, `Route`, `Link`, `NavLink`, `MemoryRouter`, `useNavigate`, `useParams`, `useSearchParams`, `useLocation`) are unchanged between v6 and v7, so no source rewrites were required - but any out-of-tree plugin still on react-router v6 should upgrade to v7 (see the React Router v6 -> v7 upgrade guide) to share the host's single router instance via the import map.
+
+  Other unified ranges (no API change): `react` -> `^18.3.1`, the `@orpc/*` family (`contract`, `server`, `client`, `tanstack-query`, `openapi`, `zod`) -> `^1.14.4`, and `better-auth` -> `^1.6.13`.
+
+  Removed the pre-rename `@orpc/react-query` leftover from `@checkstack/frontend-api`; its `createRouterUtils` / `RouterUtils` / `ProcedureUtils` now come from `@orpc/tanstack-query` (the package already in use).
+
+  Stale in-range runtime deps pulled up to current published versions: `hono` `^4.12.23`, `@tanstack/react-query` (+devtools) `^5.100.14`, `date-fns` `^4.4.0`, `jose` `^6.2.3`, `tar` `^7.5.16`, `semver` `^7.8.1`, `@xyflow/react` `^12.11.0`.
+
+### Patch Changes
+
+- Updated dependencies [9dcc848]
+- Updated dependencies [9dcc848]
+- Updated dependencies [9dcc848]
+- Updated dependencies [9dcc848]
+  - @checkstack/common@0.13.0
+  - @checkstack/secrets-common@0.2.0
+
+## 0.5.0
+
+### Minor Changes
+
+- b995afb: Surface per-variant config documentation for the `Automation` GitOps kind.
+
+  The GitOps editor and Kind Registry Browser now show the right config schema
+  for each automation trigger and provider action when authoring an
+  `Automation` YAML, mirroring how the `Healthcheck` kind documents its
+  strategy/collector configs:
+
+  - `triggers[].config` — one entry per registered trigger that declares a
+    `configSchema`, conditioned on the chosen `triggers[].event`.
+  - `actions[].config` — one entry per registered provider action,
+    conditioned on the chosen `actions[].action`.
+
+  New plugin-author contract on the entity kind registry:
+
+  - `@checkstack/gitops-common` / `@checkstack/gitops-backend`: add
+    `EntityKindRegistry.registerSpecSchemaDocumentationProvider(provider)`. The
+    provider is a thunk invoked on every `describeKinds()` (i.e. each time the
+    kind-browser RPC is queried), so the docs it returns reflect the current
+    state of whatever it reads — order-independent.
+
+  Why a lazy provider (and not the existing eager
+  `registerSpecSchemaDocumentation`): unlike Healthcheck, whose
+  strategy/collector registries are core services fully populated before any
+  plugin's `afterPluginsReady`, the automation trigger/action registries are
+  filled by other plugins across their `init` / `afterPluginsReady` phases with
+  no guaranteed ordering. Several plugins (catalog/maintenance/notification)
+  register their provider actions in their own `afterPluginsReady`, so the
+  previous one-shot eager registration snapshotted a half-populated (often
+  empty) registry and the Automation kind's "Additional Schemas" came up empty.
+  automation-backend now registers a provider instead, so trigger/action config
+  docs always reflect the fully-populated registries.
+
+  Documentation-only surface; no runtime reconcile behaviour changes.
+
+### Patch Changes
+
+- 270ef29: Internal refactor: re-export the secret-name and `${{ secrets.NAME }}` template
+  helpers (`SECRET_NAME_REGEX`, `secretNameSchema`, `SECRET_TEMPLATE_REGEX`,
+  `secretTemplateSchema`, `collectSecretNames`, `SecretName`) from
+  `@checkstack/secrets-common`, which is now the single canonical source. No public
+  API or behavior change for consumers.
+- Updated dependencies [b995afb]
+- Updated dependencies [270ef29]
+- Updated dependencies [270ef29]
+- Updated dependencies [270ef29]
+- Updated dependencies [270ef29]
+- Updated dependencies [b995afb]
+  - @checkstack/secrets-common@0.1.0
+
 ## 0.4.2
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/gitops-common",
-  "version": "0.4.2",
+  "version": "0.6.0",
   "license": "Elastic-2.0",
   "type": "module",
   "exports": {
@@ -9,14 +9,15 @@
     }
   },
   "dependencies": {
-    "@checkstack/common": "0.11.0",
-    "@orpc/contract": "^1.13.14",
+    "@checkstack/common": "0.12.0",
+    "@checkstack/secrets-common": "0.1.0",
+    "@orpc/contract": "^1.14.4",
     "zod": "^4.2.1"
   },
   "devDependencies": {
     "typescript": "^5.7.2",
     "@checkstack/tsconfig": "0.0.7",
-    "@checkstack/scripts": "0.3.3"
+    "@checkstack/scripts": "0.3.4"
   },
   "scripts": {
     "typecheck": "tsgo -b",

package/src/entity-kind-registry.ts

@@ -154,6 +154,26 @@ export interface SpecSchemaDocumentation {
   }>;
 }
 
+/**
+ * A lazy provider of spec-schema documentation. Invoked by the registry at
+ * describe time (when the kind-browser RPC is queried), NOT at registration
+ * time — so the returned entries reflect whatever state the provider reads
+ * at that moment.
+ *
+ * Use this when the documentation derives from registries that are populated
+ * across plugin lifecycle phases with no guaranteed ordering (e.g. the
+ * automation trigger/action registries, whose entries are contributed by
+ * other plugins in their `init` / `afterPluginsReady`). A one-shot eager
+ * `registerSpecSchemaDocumentation` call would snapshot a half-populated
+ * registry; a provider re-reads it every time.
+ */
+export type SpecSchemaDocumentationProvider = () => Array<
+  {
+    apiVersion: string;
+    kind: string;
+  } & SpecSchemaDocumentation
+>;
+
 /**
  * The registry interface exposed via the Extension Point.
  * Plugins call these methods during their `register()` phase.
@@ -174,4 +194,15 @@ export interface EntityKindRegistry {
       kind: string;
     } & SpecSchemaDocumentation,
   ): void;
+
+  /**
+   * Register a lazy provider of spec-schema documentation. The provider is
+   * invoked each time the kind registry is described, so the entries it
+   * returns always reflect the current state of whatever it reads. Prefer
+   * this over {@link registerSpecSchemaDocumentation} when the docs derive
+   * from registries populated with no guaranteed ordering.
+   */
+  registerSpecSchemaDocumentationProvider(
+    provider: SpecSchemaDocumentationProvider,
+  ): void;
 }

package/src/index.ts

@@ -24,6 +24,7 @@ export {
   type EntityKindRegistry,
   type ReconcileContext,
   type SpecSchemaDocumentation,
+  type SpecSchemaDocumentationProvider,
 } from "./entity-kind-registry";
 export { gitopsAccess, gitopsAccessRules } from "./access";
 export { gitopsRoutes } from "./routes";

package/src/secret-field.ts

@@ -1,82 +1,16 @@
-import { z } from "zod";
-
 /**
- * Valid characters for a secret name: letters, digits, underscores, and hyphens.
- * This must stay in sync with the capture group in {@link SECRET_TEMPLATE_REGEX}.
- */
-export const SECRET_NAME_REGEX = /^[a-zA-Z][a-zA-Z0-9_-]*$/;
-
-/**
- * Zod schema for validating secret names at creation time.
- * Ensures the name can be referenced via `${{ secrets.NAME }}`.
- */
-export const secretNameSchema = z
-  .string()
-  .min(1)
-  .max(63)
-  .regex(
-    SECRET_NAME_REGEX,
-    "Secret names must start with a letter and contain only letters, digits, underscores, or hyphens",
-  );
-
-/**
- * Regex matching ${{ secrets.NAME }} template expressions in strings.
- * Captures the secret name in group 1.
- * Supports multiple occurrences within a single string value.
- *
- * @example
- * "${{ secrets.DB_PASS }}" → captures "DB_PASS"
- * "postgres://u:${{ secrets.PASS }}@${{ secrets.HOST }}/db" → captures "PASS", "HOST"
- */
-export const SECRET_TEMPLATE_REGEX =
-  /\$\{\{\s*secrets\.([a-zA-Z0-9_-]+)\s*\}\}/g;
-
-/**
- * Zod schema for validating secret template strings.
- * Matches strings containing at least one ${{ secrets.NAME }} pattern.
- */
-export const secretTemplateSchema = z.string().regex(
-  /\$\{\{\s*secrets\.[a-zA-Z0-9_-]+\s*\}\}/,
-  "Must contain a ${{ secrets.NAME }} reference",
-);
-
-/**
- * Recursively walks a value and collects all unique secret names
- * referenced via ${{ secrets.NAME }} patterns in string values.
+ * Secret-name + `${{ secrets.NAME }}` template helpers.
  *
- * @returns Deduplicated array of secret names found in the value tree
+ * The canonical definitions live in `@checkstack/secrets-common` (the secrets
+ * platform owns this concern). This module re-exports them so existing
+ * `@checkstack/gitops-common` consumers keep their import paths unchanged and
+ * there is a single source of truth (no drift between two copies).
  */
-export function collectSecretNames(params: { value: unknown }): string[] {
-  const names = new Set<string>();
-  collectFromValue(params.value, names);
-  return [...names];
-}
-
-function collectFromValue(value: unknown, names: Set<string>): void {
-  if (value === null || value === undefined) {
-    return;
-  }
-
-  if (typeof value === "string") {
-    // Reset regex lastIndex for safe reuse (global flag)
-    SECRET_TEMPLATE_REGEX.lastIndex = 0;
-    let match: RegExpExecArray | null;
-    while ((match = SECRET_TEMPLATE_REGEX.exec(value)) !== null) {
-      names.add(match[1]);
-    }
-    return;
-  }
-
-  if (Array.isArray(value)) {
-    for (const item of value) {
-      collectFromValue(item, names);
-    }
-    return;
-  }
-
-  if (typeof value === "object") {
-    for (const val of Object.values(value)) {
-      collectFromValue(val, names);
-    }
-  }
-}
+export {
+  SECRET_NAME_REGEX,
+  secretNameSchema,
+  SECRET_TEMPLATE_REGEX,
+  secretTemplateSchema,
+  collectSecretNames,
+  type SecretName,
+} from "@checkstack/secrets-common";

package/tsconfig.json

@@ -6,6 +6,9 @@
   "references": [
     {
       "path": "../common"
+    },
+    {
+      "path": "../secrets-common"
     }
   ]
 }