[OPIK-7041] [FE] feat: Optimization runs list — columns, Item source, Discarded + refactors

[awkoy]

Details

Aligns the v2 Optimization runs list to the Figma redesign (562:37189) and folds in the list-page refactors. Part of OPIK_6528. v2 only; no backend, no migrations, no v1 changes.

Design

• Columns: Name is now the first column; added Run ID, Algorithm (getOptimizerLabel(studio_config.optimizer.type)) and Metric (objective_name); the old "Dataset name" column now reuses the Experiments ItemSourceCell relabelled "Item source" (so it gets the icon + tooltip for free and matches Experiments). Per the Figma, the default-visible set is Name, Start time, Status, Pass rate, Accuracy, Latency, Cost, Opt. cost — Run ID / Item source / Algorithm / Metric ship available-but-hidden (enable from the Columns picker).
• Status rename: trial status "Pruned" → "Discarded" (v2 label only; the internal pruned key is unchanged). Renders on the trials/chart surface (PR 5), done here per the ticket.

Fold-in refactors (v2 only)

• Split the ~440-line OptimizationsPage into OptimizationsColumns (column defs) + OptimizationsToolbar (search/filters/actions/refresh/columns) + a slim page.
• Dropped the ghost deploy column (referenced in the order/selected lists but never defined) and bumped the column-prefs keys v1 → v2 so stale prefs don't carry the dead id.
• Gated the 30s list polling: added an additive, v1-safe pollWhileInProgress param to the shared useOptimizationsView (default keeps the old unconditional 30s for v1); v2 now polls only while a run is running/initialized and stops once everything settles.
• Removed the now-orphaned v2 DatasetNameCell.

Notes for reviewers

• ItemSourceCell changes are additive: (1) an optional customMeta.resource override (used here to force the test-suite link/icon, since optimization rows carry no evaluation_method); (2) an idless fallback — when a row has a source name but no linkable id, the cell now renders the name (no link) instead of "-" (was a regression vs the old DatasetNameCell; benefits Experiments too). Experiments passes neither new option, and the only behavior change there is idless rows showing a name instead of a dash.
• Two ticket fold-ins were intentionally not done here, both because they're bigger than list-local:
  • "Strip the as never casts" — these exist because ColumnData.cell (in types/shared.ts) is typed as tanstack's Cell<T> (cell instance) instead of a cell renderer, so ~100 files app-wide use as never. Removing properly means re-typing the shared field; out of scope, tracked separately. Kept the casts (with an explanatory comment) for consistency.
  • Metric icon colors — the cell structure already matches Figma (baseline + trend icon + current); the exact trend-icon color is baked in an SVG asset (no token) and changing it touches the shared PercentageTrend/MetricComparisonCell. Deferred pending an exact color from design.
• 1:1 caveat (same as PR 1): column order + default visibility were matched to the Figma frame; pixel-level styling (widths, the icon shade) isn't render-verified — the list does render in-app, so this can be visually confirmed in review, but I didn't stand up the full app here.

Change checklist

• User facing
• Documentation update

Issues

• OPIK-7041

AI-WATERMARK

AI-WATERMARK: yes

• Tools: Claude Code
• Model(s): Opus 4.8 (1M context)
• Scope: Full implementation — planning, column module + toolbar extraction, page slimming, polling gate, status rename, and the ItemSourceCell reuse. Column order/visibility matched to Figma via the Figma MCP (562:37189, header 686:35271).
• Human verification: Author directed scope and the "1:1 with Figma" requirement. Typecheck/lint clean; existing optimization tests pass as regression. Pixel-level styling not render-verified in-app (see Notes).

Testing

Commands (from apps/opik-frontend):

• tsc --project tsconfig.json --noEmit — clean.
• eslint on all changed files — 0 problems.
• vitest run over the optimization suites — 32 tests pass (regression: optimizationChartUtils, sortCandidates, OptimizationCompareRedirect), confirming the status-label and column changes don't break existing logic.

No new unit tests were added: PR 2 is UI config + a refactor with no substantial new pure logic to test (the polling predicate is a trivial status check). The runtime UI was not exercised in a running app here — list rendering can be confirmed during review.

Documentation

N/A — UI-only changes (columns, labels, polling); no documentation update.

🤖 Generated with Claude Code

[baz-reviewer]

Idless optimization rows show blank source

OptimizationPublic.dataset_id is optional, so optimizations can arrive with dataset_name but no id, and routing this column through ItemSourceCell with idKey: "dataset_id" makes those rows fall back to "-" instead of showing the source label — should we keep rendering dataset_name and only hide the link/icon when the id is missing?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/opik-frontend/src/v2/pages/OptimizationsPage/OptimizationsColumns.tsx around lines
50-60, the `dataset_name` column routes rendering through `ItemSourceCell` with `idKey:
"dataset_id"`, which causes the entire source label to disappear (becoming `"-"`) when
`dataset_id` is missing. Refactor the `dataset_name` column so it always displays
`row.dataset_name` (using `accessorFn` or a wrapper cell) and only hides/disables the
link/icon portion when `row.dataset_id` is falsy. If needed, introduce a small wrapper
renderer in this file that passes `idKey`/resource for link behavior but falls back to
`dataset_name` for the visible label regardless of id presence.

[awkoy]

Good catch — valid regression, fixed in 5cb26c8. ItemSourceCell now falls back to rendering the source name (without a link) when there's no linkable id, instead of "-", so idless optimization rows keep their label. Applied in the shared cell so Experiments benefits too (idless rows there previously also showed a bare dash); typecheck + the experiments/optimization test suites stay green.

[baz-reviewer]

Commit 5cb26c8 addressed this comment by changing ItemSourceCell to fall back to rendering the source name when no linkable id is present. That keeps idless optimization rows showing dataset_name while omitting only the link/icon behavior.

[baz-reviewer]

Duplicate empty-state probe

useOptimizationsList adds the same page=1/size=1 existence probe and isExistencePending gating that already exists in ExperimentsPage.tsx and GeneralDatasetsTab.tsx, so any tweak to the empty-state or refetch logic has to be copied to three places — should we extract a shared useListExistenceProbe hook?

Want Baz to fix this for you? Activate Fixer

[awkoy]

Agreed it's worth a shared useListExistenceProbe. Holding it out of this PR though: the probe also lives in ExperimentsPage and GeneralDatasetsTab, so extracting it touches the Experiments and Datasets features unrelated to this optimization-runs change. Tracking as a focused follow-up so that refactor (and its regression surface) is reviewed on its own.

[baz-reviewer]

That makes sense — keeping the cross-feature refactor in a focused follow-up PR is a reasonable boundary here. I'll save this to memory once the PR is merged.

[baz-reviewer]

Cross-page INITIALIZED stops polling

The workspace-wide ACTIVE_OPTIMIZATION_FILTER only queries status=running, so INITIALIZED optimizations on other pages keep activeData.total at 0 and auto-refresh stops while work is still active elsewhere — should we include INITIALIZED in that probe?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/opik-frontend/src/hooks/useOptimizationsView.ts around lines 47-63 inside the
`useOptimizationsView` hook, the workspace-wide “active runs” probe calls
`useOptimizationsList` with `filters: ACTIVE_OPTIMIZATION_FILTER`, which only covers
`status=running`, so `hasActiveRuns` won’t be true when the only active optimization
elsewhere is `INITIALIZED`. Refactor by updating the probe filters to include
`INITIALIZED` as an active/in-progress state (either modify `ACTIVE_OPTIMIZATION_FILTER`
to include both statuses, or introduce a dedicated workspace-active filter constant for
`RUNNING` + `INITIALIZED`), and then compute `hasActiveRuns` from that expanded query.
This ensures the `refetchInterval` continues polling while work is active on other pages
for v2 callers.

[awkoy]

