You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add prepare-release workflow that leverages existing buildkit.yml
Instead of reimplementing release logic, this approach:
1. Uses prepare-patched-release.yml to cherry-pick patches
2. Creates the tag locally but doesn't push
3. Provides manual commands to push the tag
4. Leverages existing buildkit.yml for actual release
Benefits:
- No PAT needed for patches without workflow changes
- Uses upstream's proven build/release process
- Manual review step before release
- Simpler and more maintainable
Copy file name to clipboardExpand all lines: DEPLOYMENT.md
+42-28Lines changed: 42 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,42 +4,56 @@
4
4
5
5
This fork maintains patches on top of upstream BuildKit using a rebase workflow. Our `master` branch contains upstream BuildKit plus our custom patches rebased on top.
6
6
7
-
## Setup Requirements
8
-
9
-
**Required**: You must create a Personal Access Token for the workflows to function properly:
10
-
11
-
1. Go to GitHub Settings > Developer settings > Personal access tokens > Tokens (classic)
12
-
2. Click "Generate new token (classic)"
13
-
3. Give it a descriptive name (e.g., "BuildKit Fork Workflow")
14
-
4. Select these scopes:
15
-
-`repo` (all checkboxes under repo)
16
-
-`workflow` (update GitHub Action workflows)
17
-
5. Generate the token and copy it
18
-
6. Go to your fork's Settings > Secrets and variables > Actions
19
-
7. Click "New repository secret"
20
-
8. Name: `WORKFLOW_TOKEN`
21
-
9. Value: Paste your Personal Access Token
22
-
23
-
This token is necessary because:
24
-
- The default `GITHUB_TOKEN` cannot push changes to workflow files
25
-
- Some patches may include modifications to `.github/workflows/*.yml` files
7
+
## Release Strategy
8
+
9
+
We use BuildKit's existing `buildkit.yml` workflow to build and release our patched versions. This ensures consistency with upstream's build process.
10
+
11
+
### Process:
12
+
1.**Prepare**: Use `prepare-patched-release.yml` to cherry-pick patches onto an upstream tag
13
+
2.**Review**: Check which patches were applied successfully
14
+
3.**Push**: Manually push the tag to trigger BuildKit's release workflow
15
+
4.**Release**: The existing `buildkit.yml` automatically builds and publishes binaries
26
16
27
17
## Creating a Patched Release
28
18
29
-
To deploy a patched version of BuildKit:
19
+
### Step 1: Prepare the Release
20
+
21
+
```bash
22
+
# Run the prepare workflow to cherry-pick patches
23
+
gh workflow run prepare-patched-release.yml -f upstream_version=v0.17.0
24
+
```
25
+
26
+
This workflow will:
27
+
1. Cherry-pick all patches from master onto v0.17.0
28
+
2. Create a local tag `v0.17.0-blacksmith`
29
+
3. Show you which patches succeeded/failed
30
+
4. Give you the exact commands to complete the release
31
+
32
+
### Step 2: Review and Push
33
+
34
+
Check the workflow output, then run locally:
30
35
31
36
```bash
32
-
# Create release for v0.17.0 with all our patches
33
-
gh workflow run release-patched-version.yml -f upstream_version=v0.17.0
0 commit comments