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
-
Wähle dann auf der Seite 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
- 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
-
- 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 unitTests
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 source
n 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:
- Sourcing execution guards verwenden
- Binaries und Logikcode nur innerhalb von Funktionen ausführen
- 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)