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.

Sign up for GitHub

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

Jump to bottom

Push-api from windows breaks the robot container #2305

Closed
sfoster1 opened this issue Sep 18, 2018 · 0 comments
Closed

Push-api from windows breaks the robot container #2305

sfoster1 opened this issue Sep 18, 2018 · 0 comments
Labels
api Affects the `api` project bug

Comments

@sfoster1
Copy link
Member

overview

When you do a make push-api from a Windows host, with certain git settings the files in api/resources will have carriage return characters injected in them. When those files are interpreted by the robot, it will choke on those characters.

current behavior

Doing a make push-api from a windows host will prevent the robot's container from booting.

steps to reproduce

Do a make push-api from a windows host

expected behavior

The robot should boot properly after the push.
@sfoster1 sfoster1 added bug api Affects the `api` project labels Sep 18, 2018
sfoster1 added a commit that referenced this issue Sep 18, 2018
@sfoster1
fix(api): Remove crs from scripts in api/resources
e07e59b 
If a wheel is built on Windows, there's a good chance there will be carriage returns in the scripts
in api/resources, which break the container initialization scripts. To avoid editing the files in
question in the repo, add a step during the wheel build that unzips the wheel, removes carriage
returns, and rezips it.

Closes #2305
sfoster1 added a commit that referenced this issue Sep 18, 2018
@sfoster1
fix(api): Remove crs from scripts in api/resources
5e693a5 
If a wheel is built on Windows, there's a good chance there will be carriage returns in the scripts
in api/resources, which break the container initialization scripts. To avoid editing the files in
question in the repo, add a step during the wheel build that unzips the wheel, removes carriage
returns, and rezips it.

Closes #2305
sfoster1 added a commit that referenced this issue Sep 18, 2018
@sfoster1
chore(git): Set api resources as always lf in git
8b5abfc 
Though it's convenient for windows devs to have autocrlf set, the files in api/opentrons/resources
_must_ always have lf, including locally, since they are interpreted by bash on the robot. Setting
text eol=lf here is like setting core.autocrlf to input.

Closes #2305
sfoster1 added a commit that referenced this issue Sep 18, 2018
@sfoster1
fix(api): Remove crs from scripts in api/resources
3da3fcb 
If a wheel is built on Windows, there's a good chance there will be carriage returns in the scripts
in api/resources, which break the container initialization scripts. To avoid editing the files in
question in the repo, add a step during the wheel build that unzips the wheel, removes carriage
returns, and rezips it.

Closes #2305
This was referenced Sep 18, 2018
Closed
Merged
sfoster1 added a commit that referenced this issue Sep 20, 2018
@sfoster1
docs(contributing): Ask Windows users to set core.autocrlf=input (#2332)
b319a95 
Setting core.autocrlf to something that inserts carriage returns on windows means that API pushes to
robots from windows will have carriage returns in the scripts in api/opentrons/resources, which
prevents the robot from booting.

Closes #2305
b-cooper added a commit that referenced this issue Sep 26, 2018
@b-cooper
Update Protocol Designer Beta Production (#2352)
7b31543 
* fix(app): Open external links in browser instead of app window (#2327)

* feat(api): Remove deck calibration from reset options (#2330)

Remove deck calibration from factory reset options, as deck calibration reset should not be done
outside of the context of recalibration

* docs(contributing): Ask Windows users to set core.autocrlf=input (#2332)

Setting core.autocrlf to something that inserts carriage returns on windows means that API pushes to
robots from windows will have carriage returns in the scripts in api/opentrons/resources, which
prevents the robot from booting.

Closes #2305

* fix(api): Update definitions for tuberacks (#2317)

* fix(api): Update definitions for 15ml tuberack, 50ml tuberack, and 15/50ml tuberack to match actual

Closes #2290

* Modify definitions based on practical test

* feat(app): Enable autoupdate on Linux by switching to AppImage builds (#2329)

Closes #2303

* chore(chore): add exception in gitattributes for our hex files (#2339)

* fix(protocol-designer): fix whitescreen on deleting blowout labware (#2341)

* fix unticketed bug: setting blowout to a trash-box in a step and deleting the trash box caused
whitescreen
*make labware dropdown blank when nonexistent labware selected

* fix(api): Update the aluminum block definitions to match drawings (#2342)

* fix(api): Update the aluminum block definitions to match drawings and experiments
* Rename definition in shared-data to match rename in default_containers.json and fix z height
* Closes #2292

* chore(release): 3.4.0 (#2338)

* fix(protocol-designer): fix tiprack diagram only displaying right (#2340)

Fix a small bug where the tiprack diagram in the new file modal would duplicate the diagram of the
selected right pipette tiprack instead of showing both selections.

* feat(api): add module firmware update endpoint (#2173)

Closes #1654 
Adds firmware update api methods and update server functions (for modules with old as well as new bootloader)
Adds a udev rule for new bootloader
Adds tests for modules and update_server endpoint

* feat(protocol-designer): add "app build date" field to PD saved files (#2350)

* chore(api): Cleanup unused api root level files (#2336)

There were some leftovers from days of old: we don't use pip or anaconda or PyInstaller anymore.

* refactor(api): invert control of system and server (#2318)

Closes #2185
Separates out the previously entangled server and system functions so that opentrons.main handles system configuration while server.main only configures and runs the server. Entrypoint is switched from opentrons.server.main to opentrons.main

* feat(api): Add hardware_control submodule (#2349)

The hardware_control submodule is the controller of the robot's hardware. Its API can move the robot at a level of abstraction that portrays the robot as a whole, not including the labware. In this PR, the module is a stub, and not used by default

Closes #2232

* fixup: More verbose names for file and thread locks
* fixup: use functools.wraps in log_call decorator

* ci(codecov): Fix uploading of python coverage (#2360)

* fix(protocol-designer): tweak analytics copy for accuracy (#2366)

Update the copy in the analytics disclaimer to accurately portray our data collection in beta.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
api Affects the `api` project bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sfoster1