Create a Github workflow to automatically apply version increments due to qualifier changes
If an Eclipse Plugin project in one of the Eclipse top-level is changed the first time in a development cycle build failures due to missing version bumps are very common. For example like:
[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.8:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.pde.api.tools.tests:
Only qualifier changed for (org.eclipse.pde.api.tools.tests/1.3.600.v20240905-2015). Expected to have bigger x.y.z than what is available in baseline (1.3.600.v20240806-1811) -> [Help 1]
For contributors this is annoying and time-consuming because they have to check the build-logs for the exact projects need the version-bump and then how to apply it and await the build result again. In fact it's among the first things that is mentioned by existing and even new contributors when being asked about what should be improved in the contribution process (for example at the in-person Eclipse Community meeting at SAP or the Eclipse IDE - Developers Call at 18th July 2024. For newcomers this is just confusing and again requires time from Committers to explain the problem and its resolution to them.
Therefore a Github workflow used in the Eclipse Platform, Equinox, JDT and PDE project should be created to automatically apply these version bumps if necessary. The specific task of the workflow are:
-
Find all project's whose version has to be bumped
-
Create a separate Commit that contains all necessary version increments and the expected commit message. E.g.:
Version bumps for 4.33 stream- Push that commit on top of the PR's branch in the providing fork.
- Pushing to a fork from a workflow is not possible just with the
GITHUB_TOKEN, but maybe using a personal-access-token (PAT) could make it possible:
https://github.com/orgs/community/discussions/75867#discussioncomment-10439473
-
Create a comment on the PR to explain what happened and list the affected projects.
Maybe also provide a textual Git-patch so that one can apply the change manually if desired.