feat(github): add CICD job build_programs_individually

[gierens]

This adds a rudimentary CI job for building the different programs individually by basically looping over a subset of the cargo feature output.

Would look like this: https:/gierens/coreutils/actions/runs/8638198438/job/23682121436

Not sure if this is what you're looking for or rather some static list, I just stumbled across this issue and did something similar before. A future alternative could be cargo-all-features (https:/frewsxcv/cargo-all-features) but unfortunately this is more for feature combinations and still lacks a few features thus would require a fork at the moment.

Resolves: #6097

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)

[tertsdiepraam]

My idea was to base it on the show-utils script, which we do elsewhere in the CI too. This seems to work, but only for linux. Nevertheless, this would be great to have!

We could also try building the packages instead of the multicall binary. 🤔

Other considerations:

• Should we run the relevant tests?
• Should this just be a cargo check to reduce CI time a bit?

[sylvestre]

@gierens any opinion ? :)

[gierens]

@gierens any opinion ? :)

Sure :) ... sorry for the late reply, the new semester just started and I got a little distracted :D

My idea was to base it on the show-utils script, which we do elsewhere in the CI too.

Oh neat, that's a lot smarter of course :) ... yeah the CICD workflow is a little intense and I just skimmed it, but I could've probably checked the util folder, my bad :D

This seems to work, but only for linux. Nevertheless, this would be great to have!

I guess with the show-utils batch file it would be possible to make it work on windows, too.

We could also try building the packages instead of the multicall binary. 🤔

Sounds reasonable.

• Should we run the relevant tests?
• Should this just be a cargo check to reduce CI time a bit?

Hm, I guess we could first check how long that would actually run with building and tests, and then decide. Also in case it really takes too long, it could maybe be parallelized to some extent.

It's getting a little late here, but I can take a look at it tomorrow :)

[gierens]

@tertsdiepraam @sylvestre alright, I revised the CI job: It uses show-builds.sh, runs on ubuntu-latest, macos-latest and windows-latest, and does tests now.

https:/gierens/coreutils/actions/runs/8712554101/job/23899114665

In the run I executed just now in my fork it took roughly 1min@ubuntu, 2min@macos and 4min@windows, so not should be fine I guess.

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/timeout/timeout. tests/timeout/timeout is passing on 'main'. Maybe you have to rebase?

[tertsdiepraam]

Looks great! Thanks! Just one question.

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)

[cakebaker]

Thanks for your PR :)