Drop obsolete unit test workflows, run unit tests in our tasks container #20005
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
martinpitt
added
the
no-test
martinpitt
force-pushed
the
unit-tests
branch
from
4029555 to
2e2c556
Compare
martinpitt
added
the
.github-changes
|
@allisonkarlitskaya This would be a bit more complete with also dropping the |
1 task
`tput` requires `$TERM`. The Debian-based unit test container sets this by default, but the Fedora based cockpit/tasks container doesn't. Set it explicitly to a known-good value to make sure the test passes there.
We don't support the C bridge on this branch any more.
We won't add a lot of new C code any more, valgrinding Python code isn't very useful (or architecture specific), and more and more distributions drop i386 support. Also, we still run the unit tests during RPM package build through packit/COPR, which cover even more architectures. This paves the way for dropping the unit test container altogether in favor of running the tests in the cockpit/tasks container, once we agree on how to build a proper staging setup. Drop tools/valgrind.supp which was only relevant for i386.
It hasn't helped us in years, modern gcc has good static analysis (plus of course CodeQL and Coverity), none of our supported downstream distros care, and we are not going to add significant amounts of C code any more.
This reduces our tools like `ruff` to a single source of truth (as all our other projects already run their unit tests and linting in the tasks container). It also removes a lot of moving parts only relevant for CI. In practice, us developers run the unit tests in toolbox or our own dev machines anyway. Move building the guide in the release workflow to the tasks container as well.
martinpitt
changed the title
martinpitt
force-pushed
the
unit-tests
branch
from
2e2c556 to
5d06ef4
Compare
github-actions
bot
removed
the
.github-changes
martinpitt
added
the
.github-changes
|
I did the full thing now. I don't necessarily want us to land this right now, if you'd rather want to wait for some kind of staging solution for cockpit/tasks -- but I also don't think it'll hurt much in practice. But I'm still interested in what you think of it in general @allisonkarlitskaya and @jelly |
allisonkarlitskaya
approved these changes
Feb 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This reduces our tools like
ruffto a single source of truth (as all our other projects already run their unit tests and linting in the tasks container). It also removes a lot of moving parts only relevant for CI. In practice, us developers run the unit tests in toolbox or our own dev machines anyway.