Skip to content

BaseHarbor v0.4.3

Choose a tag to compare

View all tags
@github-actions github-actions released this 18 Sep 20:56
· 762 commits to main since this release
v0.4.3
7ab0ed2

BaseHarbor v0.4.3

BaseHarbor v0.4.3 makes repository understanding a first-class, deterministic capability and establishes the open provider-integration contract that later BaseHarbor integrations will follow.

The release is intentionally compatibility-preserving: Manifest v1 and the current Compose lifecycle remain unchanged.

What changed

Developers can now inspect an application repository without creating or changing anything:

baha app inspect .
baha app inspect . --json

The shared inspection core collects evidence from common Compose/Dockerfile files, dependency manifests, environment-variable names, source imports, configuration files, published ports and health checks.

Findings have explicit confidence:

  • Detected — strong evidence that can safely feed non-interactive initialization;
  • Suggested — useful evidence that still requires confirmation;
  • Possible — weak evidence that BaseHarbor reports but never auto-selects.

Guided baha app init now reuses this same shared core rather than maintaining separate CLI-only detection logic.

Why it matters

Repository understanding is now reusable infrastructure instead of wizard-specific code.

Later S3, telemetry, messaging, AI/MCP and vector capability releases can add detectors to one engine and expose the same result through CLI, future Web UI/API and future Operator surfaces.

This also makes automation safer: machine-readable inspection output has explicit evidence and confidence instead of opaque guesses.

Provider ecosystem foundation

v0.4.3 also includes the Provider Integration Contract v1 work completed after v0.4.2.

BaseHarbor now has:

  • versioned Capability Specifications;
  • baseharbor.provider/v1 as the provider protocol contract;
  • a shared semantic boundary for built-in and future external providers;
  • gRPC/Protocol Buffers as the future language-neutral external transport;
  • JSON Schema 2020-12 for provider operator configuration;
  • OCI as the future digest-first provider packaging/distribution path;
  • explicit async-operation, idempotency, deadline/cancellation and binding-secret rules;
  • open supply-chain direction using OCI referrers plus standard signature/SBOM/provenance mechanisms.

No external plugin loader is introduced yet. Current providers remain built into BaseHarbor and continue using the existing runtime implementation.

Safety

Repository inspection is strictly read-only.

  • it does not write baseharbor.yaml;
  • it does not materialize BaseHarbor runtime state;
  • environment-file values are discarded before inspection/output;
  • only variable names are retained;
  • symlinked files are skipped so inspection does not follow repository-controlled links outside the tree;
  • common generated/vendor directories such as .git, .baseharbor, node_modules, vendor, build output and virtual environments are ignored;
  • large candidate files are bounded rather than loaded without limit.

Suggested and Possible capability findings are never silently converted into application requirements. If app init --quick has no Detected capability and no explicit detected workload, it now fails closed and asks the developer to use interactive setup or explicit flags.

Behavior correction

A repository that contains an explicit application workload but no backend-capability evidence no longer receives an invented PostgreSQL requirement from app init --quick.

Compose provider detection is also scoped to service identity/image evidence, avoiding false provider classification merely because an application service contains variables such as DATABASE_URL.

Compatibility & upgrade impact

No baseharbor.yaml migration is required.

Existing repositories and explicit app init flags continue to work.

Compose remains the complete current runtime implementation. PostgreSQL, Valkey and OpenBao provisioning behavior is unchanged.

The new provider protocol is an architecture/API foundation for later external providers; installing or loading external provider modules is intentionally deferred.

Deferred work

v0.4.3 does not yet add:

  • AI-assisted repository analysis;
  • automatic mutation based on Suggested/Possible evidence;
  • external provider loading;
  • provider OCI download/execution;
  • Kubernetes/OpenShift/cloud runtime providers;
  • the later S3/observability/messaging capability implementations.

Those build on the deterministic inspection and provider-contract foundations introduced here.

Assets 5
Loading