Skip to content

add version script#143

Merged
anubra266 merged 1 commit intomainfrom
add-version
Sep 12, 2025
Merged

add version script#143
anubra266 merged 1 commit intomainfrom
add-version

Conversation

@anubra266
Copy link
Copy Markdown
Contributor

No description provided.

@vercel
Copy link
Copy Markdown

vercel Bot commented Sep 12, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
agents-docs Building Building Preview Comment Sep 12, 2025 5:11pm
agents-manage-api Building Building Preview Comment Sep 12, 2025 5:11pm
agents-manage-ui Building Building Preview Comment Sep 12, 2025 5:11pm
agents-run-api Building Building Preview Comment Sep 12, 2025 5:11pm

@anubra266 anubra266 merged commit 76dee6b into main Sep 12, 2025
3 of 7 checks passed
@anubra266 anubra266 deleted the add-version branch September 12, 2025 17:12
@claude
Copy link
Copy Markdown
Contributor

claude Bot commented Sep 12, 2025

Claude finished @anubra266's task —— View job


Reviewing PR #143: "add version script"

Conducted a comprehensive Staff Engineer-level review of this merged PR.

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Analyze the 3 changed files to understand the version script changes
  • Evaluate changes from engineering best practices perspective
  • Assess system architecture and design implications
  • Consider customer and extensibility impacts
  • Provide comprehensive review feedback

📋 Review Summary

This PR appears to be the initial repository setup commit that establishes the foundational versioning infrastructure for the Inkeep Agent Framework monorepo. While functionally sound, there are several architectural and engineering considerations that merit attention.

🔍 Key Changes Analysis

Files Changed:

  • .changeset/config.json ➜ Added Changeset configuration for automated versioning
  • package.json ➜ Added root monorepo package configuration with comprehensive scripts
  • pnpm-workspace.yaml ➜ Added PNPM workspace configuration for 9 packages

⚠️ Critical Issues & Areas for Improvement

1. Missing Documentation & Context (High Priority)

  • Issue: No PR description provided, making it difficult to understand the intent and scope
  • Impact: Reduces team understanding and makes future maintenance challenging
  • Recommendation: For infrastructure changes like this, comprehensive documentation should explain:
    • Why Changesets was chosen over other versioning strategies
    • Release workflow and branching strategy
    • How the versioning affects the multi-agent deployment model

2. Changeset Configuration Concerns (Medium Priority)

// .changeset/config.json:4
"commit": false,
  • Issue: Commits are disabled, which may complicate release automation
  • Consider: This breaks traceability between version bumps and their corresponding commits
  • Alternative: Enable commits with conventional format for better CI/CD integration
// .changeset/config.json:10
"ignore": ["@inkeep/examples", "@inkeep/agents-ui", "@inkeep/agents-docs"]
  • Issue: Ignoring agents-docs could cause documentation to drift from code versions
  • Risk: Documentation may not reflect current API state during releases
  • Recommendation: Consider versioning docs alongside code, especially for public-facing documentation

3. Package Manager Version Lock Inconsistency (Medium Priority)

// package.json:74
"packageManager": "[email protected]",

vs

# pnpm-workspace.yaml:10-11
onlyBuiltDependencies:
  - keytar
  • Issue: keytar build-only dependency is duplicated in both files
  • Better Pattern: Centralize this configuration in one location
  • Consider: Using .npmrc for pnpm-specific configurations

4. Monorepo Architecture Scalability (Medium Priority)

Package Structure:

  • 9 packages currently defined, but growth pattern isn't clear
  • Mix of APIs, UIs, CLI, and documentation suggests different release cadences
  • No clear separation between internal/external packages

