Makefile을 사용하여 Github 및 Gitea에서 프로젝트 태그 지정 및 릴리스

나는 최근에 내가 작성한 몇 가지 Python 패키지에 대한 적절한 릴리스를 만들기 시작할 기회가 있었고 패키지를 PyPi에 업로드하거나 소스 제어에서 릴리스에 태그를 지정한 다음 릴리스를 자르는 것과 같은 일에 내 프로젝트의 Makefile에 의존해 왔습니다. 해당 태그에서 로컬로 — Make를 처음 사용하는 경우 Make를 사용하여 수행할 수 있는 더 복잡한 작업이 아니라 이 상당히 일반적인 사용 사례에서 내가 하고 있는 작업을 공유할 것이라고 생각했습니다. Make를 사용하여 터미널에서 할 수 있는 모든 작업을 수행할 수 있으며 한 줄짜리 코드를 래핑하는 것 외에도 많은 추가 프로그래밍 가능성이 있지만 최근에는 수동 단계가 있는 이와 같은 프로젝트에 의존하고 있음을 알게 되었습니다. 이를 릴리스하기 위해 전체 CI/CD 파이프라인이 반드시 필요하거나 필요하거나 CI 단계를 간소화하기 위해(리포지토리의 일부인 경우) 사용할 수 있습니다(테스트를 위해 Makefile을 실행하고 릴리스를 잘라내는 등).

예를 들어 내 Makefile에는 install과 같은 매우 간단한 지침이 포함되어 있습니다.

install:

 pip3 install -e .

또는 거리 :

dist:

 rm -rf dist/ ; python3 setup.py bdist_wheel --universal

하지만 이 경우에는 내 Git 태그가 먼저 v?.??.??와 일치해야 한다는 규칙을 적용하는 데 사용하고 있습니다. 확인 후 해당 태그를 푸시하기 전에 형식을 지정하십시오.

.SILENT:

tag-release:

if [[$(TAG) == v?.?.?]]; then echo "Tagging $(TAG)"; elif [[$(TAG) == v?.?.??]]; then echo "Tagging $(TAG)"; else echo "Bad Tag Format: $(TAG)"; exit 1; fi && git tag -a $(TAG) -m "Releasing $(TAG)" ; read -p "Push tag: $(TAG)? " push_tag ; if ["${push_tag}"="yes"]; then git push self $(TAG); fi

실행하면 다음과 같이 표시됩니다.



그러면 Gitea 저장소의 릴리스 페이지에서 새 태그를 볼 수 있습니다.



이 태그를 적절한 릴리스로 전환하려면 Gitea API를 사용해야 합니다.

첫째, 이 둘의 차이점은 태그가 로그의 특정 커밋에 대한 참조일 뿐이며, 이것이 릴리스와 같은 상위 수준 개념에서 사용하기 위한 훌륭한 포인터가 되는 이유입니다. Github가 처음 Github에 이 기능을 소개했을 때 다음과 같이 말했습니다.

따라서 우리의 경우 https://{Your_Git_Host}/user/settings/applications.에서 찾을 수 있는 자체 Gitea 환경에 대한 액세스 토큰이 필요합니다.

해당 토큰이 있으면 Makefile의 다음 단계를 살펴보겠습니다.

.SILENT:

create-release:

if [[$(TAG) == v?.?.?]]; then echo "Cutting release from $(TAG)"; elif [[$(TAG) == v?.?.??]]; then echo "Cutting release from $(TAG)"; else echo "Bad Tag Format, cannot cut release: $(TAG)"; exit 1; fi && git tag -a $(TAG) -m "Releasing $(TAG)" ; read -p "Cut release from tag: $(TAG)? " push_tag ; if ["${push_tag}"="yes"]; then TAG=$(TAG) ./make-release.sh; fi

이 지침에서는 동일한 태그 확인 프로세스를 사용하고 있지만 이번에는 헬퍼 스크립트(내 편의를 위한 것이므로 Makefile에 인라인으로 수행할 수 있음)인 make-release.sh에 전달합니다. 인수, TAG 및 GITEA_TOKEN(내 bash 프로필에 설정했으므로 그렇게 하지 않으면 Make 명령에도 GITEA_TOKEN=$GITEA_TOKEN을 포함해야 합니다.):

#!/bin/bash

TAG=$TAG

TAG_COMMIT=$(git rev-parse --short ${TAG})

AUTH_TOKEN=$GITEA_TOKEN

curl -X POST "[**https://{Your\_Git\_Host}**](https://%7BYour_Git_Host%7D/user/settings/applications.)/api/v1/repos/ **{** You}/ **{** Your_Project}/releases" -H "Authorization: token $AUTH_TOKEN" \

-H "accept: application/json" -H "Content-Type: application/json" \

-d "{ \"body\": \"Cutting ${TAG} at ${TAG_COMMIT}\", \"draft\": false, \"name\": \"${TAG}\", \"prerelease\": false, \"tag_name\": \"${TAG}\", \"target_commitish\": \"${TAG_COMMIT}\"}" \

-ik

Github에서 이 흐름을 사용하려면 Gitea에서와 마찬가지로 엔드포인트 URL을 업데이트하고 추가 헤더를 포함하고 동일한 요청 본문을 사용하여 릴리스를 생성할 수 있습니다.

AUTH_TOKEN=$GITHUB_TOKEN
curl \
  -X POST "https://api.github.com/repos/jmarhee/polly-textfile-cli/releases" -H "Authorization: token $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  -d "{  \"body\": \"Cutting ${TAG} at ${TAG_COMMIT}\",  \"draft\": false,  \"name\": \"${TAG}\",  \"prerelease\": false,  \"tag_name\": \"${TAG}\" }" \

그래서 여기에서 우리는 태그를 가져오고 리포지토리의 개정 기록을 확인하여 태그가 TAG_COMMIT에 매핑되는 git commit 해시를 찾습니다(git show를 사용하여 커밋 메시지와 같은 다른 정보를 얻을 수 있습니다. 릴리스 생성 개체에서도 사용) 그런 다음 Gitea API에 POST하여 릴리스를 시작하고 해당 태그를 릴리스로 변환할 커밋을 알려줍니다.

TAG=v0.1.19 make create-release

제 경우에는 이러한 프로젝트를 Python의 패키지 레지스트리로 푸시하기 때문에 일단 릴리스되면 다음과 같은 작업도 수행할 수 있습니다.

push-test:

 make dist; python3 -m twine upload --repository testpypi dist/*

push:

 make dist; python3 -m twine upload dist/*

그리고 다시, 원하는 경우 그렇게 하기 전에 위와 같은 논리를 사용하여 태그의 유효성을 검사할 수 있습니다(예를 들어 내 setup.py의 패키지 버전과 일치하므로).

이전에 언급했듯이 이는 이러한 단계를 중심으로 CI 파이프라인을 생성할 수 있는 것입니다(더 읽기 쉽게 유지하고 추가 행동 기대치를 생성하기 위해 등).

Make에서 수행할 수 있는 작업에 대해 자세히 알고 싶다면 이 가이드가 매우 마음에 들었습니다.

https://www.gnu.org/software/make/manual/html_node/