Actions and workflows according to convention #545

guidomodarelli · 2025-02-21T20:05:02Z

Description

We need to define and implement GitHub Actions and Workflows following the established naming and usage conventions. This includes setting up Actions for various use cases and designing corresponding Workflows to ensure consistency and efficiency in our CI/CD processes.

Issues Resolved

MVP catch up - testing · Issue #7292 · wazuh/wazuh-dashboard-plugins

Changelog

feat: Update Actions and workflows to according the convention

Convention

Actions

Naming convention

Major: Product major version.
Prefix: Prefixes depicted in the use cases section.
Target: The Action target. It can be a component, module, subsystem, programming language, code analysis tool, etc.

Actions use the following naming convention:

<major>_<prefix>_<target>

Use cases

Actions are meant to cover the following cases:

Code analysis. Every tool used to do code analysis (either static or dynamic).
Action name prefix: codeanalysis
Available targets: code analysis tool.
Name example: 4_codeanalysis_coverity
Linter. Programming language linter or automatic documentation generation.
Action name prefix: codelinter
Available targets: linter.
Name example: 5_codelinter_clangformat
Unit tests.
Action name prefix: testunit
Available targets: module
Name example: 5_testunit_engine
Component tests.
Action name prefix: testcomponent
Available targets: component/module
Name example: 5_testcomponent_indexerconnector
Integration tests.
Action name prefix: testintegration
Available targets: module
Name example: 4_testintegration_cluster
Package builder. Subsystem package builder.
Action name prefix: builderpackage
Available targets: subsystem
Name example: 4_builderpackage_server
Precompiled object builder. Any needed precompiled object.
Action name prefix: builderprecompiled
Available targets: subsystem
Name example: 5_builderprecompiled_agent

Jobs

A job step must be solely comprised of Actions.
A job step cannot contain Actions with different prefixes.
A job step must use matrices whenever possible.

Workflows

Pull Request

PR workflows are run against protected branches. They should not last longer than 30m.

PR workflows are meant to cover the following use cases:

Code quality. All available codeanalysis and linter type of Actions in that repository.
Workflow name prefix: codequality
Available targets: repository
Name example: 4_codequality
Trigger: Any change.
Unit tests.
Workflow name prefix: testunit
Available targets: component/module
Name example: 5_testunit_engine
Trigger: Any change within the target component/module.
Component tests.
Workflow name prefix: testcomponent
Available targets: component/module
Name example: 5_testcomponent_comms-api
Trigger: Any change within the target module.
Integration tests.
Workflow name prefix: testintegration
Available targets: module
Name example: 5_testintegration_management-api
Trigger: Any change within the target module.
Packages.
Workflow name prefix: builderpackage
Available targets: subsystem
Name example: 5_builderpackage_agent
Trigger: Any code change.

Manual (workflow dispatch)

Precompiled.
Workflow name prefix: builderprecompiled
Available targets: subsystem
Name example: 5_builderprecompiled_dashboard
Trigger: Any change requiring new precompilation (mostly related to dependencies changes).

Evidence

For each Wazuh Dashboard repository:

List the existing workflows.
Describe its usage.
Write down if they are from OpenSearch or created by us.
Propose what to do with OpenSearch's workflows: adapt and keep or remove (default).
Fit the workflows we keep (including these created by us) on one of categories described on this issue.
Rename the workflows according to the naming convention defined in this issue.
Configure the workflows to run under the conditions defined in this issue.

Analysis of each workflow if it's convenient to use matrices

.github/workflows
├── 5_builderpackage_wazuh_dashboard.yml              (created by us)
├── 5_builderpackage_wazuh_dashboard_with_plugins.yml (created by us)
├── 5_codequality_codeql.yml                          (created by us)
├── backport.yml                                      (created by OpenSearch)
├── build_and_test_workflow.yml                       (created by OpenSearch)
├── cypress_workflow.yml                              (created by OpenSearch)
├── delete_backport_branch.yml                        (created by OpenSearch)
├── links_checker.yml                                 (created by OpenSearch)
└── opensearch_changelog_workflow.yml                 (created by OpenSearch)

Test

Ensure the Actions is following the specification:
- Ensure the naming convention is followed (<major>_<prefix>_<target>).
- Categorize Actions into the appropriate use cases (code analysis, linters, tests, builders).
- Ensure that job steps only contain Actions with the same prefix and use matrices whenever possible.
Ensure the Workflows is following the specification:
- Use the correct workflow naming prefix based on its purpose.
- Define appropriate triggers for each workflow (PR workflows or manual dispatch).
- Ensure PR workflows do not exceed the 30-minute execution limit.
- Workflows are implemented and correctly triggered based on repository changes.
- Job steps within workflows are structured correctly, following the prefix restrictions and using matrices where applicable.

Check List

All tests pass
- yarn test:jest
- yarn test:jest_integration
New functionality includes testing.
New functionality has been documented.
Update CHANGELOG.md
Commits are signed per the DCO using --signoff

This reverts commit 7555b88.

Changes workflow references to use specific manual build configurations for main plugins, security plugin, and reporting plugin. Ensures consistency in build processes across different plugins.

Adds comments to explain various steps in the Wazuh dashboard build workflow. Includes details on customization options, setup, validation, and build processes. Improves maintainability and clarity of the workflow configuration.

Eliminates the 30-minute timeout settings from various GitHub workflow jobs to allow for longer execution times and prevent premature job termination.

Enhances documentation for build automation workflows: - Adds detailed description for the Wazuh dashboard build process - Refines formatting and readability of dashboard with plugins workflow

Improves documentation within the CodeQL workflow configuration file to provide clearer instructions and highlight important notes for customization and language detection.

guidomodarelli · 2025-02-25T17:54:13Z

Analysis of each workflow if it's convenient to use matrices

`5_builderpackage_wazuh_dashboard.yml`

🔍 Is it possible to use matrices with the existing workflow?

Yes, it is possible to use matrices.

📝 Why?

Existing matrix configuration:
The workflow uses a matrix for DISTRIBUTION (currently with only tar.gz). This matrix is designed to generate packages for different formats in parallel. While minimal today, it’s structured to scale.

⚖️ Does it make sense to expand the matrix?

Current setup is fine:
If only tar.gz is needed, the existing configuration is sufficient. However, the matrix structure is already optimized for scalability.

💡 Conclusion

✅ The matrix strategy is already used effectively for DISTRIBUTION.

`5_codequality_codeql.yml`

🔍 Is it possible to use matrices with the existing workflow?

Yes, it is possible to use matrices, and it already makes sense in this case.

📝 Why?

Existing matrix configuration:
The workflow uses a matrix to specify which languages to analyze. Currently, it only includes JavaScript ('javascript'), but you can easily add additional languages (e.g., python, java, go) in the matrix if you want to analyze multiple languages in parallel.

⚖️ Does it make sense to expand the matrix?

Potential expansions:
- If the project uses more languages, you can expand the matrix to include other supported languages like python, java, go, etc. This would trigger a separate CodeQL analysis job for each language in parallel, speeding up the process.
- Example:
```
matrix:
  language: ['javascript', 'python', 'java']
```
Current setup is fine:
If your project is currently focused only on JavaScript/TypeScript (as implied by the setup), keeping the matrix with just 'javascript' is perfectly fine and efficient.

💡 Conclusion

✅ The matrix strategy is already used effectively here.
You can expand it with more languages if necessary, but for now, the current configuration is sufficient and logical for JavaScript-based analysis.

Desvelao · 2025-02-27T11:16:51Z

.github/workflows/5_builderpackage_wazuh_dashboard.yml

suggestion: For the wazuh repository, they do not use wazuh in the workflow filename: https://github.com/wazuh/wazuh/pull/28233/files, so we could only keep the stack component instead (dashboard).

suggestion: We could reference to dashboard_core in this workflow.

Desvelao · 2025-02-27T11:17:17Z

.github/workflows/5_builderpackage_wazuh_dashboard.yml

@@ -1,6 +1,14 @@
 # This is a basic workflow that is manually triggered
+#
+# This workflow automates the build of Wazuh Dashboard for different


Suggested change

# This workflow automates the build of Wazuh Dashboard for different

# This workflow automates the build of Wazuh dashboard core for different

Desvelao · 2025-02-27T11:17:58Z

.github/workflows/5_builderpackage_wazuh_dashboard.yml

+# - Clones, configures, builds and packages the Wazuh Dashboard.
+# - Is customizable in architecture and reference (`branch/tag/commit`).
+# - Uploads the final package with a structured name.


Suggested change

# - Clones, configures, builds and packages the Wazuh Dashboard.

# - Is customizable in architecture and reference (`branch/tag/commit`).

# - Uploads the final package with a structured name.

# - Clone, configure, build and package the Wazuh dashboard core.

# - Customizable in architecture and reference (`branch/tag/commit`).

# - Upload the final package with a structured name.

Desvelao · 2025-02-27T11:18:52Z