ocpp-client 0.2.1

OCPP Client Implementation. Use this library to implement an OCPP charge point
Documentation
name: CI

on:
  push:
    branches: [main]
  pull_request:

env:
  CARGO_TERM_COLOR: always

jobs:
  fmt:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
        with:
          components: rustfmt
      - name: Check formatting
        run: cargo fmt --all -- --check

  clippy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
        with:
          components: clippy
      - uses: Swatinem/rust-cache@v2
      - name: Clippy (all targets, all features)
        run: cargo clippy --all-targets --all-features -- -D warnings

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
      - uses: Swatinem/rust-cache@v2
      - name: Build (default features)
        run: cargo build
      # `--features test` adds the wait_for_* tests (see tests/ocpp_1_6_wait_for.rs) on top of
      # the default feature set - a plain `cargo test` never runs them.
      - name: Test (default features + test)
        run: cargo test --features test

  no_std:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
      - uses: Swatinem/rust-cache@v2
      # Standing proof that the engine builds without std/tokio for embedded targets. See
      # CLAUDE.md's "no_std+alloc works now" section - re-check this whenever client.rs,
      # transport.rs, error.rs, or a per-version error.rs/actions.rs changes. `-p ocpp-client`
      # is explicit (not just relying on default-members) so this keeps working even if
      # default-members ever changes.
      - name: no_std+alloc build (ocpp_1_6)
        run: cargo build -p ocpp-client --lib --no-default-features --features ocpp_1_6
      - name: no_std+alloc build (ocpp_2_0_1)
        run: cargo build -p ocpp-client --lib --no-default-features --features ocpp_2_0_1
      - name: no_std+alloc build (ocpp_2_1)
        run: cargo build -p ocpp-client --lib --no-default-features --features ocpp_2_1

  embedded:
    runs-on: ubuntu-latest
    # `RUSTFLAGS` reproduces the `--cfg getrandom_backend="custom"` a real firmware binary sets
    # in its own .cargo/config.toml (see crates/ocpp-transport-embassy-net's README) - without
    # it, `uuid`'s `v4` feature drags in `getrandom`, which has no backend for bare-metal
    # thumbv7em-none-eabihf and fails the build before reaching this workspace's own code.
    env:
      RUSTFLAGS: --cfg getrandom_backend="custom"
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
        with:
          targets: thumbv7em-none-eabihf
          components: clippy
      - uses: Swatinem/rust-cache@v2
      # ocpp-transport-embassy-net is chip-agnostic - check/clippy against the real embedded
      # target, not just the host (which its own presence in default-members already covers via
      # the `test`/`clippy` jobs above).
      - name: ocpp-transport-embassy-net check (thumbv7em-none-eabihf)
        run: cargo check -p ocpp-transport-embassy-net --target thumbv7em-none-eabihf
      - name: ocpp-transport-embassy-net clippy (thumbv7em-none-eabihf)
        run: cargo clippy -p ocpp-transport-embassy-net --target thumbv7em-none-eabihf -- -D warnings
      # ocpp-board-stm32h723-nucleo is a real firmware binary - `build` (not just `check`) so a
      # full link happens, catching link-time-only failures like a missing
      # __getrandom_v03_custom custom-backend symbol that `check`/`clippy` alone can't see.
      - name: ocpp-board-stm32h723-nucleo build (thumbv7em-none-eabihf, full link)
        run: cargo build -p ocpp-board-stm32h723-nucleo --target thumbv7em-none-eabihf
      - name: ocpp-board-stm32h723-nucleo clippy (thumbv7em-none-eabihf)
        run: cargo clippy -p ocpp-board-stm32h723-nucleo --target thumbv7em-none-eabihf -- -D warnings