.fixtures.yml

@@ -2,10 +2,10 @@ fixtures:
   forge_modules:
     stdlib:
       repo: "puppetlabs-stdlib"
-      ref: "4.5.1"
+      ref: "4.6.0"
   repositories:
     apt:
       repo: "https://github.com/puppetlabs/puppetlabs-apt.git"
-      ref: "2.0.x"
+      ref: "2.0.0"
   symlinks:
     unattended_upgrades: "#{source_dir}"

.travis.yml

@@ -0,0 +1,29 @@
+---
+language: ruby
+sudo: false
+
+script: "bundle exec rake test SPEC_OPTS='--format documentation'"
+
+matrix:
+  fast_finish: true
+  include:
+    - rvm: 2.1
+      env: PUPPET_VERSION="~> 3.0" STRICT_VARIABLES="yes" ORDERING="random"
+    - rvm: 2.1
+      env: PUPPET_VERSION="~> 3.0" STRICT_VARIABLES="yes" ORDERING="random" FUTURE_PARSER="yes"
+    - rvm: 2.1
+      env: PUPPET_VERSION="~> 4.0" ORDERING="random"
+  allow_failures:
+    - env: PUPPET_VERSION="~> 4.0" ORDERING="random"
+notifications:
+  email: false
+
+deploy:
+  provider: puppetforge
+  user: puppet
+  password:
+    secure: "PzzvPB326Yx0hheLbusZGYCGW4i1jOOMjwJMC/7QpbN4+gvMdmHpmQP3XeQ5tm+YYXqLPMyr1he1viTln8GPqLk1qpzF55H5mTakPxMjWZfRYvM+Q7lmtOEsBEXXSJk0ZYwMHXGVd8ouDrhaRzS2JqnhCAhLat0HeLcERWZx6Ok="
+  on:
+    tags: true
+    all_branches: true
+    rvm: 2.1

CHANGELOG.md

