GitLab CI – Build beim Hinzufügen von Tags vermeiden

Lesezeit: 5 Minuten

Benutzeravatar von djna
djna

Wie verhindere ich, dass eine Gitlab-CI-Pipeline ausgelöst wird, wenn ich ein Git-Tag hinzufüge? Ich führe diesen Befehl lokal aus (im Gegensatz zu einem gitlab-ci-Job).

git tag -a "xyz"

und dann das Tag drücken; und dies löst verschiedene Pipelines aus. Ich möchte einige dieser Pipelines von der Ausführung ausschließen.

Ich probiere Variationen von Ideen aus Fragen wie dieser aus; diese Frage verwendet nur, ich möchte ausschließen, also versuche ich außer. Die Antworten dort haben zwei Varianten, eine mit Refs eins ohne.

build:  
  # ... my work here ...  
  except:
    - tags


build:  
  # ... my work here ...  
  except:
    refs:
      - tags

Beides scheint keine Wirkung zu haben; Ich füge ein Tag hinzu, der Build findet trotzdem statt.

Mein Verständnis kann hier völlig falsch sein, da es drei mögliche Bedeutungen des Wortes zu geben scheint Stichworte und beim Lesen von Dokumenten oder Beispielen bin ich mir nicht immer sicher, welche Bedeutung zutrifft:

  1. Angewendete Git-Tags mit git-Tag
  2. Gitlab CI-Tags, die verwendet werden, um zu bestimmen, welche Läufer einen Job auswählen
  3. Die Ref Identifikator eines Commits, der verwendet wird, um eine Pipeline über die REST-API auszulösen. Dies ist normalerweise ein Zweigname, könnte aber auch ein Git-Tag sein.

Ich interessiere mich für die Kontrolle, was passiert, wenn der erste Fall. Aus den bisherigen Kommentaren geht hervor, dass “außer: -tags” für meinen Fall nicht relevant ist. Gibt es also einen funktionierenden Ansatz?

  • Pro docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic dies bezieht sich auf Git-Tags. Auf dieser Seite können Sie auch Informationen zur Schiedsrichterstrategie einsehen. Beachten Sie, dass es zwei Builds für einen getaggten Commit geben wird; eine für den Commit, eine für das Tag.

    – Jonsharpe

    22. Februar 2020 um 11:20 Uhr


  • Danke @jonrsharpe. Ich stimme zu, dass das, was die Dokumente sagen, der Sinn von “Tag” ist. Gibt es eine Möglichkeit zu verhindern, dass diese Builds durch Git-Tags verursacht werden?

    – DJNA

    22. Februar 2020 um 20:58 Uhr

  • Benutzt du git tag -a TAG lokal und dann git push origin TAG? Oder der git tag Befehl ist Teil Ihres .gitlab-ci.yml Arbeitsplätze ?

    – Nicolas Pepinster

    24. Februar 2020 um 9:42 Uhr

  • @Nicolas Pepinster – lokal laufen und pushen, fügte diese Klarstellung hinzu

    – DJNA

    24. Februar 2020 um 12:06 Uhr

Benutzeravatar von Makozaki
Makozaki

Except tags ist genau das, was Sie verwenden sollten, wenn Sie das Build für Tags überspringen möchten.

Sie müssen sicher sein, Commit vs. Branches vs. Tags zu verstehen

Um zu veranschaulichen, was passiert, wenn Sie ein getaggtes Commit an Gitlab senden, habe ich Folgendes getan:

  1. Erstellt .gitlab-ci.yml mit folgendem Inhalt:
tests_always_run:
    script:
      - echo I should always execute
tests_except_tags:
    script:
      - echo I skip tagged triggers
    except:
      - tags
  1. Übertragene Änderungen, getaggter Commit und gepusht mit --follow-tags um sicherzustellen, dass das Tag auch an den Server weitergegeben wird:
git add .gitlab-ci.yml
git commit -m 'my great yml with except tags'
git tag -a "abc" -m "Test tag"
git push --follow-tags

Illustrierte Ergebnisse:
Markierte Commit-Pipeline-Ergebnisse

Wenn Sie CI für den ausgewählten Commit überspringen möchten, können Sie dies verwenden git push -o ci.skipinspiriert von Dieser Artikel

Benutzeravatar von diegosasw
diegossw

Es sieht so aus, als ob GitLab die Verwendung empfiehlt rules anstatt except gem die Dokumentation

only und except werden nicht aktiv entwickelt. rules ist das bevorzugte Schlüsselwort, um zu steuern, wann Jobs zu Pipelines hinzugefügt werden sollen.

So wäre es

your_job:
  stage: your_stage
  script:
    - echo "Hello"
  rules:
    - if: $CI_COMMIT_TAG
      when: never 
    - when: always

  • @diegosaw, danke. Wir befinden uns immer noch auf Version 12, wo in den Dokumenten steht: „Hinweis: Die Regelsyntax ist jetzt die bevorzugte Methode zum Festlegen von Jobrichtlinien. Nur und außer sind Kandidaten für die Ablehnung und werden möglicherweise in Zukunft entfernt.“ Ich freue mich, dass Sie mich darauf aufmerksam gemacht haben.

    – DJNA

    26. Juni 2021 um 5:47 Uhr


Benutzeravatar von LeGEC
LeGEC

(Hinweis: Dies ist eher ein formatierter Kommentar als eine Antwort)

So debuggen Sie die Bedingungen, die Ihre Pipeline auslösen:

gitlabs doc erwähnt mehrere Variablen, die beim Ausführen eines CI-Jobs gesetzt werden, darunter:

  • CI_COMMIT_REF_NAME : Der Zweig- oder Tag-Name, für den das Projekt erstellt wird
  • CI_COMMIT_BRANCH : Der Commit-Zweigname. Nur vorhanden, wenn Zweige gebaut werden.
  • CI_COMMIT_TAG : Der Commit-Tag-Name. Nur beim Erstellen von Tags vorhanden.

Lassen Sie Ihren Build-Job einige dieser Variablen ausgeben (zB: echo "triggered by ref : " $CI_COMMIT_REF_NAME), um anzuzeigen, was Ihren Auftrag ausgelöst hat.

Ich war in der gleichen Situation, meine Lösung war folgende:

Vor::
VOR

Nach:
NACH

Beide Stufen sind in meiner .gitlab-ci.yml-Datei konfiguriert, mit unterschiedlichem Namen Die “Dev-UnitTests“, es wird nur ausgeführt, wenn sich jemand in das Repository einschreibt, keine Auswirkung auf Stichworte y der Zweig “Prüfung

Dev-UnitTests:
  stage: pruebas 
  script:
    - mvn $MAVEN_CLI_OPTS test
  artifacts:
    when: always
    reports:
      junit: 
        - target/surefire-reports/*Test.xml
        - target/failsafe-reports/*Test.xml
      cobertura: target/site/jacoco/jacoco.xml
  tags:
    - shell 
  except: 
    - test 
    - tags   

Die Unit-Tests nur ausgeführt, wenn eine Zusammenführung auf dem Zweig durchgeführt wird Prüfung

Unit Tests:
  stage: pruebas 
  script:
    - mvn $MAVEN_CLI_OPTS test
  artifacts:
    when: always
    reports:
      junit: 
        - target/surefire-reports/*Test.xml
        - target/failsafe-reports/*Test.xml
      cobertura: target/site/jacoco/jacoco.xml
  tags:
    - shell 
  only: 
    - test

Dass beim Erstellen eines Tags keine Pipeline erneut ausgeführt wurde, hoffe, es hilft Ihnen.

Der Schlüssel ist:

...
 except:  
    - tags   
...

1439980cookie-checkGitLab CI – Build beim Hinzufügen von Tags vermeiden

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy