Chore release 8.8.0 into release #20004
Open
+231,865
−57,209
Conversation
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
…19765) Standardize AWS role usage for static deployments Problem: Static deployment workflows (Protocol Designer, Labware Library, and Docs) were using inconsistent AWS role secrets, making role management complex and potentially causing deployment failures. Changes: Renamed DOCS_SANDBOX_ROLE to STATIC_DEPLOYMENT_ROLE across all static deployment workflows Updated Protocol Designer workflow to use the unified role instead of PD_SANDBOX_ROLE Fixed sandbox bucket name from sandbox.designer.opentrons.com to opentrons.sandbox.designer to match actual S3 bucket Updated corresponding test assertions to reflect the new bucket name Kept domain URLs unchanged (sandbox.designer.opentrons.com) as these are the user-facing URLs Files Updated: .github/workflows/pd-test-build-deploy.yaml .github/workflows/ll-test-build-deploy.yaml .github/workflows/docs-build-deploy.yaml .github/workflows/docs-build.yaml scripts/static-deploy/deploy_config.py scripts/static-deploy/tests/test_deploy_config.py scripts/static-deploy/tests/test_deploy.py Result: All static deployments now use a single, consistent AWS role (STATIC_DEPLOYMENT_ROLE), simplifying role management and ensuring proper permissions across all static site deployments. Note: The STATIC_DEPLOYMENT_ROLE secret will need to be created/updated in GitHub repository settings with the appropriate AWS role ARN.
* fix(protocol-designer) fix liquid form submit issue
* fix(protocol-designer): fix export button z-index issue
…#19787) * fix(protocol-designer) fix whitescreen issue when clicking an adapter
# Overview This essentially adds the TrackFromLocation and the TrackToLocation to the protocol engine commands. It then passes new information down to the OT3Api, replacing the Z distance with the end point, and updating the motion utilities to create the target position from that instead of z_distance. If no TrackToLocation is provided to the engine command then it preserves the old behavior where it tracks the meniscus. As is the protocol api just preserves the current behavior, hooking up the TrackToLocation with that layer is another ticket. TODO add checking that makes sure the X/Y/Z move is a valid move that can occur within the timeframe of the plunger move.
Closes EXEC-1957 For the camera work, the filename created when saving an image will require certain metadata that is not solely available to PE, but some of which is available on the robot-server, RunFileNameMetadata. The FileProviderExecutor singleton will need to set this metadata on a per-run basis and also manage cleanup of this metadata when a run is un-currented.
# Overview Robot context was incorrectly kicking back that the p200_96 was not a 96 channel when someone tried to use it for resin tips. This just centeralizes the test into validation and adds a test that iterates through all the pipette names to make sure everything is working properly now.
chore(release): placeholder notes for internal 2.8.0
Update title to match designs: "Shake" -> "Shake speed" Closes RQA-4731
## Overview Closes EXEC-1907. ## Changelog Behind the concurrent module actions feature flag: * Update the copy of the existing modals that show up after you save a Temperature Module or Heater-Shaker step. * Remove the ability to skip adding the pause step. * Add new modals for Thermocycler lid, block, and profile steps. These modals aren't used anywhere yet.
…tors (#19791) Just deleting some dead code: * Delete the `collapsedSteps` part of Redux state, and its sole selector `getCollapsedSteps()`. * Delete the `getSelectedStepTitleInfo()` selector.
This PR fixes up `handleContinue` logic, specifically for OT-2 liquid handling forms. Here, I correctly display errors if clicking 'continue' when errors exist on the current page of the stepform, whereas previously, clicking 'continue' advanced the stepform page with null values, resulting in a whitescreen. I also refactor the `handleContinue` logic for readability. Closes RQA-4759
Needs to checkout before sending alerts
This PR continues the implementation of tip selection functionality in Protocol Designer. It enhances how tip states are visually represented and selected within the UI, expanding from static rendering to interactive tip selection and highlighting.
* feat(app): update slot detail containers
Closes EXEC-1969 For the upcoming camera capture work, we'll need to persist image files on the robot. We don't want to handle saving images in our persistence directory, because doing so opens up issues when performing database migrations. This commit adds a new robot setting, images_directory, which allows for specifying the directory in which images will be saved. We largely mirror the behavior of persistence_directory here: if no explicit env is passed, we create a temporary directory. By default via settings injection, if the persistence directory is /data/opentrons_robot_server, then the images directory is analogously specified as /data/images.
…#19796) baby step to fixing the slot overlay stuff is making the labware renders on the deck map the default view so i deleted the other view where it just showed the rectangle copy layers --------- Co-authored-by: Max Marrone <[email protected]>
* feat(app, components): update slot detail container
# Overview Implement `/camera` requests in app - Uses hook in run set up, camera slide out, and robot settings ## Test Plan and Hands on Testing - built dev app and toggled camera switches to ensure buttons in other areas of the app updated as well: https://github.com/user-attachments/assets/a18c188a-17cd-4616-8ae9-e6f3b2cc0f28 Camera tab for run set up when camera is enabled <img width="1386" height="473" alt="Screenshot 2025-10-16 at 12 50 44 PM" src="https://github.com/user-attachments/assets/bcac5c3f-4f12-40f2-81a4-a29285958ff8" /> ## Changelog - creates hook for `POST` request - implements hook in `CameraCard`, `ProtocolRunCamera` and `ProtocolRunSetup` ## To Do in future PR create a blank image gallery when camera is disabled Finishes EXEC-1835
# Overview Hook up end location to the protocol api layer. - update all the tests - add in a check for the old dynamic pipetting version and use the new version to preserve behavior - pass start and end locations down to the engine commands.
This PR adds new fields for `tip_tracking`, `tiprack_selected`, and `tips_selected` to moveLiquid and mix forms in PD. Also adds migration for 8.7.0
…volume is out of bounds (#20056) # Overview Add a default value for the thermocycler max block volume when the found well volume is out of bounds ## Test Plan and Hands on Testing Simulated protocol `/Users/rhyannclarke/opentrons/abr-testing/abr_testing/protocols/active_protocols/4_Illumina DNA Enrichment.py` with apiLevel to 2.27 and received this error: `ProtocolCommandFailedError [line 299]: Error 4000 GENERAL_ERROR (ProtocolCommandFailedError): InvalidBlockVolumeError: Thermocycler max block volume must be between 0 and 100, but got 150.0.` After the change was made, the protocol simulated successfully with `start_set_block_temperature()` and `set_block_temperature()` ## Changelog - Added default block temperatures based on if it was higher than the max or lower than the min ## Risk assessment low Closes RQA-4820
# Fix Slack notifications to prevent workflow failures Fixes two issues with Slack notifications: 1. **Added missing `webhook-type` input** to `simple-build-alert` action (required by `slackapi/[email protected]`) 2. **Made all Slack notifications non-blocking** by adding `continue-on-error: true` to 5 notification steps in `app-test-build-deploy.yaml` Slack notification failures will no longer cause workflow failures, while still logging warnings for debugging.
…20077) Ensures the configuration file that use to default to "NONE" now reinforces the new oe-core default.
# Overview This PR updates the OT3 Controller's motion planning to adjust the commanded speed for a multi axis move if one of the plunger's are in the moving axis. this ensures that the pipettes' plunger will move at the speed commanded. Right now we only move the plunger and other axis during dynamic pipetting so this won't affect anything else in the system. After doing it's best to adjust this speed, if the move is still impossible an error will be logged into the api logs.
… color on camera settings (#20061) # Overview Removed wrapping behavior of module icons in protocol card and robot card Corrected text on camera settings in run setup Updated camera enabled text to a chip ## Test Plan and Hands on Testing Smoke tested: <img width="931" height="332" alt="Screenshot 2025-11-06 at 12 35 10 PM" src="https://github.com/user-attachments/assets/696b8acd-a14f-4b32-95c6-7643240d3ee5" /> <img width="931" height="149" alt="Screenshot 2025-11-06 at 4 11 08 PM" src="https://github.com/user-attachments/assets/b37ebf6b-7a86-4b6b-95f8-98950bbbe47e" /> <img width="900" height="547" alt="Screenshot 2025-11-06 at 3 15 43 PM" src="https://github.com/user-attachments/assets/d8198898-5852-4930-9830-85385138b68c" /> <img width="913" height="564" alt="Screenshot 2025-11-06 at 3 21 59 PM" src="https://github.com/user-attachments/assets/7a5e8bcd-6cab-417a-9724-ac342613d165" /> <img width="991" height="617" alt="Screenshot 2025-11-06 at 4 19 05 PM" src="https://github.com/user-attachments/assets/d4c4266a-45b0-4c3d-874b-5078a79c564c" /> ## Risk assessment low Closes RQA-4819 Closes RQA-4825 Closes RQA-4824 Closes RQA-4830 Closes RQA-4823 Closes RQA-4835
Currently, we inject the `runId` into the secondary window, and that `runId` serves as the basis for determining whether or not we should render the stream. However, if a user keeps the secondary window open when creating a new run on the same robot, the stream still reflects the old run. To fix, we check if this robot has a current run, and use that as the basis for rendering the livestream. All of this works as expected largely because we block the "show livestream" button for historical runs.
…20082) # Overview Changes the `check_preferences` text to yellow if the image storage is almost full, red if the camera is disabled but needed for the run, grey if the camera settings are is ready to be confirmed, and green if the camera settings have been confirmed. ## Test Plan and Hands on Testing - smoke tested on robot https://github.com/user-attachments/assets/144dce45-58f7-4da8-b9d0-c7a819ca2176 ## Changelog - an additional param was added to check the storage info - camera set up is now being viewed as a module set up type to allow for checking of camera enablement and storage ## Review requests - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. ## Risk assessment - lowish - may have accidentally changed other text formatting Closes RQA-4828
Resolved conflicts: - protocol-designer/release-notes.md
We render "robot is busy" banners on the robot details and robot settings views, however, the conditions in which we disable certain actions (ex., uploading zip files to a robot or allowing recalibration) are inconsistent from the conditions in which we render the banner. Currently, we disable or enable certain actions based on a variety of factors: * Whether the robot is "busy", which is roughly defined as whether there is a maintenance run or protocol run in progress, or there is an active subsystem update. * Whether a protocol run exists. * Whether a user has clicked specific module CTAs. The implementation of this one currently lacks a way to disable the "robot is busy" state, so once those specific items were clicked, the robot was busy so long as a user was on the robot settings page. Another downstream consequence of this logic is that we permit desktop users to launch a maintenance run flow while another maintenance run is active. The solution in this commit is the following: * No actions of any kind should be permitted if the robot is busy (see the first bullet, above). This is the most conservative approach, but it is by far the least surprising to end-users. There's no more confusion why certain settings are disabled without the banner rendering and vice versa. For example, we could in theory update camera settings while a run is in progress, but under this proposal, a user wouldn't be permitted to do so. The additional (and more important benefit I think), is the code is significantly more auditable - we invoke the useIsRobotBusy hook exactly once at the top level component responsible for rendering all the settings, and that's it. * We only block updating by zip file if there is a current, non-terminal run. NOTE: The one spot that is quite annoying is still the whole "run uncurrenting" logic, which will cause the banner to persist when an end-user may think it shouldn't. This isn't a regression introduced by this commit, but yeah, if a user over-eagerly navigates away from a run and the ODD can't implicitly close the run context, then the banner persists...but that's a different problem for a different day I think.
…onsistencies (#20093) # Overview Added missing labware images and fixed brand casing inconsistencies ## Test Plan and Hands on Testing Smoke tested on labware-library <img width="422" height="349" alt="Screenshot 2025-11-10 at 11 00 42 AM" src="https://github.com/user-attachments/assets/10221ea4-8f57-4b76-9c6f-e265f1ee603c" /> <img width="424" height="351" alt="Screenshot 2025-11-10 at 11 00 56 AM" src="https://github.com/user-attachments/assets/accb27e7-9879-4509-addd-0a259e8593a4" /> <img width="428" height="353" alt="Screenshot 2025-11-10 at 11 01 07 AM" src="https://github.com/user-attachments/assets/85e50709-a7bb-48da-9f0c-94d702144494" /> <img width="429" height="349" alt="Screenshot 2025-11-10 at 11 02 40 AM" src="https://github.com/user-attachments/assets/a6dd5ac9-e9a1-4611-8bb1-5f7f8ed1726c" /> ## Risk assessment low Finishes AUTH-1941 & EXEC-1770 Other labware do not have tickets associated.
# Overview new motion planning from dynamic pipetting can trigger a zero move length error in a new spot so that call needs to be added into the try/except portion.
The old opentrons deploy actions would build the distributables as well as deploy them; now that we're using the pypi-maintained deploy actions, we need to build them explicitly (we can't use the ones we already built because that happened in a different job aka vm).
This reverts commit 7e313a3.
# Overview The JavaScript console for the ODD was filling up with log messages of: ``` [app//opt/opentrons-app/resources/app.asar/ui/assets/index-XXX.js] debug: Received action from main via IPC -------------------------------------------------- ▶ Object ``` which is not very helpful. This PR is a small tweak to inline the action into the log message so that you can see it without clicking on `▶ Object`, decluttering the console. #### Before: <img width="1176" height="586" alt="image" src="https://github.com/user-attachments/assets/fb503f36-337a-4031-a026-2067db8df67f"/> #### After: <img width="1166" height="432" alt="image" src="https://github.com/user-attachments/assets/ec79376f-c692-4b1f-a9b4-b7bfcb7c7fab"/> ## Test Plan and Hands on Testing Built the ODD and deployed it to AuthorshipPVT for hands-on testing. ## Risk assessment Low.
# Overview Specify Camera type based on robot type on peripherals card ## Test Plan and Hands on Testing Smoke tested <img width="390" height="172" alt="Screenshot 2025-11-10 at 11 54 37 AM" src="https://github.com/user-attachments/assets/8b4368b2-7776-402c-8e68-38b8557e339b" /> <img width="341" height="166" alt="Screenshot 2025-11-10 at 11 55 18 AM" src="https://github.com/user-attachments/assets/8b09ed20-0d1d-42cd-bee1-a415b14005c2" /> ## Changelog Conditionally displays camera type based on robot, added in camera icon ## Risk assessment low closes EXEC-2040
…20122) # Overview Plunger moves in the negative direction were broken because the unit vector is negative and the plan motion function expects speed to always be positive.
The old opentrons deploy actions would build the distributables as well as deploy them; now that we're using the pypi-maintained deploy actions, we need to build them explicitly (we can't use the ones we already built because that happened in a different job aka vm). ## Testing Unfortunately there's not much we can do here, but this is already broken and this is pretty straightforward.
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.
8.8.0