Research how to integrate plugin's packaging into wazuh-indexer's workflow

[AlexRuiz7]

Description

As we are going to develop plugins for Wazuh Indexer, we need to define the process to build packages for these plugins, and how we are going to automate and integrate it into the current Wazuh Indexer build workflow.

The plugins are distributed as a zip, as a result of the ./gradlew build command. Independently of how we integrate the plugins into the Wazuh Indexer build, it is clear that we'll need a workflow in the wazuh-indexer-plugins to automate the process, accompanied by the corresponding build.sh script.

We are currently discussing a few ways to integrate the plugins into the Wazuh Indexer build process:

• Invoking the plugin's build.yml workflow from wazuh-indexer's build.yml
• Invoking the wazuh-indexer's build.yml from plugin's build.yml (inversion of dependencies: the parent workflow receives the zip's URL as parameter).
• Using Maven + GitHub Packages.
• Uploading the plugin's zip to Wazuh's development artifactory.

Tasks

• Provide more approaches, if possible.
• Explore these approaches, providing pros and cons for each of them.
• Conclusions
• Further steps: initial design and development.

[AlexRuiz7]

We'll use the 1st approach:

• Invoking the plugin's build.yml workflow from wazuh-indexer's build.yml

The main drawback of this method is that, as we are invoking an Action from another repo, it is required to specify its version explicitly. This can lead to issues where the caller and the called Actions use different versions.

  build-security-plugin:
    needs: [validate-inputs]
    name: Build security plugin
    uses: wazuh/wazuh-security-dashboards-plugin/.github/workflows/manual-build.yml@4.9.0
    with:
      reference: ${{ inputs.reference_security_plugins }}

However, this seems like the most simple and straightforward method, and is already in use in the wazuh-dashboard fork.

[AlexRuiz7]

We've seen issues following this approach on Wazuh Dashboard, during the alpha-1 phase.

Invalid workflow file:  .github/workflows/build_wazuh_dashboard_with_plugins.yml#L120 error parsing called workflow ".github/workflows/build_wazuh_dashboard_with_plugins.yml" -> "wazuh/wazuh-security-dashboards-plugin/.github/workflows/manual-build.yml@v4.9.0-alpha1" (source tag with sha:e6885dd500bb7e5a463ca1519c5b0ad40fa3fbd9) --> "./.github/workflows/dev-environment.yml" : workflow was not found. See https://docs.github.com/actions/learn-github-actions/reusing-workflows#access-to-reusable-workflows for more information.

Apparently, annotated tags cannot be used as they have their own SHA key, do they don't share the SHA of the commit they point to.

Basically, lightweight tags are just pointers to specific commits. No further information is saved; on the other hand, annotated tags are regular objects, which have an author and a date and can be referred because they have their own SHA key.

We need to have this in mind. See https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations