Run cargo update before testing

[cfvescovo]

Fixes #113

Ref: Cargo docs and rust-lang/cargo#315

[cfvescovo]

cc @j-mendez

[EdJoPaTo]

Was the Cargo.lock added for some version pinning? #97 reads a bit like that. If that's the case the pins should be added to the Cargo.toml

[nathaniel-daniel]

Looks like it was introduced for a reason, with fea28ac, though the reason is not specified. Note that this repo also contains a runnable binary at https://github.com/causal-agent/scraper/blob/master/src/main.rs.

[EdJoPaTo]

Looks like it was added/removed more than once then… whatever the problem was, a Cargo.lock file can not resolve it so there has to be another way there.

[adamreichold]

Please see #113 (comment) I don't think this should be removed as long as scraper is both a library and a CLI tool (for which the lock file does serve a purpose).

[adamreichold]

whatever the problem was, a Cargo.lock file can not resolve it so there has to be another way there.

This is not about pinning compatible versions which as you point out must either happen in the Cargo manifest (when widening the version range) or in downstream lock files for library uses (to narrow the version range). But for the binary shipped as part of this crate this lock file is used by e.g. cargo install --locked scraper.

[j-mendez]

Please see #113 (comment) I don't think this should be removed as long as scraper is both a library and a CLI tool (for which the lock file does serve a purpose).

Agreed. Lock file should be included.

[EdJoPaTo]

The binary is a good point. However it hides errors for library usage. If the lock file is kept there should be some CI or workflow to ensure both the lock file and the newest versions in the specified ranges work.

[adamreichold]

If the lock file is kept there should be some CI or workflow to ensure both the lock file and the newest versions in the specified ranges work.

We could just run cargo update at the beginning of the CI workflows which test the library.

[EdJoPaTo]

Currently it does not use clippy with updates might also hide some dependency changes but the most important ones are probably caught when building the tests.

The more important issue probably is the ignored lock file now in CI. the CI probably should do both: one with the lock file and one with cargo update.

[cfvescovo]

The more important issue probably is the ignored lock file now in CI. the CI probably should do both: one with the lock file and one with cargo update.

I am afraid doing that would considerably increase the time taken to perform our Github Actions. I do not know how many minutes are currently available.