chore(nix): add development shell and CI#2128
Conversation
Provide a Nix flake devshell so contributors can get a reproducible environment (rustc, cargo, rustfmt, clippy, cbindgen, cmake, autotools) without manual setup. The Rust toolchain is read from the existing rust-toolchain.toml via the rust-overlay input, so the devshell tracks the same channel as CI and rustup.
Mirror the CODEOWNERS convention already used in dd-trace-rb and libdatadog-rb so the Nix guild reviews changes to the development shell alongside the existing tooling owners.
Add a GitHub Actions workflow that enters the Nix development shell and builds the workspace on Linux (x86_64, aarch64) and macOS (arm64), mirroring the Nix CI in dd-trace-rb and libdatadog-rb. This guards the devshell against bit-rot so contributors relying on it keep a working, toolchain-pinned environment. Co-own the workflow with the Nix guild.
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 7b00da3 | Docs | Datadog PR Page | Give us feedback! |
The stdenv cc-wrapper injects -D_FORTIFY_SOURCE, which glibc rejects when compiling without optimization. spawn_worker's build script compiles its trampoline.c at -O0 with -Werror, turning the fortify #warning into a hard error and breaking a workspace build inside the devshell. Disable fortify hardening so these C build steps succeed.
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: efca305b12
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: efca305b12
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
The devshell is a rarely-changing safeguard, so gating every pull request on it is unnecessary. Drop the blanket pull_request trigger and keep the workflow on main and mq-working-branch-* pushes; devshell breakage will still surface in the main pipeline.
Keep the devshell guard responsive to changes that actually affect it: run on pull requests that modify the Nix files (paths mirror the Nix CODEOWNERS entries), rust-toolchain.toml (read by the flake), or this workflow.
Add a non-default `.#nightly` devshell built from ./nightly-toolchain.toml (via rust-overlay's fromRustupToolchainFile), for the workflows that need a nightly compiler. Factor the shared shell definition into mkDevShell so default and nightly only differ by toolchain.
|
Do you know what are those Test Nix / test report jobs, or where they are coming from? They have no logs and a Windows one doesn't make sense 
|
Interesting. I'm not sure, let me look that up. |
ekump
left a comment
ekump
left a comment
There was a problem hiding this comment.
Left a few nit comments, but I'm not a nix guy so not sure how relevant they are.
LGTM after we add a little bit of documentation and add a concurrency group for the workflow.
lloeki
left a comment
lloeki
left a comment
There was a problem hiding this comment.
Thanks for the astute reviews! Will address.
|
Ok so I looked up the
|
| push: | ||
| branches: | ||
| - main | ||
| - mq-working-branch-* |
There was a problem hiding this comment.
| push: | |
| branches: | |
| - main | |
| - mq-working-branch-* | |
| # Nightly safeguard: catches devshell drift from changes that don't match the | |
| # paths above (e.g. a dependency or build-script change that needs new native | |
| # tooling). Scheduled runs only fire from the default branch, against its HEAD. | |
| schedule: | |
| - cron: "0 4 * * *" # daily at 04:00 UTC |
There was a problem hiding this comment.
Instead of triggering it in every PR I think it would be better to have a nightly schedule. That way we can save some capacity for the actual pipelines.
There was a problem hiding this comment.
But wouldn't you want to check tings on PRs that change Nix files at least?
There was a problem hiding this comment.
Definitely.
As is it's not going to trigger in every PR anyway, only those that change nix files or that have an impact on nix (the toolchain files).
The schedule can be nice though as a sanity check for when those don't change often.
There was a problem hiding this comment.
But as I undestand the workflow, the job will be executed whenever any of the files involved is modified as in:
pull_request:
paths:
- "*.nix"
- "flake.*"
- "rust-toolchain.toml"
- ".github/workflows/nix.yml"
Then it will be executed nightly as a safe guard so I think there's no need to trigger it in every PR on the mq/main.
There was a problem hiding this comment.
Yes for pull requests, but not for pushes to main (e.g merge commit) or merge queue (so it will not fire and maybe fail a possible required check constraint; I'm not sure of MQ behaviour here)
If that's acceptable then it can be removed.
|
Hey I wanted to suggest many small changes (mostly styling/preferences), I created a stacked PR instead because it got too large |
|
@Eldolfin thanks for the suggestions over there. I take it you made a separate PR because of the formatting. I've swallowed a few of the tiny interesting cleanup bits in this PR. To expedite this PR, I will leave the formatting and rust tooling decisions to be addressed on a subsequent PR, which you'll be able to resolve without my involvement. |
5 participants
What does this PR do?
Adds a Nix flake development shell to the repository, with a CI workflow that exercises it.
flake.nix/flake.lock: a devshell providing the Rust toolchain (rustc, cargo, rustfmt, clippy), cbindgen, cmake and autotools. The Rust toolchain is pinned via theoxalica/rust-overlayinput reading the existingrust-toolchain.toml, so the devshell tracks the same channel as CI and rustup..github/workflows/nix.yml: enters the devshell and builds the workspace on Linux (x86_64, aarch64) and macOS (arm64), mirroring the Nix CI already present in dd-trace-rb and libdatadog-rb.CODEOWNERS: co-owns the Nix files and workflow with the Nix guild.Motivation
Contributors using Nix previously kept these files locally and unshared, with the Rust version floating with the nixpkgs channel (currently 1.91.1) rather than matching the toolchain libdatadog is built with. Committing a pinned devshell gives a reproducible, low-setup environment, and the CI guard keeps it from bit-rotting.
Additional Notes
The pin derives from
rust-toolchain.toml(single source of truth), so a future MSRV bump updates the devshell automatically.AI was used to accelerate implementation; all code was reviewed and understood.
How to test the change?
nix develop --command cargo build --workspace --exclude builder, and confirmnix develop --command rustc --versionreports the channel fromrust-toolchain.toml. CI runs the same build across the three platforms.