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
: ConfluenceLicense type
: Confluence (Data Center)Organization
: Cloudogu GmbHYour instance is
: up and runningServer ID
: BLDL-90OD-7WFG-F9D1Generate 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:
- Use sourcing execution guards
- Run binaries and logic code only inside functions
- 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).