Chore Release 8.5.0 #18470
Open
Chore Release 8.5.0 #18470
+126,530
−9,620
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
Since we have isolated Robot Stack release 8.4 into `chore_release-8.4.0` we must lock down command schema 12 for that Robot Stack Release. If changes are needed to command schema 12 they must first be done in `chore_release-8.4.0` then incorporated in `edge` via a merge back. (cherry picked from commit 1e70394)
(cherry picked from commit 55b6310)
Merge chore_release-8.4.0 mergeback branch into edge Co-authored-by: Josh McVey <[email protected]> Co-authored-by: Jamey Huffnagle <[email protected]> Co-authored-by: Ryan Howard <[email protected]> Co-authored-by: Sanniti Pimpley <[email protected]> Co-authored-by: Andy Sigler <[email protected]> Co-authored-by: Seth Foster <[email protected]> Co-authored-by: emilyburghardt <[email protected]> Co-authored-by: Max Marrone <[email protected]> Co-authored-by: Jeremy Leon <[email protected]> (cherry picked from commit 26345e1)
…cter (#17937) This fixes a small problem I noticed with the `/clientData` endpoints. These endpoints have a path parameter that's an arbitrary client-defined ID, like `PUT /clientData/<id>`, `GET /clientData/<id>`. The string ought to be at least one character long, otherwise there's no way to distinguish `DELETE /clientData/<id>`, which deletes the specific entry represented by `<id>`, from `DELETE /clientData/`, which deletes all entries. This PR adds validation for that. (cherry picked from commit 1cddbbd)
…cstring (#17980) # Overview @ddcc4 spotted a typo in the code sample in this docstring. We accidentally used the deprecated pipette delay method, instead of the proper protocol delay method. ## Test Plan and Hands on Testing [Sandbox](http://sandbox.docs.opentrons.com/fix-delay-in-prepare_to_aspirate-docstring/v2/new_protocol_api.html#opentrons.protocol_api.InstrumentContext.prepare_to_aspirate) ## Changelog - Use the right method - Parentheses on method name 🧐 ## Review requests best to put this in `edge`, no? ## Risk assessment nil (cherry picked from commit 2dabd34)
…t_context.py (#17994) # Overview For some reason, we were mocking out the entire `protocol_api/validation.py` module in `test_instrument_context.py`. There is no reason to do that, since the validation functions are pure functions that don't rely on external objects, and we really ought to test the validation functions in our tests. Furthermore, we were abusing the mocks to make the validation functions do wild things: like mistranslating `Location`s into `WellTarget`s, or turning the `"never"` tip-replacement policy into `TransferTipPolicyV2.ONCE`. There is no good reason to do that, and it just makes the test logic ridiculously hard to follow. I need to fix this because I want to write a test for my change to the `mix()` function, but it was very hard to do so given how we were using `mock_validation`. ## Test Plan and Hands on Testing I examined all the usages of `mock_validation` by hand. It was very painful. ## Risk assessment Low. This is a test-only change. (cherry picked from commit 2fece0c)
# Overview This adds the new argument `mm_from_edge` to the `touch_tip()` public API function. The option is needed for PD protocols. And we generally think that it makes more sense for users to specify `mm_from_edge` instead of `radius`. Support for `mm_from_edge` already exists in the Protocol Core and Engine (PR #17107), so all we need to do is to pass the new argument along to the Core. We follow the same convention that we adopted in the Protocol Engine, that `radius` and `mm_from_edge` are mutually exclusive, so if the user specifies `mm_from_edge`, they must leave `radius` to its default value of 1.0 ## Test Plan and Hands on Testing I added unit tests to check for all combinations of `mm_from_edge` and `radius`. ## Review requests Do I need to do anything else for API versioning? What API version would this go into? ## Risk assessment Medium. We're adding a new API option, and we have to support API changes forever once released. (cherry picked from commit 63f1512)
Merging the latest chore_release-8.4.0 back to edge. Plus adding a fix for command schema 13 that was not available for release branch. --------- Co-authored-by: Josh McVey <[email protected]> Co-authored-by: Jamey Huffnagle <[email protected]> Co-authored-by: Ryan Howard <[email protected]> Co-authored-by: Sanniti Pimpley <[email protected]> Co-authored-by: Andy Sigler <[email protected]> Co-authored-by: Seth Foster <[email protected]> Co-authored-by: emilyburghardt <[email protected]> Co-authored-by: Max Marrone <[email protected]> Co-authored-by: Sarah Breen <[email protected]> Co-authored-by: Jeremy Leon <[email protected]> Co-authored-by: Jethary Alcid <[email protected]> Co-authored-by: TamarZanzouri <[email protected]> Co-authored-by: Ed Cormany <[email protected]> Co-authored-by: Caila Marashaj <[email protected]> (cherry picked from commit 3692478)
# Overview Change build process so only the PAPI v2 docs get built on every push. [Update: also keeping hardware docs dynamic.] Addresses RTC-711, although followup work may need to be done on AWS directly to add some robots.txt rules. ## Test Plan and Hands on Testing Spot check sandbox sites against current prod: - http://sandbox.docs.opentrons.com/infra-stop-building-old-docs/ot1/index.html - http://sandbox.docs.opentrons.com/infra-stop-building-old-docs/v1/index.html Everything should look the same. Not perfect, there is some formatting jankiness that I'm not attempting to fix. ## Changelog - new git ignore rules to track built copies of the archived docs sites - commit a copy of both sites - change `make -C api docs` to only build v2 and hardware docs. other sites can still be built, if needed, with other `make` commands. ## Review requests - **Is this the right way to go about this?** It works, but does it work how we want? - Is there anything in the Sphinx output that should still be ignored? I think not, but I'm not 100% - Double check built sites. - Also now is the time to speak up if you think any of these sites should go away forever 🚮 ## Risk assessment low-ish. you should basically never notice. (cherry picked from commit eb3aeb7)
…cent factory trip (#18021) <!-- 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 Everything is working smoothly on mp.96ch.200 branch, this is that branch, rebased onto edge and smoothed over so it can be merged into edge. <!-- 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: Mehdi Zaidi <[email protected]> Co-authored-by: Carlos <[email protected]> Co-authored-by: caila-marashaj <[email protected]> Co-authored-by: Andiiiiiiyy <[email protected]> Co-authored-by: wweiye <[email protected]> Co-authored-by: Jerome <[email protected]> (cherry picked from commit ff9e95b)
* refactor(shared-data): change liquid classes order (cherry picked from commit 0de3e83)
(cherry picked from commit 5b94322)
(cherry picked from commit bf13009)
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
# Overview Lint the Python protocol files distributed as part of the v2 API docs. Addresses RTC-137. ## Test Plan and Hands on Testing 1. Add `docs/v2/example_protocols` to the `black` command `make -C api lint` and `make -C api format`. Was going to add it to `flake` as well, but these files deliberately violate some `flake` rules, like never explicitly referring back to the trash bin but definitely requiring one to pass analysis. 2. Everything should fail because I formatted these files with tabs like a heathen. 3. Run `format` and hopefully everything works. ## Changelog - [x] Update Makefile - [x] Update Python protocols to pass new lint ## Review requests Cool cool? ## Risk assessment v low, shouldn't introduce any CI failures unless the example protocols are modified (cherry picked from commit 8e72a89)
# Overview Flow rates are, in fact, rates measured in **µL/s**. ## Test Plan and Hands on Testing sandbox ## Changelog Fix the unit and true up the table cells. ## Review requests squirrel? ## Risk assessment none (cherry picked from commit 67cffae)
The Makefile targets `test-py` and `circular-dependencies-js` were running a bunch of subcommands serially even though those subcommands were logically independent. This splits them up into recipes that can be run in parallel with `make -j`, following the existing pattern based on `%` wildcards. (cherry picked from commit bc8fcd6)
# Overview Python API docs PR corresponding to changes in #18180. ## Test Plan and Hands on Testing [Sandbox](http://sandbox.docs.opentrons.com/docs-combo-adapters-retired/v2/new_labware.html#loading-together) ## Changelog - Moves all mention of combination adapters into a note. - Indicates that they are deprecated as of API version 2.15 (which they effectively have been, even if we didn't strongly discourage their use). - List a couple features that will not work with them and say that future features are also not guaranteed. ## Review requests just accuracy ## Risk assessment nil (cherry picked from commit ec1ec02)
This fixes what I suspect are mistakes in our GitHub Actions workflows, which, in edge cases, could cause problems like workflows not triggering when they should. For instance: `*` looks like it's meant to match everything, but for that, we really want `**`, otherwise we fail to match things that contain slashes. `dir1/**/*.py` looks like it's meant to match any `.py` file under `dir1/`, but I think it will only match things like `dir1/dir2/file.py` and `dir1/dir2/dir3/file.py`, and fail to match things like `dir1/file.py` (cherry picked from commit 3c8b7fa)
# Overview Any movement related commands in the robot context should have run logs associated with them. ## Test Plan and Hands on Testing 1. Check that run logs get generated for robot commands. ## Changelog - Add run logs to robot context commands ## Review requests Check that the run log messages make sense. ## Risk assessment Low. Adding run logs to un-used API. --------- Co-authored-by: Seth Foster <[email protected]> (cherry picked from commit 3782455)
This deletes the `opentrons.protocol_engine.state.update_types.SIMULATED` sentinel object, which was not used for anything. (cherry picked from commit d0499e1)
Closes AUTH-1653 # Overview Meniscus relative positions for aspirate & dispense will now be relative to the position of meniscus of the liquid *after* the aspirate or dispense action. Updated the `absolute_point_from_position_reference_and_offset()` function to use `well.estimate_liquid_height_after_pipetting()` instead of `well.meniscus()` ## Risk assessment Low. Only affects meniscus-relative pipetting locations (cherry picked from commit 7429fae)
Closes EXEC-1466 Currently, when requesting a command slice or a command error slice via the HTTP API, the exact behavior varies depending on the run status, the “current” status of the run, and which parameters are (or are not) supplied. The behavior varies in the following way: * When invoking get_slice with identical cursor and pageLength parameters, there is inconsistency in the number of returned commands when the run is in a recovery state. * When a run is historical, an unsupplied cursor but a supplied pageLength returns the most recent pageLength commands, however, when a run is current, only the most recently running/executed command is returned. * The above always applies to run command errors. This commit fixes those issues by standardizing behavior in a manner that is most useful given typical client access patterns: if a cursor is not supplied but a pageLength is supplied, we return the pageLength most recent commands and command errors (so all behavior reflects the current behavior if the command slice is derived from a historical run). After doing a complete client-side audit, the client actually seemingly expects the API to behave this way, and has fortunately worked by chance. (cherry picked from commit 2c374ff)
(cherry picked from commit 5af0934)
Closes AUTH-839 # Overview - Adds the ability to create a new liquid class based on user-specified properties - Adds the ability to customize an existing liquid class based on user-specified properties ## Changelog - adds liquid class modifiers to enable custom liquid classes - adds the custom liquid class creator API - small changes to 'version' arg typing ## Risk assessment Low. Supplementary stuff. Doesn't modify existing infrastructure. (cherry picked from commit 88da5fa)
(cherry picked from commit b5cfdf4)
…18456) Closes AUTH-1654 # Overview Adds a method `LiquidHandlingPropertyByVolume.set_fixed_override()` which overrides the existing 'by volume' values with the provided value You would use this in a protocol like this- ``` water = simulated_protocol_context.define_liquid_class("water") water_props = water.get_for(pipette_50, tiprack) # Set flow rate of 20uL/sec for all volumes water_props.aspirate.flow_rate_by_volume.set_for_all_volumes(20) ``` ## Risk assessment Low-None. Very small addition to functionality that doesn't change any existing behavior. (cherry picked from commit 6e1e58d)
…y-17932', 'cherry-17937', 'cherry-17980', 'cherry-17994', 'cherry-18012', 'cherry-18016', 'cherry-18073', 'cherry-18077', 'cherry-18081', 'cherry-18142', 'cherry-18147', 'cherry-18151', 'cherry-18163', 'cherry-18171', 'cherry-18181', 'cherry-18191', 'cherry-18195', 'cherry-18203', 'cherry-18207', 'cherry-18215', 'cherry-18237', 'cherry-18249', 'cherry-18255', 'cherry-18259', 'cherry-18261', 'cherry-18266', 'cherry-18282', 'cherry-18319', 'cherry-18323', 'cherry-18326', 'cherry-18330', 'cherry-18337', 'cherry-18345', 'cherry-18383', 'cherry-18403', 'cherry-18405', 'cherry-18416', 'cherry-18449', 'cherry-18450' and 'cherry-18456' into chore_release-8.5.0
…" in chore_release-8.5.0 (#18472) This reverts commit d06a5f3. # Overview In PR #17854, @caila-marashaj deleted the `operation_volume` parameter from the call to `move_to_well()` in `aspirate_while_tracking.py`, asserting that "It was previously called with the `operation_volume` parameter. This is wrong because we need z tracking to start from where the meniscus currently is, not where it's going to be." That PR was checked into `edge`. I picked that PR into `chore_release-8.5.0`. But Caila's change somehow disappeared from `edge` entirely. The code in `edge` now **does** have the `move_to_well(operation_volume=-params.volume)` parameter. @ryanthecoder thinks Caila's change was probably deleted from `edge` by one of the mergebacks from `chore_release-8.4.0` into `edge`. Ryan says that we **do** want `move_to_well(operation_volume=-params.volume)`. So now I have to revert Caila's change in `chore_release-8.5.0`. ## Test Plan and Hands on Testing I'm taking Ryan's word for it that `move_to_well(operation_volume=-params.volume)` is correct :) But let's run the CI tests to see if everything passes. ## Risk assessment Low I hope. Ryan says that the version **with** `move_to_well(operation_volume=-params.volume)` is what we've tested and released, so we should use that.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## release #18470 +/- ##
============================================
+ Coverage 23.45% 55.57% +32.12%
============================================
Files 3191 3217 +26
Lines 267004 277351 +10347
Branches 24779 27929 +3150
============================================
+ Hits 62616 154151 +91535
+ Misses 204368 123014 -81354
- Partials 20 186 +166
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Closes RESC-461 Loading a module, aka the mag block, into slot C2 causes LPC to error out when setting a default offset. Product + Design are working on a longer term solution, but in the interim, we want to include something for 8.5. Select a default offset location for LPC based on slots that we know do not contain a module. We preferentially select C2 if available.
<!-- 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 Historically the Gravimetric and photometric fixtures in the factory have been running on scripts. This process is slow, hard to use, hard to update and not very flexible. This PR is the last in a long series of steps that will finally get us off the scripts and onto the protocol based version of this. This has been enabled by the recent features of LLD, Liquid Tracking, Liquid Classes, Run time parameters and error recovery. This PR also adds a new set of methods on the ot3api level that enables the hardware controller to easily pull sensor data from the instruments. <!-- 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 This does not touch any existing features, and only adds functions to a non-public api level so there is no additional testing that needs to be added for the release. <!-- 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. -->
Propagating labware setup crash fix and release notes updates.
…#18460) Covers RABR-777 Update the way we validate stacking of labware to ensure labware with only "default" stacking offset and no compatible parents and stack on everything
…fers (#18527) Renames the `visit_every_well` argument of the three liquid class transfers to `group_well`, reversing the boolean logic as well for this argument.
Closes AUTH-1952 # Overview When calculating current pipette volumes following liquid handling commands, the hardware controller does floating point math. This was resulting in small python-specific floating point errors which were essentially negligible in all practical sense but were causing `==` comparisons to fail. For the specific bug reported above, this floating point error was making the pipette's `current_volume` to be a value that's 'very close to' zero, but not zero, after doing a full dispense. This was preventing the harware controller from properly executing a `prepare_for_aspirate()` as it needs the current volume to be `0`. So, this PR prevents the bug from happening by making sure that the final pipette volume after a full dispense gets saved as `0uL` ## Risk assessment Low- bug fix only
<!-- 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 tucks in the last few changes for the DVT 96ch_200 into this release so ABR can get ahead of the game testing the 96 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. --> --------- Co-authored-by: Jerome <[email protected]>
…r + ethanol, 1ch + 8ch (#18521)
# Overview After various discussions we decided to rename the liquid class API methods: `define_liquid_class` -> `get_liquid_class` `define_custom_liquid_class` -> `define_liquid_class` ## Review requests - I've updated the API version required for using `get_liquid_class` as v2.24. Are we okay with that? I think it doesn't make sense to keep it 2.23 because technically, 2.23 had a `define_liquid_class` and not `get..`. ## Risk assessment None for production code. Refactor only. Internal stakeholders who have been using liquid classes will need to update their protocols and API versions.
# Overview Added new definitions for Axygen 96 wellplate 500ul, SMC 384 read plate, Corning 96 wellplate 360ul lid, ibidi 96 square well plate 300 ul. ## Test Plan and Hands on Testing Validated dims through a test protocol "labware def checker" and LPC. Created labware definitions from technical drawings in the Labware Expansion Excel sheet. <!-- - 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. --> Closes https://opentrons.atlassian.net/browse/AUTH-1942 --------- Co-authored-by: ABR <[email protected]> Co-authored-by: Rhyann Clarke <[email protected]>
…18560) # Overview Updates the gravimetric test script to use the new `get_liquid_class()` function and makes the gravimetric script always use the latest API version. ## Risk assessment None for production code. High for testing code if updating the api version is going to have a big impact on testing. If not, then low-none risk.
<!-- 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 ibidi Lid Definition and corning plate fixes ## Test Plan and Hands on Testing Tested with protocol `abr-testing/abr_testing/protocols/test_protocols/labware_def_checker.py` ## Changelog - Added ibidi lid definition - corrected offsets in corning lid definition: removed ability to stack on plates other than corning plate to prevent users from using the wrong lid, corrected display name, - adding testing capabilities for the lid to the ibidi plate ## 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. -->
…tric protocol (#18576) # Overview #18560 attempted to make gravimetric protocol use the latest API version automatically. But it did this wrongly. So reverting that change and manually changing the version to v2.24, the current latest. This PR also adds a test that would fail if gravimetric protocol's API version is not the latest one. ## Risk assessment None.
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.5.0
Release 8.5 isolation branch
chore_release-8.5.0targetingrelease