Move shared workflows into folder '.github/workflows/shared'

[HannesWell]

We have more and more GH workflows in this repository that are shared with other repos.
While this is good from a unification POV, it becomes more and more difficult to distinguish which workflow is a shared one and which workflow is just used in this repository.

Therefore this PR proposes to move all shared workflows into a sub-folder named shared, in in order to helps to distinguish workflows shared with and called from other repositories and workflows only used in this repository.

If we have consensus on this change I can create corresponding PRs to adapt all calling projects in the SDK.
This would also be a good opportunity to rename workflows if we think there current name does not fit.

[HeikoKlare]

This is a good idea! For me, it would also help to give more structure to the shared workflows, i.e., to better separate them by purpose. So would it make sense to take the chance and also give the shared workflows more structure (e.g., by placing them in further subfolders)? Would probably be a good point in time since we need to touch consumers anway.

One proposal (without thinking much about it, so feel free to propose something else):

• prerequisites containing the freeze period verification, merge commit checks etc.
• updates containing the target and release update workflows
• verification containing the build and test publish worklows

[laeubi]

https://docs.github.com/en/actions/sharing-automations/reusing-workflows says:

As with other workflow files, you locate reusable workflows in the .github/workflows directory of a repository. Subdirectories of the workflows directory are not supported.

See also

• https://github.com/orgs/community/discussions/18055

If anything is unclear we have:

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/.github/workflows/README.MD

that hopefully explains the what and how and can be structured of course.

I can create corresponding PRs to adapt all calling projects in the SDK

Please keep in mind that they are used elsewhere (e.g. Tycho, m2e, jdt.ls...) so renaming them can have an undesirable impact on an unknown number of projects maybe.