Details
-
New Feature
-
Status: Closed
-
Normal
-
Resolution: Done
-
None
-
None
-
None
-
3
-
Language 2015-03-18, Language 2015-04-01
Description
Migration checking should be implemented as a Puppet::Pops::Migration::MigrationChecker class, that is instantiated and bound to the key :migration_checker in the Puppet Context. (This is done by the preview --migrate option when it compiles against the preview environment).
The MigrationChecker will have a number of methods to perform specific checks that will be called from various places in the 4.x evaluation logic (and possibly a few places in the 3.x logic). The specific checks are logged as individual tickets.
Logic that performs actions that should be checked should typically lookup the MigrationChecker and remember it for fastest possible access (i.e. set a instance variable when the evaluation class is created).
The module PuppetX::Puppetlabs::Migration::MigrationIssues in the module created in PUP-4149 should also be created for the purpose of containing migration specific Puppet ::Pops::Issues::Issue instances bound to constants (see puppet/pops/issues.rb). The implementation of the MigrationChecker API should require this file (and all other files specific to migration checking to ensure they are loaded).
The implementation of the MigrationChecker should configure the infrastructure to use issues (acceptor, severity-producer, etc.) and provide convenience methods to report issues (suggest the method report having the same signature as the runtime3_support.fail method.
The acceptor should discard all duplicate reported entries; an issue with the same issue code and identical semantic object (i.e. the same AST "instruction") - this since reported issues in a defined type may be evaluated a large number of times.
The entire implementation except the MigrationChecker API class, should be in the module created in PUP-4149).
Attachments
Issue Links
- blocks
-
PUP-4129 Add migration check for unquoted numbers
-
- Closed
-
- links to