run cross_compile::build_deps_for_the_right_arch test first

[matthiaskrgr]

cross_compile::build_deps_for_the_right_arch fails on my system and it always prints

This failure can be safely ignored. If you would prefer to not see this
failure, you can set the environment variable CFG_DISABLE_CROSS_TESTS to "1"
....

and then I re-run the tests with CFG_DISABLE_CROSS_TESTS=1

Can we run this test before all other tests to make sure we don't have to rerun the half the testsuit if it fails?

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[matthiaskrgr]

This issue is still marked as stale although it was referenced by a fix.
Maybe this should not happen?
Is there a way to fix stalebot config?

[dwijnand]

I think you need to "fix" GitHub for that, as stale bot only relies on the issue's updated timestamp. But actually I think referencing is fine to not update an issue.

I kind of intentionally sent a PR without touching this issue, as if my proposed fix isn't accepted I'm not sure how else to solve this issue, so I'm happy for it to close out as stale.

[matthiaskrgr]

Hmm, what I actually wanted was that the entire testsuit would immediately interrupt once it hits this failure (and prints the stderr).
The new behavior is that it just runs it as first tests but still runs hundreds of other tests before it "fails" and prints what went wrong, so this is only useful if the use actively sees the failure and investigates immediately.

running 1443 tests
test alt_registry::cannot_publish_to_crates_io_with_registry_dependency ... ok
test alt_registry::credentials_in_url_forbidden ... ok
test aaa_trigger_cross_compile_disabled_check ... FAILED
test alt_registry::block_publish_due_to_no_token ... ok
test alt_registry::alt_registry_and_crates_io_deps ... ok
[...]

[dwijnand]

I'd be happy to look into doing that if a maintainer were to confirm that change in testing behaviour is acceptable.

[alexcrichton]

I feel like that's the same story for all tests written in Rust? With hundreds of test if only the first one fails it takes awhile to see the error? I'm not sure why we'd special case these tests to fail even faster

Alternatively we could add an option to Rust's libtest like --fail-fast to allow passing that