You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the process to generate wazuh-indexer packages is split in two phases, build and assembly. While the build process consists of compiling the Java source code of indexer and bundling it alone into a package (deb, rpm or tar), the assembly process takes this bundle as input, extracts it, includes plugins and configurations and bundles it back as the final package ready to deliver.
The goal of this issue is to unify the process into a single step by using a Dockerfile that wraps both processes, making it transparent to the final user.
Although this is of great interest for bundling wazuh-indexer packages locally, I think our current process in GitHub Actions already fits this use case as it's all done in one run, so we can leave that untouched.
To summarize, the process to build packages locally must be improved to reduce user interaction as much as possible.
Functional requirements
The build process clones and builds our plugins before building indexer.
The build process clones and build wazuh-indexer.
Packages are assembled with plugins, indexer and configuration files.
Implementation restrictions
Use Docker to wrap all the process to build packages.
Apart from Docker, no additional dependencies are required.
Packages can be built using a one-line command: docker run <image> <args>
Plan
Generate Docker images to build and assembly wazuh-indexer packages (existing ones can be reused).
Build Wazuh Indexer plugins automatically.
Generate a GitHub workflow to build and push the Docker images.
Completed an initial working version of the build process Dockerfile. The build process requires two different steps, the image building, and the container execution.
There are two reasons for this approach, one is to make the image more lightweight by separating the system setup and provision from the build process execution, and the other is to be able to use volume that can be externally defined at the run stage, in which the resulting package will be stored.
Example usage:
Build Docker image
cd docker/builder && docker build -t wazuh-indexer-builder .&&cd ../..
If the command is being executed from another directory, such as the repository root, it should be ran this: docker build -t builder -f docker/builder/image/Dockerfile docker/builder/image/
Execute the builder container
docker run --rm -v ./artifacts/dist:/home/indexer/artifacts wazuh-indexer-builder
Description
Currently, the process to generate wazuh-indexer packages is split in two phases, build and assembly. While the build process consists of compiling the Java source code of indexer and bundling it alone into a package (deb, rpm or tar), the assembly process takes this bundle as input, extracts it, includes plugins and configurations and bundles it back as the final package ready to deliver.
The goal of this issue is to unify the process into a single step by using a Dockerfile that wraps both processes, making it transparent to the final user.
Although this is of great interest for bundling wazuh-indexer packages locally, I think our current process in GitHub Actions already fits this use case as it's all done in one run, so we can leave that untouched.
To summarize, the process to build packages locally must be improved to reduce user interaction as much as possible.
Functional requirements
Implementation restrictions
docker run <image> <args>
Plan
Take https://github.com/wazuh/wazuh/actions as reference.
The text was updated successfully, but these errors were encountered: