Define GitHub Actions and Workflows according to the convention

[vikman90]

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.

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).

Tasks

• Define Actions according to 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.
• Define Workflows according to 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.

Definion of Done

• All required Actions are defined and adhere to the naming convention.
• 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.
• PR workflows are optimized to complete within the 30-minute limit.