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

[ci]: test each individual crate's manifest #392

Merged
merged 9 commits into from
Jun 25, 2021
Merged

[ci]: test each individual crate's manifest #392

merged 9 commits into from
Jun 25, 2021

Conversation

niklasad1
Copy link
Member

@niklasad1 niklasad1 commented Jun 24, 2021

We have been bitten by that the CI just checks all crates compiles in the workspace (shares Cargo.lock) and features.

Thus, if a feature for an individual is not enabled for specific crate then this is not detected by CI so this PR changes that each crate using its manifest instead.

In addition:

  • Fixes the ws-server to compile outside the workspace
  • Added to run CI on macos and Windows.

We have bitten by these a few times now with that some features are leaked from the workspace
which makes it compile in the workspace but not using it's own Cargo.toml.
@niklasad1 niklasad1 requested review from dvdplm and jsdw June 24, 2021 14:40
@@ -173,8 +173,6 @@ async fn can_set_max_connections() {
assert!(conn3.is_err());
let err = conn3.unwrap_err();
assert!(err.to_string().contains("WebSocketHandshake failed"));
assert!(err.to_string().contains("Connection reset by peer"));
// Err(Io(Os { code: 54, kind: ConnectionReset, message: \"Connection reset by peer\" }))");
Copy link
Member Author

@niklasad1 niklasad1 Jun 24, 2021

Choose a reason for hiding this comment

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

windows returns https://support.microsoft.com/en-us/topic/an-application-may-receive-the-10054-error-when-the-application-receives-data-from-a-connection-on-a-computer-that-is-running-windows-7-or-windows-server-2008-r2-if-a-tdi-filter-driver-is-installed-73fd74a9-51c2-3663-e965-e1187b1cfc92

so let's remove the assertion it would be better if we used io::Error in the test client I suppose then we could actually match on the kind but as this is Box<Error> it doesn't work without downcasting.

.github/workflows/ci.yml Outdated Show resolved Hide resolved
@@ -74,8 +74,68 @@ jobs:
command: check
args: --manifest-path http-client/Cargo.toml --no-default-features --features tokio02
Copy link
Collaborator

Choose a reason for hiding this comment

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

Instead of checking every crate individually, could we just run cargo check without arguments? My experience is that that checks every crate in the workspace by default (though you can also add --workspace to, I assume, be sure).

Or do we need to check individually because http-client needs the tokio02 feature setting?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, we did do cargo check --workspace before this PR but that's the problem and why I added cargo check --manifest-path crate, see my comment below.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks, that all makes sense now :)

Comment on lines +182 to +186
- name: Cargo build
uses: actions-rs/cargo@v1.0.3
with:
command: build
args: --workspace
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we need to have a build step before the test step? (I'll need to look into these rust github actions more!)

Copy link
Member Author

Choose a reason for hiding this comment

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

no you are right, we don't have too but the previous checks only run cargo check so we have want make sure nothing weird happens when building the binary but it could be another action for clarity I suppose.

Copy link
Collaborator

Choose a reason for hiding this comment

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

My first thought was that cargo test builds the binary anyway, but of course it builds it with cfg(test) enabled, so I can see why a separate build step is useful to make sure it works "normally"!

@@ -12,7 +12,7 @@ documentation = "https://docs.rs/jsonrpsee-ws-server"
[dependencies]
thiserror = "1"
futures-channel = "0.3.14"
futures-util = { version = "0.3.14", default-features = false, features = ["io"] }
futures-util = { version = "0.3.14", default-features = false, features = ["io", "async-await-macro"] }
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nit: It doesn't look like we've added any code that requires this feature; do we want it?

Copy link
Member Author

@niklasad1 niklasad1 Jun 24, 2021

Choose a reason for hiding this comment

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

This fixes the crate to "compile" standalone i.e, outside the workspace.

It was introduced in another PR, thus it doesn't compile standalone such as if you would do cd ws-server && cargo check outside the workspace it doesn't work. Because, features in Rust are additive (the union of all features) so if another crate adds that feature it's enabled for all in workspace if that makes sense.

TLDR; on master cd ws-server && cargo check doesn't work but cargo build -p ws-server works :P

Copy link
Collaborator

Choose a reason for hiding this comment

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

Aah gotcha! Thanks for the explanation!

Copy link
Collaborator

@jsdw jsdw left a comment

Choose a reason for hiding this comment

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

Looks good to me; I have a few questions but nothing major and mainly just for my own curiosity!

Comment on lines +175 to +179
let err = match conn3 {
Err(soketto::handshake::Error::Io(err)) => err,
_ => panic!("Invalid error kind; expected std::io::Error"),
};
assert_eq!(err.kind(), std::io::ErrorKind::ConnectionReset);
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice, ty for fixing this.

@dvdplm dvdplm merged commit 2ca8355 into master Jun 25, 2021
@dvdplm dvdplm deleted the na-fix-ci branch June 25, 2021 08:56
dvdplm added a commit that referenced this pull request Jul 6, 2021
* master: (21 commits)
  New proc macro (#387)
  Streaming RpcParams parsing (#401)
  Set allowed Host header values (#399)
  Synchronization-less async connections in ws-server (#388)
  [ws server]: terminate already established connection(s) when the server is stopped (#396)
  feat: customizable JSON-RPC error codes via new enum variant on `CallErrror` (#394)
  [ci]: test each individual crate's manifest (#392)
  Add a way to stop servers (#386)
  [jsonrpsee types]: unify a couple of types + more tests (#389)
  Update roadmap link in readme (#390)
  Cross-origin protection (#375)
  Method aliases + RpcModule: Clone (#383)
  Use criterion's async bencher (#385)
  Async/subscription benches (#372)
  send text (#374)
  Fix link to ws server in README.md (#373)
  Concat -> simple push (#370)
  Add missing `rt` feature (#369)
  Release prep for v0.2 (#368)
  chore(scripts): publish script (#354)
  ...
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.

3 participants