feat(ripple): auto-resolve last export job for log/errors#10330
Merged
Conversation
After a successful export, persist the ripple job slugs + metadata to `.bit/last-export.json`. `bit ripple errors` and `bit ripple log` now fall back to that file when no current lane is detected (i.e. exports from main), look up the job via `getJob(slug)`, and prepend a contextual header showing the export age and outcome.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a “last export” fallback for Ripple CLI commands when running on main (no lane), by persisting the most recent export’s Ripple job slug(s) and then resolving the job via getJob(slug: ID!) when needed.
Changes:
- Persist last export metadata (timestamp, job slugs, lane info, exported components) to
.bit/last-export.jsonafter successful exports that return Ripple jobs. - Add Ripple support for resolving a job by slug and using
last-export.jsonwhen no job-id and no lane are available. - Render a contextual header in
bit ripple log/errorswhen the resolved job comes from the last export.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
scopes/scope/export/last-export.ts |
New helper to read/write .bit/last-export.json. |
scopes/scope/export/index.ts |
Re-exports last-export helpers/types via @teambit/export. |
scopes/scope/export/export.main.runtime.ts |
Writes last-export metadata after exports that produce Ripple jobs. |
scopes/cloud/ripple/ripple.main.runtime.ts |
Adds getLastExport() and getJobBySlug() + GraphQL query for slug lookup. |
scopes/cloud/ripple/ripple.cmd.ts |
Updates log/errors to resolve from last-export and render a contextual header. |
scopes/cloud/ripple/ripple-utils.ts |
Enhances job resolution to include last-export fallback + adds relative age formatting. |
When the user's last export targets the current lane, prefer that job over the latest lane job. This avoids the misleading 'No failed Ripple CI job found' message when on a lane where the user's last export succeeded — the new behavior shows the actual outcome with the contextual header. Also drops the FAILURE-only filter on lane fallback so 'bit ripple errors' on a lane with no failures shows the success state instead of bailing out.
When resolveJobId resolves from last-export it already calls getJobBySlug to fetch the full job. Pass that job through ResolvedJobId so RippleLogCmd can reuse it instead of issuing a second getJob round trip. Addresses copilot review on #10330.
readLastExport now rejects parsed JSON that doesn't match the expected shape (e.g. corrupted file with rippleJobs as a string), so callers can trust the returned data without repeating Array.isArray guards. Also fix a stale --lane help text in 'ripple errors' that referenced 'latest failed job' before the filter was dropped.
GiladShoham
approved these changes
Apr 27, 2026
davidfirst
changed the title
The bit.cloud /ripple-ci/job/<segment> page resolves <segment> by slug (the url-safe identifier returned in the export response), not by the GraphQL job id. Pass-through job ids were silently leading to 'No CI job found' on the rendered page. Selecting Job.slug in getJob/getJobBySlug and preferring it in getJobUrl restores working links.
- isValidLastExport now rejects entries where exportedComponents is not an array of non-empty strings, and where lane (when present) lacks string scope/name. Prevents corrupt-but-parseable files from being used in header rendering. - RippleErrorsCmd.json() now includes source/lastExport on the no-job branch so JSON consumers see a consistent shape. - RETRY_JOB / STOP_JOB mutations now select slug, so the retry-printed url uses the slug-based bit.cloud route that actually resolves.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
bit ripple errors/bit ripple logpreviously auto-detected a job only by querying the current lane. On main this didn't work at all, and on a lane with a successful latest job the errors command bailed out with "No failed Ripple CI job found".After a successful export, ripple job slugs + lane/timestamp/components are now persisted to
.bit/last-export.json. The resolver chain is: arg → last-export (when its target matches the current context) → lane → error. Slugs are looked up viagetJob(slug: ID!). A contextual header is rendered when the job came from last-export, e.g.✓ Your last export (2 minutes ago) to main succeeded.or✗ Your last export (8 minutes ago) to lane "scope/dev44" failed.Test plan
bit ripple errors/bit ripple logwith no args.bit ripple errorsshows the failure header + error details.bit ripple errorsreports "All N components built successfully" instead of the old "No failed Ripple CI job found".