Skip to content

Conversation

@SyntaxColoring
Copy link
Contributor

@SyntaxColoring SyntaxColoring commented Oct 28, 2025

Overview

Protocol Designer feature flags come in two flavors: "user-facing" and "non-user-facing." User-facing flags are always accessible through the UI, even in production builds. Non-user-facing flags are also accessible through the UI, but only if the project was built with a OT_PD_PRERELEASE_MODE=1 environment variable.

Features in development are usually gated behind non-user-facing flags. So, to test those features in the sandbox, the sandbox builds need to set OT_PD_PRERELEASE_MODE=1.

Goes towards EXEC-1666 in general.

Test Plan and Hands on Testing

I've done this:

  1. Clear sandbox.designer.opentrons.com localstorage. (This is necessary to avoid confusing behavior where PD will, sometimes, remember the last value of OT_PD_PRERELEASE_MODE).
  2. Visit the sandbox link built from this PR. Go to the gear menu in the top-right. It should list all feature flags through the UI, not just the user-facing feature flags. For example, it should list "Enable Concurrent Module Actions."

Changelog

Update the GitHub Actions workflow to set OT_PD_PRERELEASE_MODE=0 for builds deemed "production" and OT_PD_PRERELEASE_MODE=1 for builds deemed "development."

Review requests

  • Is this a good idea?
  • Scrutinize my GitHub Actions YAML syntax.
  • The other way of solving this would have been to change Protocol Designer to look at NODE_ENV, which the workflow already sets, instead of OT_PD_PRERELEASE_MODE. My vague instinct, though, is that that wouldn't be proper. It feels like NODE_ENV=development should only control debug features in the build tools themselves, not control what the build produces. Like, in my mind, if this were C, NODE_ENV=development should be like using a debug build of gcc—it's different from running gcc -g -O0. See also https://vite.dev/guide/env-and-mode.html#node-env-and-modes.

Risk assessment

Medium. Might break the build. Might accidentally expose non-user-facing feature flags in production builds.

@SyntaxColoring SyntaxColoring requested a review from y3rsh October 28, 2025 14:32
@codecov
Copy link

codecov bot commented Oct 28, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 23.72%. Comparing base (9e1911d) to head (c3b7dfd).
⚠️ Report is 1 commits behind head on edge.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             edge   #19948      +/-   ##
==========================================
- Coverage   23.72%   23.72%   -0.01%     
==========================================
  Files        3542     3543       +1     
  Lines      298370   298442      +72     
  Branches    39808    39809       +1     
==========================================
  Hits        70797    70797              
- Misses     227550   227622      +72     
  Partials       23       23              
Flag Coverage Δ
protocol-designer 18.73% <ø> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 3 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Collaborator

@ncdiehl11 ncdiehl11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants