gitops_task_helpers.ts

Shared initialization logic for all gitops tasks.

resolve_gitops_repos() loads the config's registry keys, runs repos status <keys…> --json, and resolves each key to its checkout. get_gitops_ready() then loads each repo's library as its working tree sits. gate_publish_readiness() is the read-only gate a real publish runs before its prompt, and log_readiness_block() the diagnostics' report of repos not at rest (both over repo_readiness.ts).

Used by: gitops_sync.task.ts, gitops_analyze.task.ts, gitops_plan.task.ts, gitops_publish.task.ts, gitops_validate.task.ts, and gitops_run.task.ts.

Accepts repos_ops to support testing via the operations pattern (see operations.ts for dependency injection details).

view source

Declarations
#

6 declarations

gate_publish_readiness
#

gitops_task_helpers.ts view source

(options: GatePublishReadinessOptions): Promise<void> import {gate_publish_readiness} from '@fuzdev/fuz_repos/gitops_task_helpers.js';

The readiness gate gitops_publish --wetrun runs before its confirmation prompt: fetches every npm repo from origin (`repos status <keys…> --fetch --json`, which writes remote-tracking refs and nothing else) and refuses unless each is ready (check_publish_readiness) — on its registry branch, clean, idle, in sync with origin or ahead of it, fetched without error, no other live session in its checkout, and nothing left to a person. Each ready repo ahead of origin is logged, saying whether its release push carries those commits or they stay unpushed.

Every npm repo, not just those the plan publishes or rewrites: the plan reads each one's working tree (changesets, versions, dependency ranges), so a repo off its branch or behind origin can hide a changeset and leave the plan wrong about what to publish. Changes nothing.

options

the loaded repos, the --registry if any, the package names the plan publishes, a logger, and the repos runner

returns

Promise<void>

throws

  • TaskError - if `repos status` fails or any npm repo isn't ready, naming each problem and its fix

GatePublishReadinessOptions
#

gitops_task_helpers.ts view source

GatePublishReadinessOptions import type {GatePublishReadinessOptions} from '@fuzdev/fuz_repos/gitops_task_helpers.js';

local_repos

The loaded repos; the npm ones are gated.

type readonly LocalRepo[]

registry?

A repos.toml to use instead of the one repos finds walking up from the cwd.

type string

publishing?

The package names the plan publishes, to say whether a repo's commits ahead of origin go out with its release or stay unpushed.

type ReadonlySet<string>

log?

type Logger

repos_ops?

type ReposOperations

get_gitops_ready
#

gitops_task_helpers.ts view source

(options: ResolveGitopsReposOptions): Promise<{ local_repos: LocalRepo[]; }> import {get_gitops_ready} from '@fuzdev/fuz_repos/gitops_task_helpers.js';

Central initialization function for the gitops tasks that load libraries: resolves the config's repos through repos status (resolve_gitops_repos), then loads each repo's library as its working tree sits (local_repos_load). Moves no ref; gro caches each library at .gro/library.json in its repo, at a clean commit.

options

returns

Promise<{ local_repos: LocalRepo[]; }>

the loaded repos, in config order

throws

  • TaskError - if resolving the repos or loading them fails

log_readiness_block
#

gitops_task_helpers.ts view source

(local_repos: readonly LocalRepo[], log: Logger, now?: number): void import {log_readiness_block} from '@fuzdev/fuz_repos/gitops_task_helpers.js';

Logs the diagnostics' readiness block as warnings (stderr, so a `--format json or markdown` document on stdout stays clean): each npm repo not at rest, and how. Logs nothing when every one is at rest. Reads the entries repos status already reported, from local refs.

local_repos

the loaded repos; the npm ones are reported

type readonly LocalRepo[]

log

where the warnings go

type Logger

now

the current time in unix seconds (defaults to the clock)

type number
default Math.floor(Date.now() / 1000)

returns

void

resolve_gitops_repos
#

gitops_task_helpers.ts view source

(options: ResolveGitopsReposOptions): Promise<{ config_path: string; gitops_config: { repos: string[]; }; report: { version: 18; workspace: string; registry: string; fetched: boolean; sessions: { ...; } | { ...; }; entries: { ...; }[]; unregistered: ({ ...; } | ... 4 more ... | { ...; })[] | null; }; local_repo_paths: LocalRepoPath[]; }> import {resolve_gitops_repos} from '@fuzdev/fuz_repos/gitops_task_helpers.js';

Resolves the gitops config's repos through repos status: loads the config's registry keys, reports on them, and resolves each to its checkout, in config order. Reads nothing but git state and writes nothing.

options

returns

Promise<{ config_path: string; gitops_config: { repos: string[]; }; report: { version: 18; workspace: string; registry: string; fetched: boolean; sessions: { kind: "available"; unscoped: { pid: number; cwd: string; worktree: string | null; process_cwd: string | null; source: "session_file" | "roster_worker"; }[]; } | { ...;...>

the config, the repos status report, and each repo's path and entry

throws

  • TaskError - if the config is missing, invalid, or lists no repos, `repos status` fails, or any configured repo is unknown, a reference, missing, not a repo, unprobed, or private under a public `host`

ResolveGitopsReposOptions
#

gitops_task_helpers.ts view source

ResolveGitopsReposOptions import type {ResolveGitopsReposOptions} from '@fuzdev/fuz_repos/gitops_task_helpers.js';

config

Path to the gitops config, absolute or relative to the cwd.

type string

registry?

A repos.toml to use instead of the one repos finds walking up from the cwd.

type string

host?

The package whose generated data the run writes; when it's public, a private repo in the config fails the resolve.

type { name: string; private: boolean; }

log?

type Logger

repos_ops?

type ReposOperations

Depends on
#

Imported by
#