Dies ist eine Aufzeichnung von Mercurial-Benutzern, die anfangen, Git zu verwenden und von GitHub betreut werden.

[x] Repository-Konvertierung
[x] GitHub
Um CI ← Jetzt hier
(Gibt es noch etwas ...?)

Ich mache Werkzeuge ausschließlich mit Go.

In diesem Artikel wird als Methode zur automatischen Freigabe mit dem Mechanismus von CI Folgendes beschrieben: Verwenden Sie GoReleaser für GitHub-Aktionen, um die Binärdatei festzulegen, die für jedes Tag in GitHub-Versionen hochgeladen werden soll.

master→main

Wenn Sie dies nicht separat tun, hat dies keine Auswirkungen auf die nachfolgende Arbeit und den Erfolg von GitHub-Aktionen.

Benennen Sie den Standardzweig von Git (GitHub) um [https://qiita.com/e_chan1007/items/ad3e849b7e04fcf42fad], ändern Sie jedoch den Standardzweignamen in main.

Im obigen Artikel habe ich eingerichtet, dass Zweige lokal gewechselt und dann gedrückt werden, um den Standardzweig auf GitHub zu ändern. Ich vergesse nicht, die Filialen vor Ort zu wechseln, daher denke ich, dass dies ein guter Weg ist, dies zu tun. __ In jedem Fall scheint es, dass der Standardzweig von GitHub nur auf der GitHub-Site ausgeführt werden kann. __ __

Wenn Sie sagen "Sie müssen vorerst nur auf GitHub ändern", wird dies auf der GitHub-Site abgeschlossen. (Verfahren unten) Da wir die Datei danach in Verbindung mit GitHub-Aktionen ändern werden, müssen Sie sich keine Sorgen mehr machen, sie auf der Site fertigzustellen.

Erstellen Sie eine Zweigstelle auf GitHub

↓

Geben Sie "main" ein

Zu diesem Zeitpunkt hat sich der Standardzweig noch nicht geändert. (↓ "Standard" ist an den Master angehängt)

Standardzweig ändern

Zeigen Sie eine Liste der Zweige an

↓

Klicken Sie auf "Standardzweig ändern".

↓

Wechseln Sie zu main und klicken Sie daneben auf die Schaltfläche "Update"

↓

Gehen Sie zurück zur Seite mit der Verzweigungsliste und klicken Sie auf das Papierkorbsymbol unter Master

↓

Wird so sein

Lokal wechseln

git pull
git switch main

Damit ist das Zweigwechselverfahren abgeschlossen.

GitHub Actions

Erstellen und platzieren Sie zwei Dateien

Erstellen Sie die folgenden zwei Dateien.

.github/workflows/xxx.yml
goreleaser.yml

Speicherort der zu erstellenden Datei

Siehe unten für den Inhalt der Datei.

.github/workflows/release.yml

Es scheint, dass der Dateiname nicht separat release.yml sein muss.


name: release
on:
  push:
    tags:
    - "v[0-9]+.[0-9]+.[0-9]+"
jobs:
  goreleaser:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Setup Go
        uses: actions/setup-go@v2
      - name: Run GoReleaser
        uses: goreleaser/goreleaser-action@v2
        with:
          version: latest
          args: release --rm-dist
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Es wird ausschließlich mit using: xxx geschrieben, aber Sie können Befehle wie in der Shell mit run: xxx verwenden.

GoReleaser erlaubt keine schmutzigen Bedingungen. Wenn Sie also das Tool mit go get herunterladen und verwenden, müssen Sie möglicherweise run: go mod tidy ausführen, bevor Sie GoReleaser ausführen.

Die Aktion wird zum Zeitpunkt von "git push --tags" ausgeführt. Es scheint, dass GoReleaser nicht mehrmals für dasselbe Tag veröffentlicht werden kann. Wenn ich die Beschreibung am Anfang auf "on: push: branch: --main" (ohne Zeilenumbrüche) setze, wurde die Aktion aus irgendeinem Grund überhaupt nicht ausgeführt.

Goreleaser.yml hinzugefügt

project_name: vvin
env:
  - GO111MODULE=on
before:
  hooks:
    - go mod tidy
builds:
  - binary: vvin
    flags:
      - -trimpath
    ldflags:
      - -s -w
      - -X main.Version={{.Version}}
      - -X main.Revision={{.ShortCommit}}
    env:
      - CGO_ENABLED=0
    goos:
      - windows
      - darwin
      - linux
    goarch:
      - amd64
      - 386
    hooks:
      post: upx --lzma '{{ .Path }}'
archives:
  - name_template: '{{ .ProjectName }}_v{{ .Version }}_{{ .Os }}_{{ .Arch }}{{ if .Arm }}v{{ .Arm }}{{ end }}'
    replacements:
      darwin: darwin
      linux: linux
      windows: windows
      386: 386
      amd64: amd64
    format_overrides:
      - goos: windows
        format: zip
release:
  prerelease: auto

: heart_eyes: Unter den Release-Tools bin ich dankbar, dass ich -trimpath hinzufügen und upx ausführen kann.

Wenn das Git-Tag "v1.2.3" ist, scheint "{{.Version}}" 1.2.3 "zu sein.

Sie können auch "goreleaser init" ausführen, um eine Vorlage für ".goreleaser.yml" zu erstellen. Obwohl es sich von den oben genannten Inhalten unterscheidet.

Wenn Sie Dateien zum Archiv hinzufügen möchten

Wenn Sie verschiedene Dinge in die Version von GitHub Releases aufnehmen möchten, fügen Sie sie zu archives: hinzu.

archives:
  - name_template: '{{ .ProjectName }}_v{{ .Version }}_{{ .Os }}_{{ .Arch }}{{ if .Arm }}v{{ .Arm }}{{ end }}'
    replacements:

      :

    files:
      - LICENSE*
      - README*
      - sample.bat

Die Standardeinstellung für "files:" scheint "LICENSE *", "README *" zu sein. Wenn Sie jedoch files: wie oben schreiben, scheint diese Einstellung zu verschwinden, sodass Sie auch den Standardwert angeben müssen.

push

Nachdem Sie die obigen Änderungen vorgenommen haben, fügen Sie "git push" hinzu, fügen Sie ein neues Tag hinzu und "git push --tags".

Tags werden im Format v {Major}. {Minor}. {Patch} zugewiesen. Wie in der oben angegebenen Version release.yml angegeben, wird es nur ausgeführt, wenn ein Tag dieses Formats übertragen wird.

Ergebnis

(Es gibt nur wenige Dateien, aber ich habe die obige .goreleaser.yml in die Binärdatei nur für Windows geändert.)

Im Vergleich zu CircleCI

Als ich Mercurial auf BitBucket verwendete, verwendete ich CircleCI. Da ich zu GitHub gewechselt bin, wollte ich GitHub-Aktionen erleben, also habe ich gewechselt.

Ich verwende CircleCI in meinem kostenlosen Plan, aber GitHub-Aktionen dauern jetzt ungefähr 30 Sekunden anstatt 10 Sekunden.

Ich denke auch, dass dies ein Teil ist, der mit den GoReleaser-Spezifikationen zusammenhängt, aber es scheint, dass es nicht erfolgreich auf Releases aktualisiert werden kann, ohne das Tag zu ändern. Es ist etwas stressig, wenn Sie das Tag nicht ändern möchten, weil sich die Funktion nicht geändert hat ...

[GO] Bitbucket → GitHub-Migration Teil 3 ~ CI-Umgebung ~