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

Checking semantic while importing AY settings #61

Merged
merged 15 commits into from
May 3, 2018

Conversation

schubi2
Copy link
Member

@schubi2 schubi2 commented Apr 26, 2018

No description provided.

@@ -88,6 +89,18 @@ def import(profile)
enable if profile.fetch("enable_firewall", settings.enable_firewall)
start if profile.fetch("start_firewall", false)
importer.import(profile)

# Checking if an interface has been defined for different zones
Copy link
Member

Choose a reason for hiding this comment

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

Nitpicking: we expect this to be extended in the future, a separate function, e.g., check_profile_for_errors might be better

@schubi2 schubi2 changed the title WIP: Checking semantic while importing AY settings Checking semantic while importing AY settings May 2, 2018
Copy link
Contributor

@imobachgs imobachgs left a comment

Choose a reason for hiding this comment

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

In general, it looks good. Just added some suggestions.

-------------------------------------------------------------------
Fri Apr 27 16:35:19 CEST 2018 - schubi@suse.de

- AutoYaST: Reporting warning if an interface has been defined
Copy link
Contributor

Choose a reason for hiding this comment

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

I would say just warn or report. Something like Report whether an interface....

def check_profile_for_errors
# Checking if an interface has been defined for different zones
zones = firewalld.export["zones"] || []
all_interfaces = zones.collect { |zone| zone["interfaces"] || [] }
Copy link
Contributor

Choose a reason for hiding this comment

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

We usually prefer #map to #collect (although they are just aliases). And, in this case, you might want to use flat_map (removing the #flatten! call):

all_interfaces = zones.flat_map { |z| z["interfaces"] || [] }

Take the #flat_map comment just as a suggestion, please, and feel free to ignore it :)

end
end

let(:i_list) { IssueList.new }
Copy link
Contributor

Choose a reason for hiding this comment

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

You can use a double here (or a instance_double):

let(:i_list) { double("IssuesList") }

See https://relishapp.com/rspec/rspec-mocks/v/3-7/docs/basics/test-doubles or https://relishapp.com/rspec/rspec-mocks/v/3-7/docs/verifying-doubles.

expect(firewalld).to receive(:export)
.and_return("zones" => [{ "interfaces" => ["eth0"], "name" => "public" },
{ "interfaces" => ["eth0", "eth0"], "name" => "trusted" }])
expect(Yast::AutoInstall).to receive(:issues_list).and_return(i_list)
Copy link
Contributor

Choose a reason for hiding this comment

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

np: I would move this line to a before block because it is somehow a precondition.

before do
 allow(Yast::AutoInstall).to receive(:issues_list).and_return(i_list) # We use `allow` instead of `expect`.
end

.and_return("zones" => [{ "interfaces" => ["eth0"], "name" => "public" },
{ "interfaces" => ["eth0", "eth0"], "name" => "trusted" }])
expect(Yast::AutoInstall).to receive(:issues_list).and_return(i_list)
expect_any_instance_of(IssueList).to receive(:add)
Copy link
Contributor

Choose a reason for hiding this comment

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

Given that, in the previous line, you set Yast::AutoInstall#issues_list to return i_list, this should work:

expect(i_list).to receive(:add)
  .with(...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants