feat: support build backend secrets by wolfv · Pull Request #6101 · prefix-dev/pixi

wolfv · 2026-05-12T19:39:09Z

Description

Adds a secrets list to [package.build] so manifests can declare environment variables that should be exposed to the build script as secrets, mirroring rattler-build's build.script.secrets.

[package.build]
backend = { name = "pixi-build-rust", version = "*" }
secrets = ["CARGO_REGISTRY_TOKEN", "SCCACHE_BUCKET"]

Motivation: in the rattler-build recipe execution we restrict env access by default. This gives package authors a way to opt specific env vars through, without putting secret values in the manifest. Useful for credentials such as GH_TOKEN, registry tokens, sccache config, etc.

How Has This Been Tested?

Snapshots updated and TOML parsing tests added.

AI Disclosure

This PR contains AI-generated content.
- I have tested any AI-generated content in my PR.
- I take responsibility for any AI-generated content in my PR.

Tools: Claude (Claude Code)

Checklist:

I have performed a self-review of my own code
I have made corresponding changes to the documentation
I have added sufficient tests to cover my changes.

Add a `secrets` list to `[package.build]` so the manifest can declare environment variables that should be exposed to the build script as secrets. Names flow from the manifest into the `ProjectModel` sent to the build backend; the intermediate backend then merges them into the generated recipe's `build.script.secrets`, where rattler-build performs the host-environment passthrough at build time. Only names cross the wire — values are looked up by rattler-build from the host environment during the build, so no secret material is serialized in protocol messages or build records. Example: [package.build] backend = { name = "pixi-build-rust", version = "*" } secrets = ["CARGO_REGISTRY_TOKEN", "SCCACHE_BUCKET"]

https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

wolfv · 2026-05-13T05:57:23Z

@ruben-arts thoughts? This came from Wintermute having issues using gh inside the build as we restricted the env access in rattler-build recipe execution.

ruben-arts · 2026-05-13T05:59:47Z

If it works the same as rattler-build I'm all for it!

wolfv · 2026-05-13T06:13:41Z

Yeah teh biggest question is where to put the config in the [package] toml.

baszalmstra · 2026-05-13T07:52:07Z

+fn merge_project_secrets(script_secrets: &mut Vec<String>, project_secrets: &[String]) {
+    for name in project_secrets {
+        if !script_secrets.iter().any(|existing| existing == name) {
+            script_secrets.push(name.clone());
+        }
+    }
+}


I dont think this is correct. The secrets are part of the project model, so the backend should have added the secrets when generating the initial recipe.

baszalmstra · 2026-05-13T07:53:18Z


        let build_string_prefix = th.optional("build-string-prefix");
        let build_number = th.optional("build-number");
+        let secrets: Vec<String> = th.optional("secrets").unwrap_or_default();


I dont think this type annotation is needed, is it?

baszalmstra

Can you also update the schema (model.py) and the documentation?

baszalmstra · 2026-05-13T07:54:47Z

Please also use the PR template from the repository.

wolfv · 2026-05-13T07:56:39Z

I am fine with the comments but for me the main question is whether that is the right place to put the secrets key in the pixi.toml. Do you have an opinion on that?

- switch ProjectModel.secrets and PackageBuild.secrets from Vec to BTreeSet so order changes don't invalidate caches (baszalmstra) - move secrets injection into individual backends; each generate_recipe impl now calls .with_secrets(model.secrets...) directly instead of having the intermediate backend post-process the recipe (baszalmstra) - drop redundant test_secrets_default_empty - add IsDefault impl for BTreeSet to support the field in stable hashing - document secrets under [package.build] in pixi_manifest.md and schema/model.py https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

GuillaumeQuenneville · 2026-05-13T11:35:50Z

I am fine with the comments but for me the main question is whether that is the right place to put the secrets key in the pixi.toml. Do you have an opinion on that?

It would be nice to have it at the workspace level also so we don't have to repeat for every package in a monorepo.

wolfv · 2026-05-13T11:39:05Z

That goes a bit against the isolation of the package though, and "depending on what you need" ...

GuillaumeQuenneville · 2026-05-13T12:01:05Z

That's a fair point. I see it similar to workspace dependencies proposal from bas (on my phone sorry will link in an edit).

Maybe a {workspace = true} syntax similar to the proposal?

GuillaumeQuenneville · 2026-05-13T12:20:32Z

Longer version not from my phone.

I think the isolation is a great idea. The main point being security. My monorepo includes packaging for third_party packages we had to patch. We could reasonably get supply chain hacked and have our secret environment variables exposed since most build systems can execute arbitrary code. So we definitely should not do the default "passthru to all" approach. However, we could consider an explicit one.

There is this proposal from @baszalmstra which will add the [workspace.dependencies] table. #5945 which will add to the list of fields that packages can inherit from the workspace.

I think in the interest of consistency. I think it would be a good idea to allow a

[package.build]
secret = ["MYBLAH", {workspace = true}]

so that the general concept of "packages can inherit from the workspace" isn't too arbitrary decided per field.

That being said I also see the justification for only allowing package specific secrets and making this an exception. Since broadly sending build secrets to all packages build systems sounds like a code smell at face value. And the maintenance burden isn't very high.

baszalmstra · 2026-05-13T12:40:25Z

+            .collect::<std::collections::BTreeSet<_>>()
+            .into_iter()
+            .collect();


Collecting twice seems unnecesary

baszalmstra · 2026-05-13T12:41:11Z

        let build_string_prefix = th.optional("build-string-prefix");
        let build_number = th.optional("build-number");
+        let secrets = th
+            .optional::<Vec<String>>("secrets")


Cant we just use BTreeSet here? Instead of collecting twice?

Tried optional::<BTreeSet<String>>(...) but BTreeSet doesn't implement toml_span::Deserialize (only Vec, IndexSet via the local TomlIndexSet, etc.), so the workspace fails to compile. Reverted to parsing as Vec<String> and collecting once into the field's BTreeSet. Happy to add a TomlBTreeSet wrapper in pixi_toml if you'd prefer that route.

Generated by Claude Code

Yes I want that. Its nonsense to collect twice.

https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

…::Deserialize https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

Adds a TomlBTreeSet deserializer in pixi_toml so the secrets field can be parsed into the BTreeSet without an intermediate Vec collect. https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

wolfv · 2026-05-13T13:11:21Z

I could see secrets = { workspace = true } or your "extend list" syntax working, but needs some more design thought.

Alternatively, we could also add a flag to disable the isolation globally (we have the settings in rattler-build).

Passing through secrets like this is probably the cleanest option though.

claude added 3 commits May 12, 2026 19:38

test: regenerate schema and update snapshot for build secrets

5a9a8b3

https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

style: cargo fmt

a861cb9

https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

baszalmstra reviewed May 13, 2026

View reviewed changes

Comment thread crates/pixi_build_types/src/project_model.rs Outdated

baszalmstra reviewed May 13, 2026

View reviewed changes

Comment thread crates/pixi_manifest/src/toml/build_backend.rs Outdated

baszalmstra reviewed May 13, 2026

View reviewed changes

Comment thread crates/pixi_manifest/src/build_system.rs Outdated

baszalmstra requested changes May 13, 2026

View reviewed changes

claude and others added 4 commits May 13, 2026 08:07

chore: regenerate JSON schema for build secrets field

4d0fa17

https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

docs: use behavior consistent with rest of codebase

ae1c0f2

https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

Merge branch 'main' into claude/add-build-backend-secrets-QbCHd

62e4911

wolfv requested a review from baszalmstra May 13, 2026 11:21

baszalmstra requested changes May 13, 2026

View reviewed changes

claude added 3 commits May 13, 2026 12:50

refactor: parse secrets directly into BTreeSet and avoid double collect

eeeb172

https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

fix: revert secrets parser to Vec<String> as BTreeSet lacks toml_span…

0806bd7

…::Deserialize https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

refactor: parse secrets directly into BTreeSet via TomlBTreeSet wrapper

a004865

Adds a TomlBTreeSet deserializer in pixi_toml so the secrets field can be parsed into the BTreeSet without an intermediate Vec collect. https://claude.ai/code/session_015JhTEMr2bEMaK4iSEiWbjj

baszalmstra approved these changes May 13, 2026

View reviewed changes

Merge branch 'main' into claude/add-build-backend-secrets-QbCHd

1eb060b

baszalmstra merged commit 488c883 into main May 13, 2026
41 checks passed

baszalmstra deleted the claude/add-build-backend-secrets-QbCHd branch May 13, 2026 14:33

Conversation

wolfv commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

How Has This Been Tested?

AI Disclosure

Checklist:

Uh oh!

wolfv commented May 13, 2026

Uh oh!

ruben-arts commented May 13, 2026

Uh oh!

wolfv commented May 13, 2026

Uh oh!

baszalmstra May 13, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

baszalmstra May 13, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

baszalmstra left a comment

Choose a reason for hiding this comment

Uh oh!

baszalmstra commented May 13, 2026

Uh oh!

wolfv commented May 13, 2026

Uh oh!

GuillaumeQuenneville commented May 13, 2026

Uh oh!

wolfv commented May 13, 2026

Uh oh!

GuillaumeQuenneville commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GuillaumeQuenneville commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

baszalmstra May 13, 2026

Choose a reason for hiding this comment

Uh oh!

baszalmstra May 13, 2026

Choose a reason for hiding this comment

Uh oh!

wolfv May 13, 2026

Choose a reason for hiding this comment

Uh oh!

baszalmstra May 13, 2026

Choose a reason for hiding this comment

Uh oh!

wolfv commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

wolfv commented May 12, 2026 •

edited

Loading

GuillaumeQuenneville commented May 13, 2026 •

edited

Loading

GuillaumeQuenneville commented May 13, 2026 •

edited

Loading

wolfv commented May 13, 2026 •

edited

Loading