| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat(lambda): lambda runtime for function execution (#4998) <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- Summary by @propel-code-bot --> --- **Add AWS Lambda Runtime and Multi-Fleet Orchestration for Function Execution** Introduces a Lambda-based execution path alongside the existing container runner, with a pluggable runtime selection layer driven by plan metadata and rules. Adds a dedicated `@nangohq/lambda-runner` package, extends fleet supervision to support multiple fleets and Lambda-specific node providers, and updates infrastructure (Redis, plans schema, deployment workflow) to support the new runtime while maintaining backward compatibility. <details> <summary><strong>Key Changes</strong></summary> • Adds Lambda runtime adapter, node provider, and handler (`packages/jobs/lib/runtime/lambda.adapter.ts`, `packages/jobs/lib/runner/lambda.ts`, `packages/lambda-runner/lib/index.ts`) for invoking AWS Lambda functions asynchronously with locking, heartbeat, and abort handling. • Introduces runtime orchestration layer (`packages/jobs/lib/runtime/runtimes.ts`, `packages/jobs/lib/runtime/runtimes.rules.ts`) that selects fleets based on JSON rules and per-plan runtime flags added via migration `20260108145100_add_function_runtime_flags.cjs` and plan schema updates. • Extends fleet management to support multiple fleets and Lambda nodes (new image verifiers, supervisor updates, `fleet_id` persistence, node provider API changes) and separates Redis usage into system/customer boundaries with locking enhancements (`packages/kvstore/lib/index.ts`, `packages/kvstore/lib/Locking.ts`). • Adds new `@nangohq/lambda-runner` package with build pipeline (`Dockerfile.lambda`, tsconfig, schema validations) and updates CI/CD workflow to deploy Lambda images and invoke rollout API with image type. • Updates job execution paths (sync/action/webhook/on-event) to pass runtime context and use new runtime adapter, while ensuring abort propagation through Redis flags and Lambda heartbeat polling. </details> <details> <summary><strong>Affected Areas</strong></summary> • @nangohq/jobs runtime orchestration • @nangohq/fleet supervision and node models • @nangohq/kvstore locking and Redis clients • @nangohq/server fleet rollout API • @nangohq/utils environment parsing and detection • @nangohq/lambda-runner package and deployment workflow • Database schemas for plans and fleet nodes </details> --- *This summary was automatically generated by @propel-code-bot* --------- Co-authored-by: Bastien Beurier <bastienbeurier@gmail.com> Co-authored-by: Thomas Bonnin <233326+TBonnin@users.noreply.github.com> Co-authored-by: Guilherme Bassa <guilhermebassa@gmail.com> Co-authored-by: Daniel Gonzalez <167912055+gonzalde97@users.noreply.github.com> Co-authored-by: Khaliq <khaliq@nango.dev> Co-authored-by: Hassan_Wari <85742599+hassan254-prog@users.noreply.github.com> Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com> | 9 个月前 | |
chore(lint): move import sorting to Prettier (#6582) ## Problem We're replacing ESLint with oxlint (NAN-5769). oxlint has no `import/order` equivalent — its maintainers deliberately defer import sorting to the formatter — so import ordering needs a new home before the linter swap. ## Solution Move import ordering to Prettier via `@ianvs/prettier-plugin-sort-imports`, configured to replicate the existing `import/order` grouping exactly: builtins → external → `@nangohq/*` → `@/*` + relative → type imports, blank lines between groups, alphabetised within. The `import/order` rule (and its now-pointless migrations override) is removed from the ESLint config. Doing this first — while ESLint still runs — means the change is verifiable in isolation: format-on-save behaviour is identical for developers, and CI's existing `prettier --check` + ESLint both still gate it. Two commits: - `chore(lint): move import sorting to Prettier` — the plugin + config (this is the one to actually review) - `style: sort imports across the codebase` — the mechanical 489-file reformat (skim only; import order changes only, no logic) Part of NAN-5769. Sub-issue: NAN-5808. ## Testing - `eslint . --quiet` passes clean (exit 0) on the reformatted code - Reformat is purely mechanical — only import grouping/order changed - Spot-checked plugin output against the old `import/order` grouping; identical | 4 个月前 | |
chore(lint): move import sorting to Prettier (#6582) ## Problem We're replacing ESLint with oxlint (NAN-5769). oxlint has no `import/order` equivalent — its maintainers deliberately defer import sorting to the formatter — so import ordering needs a new home before the linter swap. ## Solution Move import ordering to Prettier via `@ianvs/prettier-plugin-sort-imports`, configured to replicate the existing `import/order` grouping exactly: builtins → external → `@nangohq/*` → `@/*` + relative → type imports, blank lines between groups, alphabetised within. The `import/order` rule (and its now-pointless migrations override) is removed from the ESLint config. Doing this first — while ESLint still runs — means the change is verifiable in isolation: format-on-save behaviour is identical for developers, and CI's existing `prettier --check` + ESLint both still gate it. Two commits: - `chore(lint): move import sorting to Prettier` — the plugin + config (this is the one to actually review) - `style: sort imports across the codebase` — the mechanical 489-file reformat (skim only; import order changes only, no logic) Part of NAN-5769. Sub-issue: NAN-5808. ## Testing - `eslint . --quiet` passes clean (exit 0) on the reformatted code - Reformat is purely mechanical — only import grouping/order changed - Spot-checked plugin output against the old `import/order` grouping; identical | 4 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 9 个月前 | ||
| 4 个月前 | ||
| 4 个月前 |