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

(PDK-1108) Add pdk set config command #859

Merged
merged 5 commits into from
Mar 5, 2020

Conversation

glennsarti
Copy link
Contributor

@glennsarti glennsarti commented Feb 24, 2020

Previously the PDK::Config class could only read (get) values, it could not set
them easily, and lacked logic to deal with different value types, for example
if you set a deep hash value, then the save data method on the namespace was
not triggered.

This commit:

  • Adds a PDK::Config.set method which takes into account nested namespaces,
    setting deep hashes, creates missing hash structures, and can add to, or
    explicitly set array, values. All of this is necessary for the CLI component

  • Adds tests for the different scenarios


Now that the PDK::Config class now has a set method, we can add a set config
CLI command so users can set configuration values. Later commits will add the
remove config CLI command.

This commit:

  • Adds the basic pdk set config command
  • Adds type conversion using the --type parameter
  • Adds tests for the CLI command

Previously many calls within the PDK used .user directly. However now that
there is a formal get and set method, accessing these directly is no longer
required and is a private API. This commit updates any references to these
private methods and changes them to use .get and .set appropriately.


TODO

  • Add PDK::Config.set
  • Add pdk set config command
  • Add tests (unit/acceptance)
  • Replace any internal PDK calls that set config to use the new set method e.g. PDK.config.user['foo']['bar'] = 'baz' to PDK.config.set('foo.bar', 'baz')

@glennsarti glennsarti added the WIP label Feb 24, 2020
@glennsarti glennsarti requested a review from a team as a code owner February 24, 2020 08:20
@coveralls
Copy link

coveralls commented Feb 24, 2020

Coverage Status

Coverage increased (+0.02%) to 91.29% when pulling d9458b1 on glennsarti:finish-pdk-config into 807b1b7 on puppetlabs:master.

# Should show the command help
its(:stdout) { is_expected.to match(%r{pdk set \[subcommand\] \[options\]}) }
its(:stderr) { is_expected.to have_no_output }
end
Copy link
Contributor

Choose a reason for hiding this comment

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

It'd be good to get some functional tests here as well

Copy link
Contributor Author

@glennsarti glennsarti Feb 28, 2020

Choose a reason for hiding this comment

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

The unit tests cover A LOT of those use cases. So it felt strange to duplicate them.

Anything in particular you wanted?

Copy link
Contributor

Choose a reason for hiding this comment

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

Just a few cases to ensure the expected changes on disk which unit tests mock out. Set at system level, user level, project level, ensure the file gets created on disk at the appropriate path. Seems redundant but it covers cases like #862

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, this will be VERY tricky to do in acceptance. I'd either:

  1. Have to mock File.write calls to the expected places on disk

OR

  1. Make the config classes write to a temp file location

Point 1 is already done in spec/unit/pdk/util_spec.rb once #862 is merged

Point 2 is what's being used in this test suite already except only for user files. If I was to use temporary system and project locations then it still wouldn't have picked up the issue #862

If I don't mock, then I'd be overwriting actual file content which is not expected when running acceptance. If I want to write to actual disk locations, this would be appropriate in the package-testing which is using VMs/Containters, not the localhost.


So yeah, that kind of testing needs to go in package-testing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rodjek I've added a new commit which adds some package-testing tests.

@glennsarti
Copy link
Contributor Author

Putting back to WIP until the acceptance tests are updated.

@glennsarti glennsarti added the WIP label Feb 28, 2020
lib/pdk/cli/set/config.rb Outdated Show resolved Hide resolved
lib/pdk/cli/set/config.rb Outdated Show resolved Hide resolved
lib/pdk/cli/set/config.rb Outdated Show resolved Hide resolved
its(:stdout) { is_expected.to match(%r{user.module_defaults.mock=value}) }
its(:stderr) { is_expected.to match(%r{Set initial value of 'user.module_defaults.mock' to 'value'}) }

it_behaves_like 'a saved configuration file', "{\n \"mock\": \"value\"\n}\n"
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it worth having a JSON-specific shared behavior that parses the file contents so we don't have to serialize the whitespace and everything?

E.g.

it_behaves_like 'a saved JSON configuration file', { "mock" => "value" }

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed the bulk of the tests to use JSON (ala Hash) matching and just one for file content. I need that one to prove it's outputting "pretty" JSON instead of mini-fied JSON which is hard to read.

spec/acceptance/set_config_spec.rb Outdated Show resolved Hide resolved
spec/unit/pdk/cli/set/config_spec.rb Outdated Show resolved Hide resolved
Previously the PDK::Config class could only read (get) values, it could not set
them easily, and lacked logic to deal with different value types, for example
if you set a deep hash value, then the save data method on the namespace was
not triggered.

This commit:

* Adds a PDK::Config.set method which takes into account nested namespaces,
  setting deep hashes, creates missing hash structures, and can add to, or
  explicitly set array, values.  All of this is necessary for the CLI component

* Adds tests for the different scenarios
Now that the PDK::Config class now has a set method, we can add a `set config`
CLI command so users can set configuration values.  Later commits will add the
`remove config` CLI command.

This commit:
* Adds the basic `pdk set config` command
* Adds type conversion using the `--type` parameter
* Adds tests for the CLI command
Previously there were no full tests for the get and set configuration.  This
commit adds package-testing tests which modifies configuration files on actual
systems during testing.
Previously many calls within the PDK used `.user` directly.  However now that
there is a formal get and set method, accessing these directly is no longer
required and is a private API.  This commit updates any references to these
private methods and changes them to use .get and .set appropriately.
This commit updates the tests to use the anything matchcer instead of Object as
per recommended practice in rspec-mocks.
@glennsarti glennsarti merged commit c401002 into puppetlabs:master Mar 5, 2020
@glennsarti glennsarti deleted the finish-pdk-config branch March 5, 2020 04:56
@glennsarti glennsarti modified the milestones: March 2020, April 2020 Mar 27, 2020
@scotje scotje added the feature label May 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants