mortengregersen / bagbutik Goto Github PK
View Code? Open in Web Editor NEWGenerated Swift code for the App Store Connect API based on the official OpenAPI spec.
License: MIT License
Generated Swift code for the App Store Connect API based on the official OpenAPI spec.
License: MIT License
Bagbutik-Models
takes ~0:24 for a debug build and ~2:10 for a release build. The other targets don't have this same difference in build times.
I asked about this a while ago on Mastodon and you mentioned that Codable
could be a source of the issue.
https://mastodon.social/@mortengregersen/110210277236346597
I had some free time so I did a bit of an experiment to see what the effect of the generated Codable
implementation is on the release build time. I also included CaseIterable
just incase anything generated by the compiler was the cause. I used https://github.com/sharkdp/hyperfine to benchmark the build times one different branches with the following command.
hyperfine \
--parameter-list branch main,generate-codable,remove-codable \
--runs 5 \
--command-name "Building {branch}"\
--warmup 1 \
--setup 'git checkout {branch}' \
--prepare 'swift package clean' \
'swift build --configuration release --target Bagbutik-Models'
This was run on main
(e1bdc2d).
Benchmark 1: Building main
Time (mean ± σ): 133.187 s ± 2.863 s [User: 290.170 s, System: 55.831 s]
Range (min … max): 130.391 s … 137.076 s 5 runs
Codable
and CaseIterable
ConformancesThis was run on https://github.com/CraigSiemens/Bagbutik/tree/generate-codable
On this branch I updated the generation to create the conformances for Codable
(including CodingKeys
) and CaseIterable
for all types in Bagbutik-Models
.
Benchmark 2: Building generate-codable
Time (mean ± σ): 152.551 s ± 3.086 s [User: 310.417 s, System: 57.085 s]
Range (min … max): 150.324 s … 157.834 s 5 runs
That seems to make the build slower still, so it seems the slower builds are not caused by the compiler generating the conformance, unless it's still doing checks for whether it needs to add conformance to all the files. Watching CPU usage, it spends most of the time using a single core before switching to using all available cores.
Codable
and CaseIterable
This was run on https://github.com/CraigSiemens/Bagbutik/tree/remove-codable
On this branch I modified the generation to remove Codable
and CaseIterable
from all models to confirm whether it was the source of the slower build times. This was just for experimenting since the change also causes the rest of the project to fail to build/function.
Benchmark 3: Building remove-codable
Time (mean ± σ): 37.170 s ± 0.244 s [User: 119.392 s, System: 18.215 s]
Range (min … max): 36.890 s … 37.482 s 5 runs
The build was much faster confirming that Codable
adds a lot to the build time.
Summary
'Building remove-codable' ran
3.58 ± 0.08 times faster than 'Building main'
4.10 ± 0.09 times faster than 'Building generate-codable'
It appears that adding Codable
, regardless of whether it uses the compiler generated conformance, is the cause of the increase in build time. The next steps feel like they should be:
Codable
shouldn't impact build times that much.Debug builds show a similar relationship between the different branches, though the total time is shorter and relative improvement is less.
Benchmark 1: Building main
Time (mean ± σ): 22.309 s ± 1.616 s [User: 126.424 s, System: 12.401 s]
Range (min … max): 20.469 s … 23.955 s 5 runs
Benchmark 2: Building generate-codable
Time (mean ± σ): 25.719 s ± 1.523 s [User: 138.862 s, System: 12.123 s]
Range (min … max): 23.974 s … 28.104 s 5 runs
Benchmark 3: Building remove-codable
Time (mean ± σ): 11.727 s ± 0.755 s [User: 54.623 s, System: 9.200 s]
Range (min … max): 10.594 s … 12.276 s 5 runs
Summary
'Building remove-codable' ran
1.90 ± 0.18 times faster than 'Building main'
2.19 ± 0.19 times faster than 'Building generate-codable'
Try create a new version of my app:
func newVersion(appID: String, versionString: String) async -> AppStoreVersionResponse? {
do {
let appStoreVersionResponse = try await service.request(
.createAppStoreVersion(
requestBody: .init(
data: .init(
attributes: .init(
platform: .iOS,
versionString: versionString
),
relationships: .init(
app: .init(
data: .init(
id: appID
)
)
)
)
)
)
)
return appStoreVersionResponse
} catch {
print("ServiceError:", (error as? ServiceError)?.description ?? "")
return nil
}
}
An unhandled HTTP error occurred:
ServiceError: An unhandled HTTP error occurred. Status code 422. Data as UTF-8 string: {
"errors" : [ {
"id" : "0a77804d-9c04-4d71-93b4-a76f52bd33b2",
"status" : "422",
"code" : "ENTITY_UNPROCESSABLE",
"title" : "The request entity is not a valid request document object",
"detail" : "The data for relationship 'appStoreVersionLocalizations' is missing the required 'type' property."
}, {
"id" : "41bf8ba1-6b4d-445d-b985-3d3ca365eced",
"status" : "422",
"code" : "ENTITY_UNPROCESSABLE",
"title" : "The request entity is not a valid request document object",
"detail" : "The data for relationship 'build' is missing the required 'type' property."
} ]
}
Maybe it's a @NullCodable
related issue.
As part of #168 it introduced an "unstable" release for the Zip dependency so if you try to use SPM with that version it will fail with an error similar to this:
I'm not sure what's the best course of action here but it might be a good idea to look into removing the Zip dependency.
A hacky/faster solution would be to spin up a process calling the unzip
command using https://developer.apple.com/documentation/foundation/process# since it's only being used for that purpose for the CLI.
I can work on it if this is an acceptable change.
As mentioned in DMs, Bagbutik currently makes apps very large due to a lot of the dependencies.
Hi Morten,
There's a small issue in the CiScheduledStartCondition.Schedule
model for Xcode Cloud. Currently the type of days
for a scheduled start is the day itself instead of an array of days as specified in the App Store Connect API.
where as App Store Connect API would expect something like:
public var days: [String]?
public var days: [Items]? // In Bagbutik's case
Check the API specs for more info: CiScheduledStartCondition.Schedule
Environment
Bagbutik Version: 10.3.0
Platform: macOS Sonoma 14.5
Details
I'm making the following request to get data related to an experiment. I noticed that if I make the request without the limit parameter, I only get 10 localizations (in a random order). This isn't great for apps that have many localizations in the experiment.
let treatmentID = treatmentRelationship.id
let response = try await service.request(
.getAppStoreVersionExperimentTreatmentV1(
id: treatmentID,
includes: [.appStoreVersionExperimentTreatmentLocalizations],
limit: 50
)
)
When I make the request, I get the following error:
badRequest(Bagbutik_Core.ErrorResponse(errors: Optional([Bagbutik_Core.ErrorResponse.Errors(code: "PARAMETER_ERROR.ILLEGAL", detail: Optional("The parameter 'limit' can not be used with this request"), id: Optional("020add9f-38c7-41c8-a69c-9e8fba508db0"), meta: nil, source: Optional(Bagbutik_Core.ErrorResponse.Errors.Source.jsonPointer(Bagbutik_Core.JsonPointer(pointer: nil))), status: "400", title: "A given parameter is not allowed for this request")])))
Is something misaligned in the spec? Or is this a bug in the ASC API?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.