Chore Release v8.3.0 #17186
Merged
Chore Release v8.3.0 #17186
Conversation
This file contains 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
Selectively ignore or otherwise fix all Decoy related warnings in api tests
Resolve conflicts in: * api/src/opentrons/hardware_control/ot3api.py * api/src/opentrons/protocol_engine/commands/drop_tip.py
…update settings page to match design (#16937) fix RQA-3656, RQA-3650 <!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> 1. updated copy of incompatible file type modal to match with design 2. updated `Settings` to match with design ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. --> --------- Co-authored-by: shiyaochen <[email protected]> Co-authored-by: shiyaochen <[email protected]>
For both mix and move liquid batch edit toolboxes, fix padding for each field Closes RQA-3679
This fixes a case where in batch edit move liquid toolbox, well order was set to null, displaying an unknown translation in the WellOrder component. This PR refactors the util used to set the first and second well order values, providing a fallback if the value is null.
Closes EXEC-1027 After completing a run or during Error Recovery, the app runs tip detection logic to determine whether or not to pop the drop tip wizard. It does so by iterating through protocol analysis, keeping track of attached pipettes, and looking at specific tip exchange commands to determine whether a not a pipette has tips attached. While this approach works, it's both brittle (any changes to tip exchange commands breaks the logic) and also a command scanning operation. Now that we have tip status on our new /runs/:runId/currentState endpoint, we have a more robust option for determining tip status. There's one caveat: the robot and this util do have ideas of when a tip should be considered attached. On the app, because we want to show drop tip wizard when there might be a tip attached, such as during a failed pick up tip command, we assume there is a tip attached. In this instance however, the robot server does not think a tip is attached. Unfortunately, there's no way around manually accounting for these differences, but luckily they are few, and it's still a significant improvement over tracking every tip exchange command. There's another optimization we can make too: we don't actually need to poll /instruments for pipette data, because now, the only place we use that data is during the tip detection util. Instead, we can fetch it along with the other necessary resources when determineTipStatus is invoked. In short, these changes give us: * Much easier to reason about tip detection logic. * Significantly less brittle. * No command scanning. * No /instruments polling.
This PR fixes the layout for protocol steps, acocunting for TimelineAlerts. To maintain position without flickering when hovering timeline steps, we align the center content to the top of the container, and provide top padding dependent on the presence of timeline alerts. We also fix logic to not show timeline alerts if a stepform toolbox is open. Lastly, we make the container scrollable to handle timeline alerts and step summaries rendering at the same time, and set the timeline, stepform, and substeps toolbox heights to fill the view height with padding.
fix RQA-3682 <!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> Revert the hotkey copy to what it was before without the symbols ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. --> --------- Co-authored-by: shiyaochen <[email protected]>
* fix(protocol-designer): remove DisabledModal from PD
* fix(protocol-designer): update Heater-shaker to Heater-Shaker
# Overview List the new features of PAPI 2.21 on the Versioning page. Replaces #16935 ## Test Plan and Hands on Testing [Sandbox](http://sandbox.docs.opentrons.com/docs-versioning-2.21/v2/versioning.html#version-2-21) ## Changelog - New feature bullets (these are software-focused so they don't list all _docs_ changes) - Update version table - Bump `|apiLevel|` replacement ## Review requests Am I missing something? Feels light. But Thermocycler lids are not new API features (work in 2.16+). ## Risk assessment none, docs
Make does recipe dependences left to right. This fixes an issue where pushes would push a stale frontend.
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview Two changed - **Backend**: Previously, two endpoints end up using the same model, therefore confused during message processing. Present, two endpoints use separate models. - **Frontend**: Flex gripper is concerned with only Flex robot - opentrons-ai-client/src/resources/utils/createProtocolUtils.tsx Closes AUTH-1076 <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> ## Test Plan and Hands on Testing - Visit `opentrons.ai` - Click `Update an existing protocol` and follow instructions - Click `Create a new protocol` and follow instructions. Once you complete providing labware and other information. Click Submit then it will take you chat window where you need to see the generated protocol. It should not start like 'Simulation is successful'. <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests All tests are passing <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment Low <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. -->
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview Add labels to ABR JIRA Tickets ## Test Plan and Hands on Testing Tested script with different robots on different software changes ## Changelog - Adding label for if SW version is 8.2.0 - Added label if SW version is an internal release by searching for substring "alpha" - Added additional error handling for pulling data from ABR data sheets - Removed parent field - will revisit this later - ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. -->
… page (#16973) * fix(protocol-designer): remove unnecessary scroll bar from onboarding page
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview Fixed DVT1ABR3 Protocol and Updated liquid setup. ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog - removed abr3 csv file since the protocol no longer uses it - updated liquid set up for abr3 - changed 96 well plate to flat bottom for better compatibility with the plate reader. ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. -->
…slots (#16974) Fix logic in `createProtocolFile` and associated util `getTrashSlot` to correctly place staging areas and trash bins. Priority for staging area slots should be B3, C3, D3, A3, as specified by product. Trash bin should be in A3 unless all 4 staging area slots are added, in which case it gets bumped to A1. Also, I fix a padding issue in ProtocolOverview DeckThumbnail to account for right padding if any staging area slot is added. Closes RQA-3326
…ation part of an aspirate command (#16896)
…16975) On the WizardBody component used for creating a new protocol file, we optionally pass a tooltip to be shown when hovering the confirm button if it is disabled. This PR fixes a bug where the tooltip showed on hover even if the button is enabled.
* fix(protocol-designer): fix disabled condition in add a pipette
- the takeover modal for maintenance runs (RQA-3868) - run start confirmation (not tagged yet) - run cancel confirmation (RQA-3869) Closes RQA-3868 Closes RQA-3869 <img width="1046" alt="Screenshot 2025-01-17 at 4 58 05 PM" src="https://github.com/user-attachments/assets/66d00f4a-5e49-4f34-8049-ae74051f710e" /> <img width="1037" alt="Screenshot 2025-01-17 at 4 58 40 PM" src="https://github.com/user-attachments/assets/b39ef8b7-77aa-4cfe-8452-e447e439460b" /> <img width="1035" alt="Screenshot 2025-01-17 at 5 05 22 PM" src="https://github.com/user-attachments/assets/ffb47a09-0f02-4b26-b4e4-54fa43d7865c" />
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview This just copies the updated well geometry definitions from edge over to chore_release. <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. --> Co-authored-by: Caila Marashaj <[email protected]>
…oading (#17237) Add evo tip adapter and evo tips labware definition but as a labware so that liquid handling actions can happen in the 'labware'.
Covers EXEC-907 Introduces Evotip (or resin-tip) specific commands to the instrument context. These commands achieve the desired sealing, pressurization and unsealing steps for a resin tip protocol.
y3rsh
added
the
gen-analyses-snapshot-pr
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> Updated release notes for stable release. ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> No building on our end until the notes are live in the app, but possibility of format breaking is very low. ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> -removed specific mention of Evotips and Ultima PEEK pipettes -changed overall message to reflect our API 2.22 versioning message: "beta features for our commercial partners" ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> Just a double check on messaging to customers. ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. --> low. --------- Co-authored-by: Josh McVey <[email protected]>
We need to not use any schema v3 labware in 8.3 because we're going to change the schema. The thermocycler lids were only available in schema 3. Change that by making the lid v1 def a schema 2 def, and making a lid v2 def that is a schema 3 def. All the data is the same, and we even kept the stackLimit and added it to labware schema 2, so all the machine behavior should be exactly the same. The only other thing that's not in schema 2 now is the new lid stuff support, but that code isn't in 8.3 so we should be good. Closes EXEC-1180 ## review - seem ok? ## testing - run a smoke test for these. the data is literally all the same and nothing identity checks schemas, just whether data is there, and the same data is all still there. --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: y3rsh <[email protected]>
…votip seal command (#17438) # Overview Moving the plunger the position to 400ul rather than the maximum volume of the 1000ul pipettes. ## Test Plan and Hands on Testing - Verify that we can still push out liquid OK from the resin tips. ## Changelog - Modify the plunger volume aspirated to a lower number to avoid large pressure build-ups. ## Risk assessment Low. Beta feature
We had the evotips labware and adapter as schema 3 labware. This was probably necessary while this was a 3-element stack, but now it is not, and we need to avoid shipping schema 3 labware in 8.3 so that we retain the ability to change it. Closes EXEC-1179 ## review - seem fine? ## testing - smoke test. nothing checks schema identity, just whether data is there, and all the data that the code in 8.3 uses is still there.
…ips (#17455) Cherry-picked commit for 8.3.0 release branch Original PR: #17412 Closes RQA-3790 # Overview `Well.has_tip` property has been checking for only clean/ unused tips since API v2.2 but the docstrings don't mention that. That has understandably caused some confusion in protocol behaviors. This PR helps mitigate that issue by clarifying the exact behavior of this property ## Risk assessment None. Co-authored-by: Max Marrone <[email protected]>
The continue button "continue" text in various network settings panels needs to come from the shared i18n source, which is where it is, not the device_settings i18n source, which is where it isn't. By knowing where continue isn't, we know where continue is, and by subtracting where continue isn't from where continue is we know where continue should be, and by making where continue should be go from where continue isn't to where continue is, eventually we end up where continue is. ## testing - put this odd on a robot - from the settings screen, connect to wifi and check that continue is localized. This should now happen in the "join other network" screen and in the "select authentication type" screen - from the first-run experience, try to connect via ethernet while an ethernet cable is unplugged and note that "no data" is now localized - from the first-run experience, try to connect via wifi and note that the same things are now localized as in the setup screen Closes RQA-3960
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> updating stable 8.3.0 release notes to include a message for users around the use of Mandarin in the app. the issue: -users change their language to Mandarin in v8.3.0 -users downgrade their software -the app is stuck with unsupported text (blank boxes) ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> -add 2 sentences; let users know to change the app language back to English in settings before downgrading their software ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. --> low
Needs to be from shared.
Add macos and ubuntu minimum versions to 8.3 release notes.
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.
v8.3.0