Recommendations:

  • Consider package grouping strategies (e.g., @inkeep/core/*, @inkeep/ui/*)
  • Define clear dependency boundaries between packages
  • Establish conventions for internal vs external package versioning

5. Release Strategy Gaps (Low-Medium Priority)

// package.json:38-40
"version": "changeset version",
"release": "changeset publish", 
"release-dev": "changeset version --snapshot dev && changeset publish --tag dev",

Missing Considerations:

  • No pre-release validation scripts
  • No rollback strategy defined
  • No environment-specific release configurations
  • No integration with the A2A communication protocol versioning mentioned in CLAUDE.md

💡 Architectural Recommendations

1. Enhanced Release Workflow

{
  "scripts": {
    "pre-release": "pnpm test && pnpm lint && pnpm typecheck && pnpm build",
    "release:validate": "changeset status",
    "release:preview": "changeset version --snapshot preview",
    "postversion": "pnpm db:check" // Ensure schema compatibility
  }
}

2. Agent Framework Specific Considerations

Given this is an agent framework with A2A communication:

  • Consider versioning strategy for agent compatibility matrices
  • Plan for backward compatibility in agent communications
  • Define versioning for agent configuration schemas

3. Documentation Integration

// Suggested addition to ignore exceptions
"ignore": [
  "@inkeep/examples", 
  "@inkeep/agents-ui"
  // Remove agents-docs to maintain version sync
]

🎯 Future Extensibility Considerations

  1. Multi-tenant Versioning: How will versioning handle tenant-specific agent deployments?
  2. Tool Compatibility: How will MCP server versions align with framework versions?
  3. Database Migration Strategy: Integration with the Drizzle migration system
  4. External Agent Compatibility: Version management for external agent integrations

✅ Positive Aspects

  1. Industry Standard Tooling: Changesets is a mature, well-supported solution
  2. Comprehensive Script Coverage: Good coverage of development, testing, and database operations
  3. Proper Node Version Constraints: >=22.0.0 requirement is appropriate for modern tooling
  4. Monorepo Structure: Well-organized package structure for a complex system

🚀 Recommendations for Next Steps

  1. Documentation: Create VERSIONING.md explaining release strategy and agent compatibility
  2. CI/CD Integration: Add release validation workflows
  3. Testing: Add integration tests for version compatibility across agent communications
  4. Monitoring: Consider how versioning integrates with the Jaeger tracing mentioned in CLAUDE.md

💭 Final Thoughts

This is solid foundational work for a complex multi-agent system. The primary concerns are around documentation, configuration consolidation, and ensuring the versioning strategy aligns with the unique requirements of an agent framework with A2A communication patterns.

Overall Assessment: ✅ Approved with Recommendations
Complexity: Medium - Infrastructure setup with framework-specific considerations
Risk Level: Low - Standard tooling with good practices

Zeeeepa pushed a commit to Zeeeepa/inkeep_agents that referenced this pull request Apr 23, 2026
…nkeep#3177)

* chore: post-migration productivity hardening (tooling, CI, DX)

Rebased onto main after significant churn. Dropped items that became
redundant with inkeep#143 (monorepo trap guards) and inkeep#153 (Dependabot lockfile
auto-sync), kept the rest. Addresses review comments inline.

KEPT (11 items)

Tooling:
- .npmrc: add engine-strict, auto-install-peers, strict-peer-dependencies,
  resolution-mode=highest
- .node-version: 22 -> 22.18.0 (patch pin for reproducibility)
- package.json: preinstall `only-allow pnpm` + postinstall
  `check-node-version.mjs` + `check:node-version` script
- scripts/check-node-version.mjs: hardened against IO errors + malformed
  .node-version values (addresses pullfrog/claude review comments about
  try/catch on readFileSync + lts/* handling)
- turbo.json: globalDependencies now invalidates on root pnpm-lock.yaml,
  .node-version, pnpm-workspace.yaml (was only watching public/agents/)
- tsconfig.base.json: strict baseline for opt-in package migration
  (used by PR inkeep#133)

DX:
- setup-dev.js: validateEnvironmentEarly() fails fast on missing
  ANTHROPIC_API_KEY before any Docker/install work. parseEnvFile
  readFileSync wrapped in try/catch for EACCES resilience.

CI:
- public-agents-extended-validation.yml: turbo affected filter
  `...[origin/base_ref]` on PR events; `merge_group`/`push` keep full run.
  Ported to the new single `turbo check` command structure introduced
  by inkeep#125 (the original diff targeted the pre-inkeep#125 matrix).
- public-agents-cypress.yml + composite action: 4-way deterministic
  shard matrix (no Cypress record key required); gate job fans in on
  default needs behavior.
- private-master-ci.yml: clarifying comment about turbo affected filter
  not applying (workflow_dispatch only).

DROPPED (vs original inkeep#130)

- scripts/check-lockfile-sync.mjs + `check:lockfile-sync` script:
  superseded by inkeep#143's `check-monorepo-traps.mjs lockfiles` which actually
  runs `pnpm install --frozen-lockfile` in both directories (strictly
  stronger than my mtime heuristic). inkeep#153 auto-syncs Dependabot lockfile
  PRs, killing the main scenario this script was protecting.
- biome.jsonc noExplicitAny "off" -> "warn": would break CI because main's
  Core Validation uses `biome lint --error-on-warnings` and there are
  16+ pre-existing `any` usages in agents-docs + agents-cookbook. Defer
  the flip to a separate PR that also grinds down those violations.
- coverage.yml workflow: no team demand surfaced; non-blocking but still
  shows red. Revisit when someone owns coverage tracking.

COMMENTS ADDRESSED

- claude[bot]: IO error handling on readFileSync/statSync/readdirSync in
  check-node-version.mjs + setup-dev.js parseEnvFile -> wrapped with
  graceful fallbacks
- claude[bot]: malformed .node-version (lts/*, latest) -> regex validation
  skips with a warning instead of producing confusing "Required: v" output
- pullfrog[bot]: github.base_ref is only populated on pull_request events
  -> added in-source comment explaining the trap for future maintainers
- pullfrog[bot]: check-lockfile-sync missed public/agents/agents-* layer
  -> moot, file is dropped
- pullfrog[bot]: coverage.yml missing paths filter + prepare:public-agents-build
  -> moot, file is dropped
- claude[bot]: grep -c exit code -> handled by `|| echo 0` fallback (minor,
  no change)

Not addressed (intentional)
- Biome format/explicit-any violations in agents-docs + agents-cookbook
  flagged by PR inkeep#133's run -> pre-existing on main; out of scope for this
  PR. Will surface again when biome.jsonc flip lands.

* fix: address two CI failures on the rebased inkeep#130

1. check-node-version.mjs: skip in CI/Vercel/GitHub Actions. Vercel's
   build env runs Node 24.14.1 regardless of what .node-version says,
   which caused the postinstall hook to reject and fail the install
   with:

     [check-node-version] Node version mismatch
       Required: v22.18.0 (major v22.x)
       Current:  v24.14.1

   The script's purpose is to catch DEVS on the wrong Node locally, not
   to gate deploys — the platform manages Node. Skip when CI=true,
   VERCEL=1, or GITHUB_ACTIONS=true.

2. public-agents-cypress.yml: strip the public/agents/agents-manage-ui/
   prefix from shard spec paths. cypress runs from manage-ui as cwd
   (via pnpm --dir --filter exec), so repo-root paths double up:

     public/agents/agents-manage-ui/public/agents/agents-manage-ui/cypress/e2e/...

   Now outputs cypress-relative paths like cypress/e2e/agent-prompt.cy.ts.

* fix(ci): drop stale `private/_migration-docs/IMPORT_STATUS.md` check

Reintroduced by accident when I ported the workflow over during the
rebase. Main removed this path in inkeep#157 (`chore(ci): clean up stale
monorepo-migration artifacts`). With the line reintroduced, any
workflow_dispatch run would fail at `test -f`.

Addresses claude[bot] CRITICAL review comment on inkeep#130.

* fix(ci): use App bot identity for auto-format commits

The workflow generates an INTERNAL_CI_APP token and pushes with it
specifically so downstream CI fires on the bot's commit. But the
commit is authored as github-actions[bot], which GitHub treats as
a GITHUB_TOKEN commit and suppresses synchronize for regardless of
the push credentials. Seen on inkeep#172: required checks never reported
on the auto-format HEAD and the PR was stuck BLOCKED.

Resolve the App's own bot slug and numeric user id from the newly
minted token and use <slug>[bot] as the committer. Push still uses
the same App token; synchronize fires as intended.

* ci(extended-validation): auto-update OpenAPI snapshot on PRs

Mirrors the pattern already in public/agents/.github/workflows/ci.yml:
when a PR changes agents-api routes, openapi.*, or createApp.*, regenerate
the OpenAPI snapshot and commit it back to the PR branch using the
INTERNAL_CI_APP token so downstream CI re-runs.

Avoids recurring "OpenAPI snapshot mismatch" test failures (e.g. PR inkeep#200)
where contributors add routes without running
`pnpm --filter @inkeep/agents-api openapi:update-snapshot` locally.

- Gated on non-fork PRs (GITHUB_TOKEN on forks is read-only)
- Uses GitHub App token so commits trigger downstream workflows
- Runs before service-container setup so failure modes are cheap

* chore: align .node-version with repo convention, declare engines.node range

Two fixes to the Node pinning block:

.node-version: 22.18.0 -> 22
  The patch pin was an outlier. Every CI workflow in this repo pins
  `node-version: 22` or `22.x` (24 workflows, zero patch pins), every
  vercel.json has no nodeVersion field (Vercel uses 22.x auto-patch),
  and main's .node-version was just `22`. A patch pin creates monthly
  maintenance (fnm re-install + bump PR) without catching any bug the
  major-level pin doesn't.

package.json: add engines.node = ">=22.0.0 <23"
  .npmrc sets engine-strict=true but there was no engines field for it
  to enforce, making it a no-op. This range aligns with the major-level
  convention used everywhere else and makes engine-strict bite when a
  dev is on Node 18/24.

Belt-and-suspenders: postinstall script catches major drift at install
time (already major-only via .split('.')[0]); engines+engine-strict
catches it at dependency-resolution time. Both skip in CI/Vercel.
GitOrigin-RevId: 08d61f29389bfbbb487ed3093999449ca18b9e98

Co-authored-by: Varun Varahabhotla <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant