Skip to content
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

Add package_* test scenarios #6752

Merged
merged 14 commits into from Apr 6, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y openldap-clients
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using # packages = openldap-clients? I think it would perform better in case of combined mode as packages from this metadata should be installed at once before running the tests. Is that correct @matejak ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Benefit I see in the implemented approach is that it's clear that the installation is the actual test scenario.

With the # packages = ... approach, the installation will be part of test environment preparation and scenario will be empty (or it might be required to call some command in the scenario like true but nothing relevant to the test).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer Milan's approach with this test

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Benefit I see in the implemented approach is that it's clear that the installation is the actual test scenario.

With the # packages = ... approach, the installation will be part of test environment preparation and scenario will be empty (or it might be required to call some command in the scenario like true but nothing relevant to the test).

Yes, my idea was to have it like that as fetching yum database in every test scenario will significantly increase the tests run time when testing all rules from a profile, for example in combined mode. Isn't it actually obvious from the filename of the test scenario that it is about installation/removal?
To summarize, I am not strictly against this approach, but I would still prefer if we would use the packages metadata. I think that test suite run times are pretty high and I don't want to increase them even more if we don't have to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see both sides, and I think that there may be a solution - if you declare that you need the yum package, the test environment will have the package metadata up-to-date, so it will be only the installation that takes time for that scenario, and that's IMO OK. Moreover, the test scenario clearly needs yum, so that's not a hack.
Without that, I agree that every scenario would fetch the metadata again, which I see as a great waste of time and of electrical power.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting idea. I have added that in last commit, can you confirm that it's what you meant?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mildas Yes, thank you for updating test scenarios and thanks to @matejak for this clever idea :)

@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y openldap-clients
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y chrony
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y chrony
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y xinetd
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y xinetd
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y ypbind
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y ypbind
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y telnet
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y telnet
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y squid
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y squid
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y xorg-x11-server-common
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y xorg-x11-server-common
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y audit
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y audit
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y firewalld
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y firewalld
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y libselinux
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y mcstrans
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y mcstrans
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y setroubleshoot
@@ -0,0 +1,3 @@
#!/bin/bash

yum remove -y setroubleshoot
@@ -0,0 +1,4 @@
#!/bin/bash
# package = yum

yum install -y sudo
@@ -0,0 +1,3 @@
#!/bin/bash

rpm -e --nodeps sudo