[BUILD] main 머지 시 자동 릴리스 버전 태깅 워크플로우 추가#115
Hidden character warning
Conversation
dgh06175
changed the title
There was a problem hiding this comment.
Pull request overview
Adds GitHub Actions automation to enforce release labeling on main PRs and to create a semver-based GitHub Release when a main PR is merged.
Changes:
- Add a workflow that requires exactly one
RELEASE: {MAJOR|MINOR|PATCH}label on PRs targetingmain. - Add a workflow that, on merge to
main, computes the nextv<major>.<minor>.<patch>tag from the PR’s release label and creates a GitHub Release.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
.github/workflows/require-release-label-for-main.yml |
Enforces exactly one release label on PRs targeting main. |
.github/workflows/create-release-on-main-merge.yml |
On merged PRs to main, derives the next semver tag and creates a GitHub Release. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| latest_tag="$(git tag --list 'v*' --sort=-version:refname | head -n 1)" | ||
| if [ -z "${latest_tag}" ]; then | ||
| latest_tag="v0.0.0" | ||
| fi | ||
|
|
||
| version="${latest_tag#v}" | ||
| IFS='.' read -r major minor patch_version <<EOF | ||
| ${version} | ||
| EOF |
There was a problem hiding this comment.
latest_tag is selected from all v* tags, but the parsing logic assumes strict v<major>.<minor>.<patch> numeric format. If the repo ever has tags like v1.2.3-alpha, v1.2, or any non-numeric v* tag, the read + arithmetic will fail and the workflow will error. Consider filtering to tags that match ^v[0-9]+\.[0-9]+\.[0-9]+$ (or validating and failing with a clear message) before computing the next version.
| if gh release view "${NEW_TAG}" --repo "${REPOSITORY}" >/dev/null 2>&1; then | ||
| echo "Release ${NEW_TAG} already exists. Skipping." | ||
| exit 0 | ||
| fi | ||
|
|
||
| notes_file="$(mktemp)" | ||
| cat <<EOF > "${notes_file}" | ||
| Release type: ${RELEASE_LABEL} | ||
| Previous tag: ${PREVIOUS_TAG} | ||
|
|
||
| Merged pull request: | ||
| - #${PR_NUMBER} ${PR_TITLE} | ||
| EOF | ||
|
|
||
| gh release create "${NEW_TAG}" \ | ||
| --repo "${REPOSITORY}" \ | ||
| --target "${MERGE_COMMIT_SHA}" \ | ||
| --title "${NEW_TAG}" \ | ||
| --notes-file "${notes_file}" |
There was a problem hiding this comment.
This job can race on fast consecutive merges: two runs may read the same latest_tag, compute the same new_tag, then one gh release create will fail. Consider adding a workflow/job concurrency group to serialize release creation and/or checking for existing tag (refs/tags/${NEW_TAG}) in addition to gh release view before attempting creation.
| name: Require release label for main | ||
|
|
||
| on: | ||
| pull_request: | ||
| branches: | ||
| - main |
There was a problem hiding this comment.
PR description says the PR template was updated to include release label selection guidance, but this PR only adds workflow files and the existing .github/PULL_REQUEST_TEMPLATE.md still lacks that guidance. Either include the template change in this PR or update the description to avoid a mismatch.
📄 작업 내용 요약
🏷️ Release 라벨
📎 Issue 번호