Skip to content
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 1,141 commits into from
Sep 27, 2023
Merged

chore(release): 7.0.0 #13311

merged 1,141 commits into from
Sep 27, 2023

Conversation

sfoster1
Copy link
Member

This is the release tracking branch for 7.0.0.

andySigler and others added 25 commits August 11, 2023 15:31
…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.
@sfoster1 sfoster1 requested review from a team as code owners August 15, 2023 20:23
@sfoster1 sfoster1 requested review from smb2268 and removed request for a team August 15, 2023 20:23
sanni-t and others added 26 commits September 19, 2023 18:12
#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.
…#13613)

add open door status check to display open door alert modal for odd and fix protocol run header
banner rendering bugin desktop app

fix RQA-1604
* 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
…13622)

this is a fallback to avoid a stuck disconnect modal loading state if the browser is unable to
respond to a successful disconnect wifi request

closes RQA-1495
* 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
)

* fix(app): fix desktop door status check condition for run button
Copy link

@nusrat813 nusrat813 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@sfoster1 sfoster1 merged commit b8dd3f3 into release Sep 27, 2023
@koji koji deleted the chore_release-7.0.0 branch July 4, 2024 00:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.