//Cloudogu EcoSystem Docs

Developing the Confluence dogu

Make sure that proper ldap-mapper values are set before confluence is going to be installed or built.

etcdctl set /config/ldap-mapper/backend/type embedded
etcdctl set /config/ldap-mapper/backend/host ldap
etcdctl set /config/ldap-mapper/backend/port 389

Build confluence inside a running CES instance by changing into this repository. Call then cesapp to install/upgrade and start the confluence dogu:

cd /your/workspace/confluence
cesapp build .
cesapp start confluence

Generation and deposit of a developer license

  • Go to https://my.atlassian.com/products/
  • Create an Atlassian account with your company Google Account
  • Log in
  • go to the bottom of the page and click on New Trial License atlassian product license dashboard
  • Then select on the page https://my.atlassian.com/license/evaluation

    • Product: Confluence
    • License type: Confluence (Data Center)
    • Organization: Cloudogu GmbH
    • Your instance is: up and running
    • Server ID: BLDL-90OD-7WFG-F9D1
    • Generate License
  • Then you will be redirected back to https://my.atlassian.com/products/
  • At the bottom of the table titled Licenses you will find your newly generated license
  • Copy your license to the clipboard
  • Go to your local CES instance and open your Confluence Dogu
  • atlassian dogu no certificate
  • Click on the bluish highlighted word page in the red bordered box
  • Now paste your license from the clipboard into the displayed input field
  • Go to your local CES environment via cli and execute docker restart confluence.
  • After that you should be able to set up the dogu

Shell testing

You can create and amend bash tests in the unitTests directory. The make target unit-test-shell will support you with a generalized bash test environment.

make unit-test-shell

In order to write testable shell scripts these aspects should be respected:

General structure of scripts-under-test

It is rather uncommon to run a scripts-under-test like startup.sh all on its own. Effective unit testing will most probably turn into a nightmare if no proper script structure is put in place. Because these scripts source each other AND execute code everything must be set up beforehand: global variables, mocks of every single binary being called... and so on. In the end, the tests would reside on an end-to-end test level rather than a unit test level.

The good news is that testing single functions is possible with these little parts:

  1. Use sourcing execution guards
  2. Run binaries and logic code only inside functions
  3. Source with (dynamic yet fixed-up) environment variables
Use sourcing execution guards

Make sourcing possible with sourcing execution guards. like this:

# yourscript.sh
function runTheThing() {
    echo "hello world"

if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then

The if-condition below will be executed if the script is executed by calling via the shell but not when sourced:

$ ./yourscript.sh
hello world
$ source yourscript.sh
$ runTheThing
hello world

Execution guards work also with parameters:

# yourscript.sh
function runTheThing() {
    echo "${1} ${2}"

if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
  runTheThingWithParameters "$@"

Note the proper argument passing with "$@" which allows for arguments that contain whitespace and such.

# shellcheck disable=SC1090
source "${STARTUP_DIR}"/util.sh || sourcingExitCode=$?
if [[ ${sourcingExitCode} -ne 0 ]]; then
  echo "ERROR: An error occurred while sourcing /util.sh."
Run binaries and logic code only inside functions

Environment variables and constants are okay, but once logic runs outside a function it will be executed during script sourcing.

Source with (dynamic yet fixed-up) environment variables

Shellcheck basically says this is a no-no. Anyhow unless the test container allows for appropriate script paths there is hardly a way around it:

# shellcheck disable=SC1090
source "${STARTUP_DIR}"/util.sh || sourcingExitCode=$?
if [[ ${sourcingExitCode} -ne 0 ]]; then
  echo "ERROR: An error occurred while sourcing /util.sh."

At least make sure that the variables are properly set into the production (f. i. Dockerfile)and test environment (set-up an env var in your test).