//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

• 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
• 
• 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
  runTheThing
fi

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 "$@"
fi

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

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

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:

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

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