[release-0.0.99.5] Prepare stable branch (part 6) #1746
Conversation
The working directory from which bats(1) is invoked might not be part of
the Toolbx container. eg., the downstream Fedora CI invokes the tests
as:
$ cd /path/to/toolbox/test/system
$ bats .
... and it led to:
not ok 8 help: Try unknown command (forwarded to host)
# tags: commands-options
# (from function `assert_line' in file
./libs/bats-assert/src/assert.bash, line 488,
# in test file ./002-help.bats, line 135)
# `assert_line --index 0
"Error: unknown command \"foo\" for \"toolbox\""' failed
#
# -- line differs --
# index : 0
# expected : Error: unknown command "foo" for "toolbox"
# actual : Error: crun: chdir to `/usr/share/toolbox/test/system`:
No such file or directory: OCI runtime attempted to invoke a
command that was not found
# --
#
containers#1560
containers#1745
(backported from commit 1e90c72)
The system tests can be very I/O intensive, because many of them copy OCI images from the test suite's image cache directory to its local container/storage store, create containers, and then delete everything to run the next test with a clean slate. This makes them slow. In the case of these two particular tests, toolbox(1) is supposed to validate the command line options before trying to find the image. So, there's no need to copy the image from the test suite's image cache directory to its local container/storage store. Fallout from 32b147b containers#1595 containers#1745 (backported from commit adc8650)
Fedora 39 reached End of Life on 26th November 2024: https://docs.fedoraproject.org/en-US/releases/eol/ containers#1602 containers#1745 (backported from commit 0bb4ff8)
containers#1619 containers#1745 (backported from commit c2520f2)
Summary of ChangesHello @debarshiray, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request is a continuation of the efforts to prepare the Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
The system tests can be very I/O intensive, because many of them copy OCI images from the test suite's image cache directory to its local container/storage store, create containers, and then delete everything to run the next test with a clean slate. This makes them slow. The runtime environment tests, which includes the group and user tests, are particularly slow because they don't skip the I/O even when testing error handling. This makes them a good target for optimizations. The group and user tests check the group and user configuration in different containers without changing their state. Therefore, a lot of disk I/O can be avoided by creating these containers only once for all the tests. This can reduce the time needed to run the group and user tests from almost 22 minutes to almost 5 minutes. containers#1635 containers#1746 (backported from commit 3017a46)
debarshiray
force-pushed
the
wip/rishi/prepare-release-0.0.99.5-part-6
branch
from
b598bfa to
cf78a72
Compare
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request prepares the release-0.0.99.5 stable branch by updating CI configurations and refactoring tests. The changes to .zuul.yaml correctly scope the test jobs to the new release branch and update the Fedora versions used in system tests. The test files see several improvements, most notably in test/system/206-user.bats, where moving container creation to setup_file will significantly improve test execution speed. Other changes involve cleaning up unnecessary image pulls in tests that validate command-line arguments. Overall, the changes are well-implemented, improve performance and maintainability, and appear correct for the stated purpose. I did not find any issues requiring changes.
Fedora 40 reached End of Life on 13th May 2025: https://docs.fedoraproject.org/en-US/releases/eol/ containers#1650 containers#1746 (backported from commit 7cfe9a7)
containers#1730 containers#1746 (backported from commit 431f7f0)
Fedora 41 reached End of Life on 15th December 2025: https://docs.fedoraproject.org/en-US/releases/eol/ containers#1733 containers#1746 (backported from commit 36605d8)
The GitHub Actions workflows for building and publishing the images were removed because the image definitions were removed from this branch [1]. [1] Commit f2b2a18 containers@f2b2a18ddef288a3 containers#1739 containers#1746
The system tests can be very I/O intensive, because many of them copy OCI images from the test suite's image cache directory to its local container/storage store, create containers, and then delete everything to run the next test with a clean slate. This makes them slow. The runtime environment tests, which includes the networking tests, are particularly slow because they don't skip the I/O even when testing error handling. This makes them a good target for optimizations. The networking tests check the behaviour and configuration of the network in different containers without changing their state. Therefore, a lot of disk I/O can be avoided by creating these containers only once for all the tests. This can reduce the time needed to run the networking tests from almost 15 minutes to almost 6 minutes. containers#1637 containers#1746 (cherry picked from commit 1b9dd00)
The system tests can be very I/O intensive, because many of them copy OCI images from the test suite's image cache directory to its local container/storage store, create containers, and then delete everything to run the next test with a clean slate. This makes them slow. The runtime environment tests, which includes the D-Bus tests, are particularly slow because they don't skip the I/O even when testing error handling. This makes them a good target for optimizations. The D-Bus tests check if methods can be called across the user or session and system D-Bus instances from different containers without changing their state. Therefore, a lot of disk I/O can be avoided by reating these containers only once for all the tests. This can reduce the time needed to run the D-Bus tests from almost 10 minutes to almost 5 minutes. containers#1641 containers#1746 (cherry picked from commit 5881bc4)
|
Build succeeded. ✔️ unit-test SUCCESS in 1m 49s |
|
Build succeeded. ✔️ unit-test SUCCESS in 1m 44s |
|
Build succeeded. ✔️ unit-test SUCCESS in 1m 47s |
1 participant
... for CVE-2025-65637 or GHSA-4f99-4q7p-p3gh.
https://github.com/containers/toolbox/security/dependabot/26