Wie Sie Ihr Repository aus einer Gitlab-Pipeline aktualisieren

Waren Sie schon einmal in der Situation, dass Sie Dateien in einem Repository aus Ihrer Pipeline heraus aktualisieren wollten? Das habe ich, und zwar ein paar Mal!

Dokumentation aktualisieren

In einem meiner früheren Blogs habe ich darüber geschrieben, wie Sie Diagramme als Code verwalten können. Nun, als Mensch vergisst man manchmal, Bilder zu aktualisieren, die Sie vielleicht in Ihrer README verwenden. Die Aktualisierung dieser Bilder während des CI-Prozesses wird Ihnen dabei helfen.

Baucontainer

Es gibt verschiedene Szenarien, in denen Sie dies tun möchten. Sie bauen zum Beispiel einen Container und möchten diesen in Ihrer Umgebung bereitstellen. Ich verwende häufig den Ansatz, den Container als aktuell zu kennzeichnen und eine Neuverteilung auszulösen.

Das Problem bei diesem Ansatz ist, dass Sie möglicherweise bereits einen zwischengespeicherten Container auf Ihrem Host haben. Mit dem Ergebnis, dass Sie die vorherige Version einsetzen. Und was ist, wenn Sie, aus welchem Grund auch immer, auf die vorherige Version zurückgehen müssen? Oder wenn Sie wissen möchten, welche Version zu einem bestimmten Zeitpunkt lief?

Sie können dieses Problem lösen, indem Sie auf den aktuellen Digest des Containers verweisen. Dadurch wird immer die angegebene Version bereitgestellt, oder es wird ein Rollback durchgeführt. Und wenn Sie einen manuellen Rollback durchführen müssen? Dann können Sie den Digest auf den vorherigen Wert zurücksetzen. Und als Bonus können Sie Ihren Git-Verlauf als Audit-Protokoll verwenden.

Wenn Sie wissen möchten, wie Sie Ihre CloudFormation-Vorlagen aktualisieren können. Wir haben ein Tool namens cru entwickelt, das Ihnen dabei helfen kann!

Erstellen eines Commits von CI auf GitLab.

Damit dies funktioniert, müssen Sie einige Konfigurationen vornehmen. Sie müssen ein SSH-Schlüsselpaar erzeugen:

ssh-keygen -t ed25519 -C "<comment>"

Sie können den öffentlichen Schlüssel in Ihrem Repository unter Einstellungen und dann Repository hinzufügen. Im Abschnitt Schlüssel bereitstellen können Sie Ihren öffentlichen Schlüssel hinzufügen. Vergewissern Sie sich, dass Sie Schreibrechte für diesen Schlüssel erteilen.

Unter Einstellungen und dann CI/CD finden Sie den Abschnitt Variablen. Hier müssen Sie eine Dateityp-Variable mit dem Namen DEPLOY_SSH_KEY erstellen, als Wert verwenden Sie den privaten Schlüssel.

Der private Schlüssel wird auf dem Runner als Datei verfügbar sein. Der Speicherort der Datei ist über die Umgebungsvariable DEPLOY_SSH_KEY verfügbar.

Bevor Sie sich festlegen können, müssen Sie zunächst:

• Konfigurieren Sie den SSH-Client.
• Konfigurieren Sie den Git-Benutzer.
• Konfigurieren Sie die Git-Remote.
• Commit und Push der Änderungen, falls es welche gibt

Um es ein wenig einfacher zu machen, habe ich all diese Aktionen in das folgende Bash-Skript eingefügt:

#!/usr/bin/env bash

failed () { echo "Failed:" >&2 "$@" && exit 1; }

GIT_USER=$1
GIT_EMAIL=$2
GIT_COMMIT_MESSAGE=$3

[[ -z "${CI_SERVER_HOST}" ]] && failed "The environment variable CI_SERVER_HOST is not set, this is needed to configure git and ssh to be enable to write back to the repository."
[[ -z "${CI_COMMIT_REF_NAME}" ]] && failed "The environment variable CI_COMMIT_REF_NAME is not set, this is needed to configure git and ssh to be enable to write back to the repository."
[[ -z "${DEPLOY_SSH_KEY}" ]] && failed "The environment variable DEPLOY_SSH_KEY is not set, this is needed to configure git to be enable to write back to the repository."
[[ ! -f "${DEPLOY_SSH_KEY}" ]] && failed "The ${DEPLOY_SSH_KEY} is not available on the filesystem, this is needed to configure git to be enable to write back to the repository."
[[ -z "${GIT_USER}" ]] && failed "Please use: ./commit-changes.sh '<USER NAME>' '<EMAIL>' '<COMMIT MESSAGE>'"
[[ -z "${GIT_EMAIL}" ]] && failed "Please use: ./commit-changes.sh '<USER NAME>' '<EMAIL>' '<COMMIT MESSAGE>'"
[[ -z "${GIT_COMMIT_MESSAGE}" ]] && failed "Please use: ./commit-changes.sh '<USER NAME>' '<EMAIL>' '<COMMIT MESSAGE>'"

run_function () {
    GREEN='33[1;32m'
    RED='33[1;31m'
    NC='33[0m' # No Color

    echo -n "Running $1 "
    ERROR=$( $1 2>&1 )
    [ $? -eq 0 ] && echo -e "[ ${GREEN}DONE${NC} ]" ||  (echo -e "[ ${RED}FAILED${NC} ]" && failed "Unexpected error occurred: ${ERROR}")
}

configure_git_client() {
    git config user.name "${GIT_USER}"
    git config user.email "${GIT_EMAIL}"
}

cleanup_ssh_client() {
    rm -rf ~/.ssh
    mkdir ~/.ssh
}

configure_ssh_client() {
    local KNOWN_HOSTS=~/.ssh/known_hosts
    local CONFIG_FILE=~/.ssh/config

    ssh-keyscan $CI_SERVER_HOST > $KNOWN_HOSTS
    chmod 0644 $KNOWN_HOSTS
    echo "Host $CI_SERVER_HOST" > $CONFIG_FILE
    echo "    IdentityFile $DEPLOY_SSH_KEY" >> $CONFIG_FILE
    chmod 0600 "$DEPLOY_SSH_KEY"
}

configure_git_remote () {
    git remote remove update 2>/dev/null || echo "update remote was not present yet"
    git remote add update git@$CI_SERVER_HOST:$CI_PROJECT_PATH.git
}

commit_and_push_changes () {
    git fetch update
    git branch -D $CI_COMMIT_REF_NAME || echo "branch does not exist"
    git switch -c $CI_COMMIT_REF_NAME update/$CI_COMMIT_REF_NAME
    git diff --quiet && git diff --staged --quiet || (git commit -am "${GIT_COMMIT_MESSAGE}" && git push --set-upstream update $CI_COMMIT_REF_NAME)
}

run_function "configure_git_client"
run_function "cleanup_ssh_client"
run_function "configure_ssh_client"
run_function "configure_git_remote"
run_function "commit_and_push_changes"

Sie können es wie folgt verwenden:

./commit-changes.sh "GitLag CI" "noreply@acme.com" "chore: my commit message"

Fazit

Das Commit aus einer GitLab-Pipeline funktioniert genauso wie von Ihrem eigenen Rechner aus. Der Unterschied besteht darin, dass Sie Ihre Runner jedes Mal konfigurieren und den entsprechenden Zugriff gewähren müssen.

Foto von Jill Burrow