build: coverage does not work with clang #858
Assignees
Labels
Comments
htuch
added a commit
to htuch/envoy
that referenced
this issue
May 21, 2017
clang isn't compatible with gcov (see envoyproxy#858). We plan to switch to lcov in the future (see envoyproxy#1000). For now, just make sure we fail visibly and document.
htuch
added a commit
that referenced
this issue
May 22, 2017
|
Closing as dup of #1000 |
jpsim
pushed a commit
that referenced
this issue
Nov 28, 2022
## Context
As part of the work to support platform (Swift/Kotlin) L7 filters, we are updating the public interfaces/functionality of the Envoy Mobile library to combine the concepts of a `StreamEmitter` and `ResponseHandler` into a "stream".
## Goals
- Unify the existing response handler and stream emitter types into a single "stream" type that will make it easier to communicate with an underlying filter manager for both outbound requests and inbound responses
- Provide guard rails that prevent the consumer from making mistakes, such as setting callback handlers after starting a stream and thus missing updates
- Provide a clear interface to the user for creating and starting streams
- Focus on the basics (bi-directional streaming support), which will allow for other wrappers to be written in the future (i.e., GRPC, unary, Rx, etc.)
- Update interfaces to utilize the new wrapper types introduced on master (`ResponseHeaders`, `RequestHeaders`, etc.)
## Types
- `StreamClient`: The publicly exposed interface of `EnvoyEngine`. Provides a function for starting a new stream using Envoy Mobile, and is built using `StreamClientBuilder`
- `StreamPrototype`: Type that allows users to set up a stream (providing callbacks, etc.) prior to starting it
- `Stream`: Produced by calling `start()` on a `StreamPrototype`, and allows the consumer to send data over the stream and eventually close it
- `GRPCClient` / `GRPCStreamPrototype` / `GRPCStream`: Types wrapping the above 3 types, converting the existing gRPC types to utilize the new functionality
To start a stream, consumers now do something like this:
```swift
let streamClient = try StreamClientBuilder().build()
...
```
```swift
let headers = RequestHeadersBuilder(method: .get, authority: "envoyproxy.io", path: "/test")
.addUpstreamHttpProtocol(.http2)
.build()
streamClient
.newStream()
.setOnResponseHeaders { ... }
.setOnResponseData { ... }
.start()
.sendHeaders(headers, endStream: false)
.sendData(data)
.close()
```
## Tests
- Unit tests have been added / updated accordingly.
- Sample apps have also been updated (CI validates via "hello world").
## Notes
- A follow-up PR will migrate Android to mirror these
- Documentation will be updated separately
Signed-off-by: Michael Rebello <[email protected]>
Signed-off-by: JP Simard <[email protected]>
jpsim
pushed a commit
that referenced
this issue
Nov 29, 2022
## Context
As part of the work to support platform (Swift/Kotlin) L7 filters, we are updating the public interfaces/functionality of the Envoy Mobile library to combine the concepts of a `StreamEmitter` and `ResponseHandler` into a "stream".
## Goals
- Unify the existing response handler and stream emitter types into a single "stream" type that will make it easier to communicate with an underlying filter manager for both outbound requests and inbound responses
- Provide guard rails that prevent the consumer from making mistakes, such as setting callback handlers after starting a stream and thus missing updates
- Provide a clear interface to the user for creating and starting streams
- Focus on the basics (bi-directional streaming support), which will allow for other wrappers to be written in the future (i.e., GRPC, unary, Rx, etc.)
- Update interfaces to utilize the new wrapper types introduced on master (`ResponseHeaders`, `RequestHeaders`, etc.)
## Types
- `StreamClient`: The publicly exposed interface of `EnvoyEngine`. Provides a function for starting a new stream using Envoy Mobile, and is built using `StreamClientBuilder`
- `StreamPrototype`: Type that allows users to set up a stream (providing callbacks, etc.) prior to starting it
- `Stream`: Produced by calling `start()` on a `StreamPrototype`, and allows the consumer to send data over the stream and eventually close it
- `GRPCClient` / `GRPCStreamPrototype` / `GRPCStream`: Types wrapping the above 3 types, converting the existing gRPC types to utilize the new functionality
To start a stream, consumers now do something like this:
```swift
let streamClient = try StreamClientBuilder().build()
...
```
```swift
let headers = RequestHeadersBuilder(method: .get, authority: "envoyproxy.io", path: "/test")
.addUpstreamHttpProtocol(.http2)
.build()
streamClient
.newStream()
.setOnResponseHeaders { ... }
.setOnResponseData { ... }
.start()
.sendHeaders(headers, endStream: false)
.sendData(data)
.close()
```
## Tests
- Unit tests have been added / updated accordingly.
- Sample apps have also been updated (CI validates via "hello world").
## Notes
- A follow-up PR will migrate Android to mirror these
- Documentation will be updated separately
Signed-off-by: Michael Rebello <[email protected]>
Signed-off-by: JP Simard <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It looks like clang coverage output is not compatible with gcov/gcovr. Need to ultimately figure out some solution here. (This is true at least as of 4.0 release).
The text was updated successfully, but these errors were encountered: