web-dev-qa-db-de.com

Wie werden Releases/Binaries in GitLab gespeichert?

Ich baue einen Workflow mit Gitlab , Jenkins und - wahrscheinlich - Nexus (ich brauche einen Artefaktspeicher). Ich möchte, dass GitLab release/binaries - speichert - ist das auf bequeme Weise möglich?

Ich möchte keinen anderen Dienst haben, von dem eine Version (und Dokumentation) heruntergeladen werden könnte, aber irgendwie in den Repository-Manager integriert werden soll, genau wie Releases in z. GitHub. Irgendwelche Hinweise?

38
Kasia Gauza

Update November 2015: GitLab 8.2 unterstützt jetzt Releases .

Mit seiner API können Sie jetzt eine mit einem Tag verknüpfte Relase erstellen und aktualisieren .
Im Moment ist es nur die Möglichkeit, Versionshinweise (Markdown-Text und Anhänge) zu git-Tags (aka Releases) hinzuzufügen.


Ursprüngliche Antwort März 2015

Dies ist in Arbeit und wird in Vorschläge 4156755 vorgeschlagen. _:

Wir akzeptieren Zusammenführungsanträge für den minimalen Vorschlag von Ciro:

  1. Erlauben Sie für jedes Repository-Tag unter https://github.com/cirosantilli/test/releases/tag/3.0 das Hochladen und Herunterladen einer Liste von Dateien.
  2. Der Upload und Download kann direkt aus der Tag-Listenansicht erfolgen.
  3. Wenn ein Tag entfernt wird, werden die Uploads zerstört . (Die in den letzten Kommentaren erwähnte Bearbeitung der Tag-Nachrichten wird nicht akzeptiert.)

Die Kommentare zu diesem Vorschlag beinhalten:

Was es interessanter macht, ist der nächste Schritt.
Ich möchte wirklich eine Möglichkeit, dass öffentliche Artefakte von "Releases" heruntergeladen werden können, ohne auf Quellcode zugreifen zu können (d. H. Quellen nur für das Projektteam privat machen, ausgenommen Wiki, "Releases", Issue-Tracker).

Diese zusätzliche Funktion sieht jedoch allgemeiner aus und ich hat eine separate Funktionsanforderung dafür gestellt .

Trotzdem wiederhole ich meinen Punkt hier:
Während die vereinfachte Version von "Releases" immer noch schön ist, können viele Benutzer externe Dateiserver einrichten und URLs in der Release-/Tag-Beschreibung auf diesen Server außerhalb von GitLab verweisen.
Mit anderen Worten, "Releases" können jetzt ohne ein zukünftiges Integrationsbild nicht attraktiv aussehen.

34
VonC

Diese Antwort wird im Grunde die gleiche sein wie die von VonC, die nur für weniger erfahrene CI-Benutzer schrittweise beschrieben wird.

Angenommen, Sie haben ein wirklich cooles Commit 30728cab und möchten diese Version Ihres Codes zu einer neuen Version machen ...

1) Erstellen Sie ein Tag für Ihr Commit

git tag -a MY_TAG_NAME 30728cab

Nach diesem Befehl werden Sie aufgefordert, eine Beschreibung einzugeben, genau wie beim Festschreiben neuer Änderungen an Ihrem Code.

2) Übertragen Sie das Tag in Ihr Remote-Repository

Tags werden dort NICHT automatisch mit Ihren Commits gepusht! Sie müssen sie manuell auf Ihre Fernbedienung pushen.

git Push REMOTE_REPO_NAME REMOTE_BRANCH_NAME MY_TAG_NAME

3) Laden Sie eine Datei hoch

Jetzt können Sie entweder a) eine Datei in das GitLab-Repository hochladen, b) sie an eine andere Stelle hochladen und den Link in beiden Fällen speichern.

WARNUNG: Dateien, die in das GitLab-Repository hochgeladen wurden, können dann nicht einfach gelöscht werden und ihr Link wird später nicht angezeigt!

Obwohl ich aus dem oben genannten Grund NICHT empfehle, Binärdateien in das Repository hochzuladen, haben Sie danach gefragt.

curl --request POST --header "Private-Token: YOUR_PRIVATE_TOKEN" --form "[email protected]/PATH/TO/THE/FILE/file.txt" "https://MY_GITLAB_HOSTING.COM/api/v4/projects/MY_PROJECT_ID/uploads"

Das private Token kann in Benutzereinstellungen -> Zugriffstoken erstellt werden.

Wenn Sie die Datei wirklich löschen wollten , können Sie das Projekt exportieren den Ordner updates aus Ihrem heruntergeladenen Archiv löschen Sie das frühere Remote-Repository und erstellen Sie ein neues durch Importieren Ihr heruntergeladenes und geändertes Archiv.

4) Erstellen Sie ein Release

Jetzt können wir endlich alles mit Release zusammenbinden.

