add facts showing available updates

[damoxc]

Making use of the apt-check command from the 'update-notifier-common'
package (if available) display the number of available updates, number of
security updates as well as the update package names.

[daenney]

I would prefer apt_package_updates, that reads more natural and is more in line with apt_security_updates.

[damoxc]

Easily changed, will do so in another commit.

[daenney]

Looks good to me now! @mhaskel What do you think, facts okay?

[underscorgan]

@daenney @damoxc I'm good with there being facts, but I'd like to see some docs and at least unit testing, I suspect the facts can be tested thoroughly enough with unit tests to not need acceptance tests.

[damoxc]

Are you able to point me in the direction of some examples of docs / unit tests for the facts please?

[daenney]

I think with docs @mhaskel simply meant an update to the README that we ship these facts, what they mean and mention the difference in behaviour between Facter 1.x and 2.x.

As far as the tests go, unfortunately just about any kind of documentation on that subject is missing which is why I didn't ask for them. The best I can do right now is point you at http://unethicalblogger.com/2014/03/01/testing-custom-facts-with-rspec.html and https://github.com/puppetlabs/facter/tree/master/spec/unit

@adrienthebo might be able to be of some help on the matter.

[adrienthebo]

https://github.com/puppetlabs/puppetlabs-pe_upgrade/blob/master/spec/unit/pe_upgrade_installer_spec.rb and https://github.com/puppetlabs/puppetlabs-pe_upgrade/blob/master/spec/unit/pe_upgrade_distro_version_spec.rb are a couple of examples of how custom facts can be tested.

[underscorgan]

@damoxc @daenney correct, for docs I was just looking for README updates.

[damoxc]

Is the doc update at https://github.com/cloudbuy/puppetlabs-apt/tree/docs-update#facts OK? Just looking at sorting the unit tests now.

[underscorgan]

@damoxc Could you make the docs H3 instead of H2 (### instead of ##). As it is it makes it look like some later examples are nested under facts which is a bit confusing.

[damoxc]

Done, and unit tests added (hopefully correct unit tests!)

[daenney]

It's looking good.

However, by now we're up to 6 commits for a single feature. In order to keep the history nice and tidy I would prefer it if this could be squashed into a single commit as it essentially is one change/feature.

[damoxc]

That OK?

[underscorgan]

As long as it passes travis-ci this should be good to merge!

[daenney]

@damoxc Excellent, thank you! It's very nice to work with people who are this responsive to their PR's.

Travis seems to be a bit backed up right now so it might take a while before this goes green.

[damoxc]

My pleasure, thanks for all the guidance. First time using rspec really. Just hope it does go green!

[daenney]

@damoxc So Travis broke on Puppet 3.4.0 releases:

  1) apt_package_updates fact on Debian based distro with Facter 2.0+ should == ["puppet-common", "linux-generic", "linux-image-generic"]
     Failure/Error: it { should == ['puppet-common', 'linux-generic', 'linux-image-generic'] }
       expected: ["puppet-common", "linux-generic", "linux-image-generic"]
            got: "puppet-common,linux-generic,linux-image-generic" (using ==)
     # ./spec/unit/facter/apt_package_updates_spec.rb:21

It looks like something went wrong there, your spec is expecting an array but we get the stringified version.

I'd try and install Puppet 3.4.0 locally and run the specs with that, see what happens.

[damoxc]

Just having my morning caffeine requirement then going to tackle it.

[damoxc]

Looks like the Puppet 3.4 gem pulls in Facter 1.7 so in the first test case where I wasn't explicitly setting the Facter version it would see Facter 1.7.6 in both test cases. I've decided to just merge the 2 test cases since one of the environments covers both code paths. Seem OK?

[damoxc]

Just noticed there was some funky spacing in the unit tests so fixed that and re-pushed.

[daenney]

Thank you for sticking with us and Travis!