Intentional, documented tradeoff (see the comment block on the probe). The workspace-wide probe detects RUNNING; a cross-page INITIALIZED run is transient (flips to RUNNING almost immediately) and is still caught by the per-page IN_PROGRESS_OPTIMIZATION_STATUSES check once it surfaces, plus the next window-focus refetch. Widening the probe cleanly needs a multi-status (in) status filter — happy to add RUNNING+INITIALIZED if this proves noticeable, but keeping the single-status probe for now rather than ship an unverified status in query.

[baz-reviewer]

Thanks, that makes sense — I’ll keep this tradeoff in mind and save it to memory once the PR is merged.

[baz-reviewer]

pass_rate, accuracy, latency, cost, and opt_cost column defs are duplicated across v1 and v2 with size: 120 hard-coded four times, so any metric tweak or width change (per the PR, 120 is the Figma-matched width) has to be kept in sync everywhere — should we extract a getOptimizationMetricColumns({ width }) helper and a DEFAULT_METRIC_COLUMN_WIDTH = 120 constant and reuse them?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Extract a shared `getOptimizationMetricColumns({ width })` helper reused by both v1 and
v2 column definitions. Introduce a named constant `DEFAULT_METRIC_COLUMN_WIDTH = 120`
near the existing width constants/comments, and replace all hard-coded `size: 120`
literals in the metric columns (lines 101, 109, 118, 126) with this constant. This makes
the Figma-spec intent explicit and prevents drift when adding/removing metric columns or
syncing across files.

[baz-reviewer]

Commit b474cef addressed this comment by introducing DEFAULT_METRIC_COLUMN_WIDTH = 120 and replacing the repeated size: 120 literals in the v2 metric columns with that constant. This removes the hard-coded width duplication in this file and makes the intended metric width explicit.

[baz-reviewer]

Duplicate studio action cards

The cards array duplicates the actionCards list in OptimizationsEmptyState, so text, color, or callback changes have to be updated in two places and the views can drift apart — should we extract the shared card config or renderer into a common module?

Want Baz to fix this for you? Activate Fixer

[baz-reviewer]

Commit b474cef addressed this comment by extracting the shared onboarding card definitions into getStudioCardConfigs and reusing them in both StudioTemplates and OptimizationsEmptyState. This removes the duplicated title/description/icon/callback setup so the two views can’t drift apart as easily.

[baz-reviewer]

Metric label helper duplication

getMetricLabel duplicates the OPTIMIZATION_METRIC_OPTIONS lookup and fallback already used in lib/optimization-config.ts and the v1 OptimizationConfiguration helper, so metric naming changes have to be synced in three places and can drift — should we reuse the shared helper here instead of copying it again?

Want Baz to fix this for you? Activate Fixer

[baz-reviewer]

Commit b474cef addressed this comment by removing the duplicated getMetricLabel helper from apps/opik-frontend/src/lib/optimizations.ts and switching the table code to import getMetricLabel from the shared lib/optimization-config helper instead. That centralizes the metric-name lookup/fallback instead of keeping a third copy here.

[baz-reviewer]

Bright-positive icon bypasses theme tokens

