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

Fully deprecate puppet/staging

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.

Feature/support eyp
enhancement
needs-rebase
merge-conflicts

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'.

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

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

moving end statement to allow values from java_opts to be applied to …

…setenv.sh file. These values are needed if you are running confluence behind proxies and to allow the synchrony functionality.

<!--
Thank you for contributing to this project!

-->

Pull Request (PR) description

The PR fixes the passing of javaopt values in order to populate things like proxy servers or values for supporting synchrony.
If these values are not passed, things like the Market place will NOT work because the application is not aware of the proxy it should be sending traffic to.
Also for synchrony to work, you need to pass the following values:
`JAVA
OPTS="-Dsynchrony.proxy.enabled=true`

These values should not be bound to the version of confluence.

These values are currently in use in about 3 different Confluence installations of different versions of the application.

This Pull Request (PR) fixes the following issues

No specific issues (reported) but it does allow the following to work:
Atlassian market place
Synchrony

Add config automation (JDBC resource, license key) and bug fixes
merge-conflicts
enhancement
needs-tests

<!--
Thank you for contributing to this project!

-->

Pull Request (PR) description

  • Enables installing and configuring an external JDBC database resource.
  • Automates a little more startup configuration by installing the license key. See Skipping startup screens in the README. (Eventually I'd like to get the startup configuratuon fully automated but it's looking difficult).
  • Fixes a couple of small bugs caused by the fact that an empty string is no longer "false" in Puppet DSL.
  • Fixes confluenceserver fact not to get tricked into returning the Java version (e.g. 1.8.0 from `/usr/lib/jvm/jre-1.8.0-oracle.x8664/bin/java ...`. This was causing a confluence server restart on every Puppet run. ( this is a rebased version of #125 — thanks to @n2ygk )
If manage_user=false, don't depend on the User resource
bug

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.

release 4.0.0
skip-changelog

<!--
Thank you for contributing to this project!

-->

Pull Request (PR) description

<!--
Replace this comment with a description of your pull request.
-->

This Pull Request (PR) fixes the following issues

<!--
Replace this comment with the list of issues or n/a.
Use format:
Fixes #123
Fixes #124
-->