-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test/system: Test startup on Rawhide with supported versions #899
test/system: Test startup on Rawhide with supported versions #899
Conversation
Build failed.
|
5ce4c6a
to
a516f3a
Compare
Build succeeded.
|
a516f3a
to
a3a1867
Compare
Build failed.
|
dfb9312
to
e1dd399
Compare
Build succeeded.
|
Do we want the test to be only for Fedora Rawhide or should I adjust it even for older releases? The bottom limit would still be the "eldest" supported release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
e1dd399
to
b402f11
Compare
We need to know if the latest changes in the libc (that is dynamically linked to the binary) causes problems in containers based on older releases of Fedora. The estimate of the version numbers ís very crude and does not follow the upstream schedule. That should not be a problem. A part of an existing test has been reused an made into a helper function to implement this. containers#899
b402f11
to
fda018d
Compare
Build succeeded.
|
The 'die' function is a remnant from times before the system tests rewrite. It served for writing an error message and then failing the test. Since the rewrite it is no longer present. Instead, simply use 'false' in case a caching step fails. Fallout from da6b6a7 containers#899
We need to know if the latest changes in the libc (that is dynamically linked to the binary) causes problems in containers based on older releases of Fedora. The estimate of the version numbers ís very crude and does not follow the upstream schedule. That should not be a problem. A part of an existing test has been reused an made into a helper function to implement this. containers#899
fda018d
to
da7ec24
Compare
Let's stick to Rawhide for now as it is the main motivation behind this test and other releases may be added in the future. |
We need to know if the latest changes in the libc (that is dynamically linked to the binary) causes problems in containers based on older releases of Fedora. The estimate of the version numbers is very crude and does not follow the upstream schedule. That should not be a problem, though. A part of an existing test has been reused and made into a helper function to implement this. containers#899
da7ec24
to
b6618a0
Compare
Build failed.
|
This slowness on Rawhide is making me angry. |
The 'die' function is a remnant from times before the system tests rewrite. It served for writing an error message and then failing the test. Since the rewrite it is no longer present. Instead, simply use 'false' in case a caching step fails. Fallout from da6b6a7 containers#899
We need to know if the latest changes in the libc (that is dynamically linked to the binary) causes problems in containers based on older releases of Fedora. The estimate of the version numbers is very crude and does not follow the upstream schedule. That should not be a problem, though. A part of an existing test has been reused and made into a helper function to implement this. This increases the run time of the test suite on Rawhide which already takes longer than the same test suite on released versions of Fedora. Make up for it by increasing the timeout by 2 minutes. containers#899
b6618a0
to
874bdaa
Compare
Build failed.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the new test.
This line in the commit message made me curious:
The estimate of the version numbers is very crude and does not follow
the upstream schedule. That should not be a problem, though.
Why is it crude? How does it not follow the upstream schedule? And why it shouldn't be a problem? :)
Are you referring to how we are testing N, N-1 and N-2 (where N is the version of Rawhide)?
local os_release="$(find_os_release)" | ||
local system_id="$(get_system_id)" | ||
local system_version="$(get_system_version)" | ||
local rawhide_res="$(awk '/rawhide/' $os_release)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am curious. Can't we just use grep
? It's easier to understand than awk
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like there's no commit da6b6a7c5a6e5e284e6642c29159a872ceec94e2
:
[rishi@kolache toolbox]$ git show da6b6a7c5a6e5e284e6642c29159a872ceec94e2
fatal: bad object da6b6a7c5a6e5e284e6642c29159a872ceec94e2
I suppose it's meant to be 54a2ca1
Yes, that's exactly it. |
Ah, snap. Seems like I mistakenly pointed that to my fork :/. |
We need to know if the latest changes in the libc (that is dynamically
linked to the binary) causes problems in containers based on older
releases of Fedora.
The estimate of the version numbers ís very crude and does not follow
the upstream schedule. That should not be a problem.
A part of an existing test has been reused an made into a helper
function to implement this.