Y24-510 - Migrate GitHub actions to shared workflows

[SHIV5T3R]

Description
To streamline development across all repositories and reduce technical debt, we need to migrate our GitHub Actions to shared workflows. This will ensure consistent practices, simplify maintenance, and address issues related to deprecated dependencies. By consolidating these workflows, we aim to enhance efficiency and reduce redundant effort across the organisation.

Acceptance Criteria
The following outputs from the research are produced:

• A comprehensive list of all GitHub Actions in use across repositories that need to be migrated to shared workflows.
• Documentation mapping each action to its purpose, including naming conventions and any repository-specific differences. (Could be worked on in a pair, probably splitting by Github action rather than repo, but communicating)
• Decide the list of shared workflows we want to create (e.g. one for ruby testing, one for building release...)
• Write up the next one or few stories to be done in GitHub (probably to actually create one of the shared workflows), and a rough outline of all the stories we expect. Include mention of testing/validation.

Additional context or information
Some repositories may use unique or highly customised actions that require additional analysis before migration. Shared workflows should be designed to minimise breaking changes while adhering to best practices for security and performance.

It probably won't be possible to do a perfect job. Aim for quick wins (e.g. the action that is used across the most repos) and focus more on actively maintained repos.

An approach could be to filter the table in the spreadsheet to just SS, Limber, Traction, and then work by action - to focus first on the most used repos.

[SHIV5T3R]

https://docs.google.com/spreadsheets/d/1cBvzjzrGaGBk9h8movovWv4EMRmZXaWMk4gglo6FKbs/edit?usp=sharing

[KatyTaylor]

First thing to do - split this into multiple tasks

[KatyTaylor]

Removed the following acceptance criteria in favour of reworded ones:

• A shared workflow template designed to accommodate the most common use cases while allowing for repository-specific overrides if necessary.
• A plan for migrating each repository to the new shared workflows, including testing and validation steps.

[KatyTaylor]

First thing to do - split this into multiple tasks

Shiv and I talked about this today, and decided to leave it as one story, because the acceptance criteria need to be done sequentially, and are probably not fully separate - you'd probably be thinking about doing the third one while doing the second, for instance.

We reworded some of the acceptance criteria to try to make the output clearer and came up with some guidelines (in 'additional context') to mitigate against spending too much time on it.