在 GitLab 上託管¶

新增並提交所有內容

$ git add -A && git commit -am "shard complete"

在 GitLab 上建立一個專案，其 name 和 description 與您的 shard.yml 中指定的相同。

新增遠端： (請務必將 <YOUR-GITLAB-USERNAME> 和 <YOUR-REPOSITORY-NAME> 替換為您的資訊)

$ git remote add origin https://gitlab.com/<YOUR-GITLAB-USERNAME>/<YOUR-REPOSITORY-NAME>.git

或者如果您使用 SSH

$ git remote add origin git@gitlab.com:<YOUR-GITLAB-USERNAME>/<YOUR-REPOSITORY-NAME>.git

推送它
```
$ git push origin master
```

管線¶

接下來，讓我們設定一個 GitLab 管線，當我們將程式碼推送至儲存庫時，它可以執行我們的測試並建置/部署文件。

您可以簡單地將以下檔案新增至儲存庫的根目錄並將其命名為 .gitlab-ci.yml

image: "crystallang/crystal:latest"

before_script:
  - shards install

cache:
  paths:
  - lib/

spec & format:
  script:
  - crystal spec
  - crystal tool format --check

pages:
  stage: deploy
  script:
  - crystal docs -o public src/palindrome-example.cr
  artifacts:
    paths:
    - public
  only:
  - master

這會建立兩個工作。第一個標題為 "spec & format" (您可以使用任何您喜歡的名稱)，並且預設進入管線的 "test" 階段。它只會在 image 指定的 Docker 容器的全新實例上執行 script 中的一系列命令。您可能需要將該容器鎖定為您正在使用的 Crystal 版本 (您的 shard.yml 中指定的版本)，但在此範例中，我們只會使用 latest 標籤。

管線的測試階段會通過 (陣列中的每個元素都回傳正常的結束代碼) 或失敗 (其中一個元素回傳錯誤)。

如果通過，則管線將移動到我們在此處定義的第二個工作，該工作我們必須命名為 "pages"。這是一個特殊的任務，專門用於將內容部署到您的 GitLab Pages 網站！此任務會在測試通過後執行，因為我們指定它應在 "deploy" 階段發生。它再次執行 script 中的命令 (這次是建置文件)，但這次我們告訴它保留路徑 public (我們將文件儲存在這裡) 作為任務的成品。

將此任務命名為 pages 並將我們的文件放入 public 目錄並將其指定為 artifact 的結果是，GitLab 會將該目錄中的網站部署到預設 URL https://<YOUR-GITLAB-USERNAME>.gitlab.io/<YOUR-REPOSITORY-NAME>。

檔案中的 before_script 和 cache 鍵用於在每個任務中執行相同的腳本 (shards install) 並用於保留已建立的檔案 (cache)。如果您的 shard 沒有任何相依性，則它們不是必要的。

如果您將上述檔案提交至您的專案並推送，您將觸發新管線的首次執行。

$ git add -A && git commit -am 'Add .gitlab-ci.yml' && git push origin master

一些徽章¶

當管線正在執行時，讓我們將一些徽章附加到專案中，以展示我們的文件以及 (希望) 我們管線的成功狀態。(您可能需要閱讀徽章文件。)

徽章只是一個帶有圖像的連結。因此，讓我們建立一個指向我們管線的連結，並從 GitLab 管線徽章 API 獲取徽章圖像。

在一般設定的徽章區段中，我們將首先新增發布徽章。連結是：https://gitlab.com/<YOUR-GITLAB-USERNAME>/<YOUR-REPOSITORY-NAME>/pipelines，而徽章圖像 URL 是：https://gitlab.com/<YOUR-GITLAB-USERNAME>/<YOUR-REPOSITORY-NAME>/badges/master/pipeline.svg。

現在，如果管線已完成，我們將有文件，並且可以使用來自 shields.io 的通用徽章連結到它們。

連結：https://<YOUR-GITLAB-USERNAME>.gitlab.io/<YOUR-REPOSITORY-NAME>
圖片：https://img.shields.io/badge/docs-available-brightgreen.svg

發布¶

發布只是您歷程記錄中帶有名稱的特殊提交 (請參閱標記)。

根據 Crystal Shards 的 README，

當從 Git 儲存庫安裝函式庫時，預期儲存庫會有版本標籤，該標籤遵循類似 semver 的格式，並以 v 作為前綴。範例：v1.2.3、v2.0.0-rc1 或 v2017.04.1

GitLab 也具有發布功能，可讓您將檔案和描述與此標籤相關聯。這樣，您就可以 (例如) 分發二進位檔。

正如您從發布文件中看到的，您可以透過 UI 建立附註標籤以及發布附註/檔案

gitlab new tags UI

或者您可以像這樣從命令列建立標籤

$ git tag -a v0.1.0 -m "Release v0.1.0"

推送它

$ git push origin master --follow-tags

然後使用 UI 新增/編輯發布附註並附加檔案。

最佳實務

使用 -a 選項來為發布建立附註標籤。
遵循語意化版本控制。

發布徽章¶

如果您願意，您也可以為發布新增一個 shields.io 徽章。GitLab 對此類內容沒有完整支援，並且在有人將 GitLab 的版本徽章新增至 shields.io 之前，我們必須直接在 URL 中編寫版本號碼。

連結：https://img.shields.io/badge/release-<VERSION>-brightgreen.svg
圖片：https://img.shields.io/badge/release-<VERSION>-brightgreen.svg

其中 <VERSION> 是以 v 作為前綴的版本號碼，如下所示：v0.1.0。

鏡像到 GitHub¶

GitHub 上的專案通常具有更高的曝光率以及與其他服務的更好整合，因此如果您也希望您的函式庫託管在那裡，您可以設定從 GitLab 到 GitHub 的「推送鏡像」。

建立一個與您的專案名稱相同的 GitHub 儲存庫。
遵循此處的指示：https://docs.gitlab.com/ee/workflow/repository_mirroring.html#setting-up-a-push-mirror-from-gitlab-to-github-core
編輯您的 GitHub 描述。您可以使用以下內容
- 描述：正向和反向相同的文字。這是
- 連結：https://gitlab.com/<YOUR-GITLAB-USERNAME>/<YOUR-REPOSITORY-NAME>/ 的鏡像

這是一個推送鏡像，這表示變更只會單向傳播。因此，請務必讓潛在的協作者知道，提取請求和問題應提交至您的 GitLab 專案。