You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new Rubocop based AST Parser for inspec control processing is a great set of work and opens up a whole new set of future possibilities from streamlining profile updates and patches to automated and or even AI supported content generation. With any new effort however there are always corner cases that get missed in 1.0.
This issue is a placeholder to collect found issues that can be resolved as they are found
Input Collector
Challenge: Inputs without quotes do not seem to be parsed correctly, and or, do not throw a clear error the end user.
Suggestion: Add a better error message and see if we can collect from the parse tree which control has the offense so we can easily tell the user file 'x' has a bad input called 'y'.
Challenge: Adding the ability to actually parse and then do 'CRUD' style operations on parsed controls
Suggestion: Look into collecting all this good work into a gem called 'inspec-profile-parser' which would give a logical place to put the 'output' stage of this work and then this could be reused more directly.
The unit / functional tests do a good job of reading in all the elements of the control but some users may find it very useful to be able to work with the control structure and parsed data more like a library. Although this may be better suited in a larger library.
The start of 'cookstyle' inspec cops for each of the inspec object types?
Opportunity: The cookstyle project started making cops for inspec but as an outcome of this work, the start of cops that actually understood all the parts, prices of an inspec control and how they fit together was born, this is a great way also to start to build an auto-correctable 'inspec profile and control style guide'.
It seems this would be a great start at cops, with autocorrect capability, for each of the parts of an inspec control
Export to YAML seems to create malformed YAML with Rubocop object references when the inspec.yml has a input with no default value
Export to YAML seems to produce an odd YAML format, technically correct yaml but harder to work with
:key: value
vs
key: value
InSpec control_code_body
It would seem that we have all the parts in the parser worked out but left the actually 'ruby code body' on the table. With the parser collecting all the other elements of the controls, such as title, descriptions, tags, inputs etc. what remains in the AST must but 'the ruby part' of the control. Some users may find it useful to be able to be able to extract this part of the control object should they want to use it easily. Again perhaps more logically a part of the inspec-profile-parser gem .
Thor Inspec CLI export command forgot the to add the --with-tests flag for the export that we can pass to the ast_profile_helper.
The export with tests still 'doubles the tests' ( seems a known issue given there is a uniq call in the class but that doesn't seem to be catching everything.
The new Rubocop based AST Parser for inspec control processing is a great set of work and opens up a whole new set of future possibilities from streamlining profile updates and patches to automated and or even AI supported content generation. With any new effort however there are always corner cases that get missed in 1.0.
This issue is a placeholder to collect found issues that can be resolved as they are found
Missing
to_ruby
functionsThe unit / functional tests do a good job of reading in all the elements of the control but some users may find it very useful to be able to work with the control structure and parsed data more like a library. Although this may be better suited in a larger library.
The start of 'cookstyle' inspec cops for each of the inspec object types?
Opportunity: The cookstyle project started making cops for inspec but as an outcome of this work, the start of cops that actually understood all the parts, prices of an inspec control and how they fit together was born, this is a great way also to start to build an auto-correctable 'inspec profile and control style guide'.
It seems this would be a great start at cops, with autocorrect capability, for each of the parts of an inspec control
Export to YAML seems to create malformed YAML with Rubocop object references when the inspec.yml has a input with no default value
Export to YAML seems to produce an odd YAML format, technically correct
yaml
but harder to work withvs
InSpec
control_code_body
It would seem that we have all the parts in the parser worked out but left the actually 'ruby code body' on the table. With the parser collecting all the other elements of the controls, such as title, descriptions, tags, inputs etc. what remains in the AST must but 'the ruby part' of the control. Some users may find it useful to be able to be able to extract this part of the control object should they want to use it easily. Again perhaps more logically a part of the
inspec-profile-parser
gem .Thor Inspec CLI export command forgot the to add the
--with-tests
flag for the export that we can pass to the ast_profile_helper.The export with tests still 'doubles the tests' ( seems a known issue given there is a
uniq
call in the class but that doesn't seem to be catching everything.@sathish-progress , @clintoncwolfe , @lokeshk1987, @wdower
The text was updated successfully, but these errors were encountered: