릴리즈 필드

릴리즈를 생성하거나 편집할 때 사용할 수 있는 다음과 같은 필드가 있습니다.

제목

릴리즈 제목은 릴리즈를 생성하거나 편집할 때 릴리스 제목 필드를 사용하여 사용자 정의할 수 있습니다. 제목을 제공하지 않으면 릴리즈의 태그 이름이 대신 사용됩니다.

태그 이름

릴리즈 태그 이름에는 릴리즈 버전이 포함되어야 합니다. GitLab은 릴리즈에 의미 있는 버전 관리를 사용하며, 사용자도 이와 같이 사용하는 것을 권장합니다. (주요).(마이너).(패치)를 사용하며, GitLab 버전 관리 정책에 자세히 나와 있습니다.

예를 들어, GitLab 버전 10.5.7의 경우:

  • 10은 주요 버전을 나타냅니다. 주요 릴리스는 10.0.0이지만 종종 10.0으로도 언급됩니다.
  • 5는 마이너 버전을 나타냅니다. 마이너 릴리스는 10.5.0이지만 종종 10.5로도 언급됩니다.
  • 7은 패치 번호를 나타냅니다.

버전 번호의 어떤 부분이든 여러 자릿수일 수 있습니다. 예를 들어, 13.10.11입니다.

릴리즈 노트 설명

모든 릴리즈에는 설명이 있습니다. 사용자 정의 텍스트를 추가할 수 있지만, 릴리즈 내용을 설명하는 변경 로그를 포함하는 것이 좋습니다. 이렇게 하면 사용자가 게시하는 각 릴리즈 간의 차이를 빨리 살펴볼 수 있습니다.

Git에서 태깅 메시지는 릴리스 노트 설명에 포함될 수 있으며, 이를 위해 릴리스 노트에 태그 메시지 포함을 선택할 수 있습니다.

설명은 마크다운을 지원합니다.

릴리즈 에셋

릴리즈에는 다음과 같은 유형의 에셋이 포함됩니다:

소스 코드

GitLab은 주어진 Git 태그에서 zip, tar.gz, tar.bz2, tar로 아카이브된 소스 코드를 자동으로 생성합니다. 이러한 에셋은 읽기 전용이며, 리포지터리에서 코드 다운로드를 할 수 있습니다.

링크

링크는 문서, 빌드된 이진 파일 또는 기타 관련 자료로 이동할 수 있는 URL입니다. GitLab 인스턴스의 내부 또는 외부 링크가 될 수 있습니다. 각 링크에는 다음 속성이 있습니다.

속성 설명 필수
name 링크의 이름
url 파일을 다운로드할 URL
filepath url로의 리다이렉트 링크. 슬래시(/)로 시작해야 합니다. 자세한 내용은 이 섹션을 참조하세요. 아니요
link_type 사용자가 url을 통해 다운로드할 수 있는 콘텐츠 유형. 자세한 내용은 이 섹션을 참조하세요. 아니요

릴리즈 에셋에 대한 영구 링크

  • GitLab 15.9에서 도입되었습니다. 비공개 릴리즈의 경우 링크에는 Personal Access Token을 사용하여 액세스할 수 있습니다.

릴리즈와 연결된 에셋은 영구적인 URL을 통해 액세스할 수 있습니다. GitLab은 항상 이 URL을 실제 에셋 위치로 리디렉션하므로 에셋이 다른 위치로 이동하더라도 동일한 URL을 계속하여 사용할 수 있습니다. 이는 filepath API 속성을 사용하여 링크 생성하거나 업데이트할 때 정의됩니다.

URL의 형식은 다음과 같습니다.

https://host/namespace/project/-/releases/:release/downloads:filepath

예를 들어, gitlab.comgitlab-org 네임스페이스와 gitlab-runner 프로젝트에 대한 v11.9.0-rc2 릴리스의 경우:

{
  "name": "linux amd64",
  "filepath": "/binaries/gitlab-runner-linux-amd64",
  "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64",
  "link_type": "other"
}

이 에셋의 직접 링크는 다음과 같습니다.

https://gitlab.com/gitlab-org/gitlab-runner/-/releases/v11.9.0-rc2/downloads/binaries/gitlab-runner-linux-amd64

에셋의 물리적 위치는 언제든지 변경될 수 있으며 직접 링크는 변경되지 않습니다.

릴리즈가 비공개인 경우 요청을 할 때 private_token 쿼리 매개변수나 HTTP_PRIVATE_TOKEN 헤더를 사용하여 api 또는 read_api 스코프가 있는 Personal Access Token을 제공해야 합니다. 예를 들어:

curl --location --output filename "https://gitlab.example.com/my-group/my-project/-/releases/myrelease/downloads</path-to-file>?private_token=<your_access_token>"
curl --location --output filename --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/my-group/my-project/-/releases/myrelease/downloads</path-to-file>

최신 릴리스 에셋에 대한 영구 링크

  • GitLab 14.9에서 도입되었습니다.

릴리즈 에셋에 대한 영구 링크filepath최신 릴리스에 대한 영구 링크와 결합하여 사용할 수 있습니다. filepath는 반드시 슬래시(/)로 시작해야 합니다.

URL의 형식은 다음과 같습니다.

https://host/namespace/project/-/releases/permalink/latest/downloads:filepath

이 형식을 사용하여 최신 릴리스의 에셋에 대한 영구적인 링크를 제공할 수 있습니다.

예를 들어, gitlab.comgitlab-org 네임스페이스와 gitlab-runner 프로젝트에 대한 v11.9.0-rc2 최신 릴리스의 경우:

{
  "name": "linux amd64",
  "filepath": "/binaries/gitlab-runner-linux-amd64",
  "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64",
  "link_type": "other"
}

