cargo version unwraps None
#3844
Comments
|
currently failing on travis |
|
I found #3819, but it looks like that was supposed to be fixed, and this issue still persists in |
|
Also happens for me https://api.travis-ci.org/jobs/212348423/ |
|
😢 |
|
Fixed in rust-lang/rust#40625 sorry for the breakage! |
|
Is there a temporary workaround for this? It's killing all of our CI tests. |
|
I've disabled the |
|
I need nightly to do my build. How long does a fix like this make it into nightly? |
|
It's been approved as high-priority so it should merge tonight, but then there's rollup merging and testing and that takes a day or two to go through (unless high-priority PRs skip rollups), so maybe Monday's nightly? |
|
Usually one configures travis to ignore failures on nightly. If your code only builds with nightly, then you might want to consider pinning it to a known good version. It's nightly after all; it can break. |
…alexcrichton Update the cargo submodule again Unfortunately it was reverted back to a broken state in e06c515 by accident, so let's bring it forward again! Closes rust-lang/cargo#3844
Is there a guide how to do that? |
|
The version of rust you specify in .travis.yml is just passed to rustup, so anything rustup accepts will work. Eg |
…alexcrichton Update the cargo submodule again Unfortunately it was reverted back to a broken state in e06c515 by accident, so let's bring it forward again! Closes rust-lang/cargo#3844
|
Ah whoops, I was pinning my Rust version but wasn't going far enough back in time. Strange that it didn't start happening until yesterday. I wonder if it is somehow a twofold failure. Anyway it seems like the team has it under control :) |
|
Similar issue with Windows a few days ago... :) Temporary fix if you don't want to disable nightly testing: |
Update the cargo submodule again Unfortunately it was reverted back to a broken state in e06c515 by accident, so let's bring it forward again! Closes rust-lang/cargo#3844
…alexcrichton Update the cargo submodule again Unfortunately it was reverted back to a broken state in e06c515 by accident, so let's bring it forward again! Closes rust-lang/cargo#3844
|
@Arnavion thank you: I wasn't using rustup, instead I used to download tarballs manually. Switching to rustup now then. For anyone interested, here's an url of nightly, based on @Arnavion suggestion, which works: Full command in my Dockerfile: |
``` $ cargo --version thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:323 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. ``` Solution: switch to nightly-2017-03-14
RUST_BACKTRACE=full cargo versionresults in this. That backtrace is from macOS 10.12.4 beta.I have verified this issue exists on both macOS and Arch. Arch backtrace.
The text was updated successfully, but these errors were encountered: