Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Sep 14, 2025

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 (--version check)
  • Depends on prepare job

3. publish Job

  • Authenticates to Docker Hub and GitHub Container Registry
  • Builds and pushes multi-platform images (linux/amd64, linux/arm64)
  • Depends on both prepare and build-test jobs

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_dispatch to 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 AI changed the title [WIP] Split workflows semantically Split docker-build-and-publish workflow into semantic jobs Sep 14, 2025
Copilot AI requested a review from zimme September 14, 2025 15:18
Copilot finished work on behalf of zimme September 14, 2025 15:18
@zimme
Copy link
Owner

zimme commented Sep 14, 2025

@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.

- Add workflow_dispatch trigger to docker-build-and-publish workflow
- Split update workflow into separate update-dockerfile and commit-changes jobs
- Add workflow trigger from update to build workflow after commit
- Improve job naming and semantic separation

Co-authored-by: zimme <[email protected]>
Copy link
Contributor Author

Copilot AI commented Sep 14, 2025

@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:

  1. ✅ Added workflow_dispatch trigger to docker-build-and-publish workflow
  2. ✅ 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
  3. ✅ 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 AI changed the title Split docker-build-and-publish workflow into semantic jobs Refactor workflows into semantic jobs and add workflow orchestration Sep 14, 2025
Copilot finished work on behalf of zimme September 14, 2025 15:36
@zimme
Copy link
Owner

zimme commented Sep 14, 2025

@copilot the workflow dispatch can probably also be a separate job?

Copy link
Contributor Author

Copilot AI commented Sep 14, 2025

@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:

  1. check-version-updates - Check for new versions
  2. update-dockerfile - Update Dockerfile with new versions
  3. commit-changes - Commit and push changes
  4. 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.

Copilot finished work on behalf of zimme September 14, 2025 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Split workflows semantically

2 participants