DE 

//Cloudogu EcoSystem Docs

  1. docs.cloudogu.com
  2. Entwicklerdokumentation
  3. Dogus
  4. Confluence
  5. Entwicklung
  6. Entwickeln des Confluence-Dogus
Getting Started
Benutzerhandbuch
Entwicklerdokumentation

Entwickeln des Confluence-Dogus

Es muss sichergestellt werden, dass die richtigen ldap-mapper Werte gesetzt sind, bevor confluence installiert oder gebaut wird.

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

Bauen von Confluence innerhalb einer laufenden CES-Instanz, indem in dieses Repository gewechselt wird. Dann cesapp aufrufen, um das Confluence-Dogu zu installieren/upgraden und zu starten:

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

Generierung und Hinterlegung von einer Entwickler-Lizenz

  • Gehe zu https://my.atlassian.com/products/
  • Erstelle dir mit deinen Unternehmens Google Account einen Atlassian Account
  • Log dich ein
  • gehe auf der Seite unten auf New Trial License atlassian product license dashboard

  • Wähle dann auf der Seite 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
  • Dann wirst du wieder zurück auf die https://my.atlassian.com/products/ geleitet
  • Unten in der Tabelle mit dem Titel Licenses steht dann deine neu generierte Lizenz
  • Kopiere deine Lizenz in die Zwischenablage
  • Gehe in deine lokale CES Instanz und öffne dein Confluence Dogu
  • atlassian dogu no certificate
  • Klick in dem rot umrandeten Hinweiskasten auf das blau hinterlegte Wort page
  • Füge nun deine Lizenz aus der Zwischenablage in das angezeigte Input Feld ein
  • Gehe in deine lokale CES Umgebung per cli und führe docker restart confluence aus
  • Danach sollte das Dogu einrichtbar sein

Shell-Tests

Das Verzeichnis batsTests ist der Ort, in dem die Bash-Tests-Entwicklung stattfinden sollte. Das make-Target unit-test-shell unterstützt dabei mit einer verallgemeinerten Bash-Testumgebung.

make unit-test-shell

Um testbare Shell-Skripte zu schreiben, sollten folgende Aspekte beachtet werden:

Allgemeiner Aufbau von Zu-testenden-Skripten

Es ist eher unüblich, ein script-under-test wie startup.sh ganz alleine laufen zu lassen. Effektive Unit-Tests werden höchstwahrscheinlich zu einem Albtraum, wenn keine ordentliche Skriptstruktur vorhanden ist. Da diese Skripte sich gegenseitig sourcen und Code ausführen, muss alles vorher ordentlich eingerichtet werden: globale Variablen, Mocks von jedem einzelnen Binary, das aufgerufen wird... und so weiter.

Am Ende würden die Tests eher auf einer End-to-End-Testebene als auf einer Unit-Test-Ebene angesiedelt sein.

Die gute Nachricht lautet hierbei, dass Testen einzelner Funktionen mit diesen kleinen Teilen hervorragend ermöglicht wird:

  1. Sourcing execution guards verwenden
  2. Binaries und Logikcode nur innerhalb von Funktionen ausführen
  3. Sourcen mit (dynamischen, aber festgelegten) Umgebungsvariablen
Sourcing execution guards verwenden

Das Sourcen mit von Skripten solle mit sourcing execution guards ermöglicht werden. Beispiel:

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

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

Die folgende if-Bedingung wird ausgeführt, wenn das Skript durch einen Aufruf über die Shell ausgeführt wird, aber nicht, wenn es über eine Quelle aufgerufen wird:

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

Sourcing execution guards funktionieren auch mit Parametern:

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

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

Beachten Sie die korrekte Argumentübergabe mit "$@", die auch Argumente zulässt, die Leerzeichen und dergleichen enthalten.

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
Binärdateien und Logikcode nur innerhalb von Funktionen ausführen

Umgebungsvariablen und Konstanten sind in Ordnung, aber sobald Logik außerhalb einer Funktion läuft, wird sie beim Sourcen von Skripten ausgeführt.

Source mit (dynamischen, aber fixierten) Umgebungsvariablen

Shellcheck sagt grundsätzlich, dass dies ein No-No ist. Solange der Testcontainer keine entsprechenden Skriptpfade zulässt, gibt es ohnehin kaum eine Möglichkeit, dies zu umgehen:

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

Es sollte zumindest sichergestellt werden, dass die Variablen in der Produktions- (z. B. Dockerfile) und Testumgebung richtig gesetzt wurden (im Test wird hierfür eine Umgebungsvariable eingerichtet).

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)