.github/workflows: Migrate workflows to Blacksmith runners#23
Open
blacksmith-staging[bot] wants to merge 41 commits intomasterfrom
Open
.github/workflows: Migrate workflows to Blacksmith runners#23blacksmith-staging[bot] wants to merge 41 commits intomasterfrom
blacksmith-staging[bot] wants to merge 41 commits intomasterfrom
Conversation
Removed multiple markdown files and created a single, concise DEPLOYMENT.md that explains: - How to create patched releases - How to sync with upstream - The rebase workflow process Keeping documentation minimal and focused on the essential deployment operations.
Complete redesign to use the canonical rebase workflow: - Master = upstream + our patches (always rebased on top) - No manual patch tracking (git knows the delta) - Single workflow for creating releases Key changes: - Removed complex patch ID system and patches branch - Added release-patched-version.yml: automatically finds and applies patches - Added rebase-upstream.yml: keeps master rebased on upstream - Added FORK_WORKFLOW.md: comprehensive guide for developers Workflow: 1. Developers PR to master 2. Master stays rebased on upstream (patches on top) 3. Release workflow cherry-picks all patches onto upstream tags 4. Git automatically handles patch cleanup when merged upstream This matches how Chromium forks, Android AOSP, and Linux distros maintain their patches - battle-tested and maintenance-free.
- Use actual newlines instead of literal \n characters - Remove echo -e flags since we're using real newlines - Fix tag message formatting to properly display patch list
The go build commands need the bin directory to exist before writing output files
*: add corruption recovery to history.db
- Use printf instead of multiline strings to avoid YAML syntax errors - Fetch upstream master branch along with tags for patch discovery - Fixes yamllint errors at lines 108 and 153
- Check git push failures in release workflow and exit properly - Check git push failures in rebase workflow to avoid false success - Prevent inconsistent state where tags exist but branches don't - Provide clear error messages and manual recovery instructions
- Add contents: write to release workflow for git operations and releases - Add contents: write and issues: write to rebase workflow - Follows established pattern from buildkit.yml workflow - Ensures workflows have necessary permissions to complete operations
Add workflow automation for maintaining patched fork
The workflows need 'workflows: write' permission to push changes that modify workflow files. This is required when cherry-picking patches that include workflow updates. Fixes error: 'refusing to allow a GitHub App to create or update workflow without workflows permission'
Fix: Add workflows permission to GitHub Actions
- Remove invalid 'workflows' permission (doesn't exist in GitHub Actions) - Use WORKFLOW_TOKEN (PAT) for operations that modify workflow files - Fall back to GITHUB_TOKEN if PAT not configured - Add setup documentation for creating Personal Access Token The GITHUB_TOKEN cannot push changes to workflow files by design. When patches include workflow modifications, a PAT with workflow scope is required.
…operly Fix: Properly handle workflow file modifications in releases
- Remove fallback to GITHUB_TOKEN as it was causing authentication errors - Use only WORKFLOW_TOKEN which must be configured as a repository secret - Update documentation to make it clear the token is required, not optional - Add detailed setup instructions for creating the PAT with correct scopes The || operator in the token field was not working as expected, causing the checkout action to fail with authentication errors.
Fix: Remove broken token fallback in checkout action
- Add pull_request trigger for easier debugging - Add conditional checkout with fallback - Add debug output to understand token availability - Skip push operations during PR testing - Skip build and release jobs during PR testing - Use v0.26.1 as test version for PR runs This allows testing the workflow without manual dispatch
This alternative workflow avoids PAT requirements by: - Detecting commits that modify .github/workflows files - Skipping those commits during cherry-pick - Using default GITHUB_TOKEN which works for non-workflow files - Reporting skipped patches in the output This provides a working solution without needing PAT configuration.
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
- Remove alternative workflow (release-patched-version-alt.yml) - Remove complex release workflow (release-patched-version.yml) - Remove rebase workflow (rebase-upstream.yml) - Keep only prepare-patched-release.yml that: - Cherry-picks patches onto upstream tags - Creates tag locally without pushing - Provides manual commands to complete release - Simplify documentation to focus on the two-step process - Leverage existing buildkit.yml for actual releases This is the cleanest approach - one simple workflow for preparation, then use BuildKit's existing release process.
The previous approach created tags only in the ephemeral runner environment. Now the workflow: 1. Pushes a draft branch (v0.17.0-blacksmith-draft) 2. Pushes a draft tag (v0.17.0-blacksmith-draft) 3. User fetches these drafts locally 4. User creates and pushes the final tag to trigger release This ensures the prepared release is accessible for review and completion. Thanks to the GitHub commenter for catching this issue!
- Renamed to create-patched-release.yml (not just prepare) - Push the tag directly using GITHUB_TOKEN with contents:write - This works because we're pushing a tag, not workflow file content - Exactly like the working setup-docker-builder workflow - If it fails (rare case with workflow changes), provide manual fallback One command, fully automated release!
Add simple prepare-patched-release workflow
Problem: - Workflow created both a branch and tag with same name (e.g., v0.26.1-blacksmith) - Git push failed with 'matches more than one' error Solution: - Use temporary branch name during processing (temp-<name>-<pid>) - Push tag with explicit refs/tags/ prefix to avoid ambiguity - Update manual fallback instructions to handle conflicts This fixes the issue seen when creating v0.26.1-blacksmith release.
Fix: Resolve branch/tag name collision in release workflow
Signed-off-by: Aditya Maru <adityamaru@gmail.com>
Adds documentation for AI coding agents (Claude, Copilot, etc.) with: - GitHub CLI usage preferences (gh pr create, gh issue list, etc.) - Commit message conventions (lowercase, package: summary format) - PR title formatting requirements - Code formatting requirements (gofmt before commits) CLAUDE.md is symlinked to AGENTS.md for Claude Code compatibility. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
repo: add AGENTS.md with contribution guidelines for AI agents
When bbolt is opened with NoSync: true, transactions complete in memory without fsync to disk. On graceful shutdown, dirty pages in the OS page cache may not be flushed before Close() returns, leading to corruption when the filesystem is unmounted or snapshots are taken. This is particularly problematic with network block devices (Ceph RBD) and container snapshot workflows where: 1. BuildKit stops gracefully (SIGTERM) 2. Close() returns without syncing dirty pages 3. Unmount forces writeback of partial/torn pages 4. Snapshot captures inconsistent B-tree state The fix wraps bolt.DB with syncingDB that calls Sync() before Close(), ensuring all pending writes are flushed to disk during graceful shutdown while preserving the NoSync performance benefits during normal operation. Signed-off-by: Aditya Maru <adityamaru@gmail.com> 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
boltutil: sync bbolt databases on close to prevent corruption
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit adff42a. Configure here.
| fail-fast: false | ||
| matrix: | ||
| os: [windows-2022] | ||
| os: [blacksmith-4vcpu-windows-2025] |
There was a problem hiding this comment.
Windows OS version silently upgraded from 2022 to 2025
High Severity
The migration changes the Windows test matrix from windows-2022 to blacksmith-4vcpu-windows-2025, which isn't just a runner provider swap — it upgrades the underlying OS from Windows Server 2022 to Windows Server 2025. These have significant differences: removed software (e.g., Windows Driver Kit), different default tool versions, and importantly, Windows container base image version-matching requirements that can break containerd worker tests. The tests were intentionally targeting Windows Server 2022 and this silently changes what's being tested.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit adff42a. Configure here.
This comment has been minimized.
This comment has been minimized.
|
No description provided. |
bruce-y
force-pushed
the
master
branch
5 times, most recently
from
ab84b9a to
2017294
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
To whomever may be reviewing this PR,
Blacksmith is the fastest way to run your GitHub Actions.
What does this PR change?
This PR has been automatically generated by a team member in your GitHub organization using Blacksmith's Migration Wizard, or MigWiz for short. This PR changes the following:
runs-on: blacksmith-4vcpu-ubuntu-2204). Learn more about the different instances available to choose from.FAQ
Codesmith can help with this PR — just tag
@codesmithor enable autofix.