ci: if test core dumps, upload dump as build artifact

[lklimek]

Issue being fixed or feature implemented

When tests are killed, we want to be able to retrieve core dump and affected binary to investigate

What was done?

Extended test workflow to upload core dump and binary to github artifacts.

How Has This Been Tested?

https://github.com/dashpay/platform/actions/runs/20302691431

Breaking Changes

None

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

Summary by CodeRabbit

Chores

• Enhanced CI/testing infrastructure to improve crash handling and diagnostics with automated artifact collection and retention for test failures.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This change enhances the CI workflow by adding crash dump handling to test execution. The workflow configures the system to capture core dumps on test failure, collects related crash artifacts and binaries, and uploads them for debugging purposes.

Changes

Cohort / File(s)	Summary
CI crash artifact collection \.github/workflows/tests-rs-package\.yml	Configures core dump capture before tests by creating /cores directory and setting core_pattern. Extends test execution to enable unlimited core dump size via ulimit. Adds new steps to collect crash artifacts (core dumps, binaries, dSYM files) into a zip archive on test failure, and uploads the artifact with 3-day retention. Gracefully handles scenarios where no core files are generated.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• Single-file modification with straightforward workflow step additions
• Core dump setup involves standard system configuration commands
• Artifact collection and upload logic follows common CI patterns
• Primary attention: verify system setup paths, ulimit compatibility across OS, and artifact retention settings align with project requirements

Poem

🐰 A rabbit bounces through the CI,
When crashes happen, we don't cry!
Core dumps collected, zipped up tight,
Artifacts saved for debug delight! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and clearly summarizes the main change: adding CI workflow logic to upload core dumps as build artifacts when tests fail.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch build/core-dumps

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

.github/workflows/tests-rs-package.yml (2)

201-206: Consider more restrictive permissions for /cores directory.

While 777 permissions work in this CI container environment, it's overly permissive. Consider using 755 or 775 instead to follow the principle of least privilege.

Apply this diff to use more restrictive permissions:

       - name: Configure core dumps
         run: |
           sudo mkdir /cores
-          sudo chmod 777 /cores
+          sudo chmod 755 /cores
           # Core filenames will be of the form executable.pid.timestamp:
           sudo bash -c 'echo "/cores/%e.%p.%t" > /proc/sys/kernel/core_pattern'

---

246-251: dSYM files are macOS-specific but workflow runs on Linux.

The script collects .dSYM files, which are macOS debug symbols, but this workflow runs on ubuntu-24.04. While harmless, this check is unnecessary on Linux. The .dwp files are the appropriate debug symbol format for Linux.

Apply this diff to remove unnecessary macOS-specific debug symbol handling:

-          for extra in target/debug/deps/${BIN_PREFIX}-*.dSYM target/debug/${BIN_PREFIX}.dSYM \
-                      target/debug/deps/${BIN_PREFIX}-*.dwp target/debug/${BIN_PREFIX}.dwp; do
+          for extra in target/debug/deps/${BIN_PREFIX}-*.dwp target/debug/${BIN_PREFIX}.dwp; do
             if [[ -e "$extra" ]]; then
               cp -a "$extra" "${ARTIFACT_DIR}/binaries/"
             fi
           done

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 45111c4 and 3521cc9.

📒 Files selected for processing (1)

• .github/workflows/tests-rs-package.yml (1 hunks)

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: lklimek
Repo: dashpay/platform PR: 2318
File: .github/workflows/tests-build-image.yml:45-45
Timestamp: 2024-11-13T10:31:30.891Z
Learning: In the dashpay/platform repository, changes to `.github/workflows/tests-build-image.yml` that switch the Docker image platform from `linux/arm64` to `linux/amd64` for testing purposes are acceptable when required to run on GitHub-hosted runners. ARM64 testing is covered on the testnet.

📚 Learning: 2024-11-08T09:27:23.601Z

Learnt from: lklimek
Repo: dashpay/platform PR: 2316
File: .github/actions/librocksdb/action.yaml:22-28
Timestamp: 2024-11-08T09:27:23.601Z
Learning: Prefer to use `librocksdb/${{ inputs.version }}/${{ runner.os }}/${{ runner.arch }}` as the cache key for caching librocksdb in workflows; it's sufficient.

Applied to files:

• .github/workflows/tests-rs-package.yml

🔇 Additional comments (2)

.github/workflows/tests-rs-package.yml (2)

209-211: LGTM!

The ulimit configuration correctly enables unlimited core dump generation, which is essential for capturing crash information when tests fail.

---

255-264: LGTM!

The artifact upload configuration is well-designed with appropriate retention period, graceful handling of missing files, and helpful usage documentation.

[QuantumExplorer]

Don't we need something that cleans these up from time to time?