Migration to a Specific Action

[iThorgrim]

---

Migration to a Specific Action for Compiling mod-eluna

Summary of Changes

This PR introduces a new approach for the build and static analysis process of mod-eluna. Instead of relying on an external repository to handle workflows, we now use dedicated workflows integrated directly into this repository.

This change is driven by several key objectives:

1. Increased Flexibility: Each Lua version (lua51, lua52, lua53, lua54, luajit) can now have its own dedicated workflow. This allows for independent management and better adaptation to the specific requirements of each Lua version.
2. Improved Traceability: By embedding workflows in this repository, it becomes easier to monitor and modify pipelines as needed.
3. Enhanced Reliability: Removing the dependency on an external repository ensures workflows remain functional and accessible, even if the external repository changes or becomes unavailable.

---

Implementation of Workflows for Specific Lua Versions

• Each Lua version can now handled via a dedicated action, which is invoked directly from a corresponding workflow.
• The structure leverages a base action (Build mod-eluna base 🛠️) that handles generic steps such as installing dependencies and caching build artifacts.
• The lua_version input parameter is used to specify the target Lua version for compilation (lua51, lua52, etc.).

Workflow Example

Each dedicated workflow for a Lua version calls the base action with the appropriate parameter. For example:

Workflow for lua51

name: Build mod-eluna with Lua51 🌙

on:
  push:
    branches:
      - 'master'
      - 'main'
  pull_request:

jobs:
  build_lua51:
    uses: ./.github/workflows/core-build-base.yml
    with:
      lua_version: 'lua51'

Workflow for luajit

name: Build mod-eluna with LuaJIT 🌙

on:
  push:
    branches:
      - 'master'
      - 'main'
  pull_request:

jobs:
  build_luajit:
    uses: ./.github/workflows/core-build-base.yml
    with:
      lua_version: 'luajit'

---

Advantages of This Approach

1. Simplified Maintenance: Most of the code for the build process is centralized in the base action. Only specific parameters (like the Lua version) vary in the dedicated workflows.
2. Fixes Cppcheck Issues: Specifically addresses errors caused by macro definitions such as eObjectAccessor() in the mod-eluna codebase.

---

[iThorgrim]

For some reason, the actions in the PR are failing, even though they run perfectly on my repo and branch (see here: Actions on my repo).

[55Honey]

Let's see how it behaves after merge.