curl --request POST --header 'Content-Type: application/json' --header "Private-Token: YOUR_PRIVATE_TOKEN" --data '{"name": "MY_RELEASE_NAME", "tag_name": "MY_TAG_NAME", "description": "Release with the binary LINK_TO_YOUR_BINARY"}' "https://MY_GITLAB_HOSTING.COM/api/v4/projects/MY_PROJECT_ID/releases"

Sie sehen, dass Release von Natur aus an ein bestimmtes Tag gebunden ist, das anschließend an ein bestimmtes Commit gebunden wird. Die Verbindung mit Binärdateien erfolgt dann einfach durch die Bereitstellung von Links zu diesen Dateien.

Der lustige Punkt ist, dass Ihr descriptionMarkdown unterstützt, aber es ist wirklich schwierig, ein größeres *.md - Dokument in solch einem umständlichen Einzeiler zu schreiben. Deshalb habe ich ein kurzes Bash-Skript geschrieben, mit dem wir die Markdown-Datei beiseite schreiben und dann lesen und automatisch senden können:

#!/bin/bash

RELEASE_NAME="$1"
TAG_NAME="$2"
PROJECT_ID="$3"
DESCRIPTION_FILE_PATH="$4"
PRIVATE_TOKEN="$5"

if [ "$5" == "" ]; then
    echo "Missing parameter! Parameters are RELEASE_NAME, TAG_NAME, PROJECT_ID, DESCRIPTION_FILE_PATH and PRIVATE_TOKEN.";
    exit 1;
fi

DESCRIPTION=''

# Load data from file
while read -r line; do
    DESCRIPTION="${DESCRIPTION}${line}\n";
done < "${DESCRIPTION_FILE_PATH}"

curl --request POST\
     --header 'Content-Type: application/json'\
     --header "Private-Token: ${PRIVATE_TOKEN}"\
     --data-binary "{\"name\": \"${RELEASE_NAME}\", \"tag_name\": \"${TAG_NAME}\", \"description\": \"${DESCRIPTION}\"}"\
     "https://MY_GITLAB_HOSTING.com/api/v4/projects/${PROJECT_ID}/releases" 

echo

so kann man es einfach so benutzen

./upload_release.sh MY_RELEASE_NAME MY_TAG_NAME MY_PROJECT_ID MY_MARKDOWN_FILE_PATH MY_PRIVATE_TOKEN

Und jetzt ist es soweit! Du hast dein erstes vollständiges Release!

Bis Sie feststellen, dass Sie im Header Ihrer Release-Beschreibung einen furchtbaren Tippfehler gemacht haben ...

5) Löschen Sie eine Version (falls erforderlich)

Hier hast du Glück! Im Gegensatz zu hochgeladenen Binaries können Sie Ihre Releases auch mit der REST API löschen!

curl --request DELETE --header "Private-Token: MY_PRIVATE_TOKEN" "https://MY_GITLAB_HOSTING.com/api/v4/projects/MY_PROJECT_ID/releases/MY_TAG_NAME"

Und da es immer noch ziemlich nervig ist, dies mehrmals hintereinander zu tippen, habe ich ein anderes Bash-Skript erstellt:

#!/bin/bash

PROJECT_ID=$1
TAG_NAME=$2
PRIVATE_TOKEN=$3

if [ "$3" == "" ]; then
    echo "Missing parameter! Parameters are PROJECT_ID, TAG_NAME and PRIVATE_TOKEN.";
    exit 1;
fi

curl --request DELETE --header "Private-Token: ${PRIVATE_TOKEN}" "https://MY_GITLAB_HOSTING.com/api/v4/projects/${PROJECT_ID}/releases/${TAG_NAME}"

echo

welches verwendet werden kann wie ./delete_release.sh MY_PROJECT_ID MY_TAG_NAME MY_PRIVATE_TOKEN.

13
Eenoku

Gitlab (Server) selbst ist für Git-Repositories. Du sollst keine Binaries in git speichern. Nexus würde hier den Weg gehen. Sie könnten in Ihrer Repository-Beschreibung oder Readme-Datei einen Link zu Nexus hinzufügen (wie Sie auch dort auf Ihren Jenkins-Build verweisen können).

Sie können einen Blick auf GitLab Continuous Integration werfen, das in Gitlab integriert ist. Das scheint eher so etwas wie Jenkins zu sein. Ich weiß nicht, ob es einen Datenspeicher wie Nexus gibt.

1
volker

Wir verwenden scp, um in GitlabCI generierte Dateien wie Binärdateien oder Berichte zu kopieren.

# capture test exit code
set +e
bash build/ci/test.sh; TESTS_EXIT_CODE=$?
set -e

# copy reports
sshpass -p "$SFTP_PASS" ssh -o StrictHostKeyChecking=no [email protected] "mkdir -p ${CI_REPORTS_PATH}"
sshpass -p "$SFTP_PASS" scp -r ${CI_APP_VOLUME}/tests/_output/* [email protected]:${CI_REPORTS_PATH}

# return test exit-code
exit ${TESTS_EXIT_CODE}
1
schmunk