Task summary
I have been thinking about a way to improve confidence in workflow changes before they are merged into the main IDEasy repository.
What if we created a dedicated IDEasy-workflow-testing repository within the devonfw organization? This repository would essentially be a clone of IDEasy and serve exclusively as a testing environment for GitHub workflow changes.
The idea would be:
Any workflow modification must first be submitted as a PR to the testing repository.
After review, the PR is merged and validated there under realistic conditions.
Only once we have proven that the workflow behaves as expected do we create the equivalent PR in the actual IDEasy repository.
For release-related workflows, we could adapt the testing repository so that it does not produce a real IDEasy release. For example:
Use different Maven coordinates in the POM.
Modify the build to release only a minimal "Hello World" artifact.
Disable or mock the Maven Central deployment step.
This would allow us to execute the complete release workflow safely without affecting the real project or publishing unintended artifacts.
One of the main benefits is verifiability. Today, when a developer states that a workflow has been tested in their fork, we can choose to trust that statement, but we have no practical way to verify it ourselves. In addition, tests performed in personal forks often lack access to the same secrets, permissions, and configurations that exist in the production repository, making it difficult to judge how realistic those test results actually are.
A dedicated workflow-testing repository would provide a controlled environment that more closely mirrors production conditions while remaining isolated from the real project. This would give reviewers greater confidence that workflow changes have been validated properly before reaching IDEasy.
The concept still needs to be thought through in more detail, but overall I believe it is a promising approach. What do you think?
Additional context
Task summary
I have been thinking about a way to improve confidence in workflow changes before they are merged into the main IDEasy repository.
What if we created a dedicated IDEasy-workflow-testing repository within the devonfw organization? This repository would essentially be a clone of IDEasy and serve exclusively as a testing environment for GitHub workflow changes.
The idea would be:
Any workflow modification must first be submitted as a PR to the testing repository.
After review, the PR is merged and validated there under realistic conditions.
Only once we have proven that the workflow behaves as expected do we create the equivalent PR in the actual IDEasy repository.
For release-related workflows, we could adapt the testing repository so that it does not produce a real IDEasy release. For example:
Use different Maven coordinates in the POM.
Modify the build to release only a minimal "Hello World" artifact.
Disable or mock the Maven Central deployment step.
This would allow us to execute the complete release workflow safely without affecting the real project or publishing unintended artifacts.
One of the main benefits is verifiability. Today, when a developer states that a workflow has been tested in their fork, we can choose to trust that statement, but we have no practical way to verify it ourselves. In addition, tests performed in personal forks often lack access to the same secrets, permissions, and configurations that exist in the production repository, making it difficult to judge how realistic those test results actually are.
A dedicated workflow-testing repository would provide a controlled environment that more closely mirrors production conditions while remaining isolated from the real project. This would give reviewers greater confidence that workflow changes have been validated properly before reaching IDEasy.
The concept still needs to be thought through in more detail, but overall I believe it is a promising approach. What do you think?
Additional context