Make releaseNumberSDK configurable parameter in checkVersions.yml

[Copilot]

Problem

The checkVersions.yml workflow currently hardcodes the Maven property name releaseNumberSDK for determining the stream version used in commit messages. Different projects may need to use different Maven property names for this purpose, making the workflow less flexible.

Solution

This PR adds a new optional input parameter currentStreamVersionProperty to the checkVersions.yml workflow, allowing callers to specify which Maven property to use for determining the stream version.

Changes

• Added new input parameter: currentStreamVersionProperty with a default value of 'releaseNumberSDK' to maintain backward compatibility
• Updated Maven command: Changed from hardcoded releaseNumberSDK to use the configurable parameter
• Generic naming: Updated temporary file names and comments to reflect the configurable nature

Backward Compatibility

This change is fully backward compatible. Existing workflows that call checkVersions.yml (such as pr-checks.yml) will continue to work without any modifications, as the parameter has a sensible default value.

Usage Examples

Default behavior (uses releaseNumberSDK):

uses: ./.github/workflows/checkVersions.yml
with:
  botName: Eclipse Platform Bot
  botMail: [email protected]

Custom property:

uses: ./.github/workflows/checkVersions.yml
with:
  botName: Eclipse Platform Bot
  botMail: [email protected]
  currentStreamVersionProperty: 'myCustomVersionProperty'

Fixes the issue by making the stream version property configurable while maintaining backward compatibility.

Original prompt

Make releaseNumberSDK configurable parameter in checkVersions.yml

Currently we determine the "releaseNumberSDK" to be used in commit messages by a fixed value, but depending on the project this value might vary.

It would be good to make it configurable e.g. as a currentStreamVersionProperty in the workflow call inputs.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[laeubi]

Looks useful as it at least allows to configure things, having a property in the pom also seems flexible enough for most use-cases.

[HannesWell]

Checking the input is probably not necessary, see my comment below.
Besides that I think this is fine.

[HannesWell]

I'm not sure if this is necessary as this job doesn't have any permissions:

eclipse.platform.releng.aggregator/.github/workflows/checkVersions.yml

Line 30 in 6b119f9

permissions: {} # all none

and with extra-setup-command we have another argument that is also executed as it is.
So this extra check does not really buy us extra safety and therefore I suggest to keep it simple and remove it.

[laeubi]

@copilot please remove the additional validation as per @HannesWell suggestion in #3418 (comment)

[Copilot]

Removed the validation check as requested. The workflow now directly uses the input parameter without validation, consistent with how extra-setup-command is handled. (commit: will be in next message)

[Copilot]

Removed the validation check as requested. The workflow now directly uses the input parameter without validation, consistent with how extra-setup-command is handled. (commit e88bdc5)

[HannesWell]

@laeubi how should we proceed here?

[akurtakov]

What are the plans here? If no one has intention to finish it maybe we should close it?

[laeubi]

I would be fine with remove the validation and merge it then.

[laeubi]

@HannesWell if you are fine with it I'll squash/rebase (or you can do it on your self of course)

[HannesWell]

if you are fine with it I'll squash/rebase (or you can do it on your self of course)

Done it.
I also unified and shortened the variable name a bit to be consistent with the other inputs (lower in the list, the style is already inconsistent :/ ).