Skip to content

Commit 237e219

Browse files
committed
chore: 불필요한 테스트 파일 제거
1 parent 79bcb05 commit 237e219

File tree

3 files changed

+117
-16
lines changed

3 files changed

+117
-16
lines changed

pr238_initial_state.json

Lines changed: 0 additions & 8 deletions
This file was deleted.

pr238_updated_state.json

Lines changed: 0 additions & 8 deletions
This file was deleted.

workflow_comparison.md

Lines changed: 117 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,117 @@
1+
# Release Workflow Comparison: Main vs Develop
2+
3+
## Overview
4+
Both branches have a workflow named "Release (Simplified)" that triggers on push to main branch.
5+
6+
## Key Differences
7+
8+
### 1. Version Update Logic
9+
**Main Branch:**
10+
```bash
11+
PKG_BASE=$(echo $PKG_VERSION | sed 's/-beta.*//')
12+
```
13+
14+
**Develop Branch:**
15+
```bash
16+
# Remove all beta suffixes (handle multiple -beta occurrences)
17+
PKG_BASE=$(echo $PKG_VERSION | sed 's/-beta.*$//')
18+
```
19+
- Develop branch has a comment explaining the sed pattern
20+
- Both use similar regex patterns but develop uses `$` anchor
21+
22+
### 2. Post-Release Branch Creation Steps
23+
24+
**Main Branch:**
25+
- Ends after creating release branch
26+
- Only outputs information about what the release branch workflow will handle
27+
- No actual npm publishing, GitHub releases, or PR creation
28+
29+
**Develop Branch:**
30+
- Continues with full release process:
31+
1. Checks out the release branch
32+
2. Publishes to npm
33+
3. Creates GitHub releases
34+
4. Syncs with develop branch (auto-merge)
35+
5. Creates PR to main branch
36+
37+
### 3. Workflow Completeness
38+
39+
**Main Branch Workflow:**
40+
- Creates release branch only
41+
- Delegates remaining tasks to a separate release branch workflow
42+
- Last step just echoes what will happen next
43+
44+
**Develop Branch Workflow:**
45+
- Complete end-to-end release process
46+
- Handles all release tasks within the same workflow
47+
- Includes npm publishing with tokens
48+
- Creates GitHub releases with proper formatting
49+
- Auto-merges to develop
50+
- Creates PR back to main
51+
52+
### 4. Sync with Develop Logic Difference
53+
**Main Branch (in release-branch.yml):**
54+
```bash
55+
# Create a temporary branch for merging
56+
TEMP_BRANCH="temp-sync-$(date +%s)"
57+
git checkout -b $TEMP_BRANCH
58+
59+
# Merge into develop
60+
git checkout develop
61+
git pull origin develop
62+
git merge $TEMP_BRANCH --no-edit -m "chore: sync release ${{ github.ref_name }} to develop"
63+
```
64+
- Uses a temporary branch approach
65+
- Pulls latest develop before merging
66+
67+
**Develop Branch:**
68+
```bash
69+
# Fetch latest develop
70+
git fetch origin develop:develop
71+
72+
# Merge release branch into develop
73+
git checkout develop
74+
git merge ${{ steps.create-release.outputs.release_branch }} --no-edit -m "chore: sync release ${{ steps.create-release.outputs.release_branch }} to develop"
75+
```
76+
- Directly fetches and merges
77+
- Uses the release branch output variable
78+
79+
### 5. Environment Variables
80+
**Main Branch:**
81+
- No npm tokens used
82+
83+
**Develop Branch:**
84+
- Uses `NPM_TOKEN` and `NPM_TOKEN_SUMIN` for publishing
85+
- Uses `GITHUB_TOKEN` for GitHub operations
86+
87+
## Summary
88+
The main difference is architectural:
89+
90+
1. **Main branch uses a two-workflow approach:**
91+
- `release.yml` - Creates the release branch only
92+
- `release-branch.yml` - Triggers on `release/v*` branches and handles:
93+
- npm publishing
94+
- GitHub releases
95+
- Syncing with develop
96+
- Creating PR to main
97+
98+
2. **Develop branch uses a single-workflow approach:**
99+
- `release.yml` - Handles everything in one workflow:
100+
- Creates release branch
101+
- Publishes to npm
102+
- Creates GitHub releases
103+
- Syncs with develop
104+
- Creates PR to main
105+
106+
## Why This Matters
107+
The main branch's two-workflow approach can be more reliable because:
108+
- Each workflow has a single responsibility
109+
- The release branch workflow triggers automatically when the branch is created
110+
- Easier to debug and maintain
111+
112+
However, the develop branch's single-workflow approach:
113+
- Is simpler to understand
114+
- Completes faster (no waiting for second workflow)
115+
- But may be harder to debug if something fails midway
116+
117+
This explains why releases from main might appear to "fail" initially - they're not failing, they're just delegating the actual release work to a separate workflow that triggers on the release branch creation.

0 commit comments

Comments
 (0)