In order to allow for multiple platforms on Jenkins, use the
platform environment variable in the rake task for acceptance tests
to determine which platform to run on.
Prior to this commit, the test module used in testing was using
a Modulefile rather than metadata.json. Switch to metadata.json
instead since Modulefile is deprecated and was causing a deprecation
warning during acceptance testing.
In order to help ensure that the strings module is not broken
during development, add a full system integration test which can
run at regular intervals to ensure that the module is working as
expected.
The test installs the string module as well as a test module which
contains the different types of puppet and ruby code that the strings
module can document. It then runs strings and ensures that the HTML
generated is correct.
Additionally, make some changes to the Gemfile to allow strings to
be run as a gem even if it isn't installed in the modulepath. Also
make a few changes to the unit tests to make them compatible with
the version of rspec required by Beaker.
* hkenney-maint/master/add_committers_and_contributing_md:
(maint) Remove reference to other platforms
(maint) Remove references to stable in COMMITTERS
(maint) Add COMMITTERS.md and CONTRIBUTING.md
Closes GH-11
The "other platforms" is language from puppet where we don't always have
access to various OS and version combinations. Strings is much simpler
and so it isn't really relevant.
* hkenney-maint/master/pdoc-10_update_readme_md:
(PDOC-10) Try to simplify the installation
(maint) Add LICENSE file
(PDOC-10) Update README.md to be more detailed
The instructions for installation provided a lot of different
alternatives. In order to quickly answer the question of "how do I use
this" we can just give the most common ways of getting it installed.
Due to a merge conflict that was not properly resolved, a method
which did not exist was being called in the server action, causing
the action to fail. Remove the unneeded method call so that the
server action will work as intended.
Since puppet strings is a very small project, at the moment we
don't need to maintain a master and a stable branch. As a result,
the COMMITTERS.md guide should not contain references to the stable
branch or include information around dealing with both the master
and stable branch. Remove these references so that COMMITTERS is
consistent with our approach to the strings repository.
The plugin.rb file really only did configuration of components that were already loaded.
By relocating to the strings.rb file, it provides a central place for all of the loading
and configuration of the strings components.
Prior to this commit, the requires for the puppetx portion of this
project were dealt with in each individual file. In order to make
the code more readable and the requires more clear, move them all
into the strings file.
Prior to this commit, many of the classes in this project were declared
in two lines. The first line would put them in the context of the module
they belonged to, and the second line would declare the class and deal with
inheritance. In order to make the code more readable and to allow
require statements to be moved to the top level, turn all class declarations
into one line statements.
Prior to this commit, the puppet strings project was using require_relative
to include other classes and modules. Due to some ambiguity and the fact
that the strings project shares some naming conventions with YARD, the
use of require_relative sometimes made it unclear what was being
included and where it was coming from. Now require is being used and although
this requires the full path, it makes it very clear where things are coming
from.
Refactor the actions module so that it is a class. This is important
because it allows us to keep `Puppet[]` calls out of the library and
have them in the face itself. Additionally, move a few things around
(like `check_required_features` since it makes require statements
cleaner) and clean up some comments.
Refactor the code in the strings face and extract much of the functionality
into a separate library in order to make the code more readable and
sustainable. Additionally, remove the `modules` action from the face
since it does not have a clear use case currently. However since the `server`
action depends on it, and it may be helpful to add other features in the future,
extract the functionality previously contained in `modules` into a helper
method.
Prior to this commit, several rspec tests were using `decribe "string"'
instead of `describe constant`. Update the tests to use the constant instead.
Additionally, rename the puppet function tests to reflect the renaming of the
handlers.
In order to make contributions more accessible to the community,
add COMMITTERS.md and CONTRIBUTING.md so that there are instructions
and resources for those who would like to contribute to the strings
module.
In order to make the Gemfile compatible with the puppet strings
Jenkins job (which tests against multiple versions of puppet), update
the Gemfile to allow for for the Jenkins job to specify which version
of puppet it is testing against.
Prior to this commit, the handlers and code objects which dealt with
puppet functions were referred to as `FutureParserFunctions` and
`ParseFunctions`. This naming convention will not make very much
sense going forward when the future parser becomes the primary
parser. Therefor, rename `FutureParserFunctions` to `Puppet4xFunctions`
and `ParserFunctions` to `Puppet3xFunctions`.
Since we don't want the name of the tool to reflect the fact that
it is using yard internally (this is an implementation detail), rename
the face to `strings`. Now when one wishes to generate documentation,
`puppet strings` will be used rather than `puppet yardoc`.
In order to make the code more readable, separate the tests into
different files for each handler. Additionally, extract the helper
methods into a separate module which may be included as needed.
Update the tests around the host class handler so that they test
several different examples as opposed to just one. Additionally,
refactor the tests so that they are more detailed when it comes to
checking if the Registry is in the correct state after code has been
parsed.
Rework the tests around the 3x function handler. Make them more
verbose by having them them test against multiple examples and by making
the checking of the Registry more details.
Like the 4x function handler tests, the tests around the defined
type handler were not very specific and didn't use multiple examples.
Update the tests so that they do more than just ensure that the right
objects were added to the Registry and cover a few different cases
instead of just one.
Update the spec tests which cover the Puppet 4x function handler
to be more specific and cover different test cases. Prior to this commit,
they would simply check that the right objects had been added to the
Registry for one example. Now, they examine multiple examples and ensure that
the code objects not only exist but that the details about them are what we
would expect for each specific scenario.
Add tests to ensure that the face (puppet yardoc) works from end to
end. In other words, ensure that when given a module, puppet yardoc can
successfully evaluate the .pp and .rb files present in the module and
produce the expected HTML.
Add tests for the remaining two Puppet-specific handlers that were
not tested in the previous commit. Specifically, add tests for the
3.x function handler and the host class handler.
Begin to test the YARD handlers written for the puppet language.
Add basic tests for the defined type and puppet 4 function
handlers. In addition, make changes to the spec helper to make it
easier to work with YARD Registries for testing purposes.
Prior to this commit there was no testing around the pops component.
Since most of the API in the pops component is private, there aren't
very many things to test, so add just a few test cases.
Additionally rename a previous spec file and make some changes to
the Gemfile.
Add spec tests for Puppet face component, mainly around error checking.
Due to the use of `puppet module list`, the behavior of the `modules`
and `server` actions are not very feasible to test via spec testing.
Additionally, make a few minor changes to the gem file, and make a
small change in `check_required_features` to reflect the fact that
this module will no longer support anything earlier than Ruby 1.9.
Prior to this commit there was no Gemfile for this project. Now
a Gemfile has been added so that those developing the project
can take advantage of Bundler.
This patch recurses into any `create_function` block and processes any
`dispactch` blocks contained within. The implementation assumes docstrings will
be provided as a comment block, but this is just a temporary placeholder.
Idealy, the contents of the `dispatch` block would be processed to produce an
`@override` tag for 4.x functions.
All Future Parser functions are documented using a standard YARD comment block.
This commit adds a new code object that watches for `create_function` and
generates a YARD `CodeObject::MethodObject` containing the docstring.
Hailee Kenney