@@ -0,0 +1,14 @@
+# Change Log
+All notable changes to this project will be documented in this file.
+This project adheres to [Semantic Versioning](http://semver.org/).
+
+## [Unreleased][unreleased]
+
+## [1.0.0] - 2015-04-22
+### Added
+- Full configuration of unattended-upgrades and all possible options for `APT::Periodic`.
+- Test suite covering the current behaviour.
+- README with full documentation.
+- Boilerplate such as Gemfile, Travis configuration, LICENSE and so on.
+
+[unreleased]: https://github.com/puppet-community/puppet-unattended_upgrades/compare/1.0.0...HEAD

CONTRIBUTING.md

@@ -0,0 +1,195 @@
+Checklist (and a short version for the impatient)
+=================================================
+
+  * Commits:
+
+    - Make commits of logical units.
+
+    - Check for unnecessary whitespace with "git diff --check" before
+      committing.
+
+    - Commit using Unix line endings (check the settings around "crlf" in
+      git-config(1)).
+
+    - Do not check in commented out code or unneeded files.
+
+    - The first line of the commit message should be a short
+      description (50 characters is the soft limit, excluding ticket
+      number(s)), and should skip the full stop.
+
+    - Associate the issue in the message. If any issue exists in the body of
+      the commit a line like "Closes: #XXX" or "Mentions: #XXX" is expected.
+
+    - The body should provide a meaningful commit message, which:
+
+      - uses the imperative, present tense: "change", not "changed" or
+        "changes".
+
+      - includes motivation for the change, and contrasts its
+        implementation with the previous behavior.
+
+    - Make sure that you have tests for the bug you are fixing, or
+      feature you are adding.
+
+    - Make sure the test suites passes after your commit:
+      `bundle exec rake spec` More information on [testing](#Testing) below
+
+    - When introducing a new feature, make sure it is properly
+      documented in the README.md
+
+  * Submission:
+
+    * Pre-requisites:
+
+      - Make sure you have a [GitHub account](https://github.com/join)
+
+    * Preferred method:
+
+      - Fork the repository on GitHub.
+
+      - Push your changes to a topic branch in your fork of the repository.
+
+      - Submit a pull request to the repository in the puppet-community namespace.
+
+The long version
+================
+
+  1.  Make separate commits for logically separate changes.
+
+      Please break your commits down into logically consistent units
+      which include new or changed tests relevant to the rest of the
+      change.  The goal of doing this is to make the diff easier to
+      read for whoever is reviewing your code. In general, the easier
+      your diff is to read, the more likely someone will be happy to
+      review it and get it into the code base.
+
+      If you are going to refactor a piece of code, please do so as a
+      separate commit from your feature or bug fix changes.
+
+      We also really appreciate changes that include tests to make
+      sure the bug is not re-introduced, and that the feature is not
+      accidentally broken.
+
+      Describe the technical detail of the change(s). If your
+      description starts to get too long, that is a good sign that you
+      probably need to split up your commit into more finely grained
+      pieces.
+
+      Commits which plainly describe the things which help
+      reviewers check the patch and future developers understand the
+      code are much more likely to be merged in with a minimum of
+      bike-shedding or requested changes. Ideally, the commit message
+      would include information, and be in a form suitable for
+      inclusion in the release notes for the version of Puppet that
+      includes them.
+
+      Please also check that you are not introducing any trailing
+      whitespace or other "whitespace errors".  You can do this by
+      running "git diff --check" on your changes before you commit.
+
+  2.  Sending your patches
+
+      To submit your changes via a GitHub pull request, we _highly_
+      recommend that you have them on a topic branch, instead of
+      directly on "master".
+
+      It makes things much easier to keep track of, especially if
+      you decide to work on another thing before your first change
+      is merged in.
+
+      GitHub has some pretty good
+      [general documentation](http://help.github.com/) on using
+      their site.  They also have documentation on
+      [creating pull requests](http://help.github.com/send-pull-requests/).
+
+      In general, after pushing your topic branch up to your
+      repository on GitHub, you can switch to the branch in the
+      GitHub UI and click "Pull Request" towards the top of the page
+      in order to open a pull request.
+
+
+  3.  Update the related GitHub issue.
+
+      If there is a GitHub issue associated with the change you
+      submitted, then you should update the ticket to include the
+      location of your branch, along with any other commentary you
+      may wish to make.
+
+Testing
+=======
+
+Getting Started
+---------------
+
+Our puppet modules provide [`Gemfile`](./Gemfile)s which can tell a ruby
+package manager such as [bundler](http://bundler.io/) what Ruby packages,
+or Gems, are required to build, develop, and test this software.
+
+Please make sure you have [bundler installed](http://bundler.io/#getting-started)
+on your system, then use it to install all dependencies needed for this project,
+by running
+
+```shell
+% bundle install
+Fetching gem metadata from https://rubygems.org/........
+Fetching gem metadata from https://rubygems.org/..
+Using rake (10.1.0)
+Using builder (3.2.2)
+-- 8><-- many more --><8 --
+Using rspec-system-puppet (2.2.0)
+Using serverspec (0.6.3)
+Using rspec-system-serverspec (1.0.0)
+Using bundler (1.3.5)
+Your bundle is complete!
+Use `bundle show [gemname]` to see where a bundled gem is installed.
+```
+
+NOTE some systems may require you to run this command with `sudo`.
+
+If you already have those gems installed, make sure they are up-to-date:
+
+```shell
+% bundle update
+```
+
+With all dependencies in place and up-to-date we can now run the tests:
+
+```shell
+% rake spec
+```
+
+This will execute all the [rspec tests](http://rspec-puppet.com/) tests
+under [spec/defines](./spec/defines), [spec/classes](./spec/classes),
+and so on. rspec tests may have the same kind of dependencies as the
+module they are testing. While the module defines in its [Modulefile](./Modulefile),
+rspec tests define them in [.fixtures.yml](./fixtures.yml).
+
+Writing Tests
+-------------
+
+XXX getting started writing tests.
+
+If you have commit access to the repository
+===========================================
+
+Even if you have commit access to the repository, you will still need to
+go through the process above, and have someone else review and merge
+in your changes.  The rule is that all changes must be reviewed by a
+developer on the project (that did not write the code) to ensure that
+all changes go through a code review process.
+
+Having someone other than the author of the topic branch recorded as
+performing the merge is the record that they performed the code
+review.
+
+
+Additional Resources
+====================
+
+* [Getting additional help](http://puppetlabs.com/community/get-help)
+
+* [Writing tests](http://projects.puppetlabs.com/projects/puppet/wiki/Development_Writing_Tests)
+
+* [General GitHub documentation](http://help.github.com/)
+
+* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)

Gemfile

@@ -9,14 +9,3 @@ group :test do
   gem "metadata-json-lint"
   gem "rspec-puppet-facts"
 end
-
-group :development do
-  gem "travis"
-  gem "travis-lint"
-  gem "puppet-blacksmith"
-end
-
-group :system_tests do
-  gem "beaker"
-  gem "beaker-rspec"
-end

README.md

@@ -1,5 +1,9 @@
 # unattended\_upgrades
 
+[![Build Status](https://travis-ci.org/puppet-community/puppet-unattended_upgrades.svg?branch=master)](https://travis-ci.org/puppet-community/puppet-unattended_upgrades)
+[![Puppet Forge Version](http://img.shields.io/puppetforge/v/puppet/unattended_upgrades.svg)](https://forge.puppetlabs.com/puppet/unattended_upgrades)
+[![Puppet Forge Total Downloads](https://img.shields.io/puppetforge/dt/puppet/unattended_upgrades.svg)](https://forge.puppetlabs.com/puppet/unattended_upgrades)
+
 ## Overview
 
 The unattended\_upgrades module allows for the installation and configuration of automatic security (and other) updates through apt.
@@ -34,29 +38,50 @@ Using unattended\_upgrades simply consists of including the module and if needed
 
 #### unattended\_upgrades
 
-* `auto`: A hash of settings with three possible keys:
-  * `fix_interrupted_dpkg`(`true`): Try to fix package installation state
-  * `reboot`(`false`): Reboot system after package update installation
-  * `remove`(`true`): Remove unneeded dependencies after update installation
+* `age` (`{}`): A hash of settings with two possible keys:
+  * `min` (`2`): Minimum age of a cache package file. File younger than `min` will not be deleted.
+  * `max` (`0`): Maximum allowed age of a cache package file. File older than `max` will be deleted.
+
+  Any of these keys can be specified and will be merged into the defaults:
+  ```puppet
+  class { 'unattended_upgrades':
+    age => { 'max' => 10 },
+  }
+  ```
+* `auto` `({}`): A hash of settings with three possible keys:
+  * `fix_interrupted_dpkg`(`true`): Try to fix package installation state.
+  * `reboot`(`false`): Reboot system after package update installation.
+  * `remove`(`true`): Remove unneeded dependencies after update installation.
 
-  Any of these keys can be specified and will be merged into the defaults, so if you only want to   change the `reboot` behaviour the following is enough:
+  Any of these keys can be specified and will be merged into the defaults:
 
   ```puppet
   class { 'unattended_upgrades':
     auto => { 'reboot' => true },
   }
   ```
-* `blacklist`(`[]`): A list of packages to **not** automatically upgrade. This list is empty by default.
+* `backup` (`{}`): A hash with two possible keys:
+  * `archive_internal` (`0`): Backup after n-days if archive contents changed.
+  * `level` (`3`): Backup level.
+
+  Any of these keys can be specified and will be merged into the defaults:
+  ```puppet
+  class { 'unattended_upgrades':
+    backup => { 'level' => 5 },
+  }
+  ```
+* `blacklist`(`[]`): A list of packages to **not** automatically upgrade.
 * `dl_limit`(`undef`): Use a bandwidth limit for downloading, specified in kb/sec.
 * `enable` (`1`): Enable the automatic installation of updates.
 * `install_on_shutdown` (`false`): Install updates on shutdown instead of in the background.
 * `legacy_origin` (`false`): Use the legacy `Unattended-Upgrade::Allowed-Origins` setting or the modern `Unattended-Upgrade::Origins-Pattern`.
-* `mail`: A hash to configure email behaviour. The possible keys are:
+* `mail`: A hash to configure email behaviour with two possible keys:
   * `only_on_error` (`true`): Only send mail when something went wrong
   * `to` (`undef`): Email address to send email too
 
-  If the default for `to` is kept you will not receive any mail at all. You'll likely want to set this parameter:
+  If the default for `to` is kept you will not receive any mail at all. You'll likely want to set this parameter.
 
+  Any of these keys can be specified and will be merged into the defaults:
   ```puppet
   class { 'unattended_upgrades':
     mail => { 'to' => 'admin@domain.tld', },
@@ -65,7 +90,20 @@ Using unattended\_upgrades simply consists of including the module and if needed
 * `minimal_steps` (`true`): Split the upgrade process into sections to allow shutdown during upgrade.
 * `origins`: The repositories from which to automatically upgrade included packages.
 * `package_ensure` (`installed`): The ensure state for the 'unattended-upgrades' package.
-
+* `size` (`0`): Maximum size of the cache in MB.
+* `update` (`1`): Do "apt-get update" automatically every n-days.
+* `upgrade` (`1`): Run the "unattended-upgrade" security upgrade script every n-days.
+* `upgradeable_packages` (`{}`): A hash with two possible keys:
+  * `download_only` (`0`): Do "apt-get upgrade --download-only" every n-days.
+  * `debdelta` (`1`): Use debdelta-upgrade to download updates if available.
+
+  Any of these keys can be specified and will be merged into the defaults:
+  ```puppet
+  class { 'unattended_upgrades':
+    upgradeable_packages => { 'debdelta' => 1, },
+  }
+  ```
+* `verbose` (`0`): Send report mail to root.
 
 ## Limitations
 

Rakefile

@@ -4,13 +4,6 @@ require 'puppet/vendor/semantic/lib/semantic' unless Puppet.version.to_f < 3.6
 require 'puppet-lint/tasks/puppet-lint'
 require 'puppet-syntax/tasks/puppet-syntax'
 
-# These gems aren't always present, for instance
-# on Travis with --without development
-begin
-  require 'puppet_blacksmith/rake_tasks'
-rescue LoadError
-end
-
 Rake::Task[:lint].clear
 
 PuppetLint.configuration.relative = true
@@ -33,11 +26,6 @@ exclude_paths = [
 PuppetLint.configuration.ignore_paths = exclude_paths
 PuppetSyntax.exclude_paths = exclude_paths
 
-desc "Run acceptance tests"
-RSpec::Core::RakeTask.new(:acceptance) do |t|
-  t.pattern = 'spec/acceptance'
-end
-
 desc "Populate CONTRIBUTORS file"
 task :contributors do
   system("git log --format='%aN' | sort -u > CONTRIBUTORS")