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

Set up continuous integration #29

Closed
fitzgen opened this issue Mar 18, 2019 · 4 comments
Closed

Set up continuous integration #29

fitzgen opened this issue Mar 18, 2019 · 4 comments
Labels
bug Something isn't working

Comments

@fitzgen
Copy link
Member

fitzgen commented Mar 18, 2019

Thought I already did this but I guess not >.<

I'd like to do Azure pipelines since they have a higher level of parallelism at the free tier than travis ci. Also, they're not recently acquired by a sketchy, strip-it-down-for-parts company that laid off a ton of people.
@fitzgen fitzgen added the bug Something isn't working label Mar 18, 2019
@rylev
Copy link
Collaborator

rylev commented Mar 26, 2019

@fitzgen this is done with #46. I think any further improvements should be separate issues.

@fitzgen
Copy link
Member Author

fitzgen commented Mar 27, 2019

Thanks!

@fitzgen fitzgen closed this as completed Mar 27, 2019
@samcday
Copy link
Contributor

samcday commented Mar 28, 2019

I think this needs to be re-opened @fitzgen - the CI is only running cargo test and not running the integration tests

@fitzgen
Copy link
Member Author

fitzgen commented Mar 28, 2019

@samcday Yeah, we're fixing that in follow up PRs like #54

ranile pushed a commit that referenced this issue Feb 15, 2022
@e00E
Fix message ordering not being preserved (#29)
3100e91 
The websocket specification guarantees that messages are received in the
same order they are sent. The implementation in this library can violate
this guarantee because messages are parsed in a spawn_local block before
being sent over the channel. When multiple messages are received before
the next executor tick the scheduling order of the futures is
unspecified.
We fix this by performing all operations synchronously. The only part
where async is needed is the conversion of Blob to ArrayBuffer which we
obsolete by setting the websocket to always receive binary data as
ArrayBuffer.
ranile added a commit that referenced this issue Feb 16, 2022
@ranile @mhuesch
@shenek @yusdacra @lukechu10 @e00E
Add gloo-net crate (#191)
65fcda7 
* Initial commit

* provide a better interface for errors, rename `RequestMethod` to `Method`

* remove method for array buffer and blob in favor of as_raw

* prepare for release

* add CI, update readme

* hide JsError in the docs

* fix CI?

* Install wasm-pack in CI

* misc

* websocket API

Fixes: ranile/reqwasm#1

* add tests for websocket

* update documentation, prepare for release

* fix mistake in documentation

* Rewrite WebSockets code (#4)

* redo websockets

* docs + tests

* remove gloo-console

* fix CI

* Add getters for the underlying WebSocket fields

* better API

* better API part 2 electric boogaloo

* deserialize Blob to Vec<u8> (#9)

* Update to Rust 2021 and use JsError from gloo-utils (#10)

* Update to Rust 2021 and use JsError from gloo-utils

* use new toolchain

* Add response.binary method to obtain response as Vec<u8>

Fixes: ranile/reqwasm#7

* Remove `Clone` impl from WebSocket.

When the WebSocket is used with frameworks, passed down as props, it might be `drop`ed automatically, which closes the WebSocket connection. Initially `Clone` was added so sender and receiver can be in different `spawn_local`s but it turns out that `StreamExt::split` solves that problem very well.

See #13 for more information about the issue

* Rustfmt + ignore editor config files

* Fix onclose handling (#14)

* feat: feature gate json, websocket and http; enable them by default (#16)

* feat: feature gate json support

* feat: feature gate weboscket api

* ci: check websocket and json features seperately in CI, check no default features

* feat: feature gate the http API

* refactor: use futures-core and futures-sink instead of depending on whole of futures

* ci: test http feature seperately in CI

* fix: only compile error conversion funcs if either APIs are enabled

* fix: add futures to dev-deps for tests, fix doc test

* 0.3.0

* Fix outdated/missing docs

* 0.3.1

* Change edition from 2021 to 2018 (#18)

* Change edition from 2021 to 2018

* Fix missing import due to edition 2021 prelude

* hopefully this will fix the issue (#19)

* There's no message

* Replace `async-broadcast` with `futures-channel::mpsc` (#21)

We no longer need a multi-producer-multi-consumer channel. There's only one consumer as of ranile/reqwasm@445e9a5

* Release 0.4.0

* Fix message ordering not being preserved (#29)

The websocket specification guarantees that messages are received in the
same order they are sent. The implementation in this library can violate
this guarantee because messages are parsed in a spawn_local block before
being sent over the channel. When multiple messages are received before
the next executor tick the scheduling order of the futures is
unspecified.
We fix this by performing all operations synchronously. The only part
where async is needed is the conversion of Blob to ArrayBuffer which we
obsolete by setting the websocket to always receive binary data as
ArrayBuffer.

* 0.4.1

* move files for gloo merge

* remove licence files

* gloo-specific patches

* fix CI

* re-export net from gloo

Co-authored-by: Michael Hueschen <mhuesch@users.noreply.github.com>
Co-authored-by: Stepan Henek <stepan+github@henek.name>
Co-authored-by: Yusuf Bera Ertan <y.bera003.06@protonmail.com>
Co-authored-by: Luke Chu <37006668+lukechu10@users.noreply.github.com>
Co-authored-by: Valentin <vakevk+github@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fitzgen @samcday @rylev