| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat(ci): add Storybook PR preview deploys (#7084) ## Problem There's no stable place to share WIP components. Deploying Storybook from a feature branch overwrites `storybook.nango.dev`, and it gets clobbered again on the next `app_ui` merge to master. ## Solution - Every PR now gets its own Storybook at `pr-<N>-storybook.app-development.nango.dev`, uploaded to `previews/pr-<N>-storybook/` in the existing webapp preview bucket. - No infrastructure changes: the CloudFront viewer-request function already derives the S3 prefix from the first host label, and the wildcard cert, DNS, noindex header and 30-day lifecycle rule all cover the new host. No new Actions variables either — it reuses `PREVIEW_APP_UI_ROLE` / `_BUCKET` / `_DISTRIBUTION_ID`. - `preview-webapp.yml` is folded into `preview.yml` so all previews report into **one** sticky PR comment rather than one comment per preview. `comment-init` and `comment-final` are its only writers, avoiding the lost-update race two workflows editing one comment would hit. Adding a future preview is one more job plus one row. - The webapp and Storybook jobs run independently, so a broken story no longer blocks the webapp preview. - Shared logic extracted into `.github/actions/preview-comment` and `.github/actions/deploy-preview`. Fixes [NAN-6403](https://linear.app/nango/issue/NAN-6403) ## Testing - `npm run -w @nangohq/design-system build-storybook` passes; every file in `storybook-static/` ends in a simple extension, so the CloudFront function's extension-less → `index.html` branch only catches real routes. - `actionlint` clean on `preview.yml` (verified it actually validates the local composite-action inputs by re-running against a copy with a misspelled input — it caught it). - No required status check in the `master` ruleset references the old `preview` job name. - **Remaining:** this branch touches `.github/` only, so it doesn't match the path filter. A throwaway change under `packages/design-system/**` is needed to trigger a real run — then check one comment with both rows going 🔄 → ✅, a second commit updating that same comment, the Storybook manager and `?path=/docs/...` / `iframe.html?id=...` loading, `x-robots-tag: noindex` present, and `pr-<N>.app-development.nango.dev` still serving the webapp. | 29 天前 | |
fix(ci): stop Ubuntu mirror outages from failing the connect-ui tests (#7504) ## Context `tests-connect-ui` failed five times in the last ~33 runs, always in the same step and never in the suite itself: `playwright install --with-deps` runs `apt-get`, and when an Ubuntu mirror is unreachable from the runner it retries for ~7 minutes and then fails the job. It's a required check, so anyone whose PR caught that window was blocked with nothing wrong in their branch. The apt install is unnecessary here. Of the 30 packages it wanted, 21 were already installed and only being upgraded — including every library Chromium links against (`libnss3`, `libgbm1`, `libasound2`, `libdrm`, mesa). All 9 genuinely new ones were fonts. Chromium itself was also re-downloaded on every run, so the job now caches it. That needs a warm-up job to be worth anything: caches are scoped to the ref that writes them, and `tests-connect-ui` only ever runs on a PR branch or on a throwaway `gh-readonly-queue` ref. ## Changes - Drop `--with-deps`, so the job no longer depends on Ubuntu mirrors being up. - Cache `~/.cache/ms-playwright`, keyed on the pinned Playwright version. - Warm that cache on every push to master. ## Testing On this branch, a cold run installed Chromium in 6s and the suite passed with no apt step at all. Re-running the job restored the cache in 1s and turned the install into a 1s no-op. The master warm-up job can only be checked after this merges — the first PR opened afterwards should restore instead of downloading. | 1 天前 | |
feat(ci): add Storybook PR preview deploys (#7084) ## Problem There's no stable place to share WIP components. Deploying Storybook from a feature branch overwrites `storybook.nango.dev`, and it gets clobbered again on the next `app_ui` merge to master. ## Solution - Every PR now gets its own Storybook at `pr-<N>-storybook.app-development.nango.dev`, uploaded to `previews/pr-<N>-storybook/` in the existing webapp preview bucket. - No infrastructure changes: the CloudFront viewer-request function already derives the S3 prefix from the first host label, and the wildcard cert, DNS, noindex header and 30-day lifecycle rule all cover the new host. No new Actions variables either — it reuses `PREVIEW_APP_UI_ROLE` / `_BUCKET` / `_DISTRIBUTION_ID`. - `preview-webapp.yml` is folded into `preview.yml` so all previews report into **one** sticky PR comment rather than one comment per preview. `comment-init` and `comment-final` are its only writers, avoiding the lost-update race two workflows editing one comment would hit. Adding a future preview is one more job plus one row. - The webapp and Storybook jobs run independently, so a broken story no longer blocks the webapp preview. - Shared logic extracted into `.github/actions/preview-comment` and `.github/actions/deploy-preview`. Fixes [NAN-6403](https://linear.app/nango/issue/NAN-6403) ## Testing - `npm run -w @nangohq/design-system build-storybook` passes; every file in `storybook-static/` ends in a simple extension, so the CloudFront function's extension-less → `index.html` branch only catches real routes. - `actionlint` clean on `preview.yml` (verified it actually validates the local composite-action inputs by re-running against a copy with a misspelled input — it caught it). - No required status check in the `master` ruleset references the old `preview` job name. - **Remaining:** this branch touches `.github/` only, so it doesn't match the path filter. A throwaway change under `packages/design-system/**` is needed to trigger a real run — then check one comment with both rows going 🔄 → ✅, a second commit updating that same comment, the Storybook manager and `?path=/docs/...` / `iframe.html?id=...` loading, `x-robots-tag: noindex` present, and `pr-<N>.app-development.nango.dev` still serving the webapp. | 29 天前 | |
chore(ci): add composite setup-node action with npm cache (#6177) ## Problem npm caching was inconsistent across CI workflows — some used `cache: 'npm'`, others didn't. New workflows could easily forget it. Also, master pushes from the merge-queue bot skip `npm ci` via the `should-run` check, so no npm cache was ever saved on `refs/heads/master`, meaning every feature branch paid a cold cache miss on first run. This also lays the ground for enabling `pnpm` across the monorepo. ## Solution Add `.github/actions/setup-node`, a composite action wrapping `actions/setup-node@v4` with `cache: 'npm'` always set. Migrate all workflows to use it. Add `cache-warmup.yaml` that runs on every master push, doing just enough (`checkout` + `setup-node` + `npm ci`) to land an npm cache on `refs/heads/master` so feature branches can restore it. Only `cli-verification.yaml` and `managed-release.yaml` genuinely gain new caching — the rest were already using `cache: 'npm'` and are just migrated to the composite action. Fixes [NAN-5527](https://linear.app/nango/issue/NAN-5527) ## Testing - [ ] CI green on this PR - [ ] After merge, `Cache Warmup` workflow runs on the master push and saves a cache entry on `refs/heads/master` - [ ] Next feature branch's first run shows a cache hit in the setup-node logs | 3 个月前 | |
ci: automate Slack deploy notifications to #deploys (#6316) ## Problem Deploys are announced manually in the engineering channel, which is easy to forget and clutters the wrong channel. There's no passive, reliable awareness of who is deploying what, where. ## Solution Notify [#deploys](https://nangohq.slack.com/archives/C0B7KSD33QE) automatically on every `workflow_dispatch` deploy, via a reusable composite action at `.github/actions/slack-deploy-notification`: - `notify_start` posts a status message with a colored bar (blue) showing the service, stage, ref, who triggered it, and a link to the run. It runs independently of the deploy jobs, so Slack never delays or blocks a deploy. - `notify_result` updates that same message in place once the deploy finishes: - ✅ green — `Deploy succeeded in 2m 37s` - ❌ red — `Deploy failed after 2m 37s` - ⚠️ yellow — `No deploy ran` when no job matched the service/stage (e.g. `runner`/`lambda` on `replit`), so a no-op never reports success. Covers all services (`server`, `jobs`, `runner`, `persist`, `orchestrator`, `metering`, `connect_ui`, `app_ui`, `lambda`) and all stages (dev / staging / prod / replit). The workflow also gains a least-privilege `permissions: {}` block, granting `contents: read` only to the jobs that check out the repo. ### Slack setup (done) The **Nango CI** Slack app (scope `chat:write`) is installed and invited to `#deploys`, and its bot token is stored as the `SLACK_BOT_TOKEN` repository secret. A bot token is required because incoming webhooks can't do `chat.update`. Fixes [NAN-5643](https://linear.app/nango/issue/NAN-5643) ## Testing - Triggered `app_ui` and `connect_ui` deploys to `development` from this branch and confirmed the `#deploys` message transitions in place from blue "Deploy started" to green "Deploy succeeded in Xm Ys". - Verified the composite action resolves in both notify jobs and that the `permissions: {}` block doesn't break checkout. | 3 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 29 天前 | ||
| 1 天前 | ||
| 29 天前 | ||
| 3 个月前 | ||
| 3 个月前 |