Improvement: Implement automated Devcontainer version update workflow #2393
Description
What
Goal of the Improvement / Task:
The current devcontainer.json configurations across various repositories use the ghcr.io/eclipse-score/devcontainer:x.y.z image tag. When there is a new release of the devcontainer, each of these devcontainer.json files must be patched manually.
The goal is to eliminate this by implementing an automated process to update these fixed versions whenever a new, stable version of the eclipse-score/devcontainer image is released.
This will ensure that the development environments are consistent and reduces manual effort.
How
Details on implementation approach:
A GitHub Actions workflow within the eclipse-score/reference_integration repository should be implemented. This workflow will be responsible for orchestrating the Devcontainer version updates in other target repositories.
Key components and steps:
Trigger Mechanism:
The workflow could be triggered by new releases (tags) in the eclipse-score/devcontainer repository. This will require listening to GitHub release or create (for tags) events on the devcontainer repository.
A workflow_dispatch trigger should be included to allow for manual execution with a specified target version.
A scheduled trigger (e.g., nightly) as a fallback mechanism to catch any missed updates.
Determine Target Version:
Upon a latest release/tag in eclipse-score/devcontainer, the workflow will extract the new version
This version will be used as the target for all devcontainer.json updates.
Identify Target Repositories:
A configuration file (e.g., repositories_to_update.yml) within eclipse-score/reference_integration will list all repositories that consume the eclipse-score/devcontainer image and should be updated. This allows for explicit control over which repositories are affected.
Iterate and Update Repositories:
For each repository listed in the configuration:
Checkout Target Repository: The workflow will clone the target repository using a GitHub PAT (Personal Access Token) with appropriate permissions (repo scope).
Locate devcontainer.json: It will find the .devcontainer/devcontainer.json file.
Read Current Version: The current image tag will be read from the devcontainer.json.
Compare Versions: If the current version differs from the new target version:
Patch devcontainer.json: The image field in devcontainer.json will be updated to ghcr.io/eclipse-score/devcontainer:<new_version>.
Create New Branch: A new branch will be created in the target repository (e.g., feature/devcontainer-update-<new_version>).
Commit Changes: The patched devcontainer.json will be committed to this new branch.
Create Pull Request: A Pull Request will be opened against the target repository's default branch (e.g., main).
Title: feat: Update devcontainer image to <new_version>
Error Handling: Robust logging and error handling will be implemented for failed operations (e.g., repository not found, devcontainer.json malformed, PR creation failed).
GitHub Token Management:
A GitHub Personal Access Token (PAT) will be required for the workflow, stored as a secret in eclipse-score/reference_integration, to grant permissions for cross-repository operations (cloning, pushing branches, creating PRs).
Remark: An automation with Dependabot has been checked but is not possible (only bumping of devcontainer features is possible https://containers.dev/guide/dependabot, but not bumping the version of the image dependabot/dependabot-core#7000)
Estimates for realization
Estimate the effort, resources, risk for the realization:
Effort:
Small (1-2 days): Design and initial implementation of the core workflow logic.
Small (1-2 days): Patch script, e.g. Python
Medium (3-5 days): Robust error handling, comprehensive logging, defining the list of target repositories, thorough testing in a staging environment.
Total Estimate: ~1 week for a fully functional and tested solution.
Resources:
1 Developer: To implement and test the GitHub Actions workflow.
GitHub PAT: Creation and secure storage of a Personal Access Token with repo scope.
Code Reviewer: For the workflow changes and potentially for a few initial generated PRs.
Category
- Affects Detailed Design
Requirements / Architecture
- Requirements / Architecture are not affected by this change?