brightPositive maps the icon to text-[#00d14c], and MetricComparisonCell enables that path, so the vivid green is hard-coded in the UI instead of coming from theme tokens — should we add a CSS variable for it in src/main.scss under :root and .dark, then switch to text-[var(--...)] as .agents/skills/opik-frontend/ui-components.md suggests?

Want Baz to fix this for you? Activate Fixer You can also update your AI coding guidelines based on this comment by apply pr to [branch name]

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/opik-frontend/src/shared/PercentageTrend/PercentageTrend.tsx around lines 59-61
(the `iconColorClassName` logic inside `PercentageTrend`), remove the hard-coded
Tailwind class `text-[#00d14c]` for `brightPositive` and replace it with a theme-aware
class that references a CSS variable (e.g., `text-[var(--...)]`). Then update
src/main.scss (near the existing :root and .dark color/token definitions) to add a new
token for this vivid positive green shade so it works correctly in dark mode. Ensure
`brightPositive` still only applies when `variant === "green"`, but the color source is
the new CSS variable rather than the literal hex.

[baz-reviewer]

Commit 9f323b3 addressed this comment by adding a shared --color-green-bright CSS variable in src/main.scss and switching the bright-positive icon class to text-[var(--color-green-bright)] via TREND_COLOR_CLASS. The related MetricComparisonCell change now reuses the shared trend color mapping instead of relying on a hard-coded green hex.

[baz-reviewer]

Theme tokens bypassed for cards

chipColor, tintBg, and tintBorder are hard-coded here, so the onboarding cards bypass the CSS-variable theme path and dark mode keeps the light tints — should we move them to main.scss vars/classes and add .dark overrides, as .agents/skills/opik-frontend/ui-components.md suggests?

Want Baz to fix this for you? Activate Fixer You can also update your AI coding guidelines based on this comment by apply pr to [branch name]

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/opik-frontend/src/v2/pages-shared/optimizations/StudioTemplates/StudioTemplates.tsx
around lines 38-62, the `cards` array hard-codes `chipColor`, `tintBg`, and `tintBorder`
as hex/rgba, which breaks theme awareness (especially dark mode) and violates
ui-components.md’s requirement to use CSS variables defined in `main.scss` under
`:root` and `.dark`. Refactor by introducing new CSS variables for these three palettes
(mirroring the existing upload-chip variables pattern like `--upload-chip-bg`,
`--upload-chip-border`, `--upload-chip-icon-bg`), add dark-mode `.dark` overrides if
needed, and update the card rendering to use theme-aware classNames/variables instead of
inline color literals. Ensure the `style={{ backgroundColor: tintBg, borderColor:
tintBorder }}` and chip `style` are replaced/derived from the new tokens so
DatasetCsvDropzone-like behavior is consistent across light/dark.

[awkoy]

Partly addressed: b474cef extracts getStudioCardConfigs so the card copy/icon/routing is shared between the populated cards and the empty state. The remaining bit (chip/tint colors -> main.scss vars + .dark) I'd rather not guess at — these are Figma light-mode-specific tints with no dark equivalent yet. Flagging for design to provide the dark-mode card treatment, then I'll tokenize in a follow-up.

[baz-reviewer]

Thanks, that makes sense — noted. I'll save this to memory once the PR is merged.

[baz-reviewer]

Hard-coded status colors ignore dark theme

STATUS_DOT_COLOR and the <Tag> styles use raw hex values instead of the theme variables from main.scss, so the status pill stays on light-mode colors in dark mode — should we move these to CSS variables or theme-aware utility classes?

Want Baz to fix this for you? Activate Fixer You can also update your AI coding guidelines based on this comment by apply pr to [branch name]

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/opik-frontend/src/v2/pages-shared/optimizations/OptimizationStatusTag/OptimizationStatusTag.tsx
around lines 10-15 and 27-37, the `STATUS_DOT_COLOR` map and the `Tag` className
(`border-[#f1f5f9] bg-[#f8fafc]`) hard-code light-mode hex colors instead of using the
existing theme CSS variables/tokens used by `main.scss` and its dark overrides. Refactor
by replacing the hex values with theme-aware CSS variables (e.g., map each
`OPTIMIZATION_STATUS` to a `var(--...)` token) and update the `Tag` styling to use theme
tokens or utility classes that resolve to dark-mode values. If the needed tokens don’t
exist yet, add them to the theme stylesheet (main.scss and dark overrides) and reference
those variables from this component so the status tag tracks both themes.

[baz-reviewer]

Commit 9f323b3 addressed this comment by replacing the hard-coded status dot hex values with theme CSS variables (var(--color-green-bright), var(--color-red), hsl(var(--light-slate))). That makes the status indicator theme-aware instead of fixed to light-mode colors.

[baz-reviewer]

Inconsistent optimization status colors

OptimizationStatusTag centralizes the status color mapping, but the v2 detail header still uses its own STATUS_TO_VARIANT_MAP, so the list and header can show different colors for the same status — should we reuse the shared map there too?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/opik-frontend/src/v2/pages-shared/optimizations/OptimizationStatusTag/OptimizationStatusTag.tsx
around lines 8-16 (the status-to-color mapping), ensure this shared
OPTIMIZATION_STATUS→color map is the single source of truth. Refactor any other
components (notably the v2 detail header and trials/list renderers) that still define
their own STATUS_TO_VARIANT_MAP to instead import and use the same mapping (or route
through OptimizationStatusTag) so RUNNING/COMPLETED/INITIALIZED/CANCELLED/ERROR render
identical colors across surfaces. Verify by checking the header and list/trials for each
status and removing/unused duplicate maps after wiring them to the shared one.

[awkoy]

Fixed in b474cef. The v2 run-detail header now renders the shared OptimizationStatusTag instead of its own STATUS_TO_VARIANT_MAP, so the list and header show identical status colors + the same pill+dot styling.

[baz-reviewer]

Commit b474cef addressed this comment by replacing the v2 detail header's local STATUS_TO_VARIANT_MAP/Tag usage with the shared OptimizationStatusTag. That makes the header use the same status-to-color mapping as the list, eliminating the inconsistent colors for the same optimization status.

[baz-reviewer]

Low-contrast trend tags

PercentageTrend now uses text-[var(--color-green-bright)] / text-[var(--color-red)] on the existing Tag pill backgrounds, so the percentage label and lucide icon lose contrast and become hard to read in every v1/v2 caller — should we keep --tag-green-text / --tag-red-text here, or switch to darker trend tokens?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/opik-frontend/src/shared/PercentageTrend/PercentageTrend.tsx around lines 48-50
(the trend style color mapping for `green`/`red`), the component uses
`text-[var(--color-green-bright)]` / `text-[var(--color-red)]`, but the Tag backgrounds
remain `bg-[var(--tag-green-bg)]` / `bg-[var(--tag-red-bg)]`. Refactor the color mapping
so the `green`/`red` variants use the Tag’s paired text token(s) (e.g.,
`--tag-green-text` / `--tag-red-text`) or switch to a darker trend token that preserves
contrast on those pill backgrounds, ensuring both the percentage label and lucide icon
inherit the corrected text color. Verify readability/contrast for all v1/v2 callers
using the Tag background presets.

[baz-reviewer]

Commit b474cef addressed this comment by removing the explicit bright trend text classes from PercentageTrend and letting the Tag variant supply its own paired text color. That restores contrast for both the percentage label and the lucide icon on the tinted tag backgrounds.

[awkoy]

Fixed in b474cef. Removed the bright-color override on PercentageTrend's Tag — it now uses the Tag variant's own text token, so the % label + icon keep proper contrast on the tinted tag background in every v1/v2 caller. The vivid green (--color-green-bright) now lives only in the runs-list metric pill, where the icon sits on a neutral #f8fafc surface (matches Figma 689:34516).

[baz-reviewer]

The isFinite(percentage) guard blocks getTrendConfig() when calcFormatterAwarePercentage() returns Infinity (i.e. baseline === 0), so compact mode drops the trend icon entirely for zero-baseline comparisons — should we still compute the trend variant for non-finite values and just null out the percentageLabel?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

In
apps/opik-frontend/src/v2/pages-shared/experiments/MetricComparisonCell/MetricComparisonCell.tsx
around lines 35-38 inside the `compact` branch, refactor the `trendConfig` construction
so `getTrendConfig()` is still called for non-finite percentages (Infinity/-Infinity
from `baseline === 0`), preserving the icon-only `PercentageTrend` badge behavior. Keep
`percentageLabel` as null when the percentage is non-finite so no "%" text is shown, but
ensure `trendConfig.Icon` is always available for zero-baseline comparisons. Add or
update a unit test/story for `baseline === 0` cases to prevent regressions.

[awkoy]

Fixed in ac6687c. Compact mode now computes the trend variant whenever a percentage exists (including Infinity from a zero baseline) and only drops the numeric label when the value isn't finite — so zero-baseline comparisons keep their direction icon.

[baz-reviewer]

Commit ac6687c addressed this comment by removing the isFinite(percentage) check from trendConfig creation, so compact mode still computes the trend icon for Infinity/-Infinity values from zero baselines. It also keeps percentageLabel null for non-finite percentages, preserving the icon-only badge behavior.

[baz-reviewer]

The compact pill uses hard-coded spacing (gap-1.5, px-1.5, py-0.5) and color classes (border-[#f1f5f9], bg-[#f8fafc]), so it drifts from the design system and won't follow theme switches — should we swap these for approved spacing steps and theme-aware tokens, as .agents/skills/opik-frontend/ui-components.md suggests?

Want Baz to fix this for you? Activate Fixer You can also update your AI coding guidelines based on this comment by apply pr to [branch name]

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/opik-frontend/src/v2/pages-shared/experiments/MetricComparisonCell/MetricComparisonCell.tsx
around lines 46-48 (the `if (compact)` branch rendering the neutral trend pill div): 1.
Spacing: Replace non-standard utility classes `gap-1.5`, `px-1.5`, and `py-0.5` with
approved spacing steps from `.agents/skills/opik-frontend/ui-components.md` (e.g.,
closest allowed `gap-2|4|6|8` and `p-2|4|6` equivalents). If the design specifically
requires these exact values, add an explicit documented exemption reference in a
comment. 2. Colors: Remove hard-coded Tailwind color classes `border-[#f1f5f9]` and
`bg-[#f8fafc]`. Refactor to use existing theme-aware classes/tokens (e.g., the same
neutral surface styling used by the status tag) or, if no matching token exists, add a
dedicated CSS variable pair for the pill surface in `main.css` under `:root` and
`.dark`, then reference those variables via the component's className. Ensure the pill
background and border automatically switch in dark mode.

[awkoy]

The spacing matches the Figma cell spec (689:34516) and uses standard Tailwind steps (outer gap-1.5=6px, pill gap-1=4px, px-1.5=6px, py-0.5=2px). The neutral surface (#f8fafc/#f1f5f9) is deliberately identical to the shared OptimizationStatusTag pill — I'd rather tokenize that surface (with .dark overrides) across the status tag + metric pill together, as the same follow-up as the card-tokens comment, than diverge one pill now.

[baz-reviewer]

Thanks, that makes sense — the spacing is intentional per Figma, and the shared neutral pill surface should be tokenized together rather than changed in one place first. I'll save this to memory once the PR is merged.

[baz-reviewer]

Commit 4326ecd addressed this comment by replacing the pill’s hard-coded border/background colors with shared CSS variables (--pill-neutral-bg / --pill-neutral-border) and adding dark-mode values in main.scss. The compact pill now follows theme switches, even though the spacing classes were left as-is per the discussion.

[github-actions]

🔄 Test environment deployment process has started

Phase 1: Deploying base version 2.1.13-5869 (from main branch) if environment doesn't exist
Phase 2: Building new images from PR branch awkoy/opik-7041-runs-list
Phase 3: Will deploy newly built version after build completes

You can monitor the progress here.

[CometActions]

✅ Test environment is now available!

To configure additional Environment variables for your environment, run [Deploy Opik AdHoc Environment workflow] (https://github.com/comet-ml/comet-deployment/actions/workflows/deploy_opik_adhoc_env.yaml)

Access Information

• URL: https://pr-7227.dev.comet.com
• Cluster: comet-ml-development
• Namespace: pr-7227
• Version: 2.1.13-7227-merge-2417
• Application logs: View in Grafana

The deployment has completed successfully and the version has been verified.

[baz-reviewer]

cards.map returns <Button>s without a key, so React can't reconcile instances across rerenders and may lose focus/hover state — should we add key={id} to the root Button?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

In
apps/opik-frontend/src/v2/pages-shared/optimizations/StudioTemplates/StudioTemplates.tsx
around lines 51-63, the `cards.map(({ id, icon: Icon, title, description, onClick }) =>
...)` callback renders a `<Button>` for each card without a stable React `key`. Add
`key={id}` to the root `Button` element returned from the map, using the existing `id`
from the destructured card data. This removes React's key warning and ensures correct
reconciliation for focus/hover state during rerenders.

[github-actions]

🔄 Test environment deployment process has started

Phase 1: Deploying base version 2.1.13-5869 (from main branch) if environment doesn't exist
Phase 2: Building new images from PR branch awkoy/opik-7041-runs-list
Phase 3: Will deploy newly built version after build completes

You can monitor the progress here.

[CometActions]

✅ Test environment is now available!

To configure additional Environment variables for your environment, run [Deploy Opik AdHoc Environment workflow] (https://github.com/comet-ml/comet-deployment/actions/workflows/deploy_opik_adhoc_env.yaml)

Access Information

• URL: https://pr-7227.dev.comet.com
• Cluster: comet-ml-development
• Namespace: pr-7227
• Version: 2.1.13-7227-merge-2422
• Application logs: View in Grafana

The deployment has completed successfully and the version has been verified.

[CometActions]

🌙 Nightly cleanup: The test environment for this PR (pr-7227) has been cleaned up to free cluster resources. PVCs are preserved — re-deploy to restore the environment.

[github-actions]

🔄 Test environment deployment process has started

Phase 1: Deploying base version 2.1.13-5869 (from main branch) if environment doesn't exist
Phase 2: Building new images from PR branch awkoy/opik-7041-runs-list
Phase 3: Will deploy newly built version after build completes

You can monitor the progress here.

[CometActions]

✅ Test environment is now available!

To configure additional Environment variables for your environment, run [Deploy Opik AdHoc Environment workflow] (https://github.com/comet-ml/comet-deployment/actions/workflows/deploy_opik_adhoc_env.yaml)

Access Information

• URL: https://pr-7227.dev.comet.com
• Cluster: comet-ml-development
• Namespace: pr-7227
• Version: 2.1.13-7227-merge-2430
• Application logs: View in Grafana

The deployment has completed successfully and the version has been verified.

[CometActions]

🌙 Nightly cleanup: The test environment for this PR (pr-7227) has been cleaned up to free cluster resources. PVCs are preserved — re-deploy to restore the environment.

[aadereiko]

LGTM! Nice work :)

[CometActions]

🌙 Nightly cleanup: The test environment for this PR (pr-7227) has been cleaned up to free cluster resources. PVCs are preserved — re-deploy to restore the environment.

[CometActions]

🌙 Nightly cleanup: The test environment for this PR (pr-7227) has been cleaned up to free cluster resources. PVCs are preserved — re-deploy to restore the environment.

[CometActions]

🌙 Nightly cleanup: The test environment for this PR (pr-7227) has been cleaned up to free cluster resources. PVCs are preserved — re-deploy to restore the environment.

[github-actions]

🔄 Test environment deployment process has started

Phase 1: Deploying base version 2.1.13-5869 (from main branch) if environment doesn't exist
Phase 2: Building new images from PR branch awkoy/opik-7041-runs-list
Phase 3: Will deploy newly built version after build completes

You can monitor the progress here.

[CometActions]

❌ Test environment deployment failed

The deployment encountered an error. Please check the deployment logs for details.

[CometActions]

❌ Test environment deployment failed

The deployment encountered an error. Please check the deployment logs for details.

[awkoy]

✅ Test environment is now available!

Access Information

• URL: https://pr-7227.dev.comet.com
• Cluster: comet-ml-development
• Namespace: pr-7227
• Version: 2.1.13-7227-merge-2474
• Application logs: View in Grafana

The environment was rebuilt after its EBS volumes were reaped by the nightly cleanup (all 9 pods now Running).

[CometActions]

🌙 Nightly cleanup: The test environment for this PR (pr-7227) has been cleaned up to free cluster resources. PVCs are preserved — re-deploy to restore the environment.