63d664b9fb
Updates the GitHub Actions workflow concurrency configuration to allow
parallel execution of workflows on the `develop` branch while
maintaining cancellation behavior for other branches.
## Problem
Previously, all workflow runs were subject to cancellation when new
commits were pushed to the same branch (`cancel-in-progress: true`).
This caused issues on the `develop` branch where important CI runs could
be prematurely cancelled, potentially missing critical feedback on the
main development branch.
## Solution
Modified the `concurrency` settings in `.github/workflows/build.yml` to
use separate concurrency groups and conditional cancellation:
```yaml
concurrency:
# Use separate concurrency groups for develop vs other branches to prevent cross-cancellation
group: ${{ github.workflow }}-${{ github.ref }}-${{ github.ref == 'refs/heads/develop' && github.run_number || 'branch' }}
cancel-in-progress: ${{ github.ref != 'refs/heads/develop' }}
```
## Behavior
- **`develop` branch**: Each run gets its own concurrency group (using
`run_number`), allowing parallel execution without cancellation or
queuing delays
- **All other branches**: Shared concurrency group with
`cancel-in-progress: true` - workflows are cancelled when new commits
are pushed
This ensures that the `develop` branch can run multiple workflows in
parallel without interference while still providing the efficiency
benefits of workflow cancellation on feature branches and pull requests.
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 Share your feedback on Copilot coding agent for the chance to win a
$200 gift card! Click
[here](https://survey.alchemer.com/s3/8343779/Copilot-Coding-agent) to
start the survey.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: kuznetsss <15742918+kuznetsss@users.noreply.github.com>
Co-authored-by: mathbunnyru <12270691+mathbunnyru@users.noreply.github.com>
Clio
Clio is an XRP Ledger API server optimized for RPC calls over WebSocket or JSON-RPC. It stores validated historical ledger and transaction data in a more space efficient format, and uses up to 4 times less space than rippled.
Clio can be configured to store data in Apache Cassandra or ScyllaDB, enabling scalable read throughput. Multiple Clio nodes can share access to the same dataset, which allows for a highly available cluster of Clio nodes without the need for redundant data storage or computation.
📡 Clio and rippled
Clio offers the full rippled API, with the caveat that Clio by default only returns validated data. This means that ledger_index defaults to validated instead of current for all requests. Other non-validated data, such as information about queued transactions, is also not returned.
Clio retrieves data from a designated group of rippled nodes instead of connecting to the peer-to-peer network.
For requests that require access to the peer-to-peer network, such as fee or submit, Clio automatically forwards the request to a rippled node and propagates the response back to the client. To access non-validated data for any request, simply add ledger_index: "current" to the request, and Clio will forward the request to rippled.
Note
Clio requires access to at least one
ripplednode, which can run on the same machine as Clio or separately.
📚 Learn more about Clio
Below are some useful docs to learn more about Clio.
For Developers:
For Operators:
General reference material:
🆘 Help
Feel free to open an issue if you have a feature request or something doesn't work as expected. If you have any questions about building, running, contributing, using Clio or any other, you could always start a new discussion.