See https://travis-ci.org/locp/gitssh/builds/160898169

The subject says it all.

Release Preparation

• A branch has been created for the release (e.g. release/42/v1.2.3)
• All branches have been merged onto the release branch.
• All spec tests are passing as expected.
• All beaker tests are passing as expected.

Release Build and Upload (master branch)

• Merge the release branch onto the master.
• Contributors of pull requests have been acknowledged.
• The change log has been updated.
• The metadata has been updated.
• A tag has been created branch (automatically done).
• The package has been built and uploaded to Puppet Forge branch (automatically done).

Post Release

• The milestone associated with the release has been closed.
• Master branch has been merged onto release/latest branch (automatically done).
• All branches associated with issues closed down in the release have been deleted.
• A message has been posted to https://gitter.im/locp/cassandra

See Travis logs for this project.

• Currently the gitssh::repo and gitssh::client defined types are not in the reference section of the README.
• Not all attributes to the gitssh class are described.
• The limitations section needs expanding.
• Add a change log.

When I try use the accounts on module on a server running Puppet 3.4.3, the module failed with this error message:

Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid parameter purge_ssh_keys at /etc/puppet/environments/production/modules/gitssh/manifests/init.pp:27
It is found that the module tries to create a user resource, passing the parameter purge_ssh_keys (manifests/init.pp:25). By commenting out that line, it could be run successfully.
The purge_ssh_keys on user type is introduced in 3.6.0 https://docs.puppetlabs.com/puppet/3.6/reference/release_notes.html#feature-purging-unmanaged-ssh-authorized-keys.

Maybe, it is better to check the version of puppet before using user type to purge the ssh keys: https://ask.puppetlabs.com/question/6640/warning-the-package-types-allow_virtual-parameter-will-be-changing-its-default-value-from-false-to-true-in-a-future-release/?answer=9525#post-id-9525