chore: update dependencies

[weihanglo]

Hand-picked some dependencies to update. Looks pretty safe?

• anyhow 1.0.70 -> 1.0.71
• base64 0.21.0 -> 0.21.2
• clap@4.2.1 4.2.1 -> 4.3.3
• flate2 1.0.25 -> 1.0.26
• git2 0.17.1 -> 0.17.2
• libgit2-sys 0.15.1+1.6.4 -> 0.15.2+1.6.4
• log 0.4.17 -> 0.4.19
• openssl 111.25.3+1.1.1t -> 111.26.0+1.1.1u
• pkg-config 0.3.26 -> 0.3.27
• proptest 1.1.0 -> 1.2.0
• pulldown-cmark 0.9.2 -> 0.9.3
• serde 1.0.160 -> 1.0.164
• serde_json 1.0.95 -> 1.0.96
• snapbox 0.4.10 -> 0.4.11
• tempfile 3.5.0 -> 3.6.0
• time 0.3.20 -> 0.3.22
• toml 0.7.3 -> 0.7.4
• toml_edit 0.19.8 -> 0.19.10
• url 2.3.4 -> 2.4.0

Additional information

This is a bit painful, shall we introduce some bot (dependant/renovate) to help this process.

In addition, we should have a job of cargo update && cargo test in our CI pipeline.

[rustbot]

r? @ehuss

(rustbot has picked a reviewer for you, use r? to override)

[ehuss]

Thanks!

@bors r+

This is a bit painful, shall we introduce some bot (dependant/renovate) to help this process.

In the past we did a blanket update just after a release to maximize the time for testing and exposure. We could add cargo update as part of the version bump process?

Otherwise, if we use a bot, I would prefer to configure it to minimize the number of updates it does. I find that they generate a lot of noise otherwise. I'd also like to avoid doing unnecessary updates just before a beta branch. My impression is that renovate is more configurable and generally better, but I don't have much experience with either.

In addition, we should have a job of cargo update && cargo test in our CI pipeline.

Part of the motivation for using a lock file is to avoid breaking CI for PRs due to issues with updates. If we do something like this, I would recommend using a scheduled workflow instead. One problem with scheduled workflows is sending notifications. I think that can be fixed by using gh to post a new issue if the job fails, which probably shouldn't be too difficult, but I haven't tried that, yet.

[bors]

📌 Commit bf06fc8 has been approved by ehuss

It is now in the queue for this repository.

[bors]

⌛ Testing commit bf06fc8 with merge 0d5acab...

[ehuss]

Oh, I didn't notice CI failed.

@bors r-

[ehuss]

Do you want me to help with debugging that?

[ehuss]

I'm not sure if that is a fluke. I hit the rerun button to see if it fails again.

I'm not sure why apache would respond with 503 Service Unavailable. Maybe it needs more time to start up? I would have thought that if it is accepting connections it should be ready.

[epage]

Otherwise, if we use a bot, I would prefer to configure it to minimize the number of updates it does. I find that they generate a lot of noise otherwise. I'd also like to avoid doing unnecessary updates just before a beta branch. My impression is that renovate is more configurable and generally better, but I don't have much experience with either.

I've switched from Dependabot to RenovateBot.

Example config: https://github.com/crate-ci/cargo-release/blob/master/.github/renovate.json5

• One PR for compatible upgrades
• A PR per incompatible upgrades (we could just disable them)
• Upgrade MSRV on a schedule
• A dependency dashboard

Challenges

• I don't know if there is a good way for us to schedule for a 6 week cadence
• Setting an MSRV would be great but I don't know of a way to decouple the cadence of "immediate" for MSRV and "every couple weeks" for dependecies.

[bors]

☀️ Try build successful - checks-actions
Build commit: 0d5acab (0d5acab494ee22099c1574ec2af5718185098850)

[ehuss]

@bors r+

Looks like it might have been a flaky error. I haven't seen it before, and I'm not sure what might have caused it. For posterity, here is the output:

---- https::self_signed_should_fail stdout ----
thread 'https::self_signed_should_fail' panicked at 'called `Result::unwrap()` on an `Err` value: process didn't exit successfully: `docker build --tag cargo-test-apache /home/runner/work/cargo/cargo/crates/cargo-test-support/containers/apache` (exit status: 1)
--- stdout
Sending build context to Docker daemon  6.656kB

Step 1/12 : FROM httpd:2.4-alpine
2.4-alpine: Pulling from library/httpd

--- stderr
received unexpected HTTP status: 503 Service Unavailable
', crates/cargo-test-support/src/containers.rs:102:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

If we see this again, we should look into it more. Perhaps the service just needs more time to start up.

[bors]

📌 Commit bf06fc8 has been approved by ehuss

It is now in the queue for this repository.

[bors]

⌛ Testing commit bf06fc8 with merge 1703e06...

[bors]

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing 1703e06 to master...