-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(release): 7.0.0 #13311
Merged
Merged
chore(release): 7.0.0 #13311
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
…13288) * Added a fastapi dependency to assert that the estop is in a good state for certain endpoints * Added dedicated estop http errors to robot server * Added the check_estop dependency to protocol POST routes.
The OT-2 and the Flex have different default behaviors in hardware for how they should handle homing after drop tip. That was getting overridden by behavior in the protocol engine itself. Leave the defaults to the hardware.
…flex (#13234) The current app stack supports only one kind of update file and path. In internal-releases, we reuse that code for flex by pointing it at flex update media and flex robots... which just means the internal-release app can't update OT-2s with the automatically-distributed releases. It also renames from buildroot to robot update, fixes dev-mode updates, and lets you specify OPENTRONS_PROJECT in the ODD. The new update flow works by: - Downloading both ot-2 and flex update files, separately - Keeping them around separately (in the app data dir) - Keeping track of them in redux separately - Including changing selectors to require specifying a robot name so we can get the right kind of update - Pulling what kind of robot is getting updated from state when you start to update, and using the code paths previously only taken by user file robot updates (with the browse button) for everything Note: This PR changes the download location for robot updates to be targeted on new infrastructure for flex launch. Specifically, - internal-release robot software at ot3-development.builds.opentrons.com (sorry about the url, it's old). Flex builds can be seen here: https://ot3-development.builds.opentrons.com/ot3-oe/releases.json and OT-2 builds can be seen here: https://ot3-development.builds.opentrons.com/ot2-br/releases.json - release robot software at builds.opentrons.com. This infra isn't up yet, but we can still merge this if we want Also, I renamed all the redux and app-shell stuff from buildroot to robot-update. Specifying OPENTRONS_PROJECT in the odd: Add the ability to override OPENTRONS_PROJECT from the app-shell-odd makefile and add a log to the app-shell-odd code for what url we're lookinh for updates from and what we found. Fixing dev-mode updates: When we run the app in dev mode (i.e. with yarn electron /path/to/app/dir), electron-updater still runs but takes its settings from a dev-app-update.yml file instead of configuration interned by electron-builder. It also reads the app current version directly from package.json so you're always 0.0.0-dev. By swapping out the app update yml file depending on which opentrons project we're in we can point the dev app at the right place for its updates depending on the value of the OPENTRONS_PROJECT variable. This doesn't fix the current-version thing, but you can at least edit the package.json file to fix that and now get the right update-prompting behavior. More details about the update file Redux flow: Changes the update file selection flow to use different files for different robots. Since we already download the two different kinds of file in the shell, we need to figure out how to appropriately expose them to the app and then how to appropriately select them. That means we need details about the robot (which are available through redux on the app side) and we need to send them to the app shell via one of the shell actions; and we need to store the details about update availability separately for the two robots (and be able to retrieve them separately). First, storing and retrieving update details. This requires splitting the redux state into two, one for ot2 and one for flex; each has the same data about available system updates. The selectors that retrieve that data now require robot names because we need to know what robot kind to get data for. Second, sending the right file. There are a couple possibilities for where to do this, but there's one in particular that lets us bring the user-specified-update-file flow (i.e. the one where you click a button and pick a file from your filesytem) and the system automatic flow closer together: specify the file via a read file action that happens when you start an update. This is a generalization of the READ_USER_FILE flow: the system file, like the user file, would be stored in the redux mirror of the session; a new action called READ_SYSTEM_FILE that carries the kind of robot gets dispatched if you start a robot update without specifying your own file, and the flows are the same from there (including the response FILE_INFO action being the same between the two - it carries the same information). So the flow now looks like - robotUpdate:START_ROBOT_UPDATE with EITHER a robot-type or a filepath - if this was a filepath, robotUpdate:READ_USER_FILE to shell with path; - if this was a robot-type, robotupdate:READ_SYSTEM_FILE to shell with type; - shell reads appropriate filekind and responds with robotUpdate:USER_FILE_INFO - info is stored in redux session state - robotUpdate:CREATE_SESSION - (...the same flow...) - robotUpdate:UPLOAD_FILE, which now always carries a filepath read from the session state And the migration workflow is unchanged. Co-authored-by: Shlok Amin <[email protected]>
* feat(app): add run failed modal for desktop app
…lag toggles (#13241) Introduce variant of Labware Position Check that uses the flex's calibration probe instead of pipette tips for visual checks. Put it behind new lpcWithProbe feature flag, and allow feature flags to be toggled on and off in the ODD
…folding (#13219) adds the scaffolding to implement the module calibration wizard. updates module api types with moduleOffset and meta fields. updates shared-data module calibration types. re RAUT-549 --------- Co-authored-by: smb2268 <[email protected]> Co-authored-by: Brent Hagen <[email protected]>
* Add description. * Add integration test.
condition ODD cancel run modal run dismissal on stopped run status. navigate to protocols list page from protocol details back button. closes RQA-1174
when downloading run log, fetches the total length of commands initially in order to fetch all commands. closes RAUT-532
after clicking start run, users should be routed to the run preview tab on the protocol run page. this is necessary in order to show intervention modals. fixes a regression from prior desktop app behavior
This PR changes the app to deploy to builds.opentrons.com instead of the legacy bucket. It also refactors the app build workflow in some ways that should make it a little more pleasant to deal with: - Separate backend tests from builds - Reduce duplication between internal release and release builds - Make the logic about what kind of build we have clearer
* build: robot builds for all release types * allow other release branch format in robot builds * truncate changelogs if necessary * handle limiting the message more readably
Machinery directive requires specific color patterns for semantic actions. Update our status bar to be in line with the requirements. Closes RCORE-819
* feat(app): add loading skeleton to ODD ProtocolDetails route Adds a shimmer skeleton fallback and prevents Start Setup button selection until the protocol data loads. Also addresses an edge case concerning components rendering without data after the sever successfully responds. * fix(app): prevent protocol setup button resizing when disabled * fix(app): prevent screen jitter when transitioning from skeleton to page components Loading skeleton matches the ProtocolSetup components. Refactored skeleton to file and added testing. * feat(app): add loading spinner on Start Setup button press * fix typing errors * fix lint errors... * swapped isLoading logic * fix(app): add skeleton testing for protocol routes * Review fixes * final linting... * Refactored skeleton
…ata and requirements (#13295) * Add persistence snapshot test, and test for rerunnability. * Add test for local analysis rejection. * Add test for POST rejection. * Rename v6.2.0Large -> v6.2.0_large
fix(app): remove back to RobotDashboard button from RunningProtocol and RunSummary
I don't think this action likes having multiple globs as an artifact target, so do the three separately.
#13567) * updated TCV2 labwareOffset and its flex transform * added stackingOverlap with TCV2 for imp TC-related labware * update calibration block well z, update api tests
All the flex multi pipettes have different tip overlaps than we thought, so update them and also add entries for filter tipracks since they would otherwise use the default of 10.5mm which is definitely wrong.
fixes a reversion introduced by the Flex icon priority changes. since an OT-2 usb connection is actually an ethernet connection inside the frame of the OT-2, we need to only render the ethernet icon for the Flex. closes RQA-1556
…on sessions (#13607) * Move test_sesion.tavern.yaml to sessions/. * Add an integration test. * Do not require a "default" key within gripperOffsets. * Flesh out `get_labware_gripper_offsets()` docstring. * Fix state leakage between /sessions integration tests.
…3606) OT3 tiprack naming convention transitioned to "opentrons_flex_96_tiprack..." standard.
…ror message (#13609) * Map internal strings to user-facing strings. * Resolve todo in integration test.
* fix(app): display alerts for pipette offset discrepencies fix RAUT-737
* feat(app): fix small ui bugs on ODD
* fix(app): fix tc module calibration issue
* fix(app): fix open door alert modal display condition
* feat(app): oDD banners for pipette calibration warning fix RAUT-737 * Update app/src/organisms/Devices/InstrumentsAndModules.tsx Co-authored-by: koji <[email protected]> * format --------- Co-authored-by: Seth Foster <[email protected]> Co-authored-by: koji <[email protected]>
The issue was that the implementation couldn't handle OT-2 case since the initial renderModuleStatus was the button. Update the initial renderModuleStatus and update the conditions. close RQA-1549
* fix(app): update software update modal text style
* fix(app): enable doorSafetySwitch for OT-2
When detaching a gripper instrument, the left hand text prompts the user to remove the bottom screw twice without referencing the top screw. This PR changes the first reference of unscrewing the bottom screw to the top screw.
* fix(app): update conditional calibration required banner rendering Clearing pipette/gripper calibration now sets the calibrated offsets to zero instead of clearing the calibrated offsets property. Checking the date last calibrated property is the easiest and most accurate way to determine if a calibration is necessary. * fix(app): hide OT-2 calibration banner when robot is not viewable
* fix(app): fix odd module screen update issue
a680b77
to
b8dd3f3
Compare
nusrat813
approved these changes
Sep 27, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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.
This is the release tracking branch for 7.0.0.