| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 | 2 个月前 | |
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> | 7 个月前 | |
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 | 2 个月前 | |
feat(fleet): add support for runner replicas (#5579) Allow runner instances to have more than one replicas Warning: requires runner to be updated to use shared kvstore for conflict detection before we can make a runner instance have more than one replica <!-- Summary by @propel-code-bot --> --- This change also extends fleet configuration to support replica counts via shared types, database schemas, and model mappings, and updates providers and supervisor logic so replica overrides are treated as configuration differences and applied when creating or updating nodes. <details> <summary><strong>Key Changes</strong></summary> • Added `replicas` columns via migration in `packages/fleet/lib/db/migrations/20260305000000_add_replicas.ts` for `nodes` and `node_config_overrides` • Extended `NodeConfig`, `Node`, and `NodeConfigOverride` types with `replicas` in `packages/types/lib/fleet/index.ts` and `packages/fleet/lib/types.ts` • Propagated `replicas` through model mappings and creation paths in `packages/fleet/lib/models/nodes.ts` and `packages/fleet/lib/models/node_config_overrides.ts` • Updated supervisor logic in `packages/fleet/lib/supervisor/supervisor.ts` to outdate nodes on replica changes and apply replica overrides when creating nodes • Adjusted runner providers to default `replicas: 1` and use replica counts in `packages/jobs/lib/runner/kubernetes.ts` plus conflict mode env var when `replicas > 1` </details> <details> <summary><strong>Possible Issues</strong></summary> • Replica override application uses `||` fallback in `packages/fleet/lib/supervisor/supervisor.ts`, which could treat `0` as falsy if ever allowed for `replicas` </details> --- *This summary was automatically generated by @propel-code-bot* | 6 个月前 | |
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 | 2 个月前 | |
feat(mtls): add mtls support to internal service-to-service calls (#6928) <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/6928?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> | 1 个月前 | |
feat: fleet into jobs/server (#3129) I apologize in advance for the big PR. Fleet is now integrated in jobs and server. It is being a feature flag because it only support local runners for now. (The migration creating the tables would run in staging/prod though) This PR: - adds runner routing logic in jobs (behind flag) - implement local runner logic (pretty much copied from previous logic) - adds register and idle mechanism/endpoints between jobs and runners - fixes bugs with the fleet supervisor Note: I want fleet to manage local runner as well so it is the same code (almost) running locally and in prod. In order to do so every time jobs starts locally a new fake deployment is added to the db so fleet automatically rolls out a new runner and manage its lifecycle. Other than that there are tiny adjustments of the logic that only exist for local execution (ex: shorter timeouts, finishing timeout = idle) What's not in this PR but will come next: - /deploy endpoint - render node provider - locking mechanism to ensure only one supervisor is running - CI script to call /deploy endpoint - runner config override mechanism for customers that must get more runner resources # How to test 1. enable feature flag locally a. `redis-cli` b. `set flag:fleet:global true` 2. start nango locally | 1 年前 | |
feat(fleet): add support for runner replicas (#5579) Allow runner instances to have more than one replicas Warning: requires runner to be updated to use shared kvstore for conflict detection before we can make a runner instance have more than one replica <!-- Summary by @propel-code-bot --> --- This change also extends fleet configuration to support replica counts via shared types, database schemas, and model mappings, and updates providers and supervisor logic so replica overrides are treated as configuration differences and applied when creating or updating nodes. <details> <summary><strong>Key Changes</strong></summary> • Added `replicas` columns via migration in `packages/fleet/lib/db/migrations/20260305000000_add_replicas.ts` for `nodes` and `node_config_overrides` • Extended `NodeConfig`, `Node`, and `NodeConfigOverride` types with `replicas` in `packages/types/lib/fleet/index.ts` and `packages/fleet/lib/types.ts` • Propagated `replicas` through model mappings and creation paths in `packages/fleet/lib/models/nodes.ts` and `packages/fleet/lib/models/node_config_overrides.ts` • Updated supervisor logic in `packages/fleet/lib/supervisor/supervisor.ts` to outdate nodes on replica changes and apply replica overrides when creating nodes • Adjusted runner providers to default `replicas: 1` and use replica counts in `packages/jobs/lib/runner/kubernetes.ts` plus conflict mode env var when `replicas > 1` </details> <details> <summary><strong>Possible Issues</strong></summary> • Replica override application uses `||` fallback in `packages/fleet/lib/supervisor/supervisor.ts`, which could treat `0` as falsy if ever allowed for `replicas` </details> --- *This summary was automatically generated by @propel-code-bot* | 6 个月前 | |
feat(fleet): add support for runner replicas (#5579) Allow runner instances to have more than one replicas Warning: requires runner to be updated to use shared kvstore for conflict detection before we can make a runner instance have more than one replica <!-- Summary by @propel-code-bot --> --- This change also extends fleet configuration to support replica counts via shared types, database schemas, and model mappings, and updates providers and supervisor logic so replica overrides are treated as configuration differences and applied when creating or updating nodes. <details> <summary><strong>Key Changes</strong></summary> • Added `replicas` columns via migration in `packages/fleet/lib/db/migrations/20260305000000_add_replicas.ts` for `nodes` and `node_config_overrides` • Extended `NodeConfig`, `Node`, and `NodeConfigOverride` types with `replicas` in `packages/types/lib/fleet/index.ts` and `packages/fleet/lib/types.ts` • Propagated `replicas` through model mappings and creation paths in `packages/fleet/lib/models/nodes.ts` and `packages/fleet/lib/models/node_config_overrides.ts` • Updated supervisor logic in `packages/fleet/lib/supervisor/supervisor.ts` to outdate nodes on replica changes and apply replica overrides when creating nodes • Adjusted runner providers to default `replicas: 1` and use replica counts in `packages/jobs/lib/runner/kubernetes.ts` plus conflict mode env var when `replicas > 1` </details> <details> <summary><strong>Possible Issues</strong></summary> • Replica override application uses `||` fallback in `packages/fleet/lib/supervisor/supervisor.ts`, which could treat `0` as falsy if ever allowed for `replicas` </details> --- *This summary was automatically generated by @propel-code-bot* | 6 个月前 | |
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> | 7 个月前 | |
feat(fleet): add support for runner replicas (#5579) Allow runner instances to have more than one replicas Warning: requires runner to be updated to use shared kvstore for conflict detection before we can make a runner instance have more than one replica <!-- Summary by @propel-code-bot --> --- This change also extends fleet configuration to support replica counts via shared types, database schemas, and model mappings, and updates providers and supervisor logic so replica overrides are treated as configuration differences and applied when creating or updating nodes. <details> <summary><strong>Key Changes</strong></summary> • Added `replicas` columns via migration in `packages/fleet/lib/db/migrations/20260305000000_add_replicas.ts` for `nodes` and `node_config_overrides` • Extended `NodeConfig`, `Node`, and `NodeConfigOverride` types with `replicas` in `packages/types/lib/fleet/index.ts` and `packages/fleet/lib/types.ts` • Propagated `replicas` through model mappings and creation paths in `packages/fleet/lib/models/nodes.ts` and `packages/fleet/lib/models/node_config_overrides.ts` • Updated supervisor logic in `packages/fleet/lib/supervisor/supervisor.ts` to outdate nodes on replica changes and apply replica overrides when creating nodes • Adjusted runner providers to default `replicas: 1` and use replica counts in `packages/jobs/lib/runner/kubernetes.ts` plus conflict mode env var when `replicas > 1` </details> <details> <summary><strong>Possible Issues</strong></summary> • Replica override application uses `||` fallback in `packages/fleet/lib/supervisor/supervisor.ts`, which could treat `0` as falsy if ever allowed for `replicas` </details> --- *This summary was automatically generated by @propel-code-bot* | 6 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 个月前 | ||
| 7 个月前 | ||
| 2 个月前 | ||
| 6 个月前 | ||
| 2 个月前 | ||
| 1 个月前 | ||
| 1 年前 | ||
| 6 个月前 | ||
| 6 个月前 | ||
| 7 个月前 | ||
| 6 个月前 |