Fix/enhance CICD

[rivy]

This PR contains several fixes/enhancements for CI...

• style updates

  • style steps can now be globally and individually configured to fail the build on error or report-only
  • convert the cargo udep ... check into a style

• fix clippy and spelling style lints

  • fix dashboard display of cargo clippy lint complaints
  • fix broken cspell

• fix FreeBSD test

  FreeBSD testing only functioned if the repository name was 'coreutils'. If the repository had another name, the step broke. It's now been revised into a more robust form which will function within any repository.

• fix MacOS code coverage

  Recent commits to 'coreutils' use the 'selinux' crate which forces the use of the 'nix' v0.23+ crate which, unfortunately, has a number of recent changes which break the MacOS coverage build and the 'uu_yes' sub-crate.

  • The MacOS error needs a reversion to an earlier 'nix' version, but the earlier working version can't be used because of the force by 'selinux'. So, a patched version was vendored, all uses of 'nix' were normalized/pinned to the 'nix' patch version, the patch was entered into 'Cargo.toml' (with a FixME comment to remove when 'nix' incorporated the PR), and a PR was opened to make the required change to 'nix' (see nix/PR).
    • ref: PR ; issues ... MacOS: Undefined symbols for architecture x86_64 nix-rust/nix#1588 , Cannot have nix 0.20 and 0.23 in same package due to conflicting bitflags requirement  nix-rust/nix#1555 , Vendor the bitflags crate nix-rust/nix#1560
  • uu_yes: Some error conversion logic had to be re-written b/c of changes within 'nix' for v0.23. I believe that the code in question converts nix::Errors to std::Error, with a fallback to last_os_error() error number. With 'nix' v0.23, nix::Error is now == nix::Errno. I believe I captured the correct gist of the code and all tests still pass, but @blyxxyz , would you mind looking at commit (4ef2faf) and let me know if it needs a change?

The last commit is an exploration of adding dependencies between CI steps; eg, the build/test steps won't run until dependency and MSRV checks pass, and code coverage won't run until/unless the build steps all pass.

• More efficient in not burning CPU cycles when the build is failing.
• Slightly better look on the dashboard?
• Hate it? Like it?
• Easy to drop if everyone hates it.

I'll convert from draft to final PR when the yes change is ok'd and we make a decision about whether to keep the new step dependencies.

[blyxxyz]

I believe I captured the correct gist of the code and all tests still pass, but @blyxxyz , would you mind looking at commit (4ef2faf) and let me know if it needs a change?

That change looks good. My old code was questionable, the new Nix errors make it saner.

[sylvestre]

It would be easier to review if you could split PR into smaller PR. Don't bother for this one but for the future, please consider it!

The last commit is an exploration of adding dependencies between CI steps; eg, the build/test steps won't run until dependency and MSRV checks pass, and code coverage won't run until/unless the build steps all pass.

I love this idea

[sylvestre]

And sad about the vendoring :(

[rivy]

It would be easier to review if you could split PR into smaller PR. Don't bother for this one but for the future, please consider it!

I agree that it's too big, but it's really the vendoring of 'nix' that makes this huge... the primary core of the change is much more reasonable. Look at master...39a6e6c for a better overview not cluttered by the vendoring. Not small, but I hope/think reasonable, and all logically connected.

The last commit is an exploration of adding dependencies between CI steps; eg, the build/test steps won't run until dependency and MSRV checks pass, and code coverage won't run until/unless the build steps all pass.

I love this idea

Then I'll make it a change instead of an experiment.

And sad about the vendoring :(

I should be able to remove the vendored code upon the release of nix-v0.24.0 (which should have feature-gated functionality; see nix-rust/nix#1588 (comment) and nix-rust/nix#1498). We'll just need to evaluate the used functionality and enable that subset of features within the Cargo.toml of the crates using 'nix'; that should avoid the problem.

[rivy]

That change looks good. My old code was questionable, the new Nix errors make it saner.

@blyxxyz , thanks for the look.

[rivy]

Once tests on the rebase pass, I'll change this from draft to ready.