이 에셋의 직접 링크는 다음과 같습니다.

https://gitlab.com/gitlab-org/gitlab-runner/-/releases/permalink/latest/downloads/binaries/gitlab-runner-linux-amd64

링크 유형

  • GitLab 13.1에 도입되었습니다.

링크의 네 가지 유형은 “Runbook,” “Package,” “Image,” 및 “Other”입니다. link_type 매개변수는 다음 네 가지 값 중 하나를 허용합니다:

  • runbook
  • package
  • image
  • other (기본값)

이 필드는 URL에 영향을 미치지 않으며 프로젝트의 릴리스 페이지에서 시각적인 목적으로만 사용됩니다.

일반 패키지 사용하여 이진 파일 첨부

릴리스나 태그 파이프라인의 아티팩트를 저장하거나 개별 릴리스 항목에 바이너리 파일을 첨부하기 위해 일반 패키지를 사용할 수 있습니다. 기본적으로 다음을 수행해야 합니다:

  1. 아티팩트를 제네릭 패키지 레지스트리에 푸시.
  2. 패키지 링크를 릴리스에 첨부.

다음 예제는 릴리스 자산을 생성하고 일반 패키지로 게시한 후 릴리스를 만드는 것을 보여줍니다:

stages:
  - build
  - upload
  - release

variables:
  # Package version can only contain numbers (0-9), and dots (.).
  # Must be in the format of X.Y.Z, i.e. should match /\A\d+\.\d+\.\d+\z/ regular expresion.
  # See https://docs.gitlab.com/ee/user/packages/generic_packages/#publish-a-package-file
  PACKAGE_VERSION: "1.2.3"
  DARWIN_AMD64_BINARY: "myawesomerelease-darwin-amd64-${PACKAGE_VERSION}"
  LINUX_AMD64_BINARY: "myawesomerelease-linux-amd64-${PACKAGE_VERSION}"
  PACKAGE_REGISTRY_URL: "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/myawesomerelease/${PACKAGE_VERSION}"

build:
  stage: build
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - mkdir bin
    - echo "Mock binary for ${DARWIN_AMD64_BINARY}" > bin/${DARWIN_AMD64_BINARY}
    - echo "Mock binary for ${LINUX_AMD64_BINARY}" > bin/${LINUX_AMD64_BINARY}
  artifacts:
    paths:
      - bin/

upload:
  stage: upload
  image: curlimages/curl:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - |
      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file bin/${DARWIN_AMD64_BINARY} "${PACKAGE_REGISTRY_URL}/${DARWIN_AMD64_BINARY}"
    - |
      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file bin/${LINUX_AMD64_BINARY} "${PACKAGE_REGISTRY_URL}/${LINUX_AMD64_BINARY}"

release:
  # 주의, 2021-02-02 기준 이러한 자산 링크는 로그인이 필요합니다. 자세한 내용은 다음을 참조하십시오:
  # https://gitlab.com/gitlab-org/gitlab/-/issues/299384
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - |
      release-cli create --name "릴리스 $CI_COMMIT_TAG" --tag-name $CI_COMMIT_TAG \
        --assets-link "{\"name\":\"${DARWIN_AMD64_BINARY}\",\"url\":\"${PACKAGE_REGISTRY_URL}/${DARWIN_AMD64_BINARY}\"}" \
        --assets-link "{\"name\":\"${LINUX_AMD64_BINARY}\",\"url\":\"${PACKAGE_REGISTRY_URL}/${LINUX_AMD64_BINARY}\"}"

PowerShell 사용자들은 JSON 문자열 내의 이중 인용부호 "--assets-linkConvertTo-Json으로 넘기기 전에 ` (백틱)로 이스케이핑해야 할 수 있습니다. 예를 들면 다음과 같습니다:

release:
  script:
    - $env:asset = "{`"name`":`"MyFooAsset`",`"url`":`"https://gitlab.com/upack/artifacts/download/$env:UPACK_GROUP/$env:UPACK_NAME/$($env:GitVersion_SemVer)?contentOnly=zip`"}"
    - $env:assetjson = $env:asset | ConvertTo-Json
    - release-cli create --name $CI_COMMIT_TAG --description "릴리스 $CI_COMMIT_TAG" --ref $CI_COMMIT_TAG --tag-name $CI_COMMIT_TAG --assets-link=$env:assetjson
note
작업 아티팩트를 직접적으로 릴리스에 첨부하는 것은 권장되지 않습니다. 왜냐하면 아티팩트는 일시적이며 동일한 파이프라인에서 데이터를 전달하는 데 사용됩니다. 이는 그들이 만료될 수도 있고 누군가가 매뉴얼으로 삭제할 수도 있는 위험이 있기 때문입니다.

새로운 기능과 총 기능 수의 수

Tier: Free, Premium, Ultimate Offering: GitLab.com
  • GitLab 13.5에 도입되었습니다.

GitLab.com에서 프로젝트의 새로운 기능과 총 기능 수를 확인할 수 있습니다.

기능 수 카운트

총 수는 shields에 표시되며 www-gitlab-com 리포지터리의 Rake 작업에 의해 릴리스 당 생성됩니다.

항목 수식
새로운 기능 프로젝트의 단일 릴리스에 대한 모든 티어의 릴리스 게시물 수를 총한 수.
총 기능 프로젝트의 모든 릴리스에 대한 역순의 릴리스 게시물 수.

카운트는 라이선스 티어별로도 표시됩니다.

항목 수식
새로운 기능 프로젝트의 단일 티어에 대한 단일 릴리스의 릴리스 게시물 수를 총한 수.
총 기능 프로젝트의 모든 릴리스의 역순에 대한 단일 티어의 릴리스 게시물 수를 총한 수.