-
-
Notifications
You must be signed in to change notification settings - Fork 882
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 explicit parameter types to all parameters #1189
Conversation
b21e1b2
to
a06ecf8
Compare
As I continue to work through this, I notice that there are a bunch of odd situations that should probably discussed.
I'll add examples in contextual comments once I get my branch passing unit tests. |
In #1155 I started doing the same. Could be good to align the two. |
Agreed. After I update my branch to pass all tests, I think it would be
best to gather consensus regarding the odd situations I mentioned, to
determine if the definition or behavior within the module needs to change.
|
For now I added the backwards-incompatible label because I don't know if any type changed. This may not be true and we could remove it later. I'd be happy to change some parameters so the types are consistent and parameters aligned.
I noticed those as well when I started to work on it. I'd be happy if we could be consistent. |
1631dc2
to
60b171b
Compare
Now that #1190 is fixed, it looks like all tests are passing. When I have some time (hopefully this weekend), I will comment on the cases that should be discussed. |
One pattern I've noticed a bunch of times is the use of strings "on" and "off" to match nginx's config representation, rather than booleans. Do we want to standardize these values, and restrict these parameters to Enum["on","off"], or should a breaking change be introduced to set these as boolean parameters? |
That's something I've struggled with as well. I believe there are option that accept |
Is there any consensus on whether Enums with ["on","off"], booleans, or the current hybrid of the two and the optional type should be used? Since this will be a breaking change, I want to make sure there's some agreement before standardizing it one way or another. |
1b08230
to
72f4f98
Compare
72f4f98
to
cfed312
Compare
I believe this is ready for review and discussion. |
cfed312
to
1a30582
Compare
manifests/init.pp
Outdated
Optional[String[1]] $daemon_group = undef, | ||
String[1] $global_owner = $::nginx::params::global_owner, | ||
String[1] $global_group = $::nginx::params::global_group, | ||
Stdlib::Filemode $global_mode = $::nginx::params::global_mode, |
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.
great that we finally have a datatype for this
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.
manifests/init.pp
Outdated
Variant[String[1], Boolean] $pid = $::nginx::params::pid, | ||
String[1] $proxy_temp_path = $::nginx::params::proxy_temp_path, | ||
String[1] $root_group = $::nginx::params::root_group, | ||
String[1] $run_dir = $::nginx::params::run_dir, |
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.
We can you Stdlib::Absolutepath here?
@@ -300,10 +300,10 @@ | |||
# Check to see if SSL Certificates are properly defined. | |||
if $ssl { | |||
if $ssl_cert == undef { | |||
fail('nginx: ssl_cert must be set to false or to a fully qualified path') | |||
warning('nginx: ssl enabled but ssl_cert undef') |
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.
why did you change this? Doesn't a fail() make more sense?
1a30582
to
3677b16
Compare
Optional[String[1]] $proxy = undef, | ||
Nginx::Duration $proxy_read_timeout = $::nginx::proxy_read_timeout, | ||
Nginx::Duration $proxy_connect_timeout = $::nginx::proxy_connect_timeout, | ||
Array[String[1]] $resolver = [], |
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.
now resolver is a required parameter, it needs to contain a string, this wasn't the case before. Should we change it back?
3677b16
to
cfc9f32
Compare
cfc9f32
to
8f12b01
Compare
8f12b01
to
24f7831
Compare
Is there still interest in this? |
There sure is! I raised a few inline questions within the code, can you take a look? In the meantime we also defined some guidelines for a consistent code style: https://voxpupuli.org/docs/#reviewing-a-module-pr |
To get this merged I think it's easier if we split this up into manageable pieces. Would you be willing to submit a PR per file? |
Ping @JacobHenner :) |
Dear @JacobHenner, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
1 similar comment
Dear @JacobHenner, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
Dear @JacobHenner, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
Dear @JacobHenner, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
Replacement in #1413 |
This is a WIP to specify parameter datatypes where missing, and reconsider some potentially inconsistent types.