Adopt OpenAPI for fetching current swiftly releases #205
Conversation
cmcgee1024
force-pushed
the
use_openapi_spec
branch
from
3fdbb28 to
de41cd9
Compare
|
@swift-ci test macOS |
cmcgee1024
force-pushed
the
use_openapi_spec
branch
from
de41cd9 to
505e041
Compare
Use the OpenAPI specification for the swift.org API and the swift OpenAPI generation capabilities to avoid having to hand craft the HTTP handling and local data types.
cmcgee1024
force-pushed
the
use_openapi_spec
branch
from
505e041 to
ffdc305
Compare
| generate: | ||
| - types | ||
| - client | ||
| namingStrategy: idiomatic |
There was a problem hiding this comment.
You can add a filter to only generate the exact operations you're using, to reduce the codegen and build times: https://swiftpackageindex.com/apple/swift-openapi-generator/1.7.0/documentation/swift-openapi-generator/configuring-the-generator#Document-filtering
There was a problem hiding this comment.
Thanks, I've applied a filter to the Swiftly portions of the API.
| public struct SwiftOrgSwiftlyRelease: Codable { | ||
| public var version: SwiftlyVersion | ||
| public var platforms: [SwiftOrgSwiftlyPlatform] | ||
| } |
There was a problem hiding this comment.
You could keep these types, remove their Codable conformance, and add a eg init(_ release: Components.Schemas.Release) initialize on each of them that converts from the generated equivalent into this business logic type.
It's good practice to keep the API and business logic types separate, and explicitly convert between them. It then allows the API to keep evolving without it affecting your codebase too much (you'd only need to update the conversion initializer).
There was a problem hiding this comment.
Thanks for the suggestions. Swiftly doesn't do much with these types so they don't really add much value beyond holding the parts of the message payload that it uses right away. They don't go any further than swiftly itself. I was hoping to reduce the duplication and just use (or maybe extend) the ones generated by the OAG.
There was a problem hiding this comment.
Yeah, the extensions you added also look good.
| let client = Client( | ||
| serverURL: URL(string: "https://swift.org/api")!, | ||
| transport: AsyncHTTPClientTransport(configuration: config) | ||
| ) |
There was a problem hiding this comment.
You can inject a user agent by adding the middlewares parameter on this Client. An example of a header injection middleware that you can copy is here: https://github.com/apple/swift-openapi-generator/blob/main/Examples/auth-client-middleware-example/Sources/AuthenticationClientMiddleware/AuthenticationClientMiddleware.swift
There was a problem hiding this comment.
Thanks, this example was what I needed to find the correct imports.
| @@ -1,6 +1,6 @@ | |||
| import Foundation | |||
|
|
|||
| public struct Error: LocalizedError, CustomStringConvertible { | |||
| public struct SwiftlyError: LocalizedError, CustomStringConvertible { | |||
There was a problem hiding this comment.
I'd suggest you break out this renaming into a separate PR, it'll then make the OpenAPI changes a lot easier to review.
There was a problem hiding this comment.
Sorry for the noise. Thanks for having a look at this.
Add swiftly user agent middleware Restrict the generator to only the swiftly portion of the API
|
@swift-ci test macOS |
Sources/SwiftlyCore/HTTPClient.swift
Outdated
| let swiftlyUserAgent = SwiftlyUserAgentMiddleware() | ||
|
|
||
| let client = Client( | ||
| serverURL: URL(string: "https://swift.org/api")!, |
There was a problem hiding this comment.
I think this either needs to be https://www.swift.org/api/v1 (you're missing /v1), or just use the generated value: serverURL: Servers.Server1.url().
There was a problem hiding this comment.
Looks like a test gap. I will add an integration test case for this.
Thanks again for your help with this. I think it should be ready for review and merge. |
|
@swift-ci test macOS |
|
@swift-ci test macOS |
Use the OpenAPI specification for the swift.org API and the swift OpenAPI generation capabilities to avoid having to hand craft the HTTP handling and local data types.