Chore Release v8.3.0 #17186
Open
Chore Release v8.3.0 #17186
+223,476
−112,052
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
<!-- 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 Hardware got back to me with some updated numbers. <!-- 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. -->
…ugh_pcr_lid (#16849) <!-- 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 Adds compatibility between `biorad_96_wellplate_200ul_pcr` and `opentrons_tough_pcr_auto_sealing_lid` with stacking z offset ## Test Plan and Hands on Testing - Tested on thermocycler in ABR ## Changelog - added `biorad_96_wellplate_200ul_pcr` stacking offset to shared data file ## 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. -->
…se behavior (#16889) This PR addresses several functional issues with our LabwareTools component, produced when adding labware to the starting deck state. Here, I add filtering to populated expanded categories, allow independent expand/collapse toggling for multiple categories simultaneously, and auto expand/collapse all categories based on the state of the current search term. NOTE: This component is pretty bloated as is, and I think we can address condensing filtering logic and improving performance in a followup. Also, I notice a ton of rerenders after mounting— I will address in a followup. Closes RQA-3590
<!-- 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 new pipette type features a different threaded rod drive nut and some other mechanical changes that increase the maximum speed that the plunger can move so that this pipette can be used in emulsification applications. <!-- 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. -->
…bware fields are unselected (#16894) fix RQA-3622 <!-- 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 the `updatePatchOnPipetteChannelChange` in `dependentFieldsUpdateMoveLiquid` to allow switching from a multi-channel to a single channel pipette when source and destination labwares field are empty. ## 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. --> - add a transfer step with no labware on deck - switch pipettes correctly responds when labware fields are empty. ## 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 <shiyaochen@admins-MacBook-Pro.local>
…me and position type (#16682)
<!-- 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 adds support on the python side for the new pipette so we can provision and load them <!-- 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. -->
<!-- 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 In order to simplify and make future planning for how to display this OEM rename emulsify to EM everywhere for the new 8 channel <!-- 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. -->
… and update path selection for trash bin (#16908) fix RQA-3607 <!-- 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. --> In this PR, I updated the `SlotOverflowMenu` to disallow adding liquid and renaming labware for tipracks on adapters. Additionally, I updated `updatePatchOnWellRatioChange` to check if the `dispense_labware` includes 'movableTrash' or 'fixedTrash'. This fixes the issue where the consolidate path could not be selected when dispensing liquid into the trash bin. ## 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. --> - Added const `isTiprackAdapter` in `SlotOverflowMenu` to check if the slot is a tiprack adapter. ## 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 <shiyaochen@admins-MacBook-Pro.local>
* fix(protocol-designer): fix navbar z-index issue
# Overview Updating versioning page and API reference for changes to mix behavior <!-- 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 http://sandbox.docs.opentrons.com/docs-lld-mix/v2/ <!-- 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 4 lines in versioning.rst to provide description of changes to mix behavior in version 2.21 2 lines in instrument_context.py to provide description of changes to mix behavior in version 2.21 <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests no special requests <!-- - 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. -->
…16922) # Overview Ensures data collection scripts can all use the same IPs.json file when connecting to robots --------- Co-authored-by: rclarke0 <rhyann.clarke@opentrons.com>
…s to list of robot ips (#16909) # Overview Adds the ability to push one or more folders to one or more roots at once ## Test Plan and Hands on Testing Manually tested functionality of command ## Changelog Added push-folder definition to opentrons makefile --------- Co-authored-by: rclarke0 <rhyann.clarke@opentrons.com> Co-authored-by: Rhyann Clarke <146747548+rclarke0@users.noreply.github.com>
# Overview Fixes the issue of make-simulate not simulating liquid setups in protocols folder --------- Co-authored-by: rclarke0 <rhyann.clarke@opentrons.com>
# Overview Documents how to use the Opentrons Tough PCR Auto-sealing Lids and Opentrons Flex Deck Riser in a Python protocol. ## Test Plan and Hands on Testing - [Sandbox](http://sandbox.docs.opentrons.com/docs-tc-lids/v2/modules/thermocycler.html#auto-sealing-lids) - all new code samples pass simulation ## Changelog - New section on auto-sealing lids - Change load statement at top of article to use Opentrons PCR plate instead of NEST ## Review requests - Completeness, clarity, etc. - Double-check code - There is some deliberate vagueness around lid loading that is meant to future-proof against labware schema and API changes ## Risk assessment none, docs.
# Overview AUTH-851 Export the liquid classes we loaded into the Protocol Engine to the `StateSummary`, which will let clients see what liquid classes we loaded. The liquid classes are stored internally as a map of `{liquid_class_id -> LiquidClassRecords}`, but following the convention for the other fields in the `StateSummary`, we want to export the liquid classes as a list, so this PR defines a new `LiquidClassRecordWithId` class for the summary. The fields in the `StateSummary` in turn are propagated to the CLI `AnalyzeResults`, and are mirrored to the robot-server `CompletedAnalysis`, `Run`, and `MaintenanceRun` models. So every call-site that uses those classes had to be updated, as well as every test that checks those classes, as well as 200 snapshot tests -- which was kind of painful. ## Test Plan and Hands on Testing I'm relying on the CI tests to make sure I found all the call-sites that are affected. (We don't yet have any protocols that load liquid classes, but when we do, we can probably add integration tests to show that the liquid classes end up in the summaries.) ## Review requests I recommend collapsing the `analyses-snapshot-testing/` when looking at this PR in Github. There are so many snapshot changes that Github sometimes errors out when trying to render the diff. The primary files with code changes are: - `api/src/opentrons/protocol_engine/types.py` - `api/src/opentrons/protocol_engine/state/state.py` - `api/src/opentrons/protocol_engine/state/state_summary.py` - `api/src/opentrons/cli/analyze.py` - `robot-server/robot_server/runs/run_models.py` - `robot-server/robot_server/protocols/analysis_models.py` - `robot-server/robot_server/maintenance_runs/maintenance_run_models.py` The other files are pretty mechanical changes. ## Risk assessment Low risk, should affect dev only. --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: y3rsh <502770+y3rsh@users.noreply.github.com>
Add hover state and fix border radius for EmptySelectorButton component Closes RQA-3659
…6936) Add optional shrinkToContent to Tag component Closes [RQA-3667](https://opentrons.atlassian.net/browse/RQA-3667)
…16939) * fix(protocol-designer): fix Incorrect copy in IncompatibleTipsModal
… tag (#16938) * fix(protocol-designer): switch back textarea from component to styled tag
y3rsh
added
the
DO NOT MERGE
## Overview This PR is the rebased version of #17141
opentrons_simulate tries to see if any json file it can reach is a labware and load it if so. We recently changed the exceptions we raise in verify_labware_definitions if that call fails, so now instead of ignoring the file on exception opentrons_simulate raises the error through and terminates. No good! Change the exception to something a little saner and make sure we can actually ignore invalid labware files in sim. Closes RQA-3820
We pipe errors from nmcli straight to the display when we get them. NMCLI has famously awful errors. We don't want to always squash them, because they could be useful, but in the case of a mis-entered WPA2 PSK, we can be pretty sure that's the problem. This will now say "check your wifi credentials" <img width="607" alt="Screenshot 2025-01-07 at 4 46 15 PM" src="https://github.com/user-attachments/assets/d9006f01-37e8-4221-812a-900ffcb61960" /> ## Testing - [x] Connect to a wifi network and purposefully enter the wrong password; you should get a less awful message. Note that this only actually works if you're disconnected from wifi when you try to connect; if you're connected to wifi and then try and connect to a network and use the wrong password, you just don't get a result because the request went out over the original wifi network which got disconnected. It's the same code on the flex, ot-2 on the desktop (the ODD has a different message). Closes RSQ-3
Fix a flaky test by running filesystem commands sequentially instead of in parallel.
This is very odd and I'm not sure when it would have changed but this is the thing the error message says to do. ## Testing - [x] does the apple build work - [x] does the apple build run
…rotocol (#17216) <!-- 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 We're doing a direct "load_definintion" call in this protocol so we need to update it to have the new OEM arg added in 8.3 <!-- 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. -->
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## release #17186 +/- ##
===========================================
+ Coverage 63.28% 68.03% +4.75%
===========================================
Files 300 75 -225
Lines 15786 4965 -10821
===========================================
- Hits 9990 3378 -6612
+ Misses 5796 1587 -4209
Flags with carried forward coverage won't be shown. Click here to find out more. |
Came up for PD ( #17229 ), probably will come up here too. Let's get ahead of it. If the build passes this should be fine.
… can errors (#17117) <!-- 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 We occasionally get some ABR issues where the can bus says it's not receiving ACKs or that a move group says it didn't get all expected nodes, but reports [] as the missing nodes. I think the second bug is because we're checking with `if not self._moves[group_id]` instead of checking `if len(self._moves[group_id]) == 0:` Which should be equivalent but I think there may be some python cleanup bug that reports the list as true due to a remnant that hasn't been garbage collected yet. <!-- 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. -->
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