Fix/enhance CICD #2750
Fix/enhance CICD #2750
Conversation
|
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 love this idea |
|
And sad about the vendoring :( |
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.
Then I'll make it a change instead of an experiment.
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. |
- fixes conversion of new `cargo clippy` output style to GHA annotations ## [why] `cargo clippy` output formatting changed, using relative instead of absolute paths.
- add individual job-step control for 'style' step faults (build failure vs only a warning)
…`) into a style warning
…ceptions to sub-crates)
# [why] The tool cache is currently failing and seems to be getting further behind current versions. The [actions-rs/install#12] issue addresses this but seems to be languishing without any proposed solution. [ref]: <actions-rs/install#12>
….2.8 ## [why] `cspell` in CI started mysteriously failing mid-2021. Tracking down the error took some time as it was not obvious from `cspell` feedback where the issue lay. Ultimately, it was discovered that `cspell` had deprecated use on NodeJS versions < v12 for `cspell` v5+. `cspell` is now pinned to v4.2.8, with a maintenance note to allow an upgrade to the `cspell` version when a version of NodeJS >= v12 is being used in the CI. An issue requesting better tool feedback for similar situations was also opened on the `cspell` repo.[*] [*]: [🙏🏻 Add warning (or error) when used on deprecated/outdated JS platform versions](streetsidesoftware/cspell#1984)
…eq, toolchain, ...)
- a PR has been submitted to 'nix'; ref: <nix-rust/nix#1590>
- the build and test steps won't run until/unless Dependency and MSRV checks pass - code coverage won't run until/unless the build steps all pass ## [why] This helps make more efficient use of CI resources and can help more easily visualize build issues from the resultant GHA dashboard flow diagram.
@blyxxyz , thanks for the look. |
|
Once tests on the rebase pass, I'll change this from draft to ready. |
This PR contains several fixes/enhancements for CI...
style updates
cargo udep ...check into a stylefix clippy and spelling style lints
cargo clippylint complaintscspellfix 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.
0.20and0.23in same package due to conflictingbitflagsrequirement nix-rust/nix#1555 , Vendor the bitflags crate nix-rust/nix#1560uu_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::Erroris 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.
I'll convert from draft to final PR when the
yeschange is ok'd and we make a decision about whether to keep the new step dependencies.