New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "CI best practicies" section to the guide #5656

Open
matklad opened this Issue Jun 26, 2018 · 11 comments

Comments

Projects
None yet
8 participants
@matklad
Copy link
Member

matklad commented Jun 26, 2018

Things to talk about:

  • what directories should be cached (probably ~/.cargo, ./target, but keep ~/.cargo/credentials in mind)
  • Rust channels (testing on current stable, beta and the oldest supported rustc)
  • using --minimal-versions to verify dependencies in Cargo.toml
  • setting-up rustfmt/clippy

Ideally, the section should contain copy-pastable config files for various CI providers.

@matklad

This comment has been minimized.

Copy link
Member Author

matklad commented Jun 26, 2018

@ehuss

This comment has been minimized.

Copy link
Contributor

ehuss commented Jun 26, 2018

I assume this means to expand https://github.com/rust-lang/cargo/blob/master/src/doc/src/guide/continuous-integration.md? Should it maybe leverage or at least point to japaric/trust?

@matklad

This comment has been minimized.

Copy link
Member Author

matklad commented Jun 26, 2018

Ah, I haven't realized that https://github.com/rust-lang/cargo/blob/master/src/doc/src/guide/continuous-integration.md exists.

Should it maybe leverage or at least point to japaric/trust?

Yep, we should definitely mention it!

@Eh2406

This comment has been minimized.

Copy link
Contributor

Eh2406 commented Jun 26, 2018

@ehuss That is a good place for it to go, thanks for the reminder!

The impetus for this is that when we stabilize --minimal-versions we want to craft a message about how to use it. Specifically as a small part of a thorough CI setup. Witch will just lead everyone to ask, "What showed the big parts of the CI setup be?" So we thought we should write up our opinion before we stabilize --minimal-versions.

@withoutboats

This comment has been minimized.

Copy link
Contributor

withoutboats commented Jul 9, 2018

@aturon

This comment has been minimized.

Copy link
Member

aturon commented Jul 26, 2018

I've just posted a blog post that talks about version selection in detail, and touches on the questions here as well.

@Eh2406

This comment has been minimized.

Copy link
Contributor

Eh2406 commented Jul 26, 2018

That is an excellent read. Thank you for writing this up so articulately. I especially liked the paragraph of:

In the long run, it could even make sense to combine the two approaches, allowing crates to state their toolchain requirements (and have that influence resolution), but encourage core crates to state “LTS” as their requirement.

That sounds like the tradeoff bending I know and love from the rust ethic. I.E. a careful and pedantic system to ensure you are correct but with a large pit of success to make it usable. It also involves the most design work, so it may not be feasible.

In our earlier discussion today you suggested that "equality constraints are rare in the ecosystem" and I resisted being pedantic and pointing out lock files. So I was glad to see them addressed in your blog post. But I do have one nit with:

Similarly, when dependencies are subsequently adjusted, Cargo will “unlock” the affected dependencies and again choose the maximum version.

Currently that adjustment is very conservative, if the version of the sub dependency that appears in the lock file satisfies the requirement of the new dependency then it is not unlocked. Meaning that I am often testing a combination not in the well tested set. So if the new dependency does not have lower-bound precision and my lockfile is old enough then I will brake.

Thanks for the thought provoking guidance of this community.

@Nemo157

This comment has been minimized.

Copy link
Contributor

Nemo157 commented Jul 26, 2018

There's also the https://crate-ci.github.io/ project (cc @epage). Maybe the Cargo Guide could have a small CI best practices section and link out to a larger exploration of the area like this?

@withoutboats

This comment has been minimized.

Copy link
Contributor

withoutboats commented Jul 26, 2018

In our earlier discussion today you suggested that "equality constraints are rare in the ecosystem" and I resisted being pedantic and pointing out lock files.

The important difference with lock files is that you once you have one you should have a successful build, and because it was generated using max versions, it will not run into the too low min version problem. Ceiling'd constraints are a problem because they influence version resolution, whereas the lockfile is after version resolution.

You do identify exactly where a problem can arise, though: cargo update -p. It might be worth considering changing the behavior of cargo update -p to update the entire subgraph under the crate you're updating.

@Turbo87

This comment has been minimized.

Copy link
Member

Turbo87 commented Dec 10, 2018

Currently that adjustment is very conservative, if the version of the sub dependency that appears in the lock file satisfies the requirement of the new dependency then it is not unlocked. Meaning that I am often testing a combination not in the well tested set. So if the new dependency does not have lower-bound precision and my lockfile is old enough then I will brake.

I've run into this problem quite a few times lately. I'm using dependabot on some of my projects to automatically update dependencies, and the updates regularly break CI because the lockfile has an older transitive dependency, but some other dependency relies on it being the most recent release.

Examples:

It’s possible that we will eventually have workflows that depend on the accuracy of lower bounds in Cargo.toml. At the moment, however, this is purely speculative; the Cargo team does not have any ready examples.

Hopefully the examples above are helpful in that regard

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment