So markieren Sie den Quellcode mit gitlabCI

Wir haben Gitlab neu in unserer Umgebung und versuchen, einige CI-CD-Pipelines mit Gitlab CI zu erstellen. Ich habe einige bessere Fortschritte beim Ausführen einiger Maven-Ziele, beim Erstellen von Pipelines und beim Archivieren von Artefakten mit meiner .gitlab-ci.yml (siehe unten) erzielt. Ich habe versucht, Give-Tags nach dem Skript zu geben, was nicht funktioniert. Jetzt versuche ich herauszufinden, wie ich Git-Tags für meinen Quellcode automatisieren kann. Ich möchte ein Tag für den Quellcode erstellen, nachdem der Master-Zweig erfolgreich erstellt wurde. Wir verwenden semantische Versionen, um unseren Quellcode zu kennzeichnen. Wenn der Master erfolgreich erstellt wurde, möchte ich ein Tag für meinen Master-Zweig erstellen.

image: maven:3.5-jdk-8-alpine

stages:
 - build
 - deploy
 - tag

maven_build:
  stage: build

  script:
   - mvn clean package
artifacts:
 paths:
 - target/*.jar

after_script:
   - ls -a
   - cd target && ls -a
   - git --version
   - git tag -a 1.0.15 -m "Version created by gitlab-ci Build"
   - git push origin 1.0.15
only:
  - master

Protokolle:

Running after script...
$ ls -a
.
..
.git
.gitignore
.gitlab-ci.yml
 LICENSE
README.md
pom.xml
src
target
$ cd target && ls -a
.
..
apidocs
classes
generated-sources
generated-test-sources
javadoc-bundle-options
maven-archiver
maven-simple-0.2-SNAPSHOT-javadoc.jar
maven-simple-0.2-SNAPSHOT-sources.jar
maven-simple-0.2-SNAPSHOT.jar
maven-status
surefire-reports
test-classes
Uploading artifacts...
target/maven-simple-0.2-SNAPSHOT-javadoc.jar: found 1 matching files 
Uploading artifacts to coordinator... ok            id=60598296 
responseStatus=201 Created token=Gu-eH1es

Job war erfolgreich

continuous-integration gitlab gitlab-ci-runner

— Pandey
quelle

Bitte fügen Sie das Protokoll hinzu

— 030

beigefügt ist die Protokolle @ 030

— Pandey

Antworten:

Ich habe versucht, das Docker-Image zu ändern und ein paar Schritte für das Git-Tag hinzugefügt. Unten ist die Antwort für mich gearbeitet,

image: maven

stages:
- build
- deploy
- tag

maven_build:
stage: build

  script:
   - mvn clean package
   artifacts:
  paths:
   - target/*.jar

  after_script:
   - ls -a
   - cd target && ls -a
   - git --version
   - git remote remove origin
   - git remote set-url origin https://"username:passwd"@gitlab.com/accountname/projectname
   - git tag -a 1.0.15 -m "Version created by gitlab-ci Build"
   - git push origin 1.0.15
  only:
    - master

— Pandey
quelle

Wenn Sie den Ursprung auf ein Gitlab-Zugriffstoken festlegen möchten, verwenden Sie ihn oauth2:${GITLAB_ACCESS_TOKEN}als Basisauthentifizierung.

— Overbryd

Auch möchte ich darauf hinweisen, dass Sie das nicht entfernen müssen origin, Sie können nur git remote add api-origin https://...das rasieren von einer Zeile. Verwenden Sie später diesen neuen Ursprung in git push api-origin 1.0.15.

— Overbryd

Und ich brauchte zwei Zeilen hinzufügen, git config user.email "${GITLAB_USER_EMAIL}"und git config user.name "${GITLAB_USER_NAME}"um es schön zu drücken.

— Overbryd

Sie können auch eine Job- / Pipeline-Ausführung überspringen, indem Sie -o ci.skipIhren Git-Push-Befehl hinzufügen

— Nicolas Pepinster

git push origin 1.0.15 sollte funktionieren und ein neues Tag sollte zu den Tags in gitlab hinzugefügt werden

https://docs.gitlab.com/ee/university/training/topics/tags.html

git checkout master

# Lightweight tag
git tag my_lightweight_tag

# Annotated tag
git tag -a v1.0 -m ‘Version 1.0’
git tag

git push origin --tags

— 030
quelle

Ich denke, der Läufer erhält nur einen Leseschlüssel, um das Repo zu klonen. Der Läufer kann das Repo IIRC

— Tensibai am

Könnte möglich sein, aber dies wird nicht im Protokoll angezeigt. @pandey Könnten Sie das vollständige Protokoll veröffentlichen?

— 030

@ 030 Git-Befehle funktionieren nicht, wenn ich sie nach dem Skript definiert habe ... muss ich sie als Job1 und Job2 erstellen?

— Pandey

Wenn git im Docker-Image installiert ist und die Authentifizierung erfolgreich ist, sollte es funktionieren.

— 030

@ 030 Dies funktioniert im Allgemeinen nicht. Der Runner hat normalerweise nur Lesezugriff auf das Repository. Der Fehler in den Protokollen sieht aus wie:$ git push origin --tags \nremote: You are not allowed to upload code.

— Ken Williams

Ich befinde mich in der gleichen Situation, in der ich nach dem Veröffentlichen eines Builds eines Artefakts das Commit mit einem Versionsnummern-Tag versehen möchte.

Eine Lösung, die ich in Betracht ziehe, besteht darin, einen Dienst (entweder innerhalb oder außerhalb von GitLab) zu erstellen, der in der Lage ist, ein Tag in ein beliebiges Repository zu verschieben, aber nichts anderes tun kann . Der Dienst selbst verfügt über Anmeldeinformationen, mit denen er in Repositorys schreiben kann, sodass nicht jedem Projekterstellungszugriff Schreibzugriff auf das Repo gewährt werden muss.

Ich mag diese Lösung, weil GitLab anscheinend keine Berechtigungsstufe bietet, mit der Tags auf vorhandene Commits übertragen werden können, ohne dass auch Commits mit neuen Inhalten übertragen werden können. Generischer Schreibzugriff ist mehr Berechtigung, als wir für diesen Anwendungsfall benötigen oder wollen. Wenn wir sie hätten, müssten wir wahrscheinlich den Bereich einschränken, indem wir für jedes Repository einen Benutzer oder ein Token erstellen, das die Berechtigung hat, nur für dieses Repository festzuschreiben. Dann müssten wir all diese Benutzer oder Token im Laufe der Zeit verwalten, was anscheinend unhandlich werden könnte.

— Ken Williams
quelle