This patch catches and reports on issues that have occurred during YARD
processing of the data to be processed.
The issue itself is not resolved but this does provide you with as much
documentation as can be reasonably generated for your materials without
crashing the build.
This was the result of the Baltimore Puppet Users Group Meetup of 22
June 2016.
Prior to this commit, we were not setting a specific version of
YARD in the Gemfile. Since YARD has a lot of potential to break the
way strings works since strings relies so much on YARD internals,
we should be more deliberate about deciding to upgrade to a new
YARD version.
Once the kinks are worked out with the 0.9 release of YARD, we will
update the Gemfile again.
This is additional work for QENG-3888 in ci-job-configs. We were using static
nodesets within specs/acceptance/nodesets before and this commit will instead use beaker-hostgenerator
to get the specified platform .yml configurations.
Prior to this commit, strings had a hostfile that was using an old
format that is no longer compatible with beaker which was causing
the acceptance tests to fail.
Update the hostfile so that it works.
Prior to this commit, the acceptance tests were trying to install
strings as a module and failing due to the fact that strings has
transition to a gem and does not have metadata. Update the tests
so that they install strings as a gem instead.
Prior to this commit, the Gemfile did not specify an rspec version
but relied on methods that were only in rspec 3. In order to prevent
failures when running with versions older than 3, tie the specs to
3.1 or greater, which is what puppet does.
Update the README to reflect the fact that strings will not longer
be released as a forge module. Include a quick note to explain that
while the module is still available on the forge, that is not the
preferred method of installation because it will not be updated.
It will prevent providers of different types but with
the same name from merging together.
For example:
type1:ruby
type2:ruby
type3:ruby
Will be different providers instead of the one "ruby" provider.
Prior to this commit, the rake task section of the README did not
reflect that strings:generate rake task would also create a strings.json
file. Update the README to include this detail.
Prior to this commit, strings relied on failure_message_for_should
which produced a deprecation warning. Use the suggested alternative
'failure_message' instead to removed the deprecation warning and
ensure the tests are up to date.
Prior to this commit, strings would fail with puppet 4.4.0 and
newer. This was because strings was making use of a method that was
marked API private and thus subject to change. The method was changed
in 4.4.0 release of puppet to take two variables, meaning that strings
much adjust how it calls the method based on the version of puppet
it's running with.
Prior to this commit, the beaker gem and all its dependencies were
being installed just to run spec tests. Excluding beaker when running
spec tests should make things go faster because we won't have to
install so many gems.
Prior to this commit, the gemspec for strings relied on the module
metadata.json. Since we would ultimately like to stop releasing
strings as a module entirely, update the gemspec not to rely on the
module metadata so it is not broken when we ultimately remove it.
Since 0.4.0 will be the last version of strings released as a puppet
module, update the README to reflect the fact that this method of
distribution is deprecated and add a description of how to install
the Ruby gem version of strings.
I'm super enthusiastic about the potential for folks to build things on
top of the JSON output, we've had several related conversations at
Config Management Camp and on puppet-dev recently. I think this is a
sane default, and calling the file strings.json seems a nice
reinforcement.
Without a .yardopts options array.pop is nil, and everything explodes
with an exception. Applying this patch allowed for running rake
strings:generate cleanly.
Note that this did not affect strings:serve.
Peter Huene