Add weekly CI to verify networkd enum sync with systemd

[Copilot]

The networkd module manually replicates C enum definitions from systemd headers (LinkOperationalState, LinkCarrierState, etc.). When systemd changes these enums, monitord silently becomes incompatible.

Changes

• Weekly CI workflow (.github/workflows/systemd-enum-sync.yml)

  • Fetches network-util.h and networkd-link.h from systemd/systemd main branch
  • Runs enum verification tests
  • Triggers on schedule, manual dispatch, or changes to networkd code

• Integration test (tests/systemd_enum_sync.rs)

  • Parses C enum definitions from headers, extracts variant names and integer values
  • Handles enum aliasing (e.g., LINK_CARRIER_STATE_OFF = LINK_OPERSTATE_OFF)
  • Validates 5 enums: AddressState, AdminState, CarrierState, OnlineState, OperState
  • Fails with specific enum/variant mismatch on drift

Example test output when out of sync:

thread 'test_carrier_state_sync' panicked at tests/systemd_enum_sync.rs:191:
assertion failed: CarrierState::off has value 1 in Rust but 2 in systemd

This catches upstream breaking changes before they affect production deployments.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/systemd/systemd/contents/src/libsystemd/sd-network
  • Triggering command: /usr/bin/curl curl -s REDACTED (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Keep enums in sync with systemd</issue_title>
<issue_description>We enumerate the enums here in networkd.rs ... Wonder if we could write some weekly CI to do some C to rust interaction and check we're still in sync.

• Don't want to really have build time C to Rust fun ... plus including systemd header files.

The code now enumerates the header file the structs are in.

Thoughts?</issue_description>

<agent_instructions>Please go and write a test that periodically runs (weekly) to compile and compare the rust structs to the systemd C structs on main.

We should fail so we can add / fix monitord code when systemd upstream changes.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Keep enums in sync with systemd #1

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[cooperlees]

I also guess, fix the enums if out of sync at the moment ... e.g. #105

[cooperlees]

@copilot - rather than parse the C code can we compile it in with rust bindgen and inspect that way?

[Copilot]

I also guess, fix the enums if out of sync at the moment ... e.g. #105

The enum sync test currently passes - all 5 enums (AddressState, AdminState, CarrierState, OnlineState, OperState) match their systemd counterparts. The test will fail automatically when systemd makes changes, alerting us to update monitord.

@copilot - rather than parse the C code can we compile it in with rust bindgen and inspect that way?

I explored using bindgen, but it adds significant complexity:

• Requires clang/libclang at build time
• Systemd headers have complex dependencies (EINVAL, macros, function declarations)
• Would need to extract/clean enum definitions before passing to bindgen

The current manual parsing approach is:

• Self-contained (no build-time dependencies)
• Robust (handles cross-references like CarrierState → OperState)
• Simple (320 lines vs bindgen setup + extraction logic)
• Works reliably

The manual parser effectively does what bindgen would do, but tailored specifically for extracting enum values from these headers.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/cooperlees/monitord/issues/105
  • Triggering command: /usr/bin/curl curl -s REDACTED -shared -fuse-ld=lld -z relro -o int_enum.c248e4e36fd0b157-cgu.0.rcgu.o int_enum.c248e4e36fd0b157-cgu.1.rcgu.o /usr/lib/gcc/x86_64-linux-gnu/13/crtbeginS.o 7hdqa4x546n2041h41h37tddz.rcgu.o lib/�� lib/rustlib/x86_--error-format=json -abbd0d2fab7304af.rlib ib rlib f3513.rlib ea3d83b.rlib 64-REDACTED-linux-gnu/lib/libproc_macro-9bb76dbda537fcf7.rlib (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[cooperlees]

Ok looks a good start.

@copilot explain how these tests are not picked up by normal "cargo test" ci?

I don't want them to fail on PRs and pushes. If that's covered just explain how please.