Skip to content

OAS v0.21.2

Latest
Latest

Choose a tag to compare

View all tags
@github-actions github-actions released this 26 Aug 11:36
· 6 commits to main since this release
v0.21.2
30734a7
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

OAS v0.21.2

OAS v0.21.2 is a corrective release for the v0.21 line. There are no new
features and no lock, manifest, or CLI-surface changes: the single correction
below, and the tests that pin it.

Package payload is no longer discovered as a deployment scope

At a config scope declaring team:, bare oas install reconciles the whole
workspace: it walks downward for descendant scopes, restores each one, and
validates that every config-referenced installed capability is supplied by a
visible locked package. The walk recognized a scope by the presence of an
oas-config.yaml (or an oas-lock.json) — and a member repository that
publishes an OAS package carries oas-config.yaml files that are not scopes
at all: the config templates the package exports, declared through
configTemplates and living under config-templates/ per the v0.20 contract.

A template deliberately binds a layer to the capability its own package
supplies, on the assumption that the adopting deployment installs that package
first. Reconciled as if it were live, it therefore failed by construction:

Failures by scope:
  <workspace>/oas-jira/oas-package/config-templates/default: oas.jira — referenced by
    capabilities.layers.tasks but supplied by no visible locked package
  <workspace>/oas-linear/oas-package/config-templates/default: oas.linear — referenced by
    capabilities.layers.tasks but supplied by no visible locked package

One healthy workspace failed reconciliation for every package it develops, and
the failures named directories no operator could act on. Templates that happened
to resolve against the surrounding chain passed only by accident — the same
walk had been treating all of them as live deployments.

Scope discovery now excludes package payload. A directory holding an
oas-package.json is a package root, and every path beneath it is content
the package exports, never a scope: it is not reconciled, not validated, and
never acquires anything. The rule is the manifest, not the literal
config-templates/ path — custom payload roots exist and one repository may
ship several packages at different paths, and all of them are covered.

Because the test is a containing ancestor, a repository that ships a package
and is itself a deployment scope is unaffected: an oas-config.yaml at a
repository root whose manifest sits in a subdirectory (the framework repo's own
shape) has no oas-package.json ancestor and stays a scope exactly as before.

The same walk backs oas migrate --official --recursive's descendant discovery,
so the exclusion applies there too — a lock stranded inside a payload is no
longer planned as a migration scope.

Genuine failures are untouched. A real member scope referencing a capability no
visible locked package supplies still reports the same message, at the same
scope, with the same nonzero exit.

Compatibility

  • No lockfile, manifest, config, or CLI-surface changes. v0.21.x locks,
    artifacts, and approvals are unaffected; nothing needs reacquiring.
  • Workspaces holding no package payload see no change. Workspaces that develop
    packages stop reporting failures for directories that were never scopes.
Assets 9
Loading