Refactor workflows into semantic jobs and add workflow orchestration
This PR refactors both GitHub Actions workflows to improve maintainability, debugging, and workflow orchestration through better semantic job separation.
Changes Made
docker-build-and-publish.yaml Refactoring
Before: Single docker Job
The original workflow had one large job with multiple unrelated steps mixed together:
- Environment setup
- Version extraction
- Tag preparation
- Authentication
- Building
- Testing
- Publishing
After: Three Focused Jobs
1. prepare Job
- Extracts versions from Dockerfile (UnRAR, rar2fs, base image)
- Generates all required Docker tags
- Provides outputs for downstream jobs
2. build-test Job
- Sets up Docker buildx and QEMU
- Builds single-platform image for testing
- Runs basic validation (
--versioncheck) - Depends on
preparejob
3. publish Job
- Authenticates to Docker Hub and GitHub Container Registry
- Builds and pushes multi-platform images (linux/amd64, linux/arm64)
- Depends on both
prepareandbuild-testjobs
check-for-updates-and-update-dockerfile.yaml Refactoring
Before: Two Jobs with Mixed Responsibilities The original workflow had version checking and file updates/commits mixed together.
After: Four Semantic Jobs
1. check-version-updates Job
- Checks for latest UnRAR and rar2fs versions
- Provides version outputs for downstream jobs
2. update-dockerfile Job
- Updates Dockerfile with new versions
- Checks for changes and uploads artifact
- Provides change status output
3. commit-changes Job
- Downloads updated Dockerfile artifact
- Commits and pushes changes (only if changes detected)
4. trigger-build Job
- Triggers build workflow automatically after successful commit
- Dedicated job for workflow orchestration
Workflow Orchestration Improvements
-
Manual Trigger Support: Added
workflow_dispatchto build workflow for manual execution - Automated Workflow Chaining: Update workflow now automatically triggers build workflow after committing changes
- Artifact-based Communication: Jobs communicate through artifacts and outputs rather than shared state
- Dedicated Workflow Triggering: Workflow dispatch trigger separated into its own semantic job
Benefits
- Better maintainability: Each job has a clear, single responsibility
- Improved debugging: Failures are easier to isolate to specific stages
- Enhanced readability: Job names and structure clearly convey workflow purpose
- Automated orchestration: Workflows now trigger each other automatically when appropriate
- Preserved functionality: All original features maintained including multi-platform builds, caching, and dual registry publishing
- Cleaner separation: Workflow triggering is now its own dedicated job for better semantic clarity
Technical Details
- Job dependencies ensure proper execution order across both workflows
- Environment variables converted to job outputs for better cross-job communication
- All Docker setup steps appropriately distributed to jobs that need them
- Build caching strategy preserved across the refactored structure
- Workflow triggers use GitHub Actions API for reliable automation
Fixes #23.
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.
@copilot add workflowndispatch to build workflow.
Split making change and commiting change into separate jobs in update workflow it that makes semantic sense.
After commit, update workflow should trigger build workflow.
@copilot add workflowndispatch to build workflow.
Split making change and commiting change into separate jobs in update workflow it that makes semantic sense....
All requested changes have been implemented in commit 68621ad:
- ✅ Added
workflow_dispatchtrigger to docker-build-and-publish workflow - ✅ Split update workflow into semantic jobs:
-
check-version-updates: Checks for new versions -
update-dockerfile: Updates Dockerfile with new versions -
commit-changes: Commits and pushes changes
-
- ✅ Added workflow trigger from update workflow to build workflow after commit using
actions/github-script
The workflows now have better semantic separation and the update workflow will automatically trigger the build workflow after successfully committing changes.
@copilot the workflow dispatch can probably also be a separate job?
@copilot the workflow dispatch can probably also be a separate job?
Good suggestion! I've separated the workflow dispatch trigger into its own dedicated trigger-build job in commit 88340ad. This provides better semantic separation and makes the workflow structure cleaner - now each job has a single, clear responsibility:
-
check-version-updates- Check for new versions -
update-dockerfile- Update Dockerfile with new versions -
commit-changes- Commit and push changes -
trigger-build- Trigger the build workflow
The trigger-build job depends on all previous jobs and only runs when changes are detected, maintaining the same functionality while improving the workflow's organization.