graphql-client
graphql-client copied to clipboard
graphql-rust
CI turn around time is really long
I think this comes down to there only being 3 tracks right now. It would be faster to do the WASM tests in a separate job pipeline. cargo fmt/prettier and cargo clippy can also be separate jobs as well (cargo fmt is fast since there's no download and cargo clippy is just doing cargo check under the hood). It also highlights their issues rather than putting them in the middle of the gigantic log. I see just cargo install wasm-bindgen-cli taking 450 s (almost 8 minutes). This could almost certainly be cached somehow. Caching the target directory may also be useful if some good way of fingerprinting the thing can be found.
I think the biggest problem is the examples directories starting everything from scratch again. I think it may be useful to fold them into the standard examples/foo/bin.rs pattern and add their oddball deps to dev-dependencies (with comments as to why they're there). Each one is taking 4+ minutes and there's only 3 right now.
Thoughts?
Hrm. Examples are not so easy. They'd need to be moved into a crate directly (probably graphql_client?) rather than living at the workspace level. See rust-lang/cargo#7467 for a cargo-level solution to the problem.
I haven't done the work, but I was thinking about single-file examples as most projects seem to have, instead of separate cargo projects, like you said.
It would also be possible to consider switching to circleCI, maybe github actions or azure pipelines.
I suspect GitHub Actions is unsuitable due to the time limits and such. 5 builds, ~8 min per build means we have 50 PR updates (including the merge) per month. Without caching of things like the target directory between builds, I don't know if that is sufficient; maybe it is. I haven't played with Azure since I don't have a Microsoft account and Circle because they require access to all repos in order to work (or did). That's the main reason I ended up at Cirrus, but whatever you/the org is OK with using/investigating is fine with me.
@mathstuf @tomhoule I've used both AzurePipeline and CircleCI in a project, can I try them once?
I'm sorry, I was mistaken. The repository setting can only be changed by the owner. :p
On November 10, 2019 11:58:10 PM EST, Hirokazu Hata [email protected] wrote:
I'm sorry, I was mistaken. The repository setting can only be changed by the owner. :p
You should be able to experiment in your fork at least.
I can recommend Github Actions. 8 concurrent jobs on pretty good machines and it's nice to have it integrated into the same UI/site.
I'll switch juniper over from Azure Pipelines this week.
Also it supports Docker actions, so you could come up with a baseline image with the important dependencies like wasm-bindgen-cli pre-installed. (which could also be automatically re-built daily with a scheduled job)
@theduke https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-github-actions#usage-limits
The number of jobs you can run concurrently across all repositories in your account depends on your GitHub plan.
Do you know what this limit will be for organizations?
I think for open source projects only the per-repo limits apply. (no guarantee though)
@theduke ty. I'll try it :) FYI: https://github.community/t5/GitHub-Actions/Caching-files-between-GitHub-Action-executions/m-p/30974#M630