use shard lib on github action ubuntu

[antonvw]

PR Type

Enhancement

---

Description

• Remove build flag -b from build script invocation

• Change artifact upload from static libraries to shared libraries

• Align Ubuntu CI workflow with shared library usage pattern

---

Diagram Walkthrough

flowchart LR
  A["Build Configuration"] -->|Remove -b flag| B["Shared Library Build"]
  C["Artifact Collection"] -->|Change .a to .so| D["Shared Library Artifacts"]
  B --> E["Ubuntu CI Pipeline"]
  D --> E

Loading

File Walkthrough

	Relevant files
Configuration changes	ci-ubuntu.yml Switch to shared libraries in Ubuntu CI                                    .github/workflows/ci-ubuntu.yml Removed -b flag from build-gen.sh invocation to disable static library build Changed artifact upload pattern from build/**/*.a to build/**/*.so for shared libraries Maintains boost root configuration and compiler environment variables +2/-2

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟢	🎫 #1170 🟢 Update Ubuntu CI/build to use shared libraries instead of static libraries. Adjust build script invocation accordingly (remove static-library-specific flags). Update artifact collection to upload shared library outputs.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Use a valid action version Correct the actions/upload-artifact version from @v6 to a valid one, such as @v4, to prevent workflow failure. .github/workflows/ci-ubuntu.yml [103-110] - name: Artifacts - uses: actions/upload-artifact@v6 + uses: actions/upload-artifact@v4 with: name: wex-lib-ubuntu path: | data/*.* build/**/*.so build/**/setup.h [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 10 __ Why: The suggestion correctly identifies that actions/upload-artifact@v6 is an invalid version, which would cause the workflow to fail. Applying this change is critical for the CI pipeline to succeed.	High
General	Explicitly enable shared build Add the -s flag to the build-gen.sh command to explicitly request a shared library build. .github/workflows/ci-ubuntu.yml [97] -run: ./build-gen.sh -g -B ${{steps.install-boost.outputs.BOOST_ROOT}} +run: ./build-gen.sh -s -g -B ${{steps.install-boost.outputs.BOOST_ROOT}} Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion improves the build command by making the intent to build shared libraries explicit with the -s flag, which enhances clarity and robustness, ensuring the script behaves as expected.	Medium
	Expand shared library pattern Change the artifact path pattern from build//.so to build/**/.so* to ensure versioned shared library files are also uploaded.** .github/workflows/ci-ubuntu.yml [109] -build/**/*.so +build/**/*.so* Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion correctly points out that shared libraries can be versioned (e.g., .so.1), and using build/**/*.so* ensures these files are included in the artifact, making the process more robust.	Low
	Ensure artifacts always upload Add if: always() to the artifact upload step to make it run even if previous steps in the job fail. .github/workflows/ci-ubuntu.yml [103-104] - name: Artifacts + if: always() uses: actions/upload-artifact@v6 [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 3 __ Why: The suggestion proposes a valid workflow pattern (if: always()) for debugging purposes, but it changes the logic to upload artifacts even on build failure, which may not be the intended behavior for a CI pipeline.	Low
More

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud