eclipse-score / eclipse-score/inc_security_crypto

[Improvement] CI/CD: Implement Parallel GitHub Actions Matrix to Build and Test Both SoftHSM and Rust Cryptoki

Open
#179 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
3
Forks
15
Avg merge
1d 13h
Merged PRs (30d)
24

Description

### What

**Description:**

Currently, when S-CORE's CI pipeline runs on GitHub, Bazel executes a wildcard build (bazel test //score/...). S-CORE compiles both the C++ daemon and secure Rust Cryptoki library (libcryptoki.so) successfully.

However, during S-CORE's test execution phase, the C++ daemon boots up under S-CORE's default SoftHSM backend path. S-CORE means:
* The C++ daemon only loads libsofthsm2.so inside the Docker sandbox container.
* The C++ client demo (score_demo) and other integration tests only execute and validate the C++ SoftHSM backend.
* The compiled secure Rust library libcryptoki.so is completely ignored and never physically executed or functionally tested on the CI!

Update S-CORE's GitHub Actions workflow file (.github/workflows/test_linux.yml) to automatically compile, build, and test entire workspace (//score/...) two times on every commit.

**Purpose:**
Because Bazel can only compile one PKCS#11 backend at a time during a single compiler run, S-CORE's parallel matrix allows GitHub Actions to spin up two completely separate virtual machines on the cloud as following:

* VM Runner 1 (SoftHSM path) compiles and tests the default C++ SoftHSM configuration to ensure 100% regression-free backward compatibility.
* VM Runner 2 (Rust path) compiles and tests secure Rust configuration, physically executing actual secure Rust libcryptoki.so library inside SCORE's Docker sandbox container on every commit!

**Note**
At compile-time, the PKCS#11 backend options are strictly mutually exclusive—only exactly one backend library (either libsofthsm2.so OR secure Rust libcryptoki.so) is compiled into the physical target daemon at any given time.
By using the parallel GitHub Actions Matrix, we do NOT try to compile both inside the same binary. Instead, we spin up two completely separate virtual machines on the cloud, compiling and testing one isolated backend per VM. This allows us to verify both build modes concurrently without any compile-time or runtime conflicts!

This concurrent execution mathematically guarantees 100% regression-free coexistence and 100% functional safety across both backends on every commit with zero added delay to S-CORE's pull request pipeline.

### Acceptance Criteria (DoD)

[ ] GitHub Actions test workflow compiles, builds, and tests S-CORE's entire workspace (//score/...) under both SoftHSM and secure Rust backend configurations in parallel, with both runs passing 100% green on every commit.

### How

_No response_

Contributor guide

No contributing guide indexed for this repository

Research direction

Read .github/workflows/test_linux.yml and the existing Bazel invocation for //score/.... Check how the SoftHSM and secure Rust backend selections are currently passed into the build and test steps. Done means the workflow runs isolated matrix jobs for both configurations and both complete the full workspace build and tests successfully.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, docker, github-actions, rust
Domain
build-system, ci-cd, security
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.