On: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

[dmm]

This is only about seven builds per month for my Rust project, not too bad but something I'll have to keep in mind.

Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects? I just can't get myself to use Dyn...

[rumanator → dmm]

> Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects?

No,not really. I mean, in healthy projects build times are dwarfed by the time it takes to run tests. In web development projects even the delivery and deployment steps dwarf build times.

[dmm → rumanator]

> in healthy projects build times are dwarfed by the time it takes to run tests

I don't doubt that's often true but many Rust projects may be outliers here. A full, non-incremental build of a Rust project involves building all of its dependencies. This can add significant amounts of time if a project uses a big framework like Actix-web, which adds many dependencies.

My tests however run very quickly, ~1ms each. So running thousands of tests only takes a few seconds, even on relatively slow gitlab runners.

[kevincox → dmm]

You should be caching the builds of your dependencies. This is very easy with cargo and GitLab. I think encouraging people to optimize this is a reasonable cost to push onto the free users.

[papaf → kevincox]

To add to your point, the caching is done by adding a cache entry to .gitlab-ci.yml :

  variables:
    CARGO_HOME: $CI_PROJECT_DIR/cargo

  cache:
    key: "$CI_JOB_NAME"
    untracked: true
    paths:
      - cargo/
      - target/

[snovv_crash → dmm]

Is there an equivalent of `ccache` for Rust? For C++ it's been a total lifesaver, I've introduced it in multiple organizations for massively reducing (average) build times, even by sharing the cache on an NFS drive between multiple machines.

[Camas → snovv_crash]

https://github.com/mozilla/sccache

[IshKebab → Camas]

Note the caveats though. In particular it can't cache Serde, which is easily the slowest popular crate to compile. Also the heavy use of static dispatch and LTO in Rust means a lot of the actually compilation happens in the final crate which is usually the one you modified.

It definitely helps but not as much as in C++.

[oehtXRwMkIs → dmm]

Plus Rust by design avoids all sorts of bugs leading to less tests imo. Python for example you really want a lot of testing, maybe even contracts, but with Rust I find that many of those tests are irrelevant.

[rumanator → oehtXRwMkIs]

> Plus Rust by design avoids all sorts of bugs leading to less tests imo.

This assertion on the amount to tests makes no sense at all. Tests are not about language features. Tests are about checking invariantes, checking input and output bounds, and checking behavior. Tests focus on the interface, not the implementation. Tests only work if test coverage is high.

[IshKebab → rumanator]

It makes total sense. Rust statically enforces many things you'd have to explicitly test for in other languages, for example types. So you don't need to write as many tests.

[jamesh-gl → rumanator]

GitLab Product Manager here - We’re working on ways to run fewer tests OR only the necessary tests earlier in a pipeline so you get to a result in fewer minutes. The first project towards this in the product is https://docs.gitlab.com/ee/user/project/merge_requests/fail_... which we hope to bring down to the Core tier soon.

-James H, GL Product Manager, Verify:Testing

[karlerss → jamesh-gl]

I think most test runners have a --stop-on-failure feature, but using it has the downside of not giving you the complete list of failing tests.

If you haven't touched your gitlab pipelines for a few months, check out DAG pipelines [0] - I got my web project deployment pipeline down from 25 to ~12 minutes by running tests sooner.

[0] https://docs.gitlab.com/ee/ci/directed_acyclic_graph/

[toupeira → dmm]

If that's an Open Source project you could apply for a free Gold license and get 50'000 minutes per group per month (see links in the article).

[YorickPeterse → dmm]

> Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects? I just can't get myself to use Dyn...

I presume this is some kind of joke. If not, why on earth would GitLab campaign against the use of dyn types? GitLab doesn't even use Rust.