GitHub puppet-confluence
18
18
21
A puppet module to install confluence

Metadata Valid
No translation
Correct Puppet Version Range
Supported Puppet version range is %{PUPPET_VERSION_RANGE}
With Puppet Version Range
Puppet version range is present in requirements in metadata.json
With Operatingsystem Support
No translation
Supports Only Current Centos
No translation
Supports Latest Centos
No translation
Supports Only Current Ubuntu
No translation
Supports Latest Ubuntu
No translation
Supports Only Current Debian
No translation
Supports Latest Debian
No translation
In Modulesync Repo
No translation
In Plumbing
Is in plumbing
Has Secrets
Has a .sync.yml file
Synced
Has a .msync.yml file
Latest Modulesync
No translation
Has Modulesync
Is present in voxpupuli/modulesync_config/managed_modules.yml
Released
Is in modulesync_config and in forge releases.
Reference Dot Md
The repository has a REFERENCE.md. It needs to be generated / puppet-strings documentation is missing.

Open Pull Requests

added support for Amazon linux 2018 (using sysv not systemd)
merge-conflicts
needs-rebase
needs-work

Pull Request (PR) description

Adds support for Amazon linux 2018. The default behavior attempts to use systemd and fails.

This Pull Request (PR) fixes the following issues

There is no issue associated with this PR

Fully deprecate puppet/staging
needs-rebase
merge-conflicts

This PR completely removes the puppet/staging module dependancy

  • Remove the ability to use it via $deploy_module
  • Remove dependancy from metadata.json
  • Updated README and CHANGELOG

This will break things for anyone using deploy_module => 'staging', so a major version bump is proposed.

If manage_user=false, don't depend on the User resource
bug
needs-rebase
merge-conflicts

Pull Request (PR) description

If manage_user=false, don't depend on the existence of a User[] resource.

We are forced to rely on a user supplied by LDAP, which is not created (and cannot be edited by) a User[] resource.

The only negative I can think of to this PR is if somebody is defining a User resource elsewhere, setting manage_user to false, and then expecting resources within this module to be subscribed to it. It seems unlikely but possible.

For reference, we are following the same methodology with BitBucket, where it behaves as expected if manage_usr_grp is set to false.

Feature/support eyp
enhancement
merge-conflicts
needs-rebase

Pull Request (PR) description

This PR adds a new parameter called 'systemd_module' which allows a user to choose which systemd module to use to manage the Confluence service. It defaults to 'camptocamp' and also supports 'eyp'.

modulesync 4.0.0
modulesync

modulesync 4.0.0

modulesync 3.1.0
modulesync

modulesync 3.1.0