Closed AlexRuiz7 closed 1 week ago
We'll use the 1st approach:
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.
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
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 thewazuh-indexer-plugins
to automate the process, accompanied by the correspondingbuild.sh
script.We are currently discussing a few ways to integrate the plugins into the Wazuh Indexer build process:
build.yml
workflow fromwazuh-indexer
'sbuild.yml
wazuh-indexer
'sbuild.yml
from plugin'sbuild.yml
(inversion of dependencies: the parent workflow receives the zip's URL as parameter).Tasks