Add module_template_rollout job in workflow

[Subramanian-K812]

A new job module_template_rollout has been added to _local_daily.yml.

What the job does

Runs daily (and on manual trigger). For each eclipse-score repo that has a
.bazelversion file:

1. Reads the current .bazelversion from eclipse-score/module_template
2. Compares it against each repo's version
3. If outdated: creates a branch, commits the updated version, opens a PR

Testing

Tested manually using workflow_dispatch with target_repo input, targeting
qorix-group/reference_integration (.bazelversion = 8.4.2).

The job correctly detected the gap vs template (8.6.0) and opened a PR:
→ qorix-group/reference_integration#16

[FScholPer]

We should not build workflows for single update sync. I would propose to utilize a single workflow for template sync like the one I created some time ago:https://github.com/eclipse-score/cicd-workflows/blob/main/.github/workflows/template-sync.yml. @AlexanderLanin any thoughts on this?

[AlexanderLanin]

@FScholPer thats kind of exactly the point on how to roll this out. It seems we have some options, and either we make a full fledged DR or we discuss it next Monday in infrastructure meeting?!

My current thought process:

• we can put it into the template, and "all repos" therefore get it once somehow. Then they do self update. We end up maintaining 20+ self update workflows.
• to make life easier for infrastructure team a push approach (like renovate) is easier, as all config is in a single place.
• but then it doesn't belong into the module_template repository, as we dont want modules to have copies of that workflow. It shall be in a single place.
• therefore cicd-workflows, as thats the best matching such place

[AlexanderLanin]

Is ahmadnassri/action-template-repository-sync a viable + good option for this workflow? (Just asking, not suggesting)

Update: no, it relies on proper template usage. Half our modules use the template without "using" it.

[AlexanderLanin]

Review:

• this PR solves the problem statement perfectly.
• Will probably require slight fiddling to pass ECA check
• We need prettier PR descriptions ;-)

Open points to discuss:

• General approach (workflow in this repo?)
• Generic approach (solve current problem vs solve all sync problems)

[AlexanderLanin]

Gap: if some repository rejects the PR, they should not get the same one on the next day.

[github-actions]

Thanks for the pull request. This thread has been quiet for 30 days, so we are marking it as stale for now. Please take a quick look and let us know whether it is still up to date, still relevant, needs review, or is ready to merge. Any new activity will remove the stale label automatically. If nothing changes in the next 10 days, we will close it to keep the backlog current.