Chore Release v8.3.0 #17186
Open
Chore Release v8.3.0 #17186
+223,352
−111,910
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 closes AUTH-1050 This PR introduces Anthropic model, named `claude-3.5-sonnet` in addition to OpenAI. <!-- 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 Please interact with UI <!-- 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 - integrated anthropic model and set it as default <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests **Review scripts:** - `opentrons-ai-server/api/domain/anthropic_predict.py` - `opentrons-ai-server/api/domain/config_anthropic.py` - `opentrons-ai-server/api/handler/fast.py` **UI** - Please interact with UI and create protocols. - not required to check `storage/docs` unless if you have time <!-- - 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. -->
…#16891) * (protocol-designer) fix liquid long name display issue in slot detail
* fix(protocol-designer): support responsiveness more
We had the ability to load liquids on individual Wells, but this creates an engine command per well - which can be very onerous for large labware - and requires loops and such to load liquids. The common case for loading liquids is that everything is the same, and the second common case is that you care about a labware as a whole at a time (e.g. because you're reading from a platemap). We can support these uses better by having Labware.load_liquid (for many wells with the same amount of liquid), Labware.load_liquid_by_well (more complex, for more complex use cases) and Labware.load_empty, all taking arguments of the type that you can derive from other PAPI methods or domain-specific reasoning. Also, remove well.load_empty because it wasn't shipped yet and is now duplicative. Closes EXEC-825
<!-- 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 <[email protected]>
…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 <[email protected]>
* 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 <[email protected]>
…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 <[email protected]> Co-authored-by: Rhyann Clarke <[email protected]>
# Overview Fixes the issue of make-simulate not simulating liquid setups in protocols folder --------- Co-authored-by: rclarke0 <[email protected]>
…ties (#16878) Modifies the schema from ticket AUTH-832, removes `default` key and refactors `byVolume` property schema --------- Co-authored-by: jbleon95 <[email protected]>
# 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.
* feat(protocol-designer): make timeline responsive
* chore(app): update import statements for react
* chore(components): clean up react imports
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.
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