zarf-config.yaml - package.deploy.components ignored during zarf init --confirm

[upics]

Was working as expected till version v0.63.0.
From version v0.64.0 (tested also v0.65.0 and v0.66.0), when doing:

zarf init --confirm

with a zarf-config.yaml with

package:
    deploy:
        components: name-component

compoents are ignored:

2025-12-05 14:18:50 INF starting deploy package=init
2025-12-05 14:18:50 WRN no components were selected for deployment. Inspect the package to view the available components and select components interactively or by name with "--components"

[brandtkeller]

I am looking for a change to the structure that would have caused this - solely looking at the code - to select components during init with the zarf-config.yaml file - you would need:

init:
  components: 'git-server'

this is distinctly separate from package deploy components and the viper configuration hasn't changed in quite some time.

I can grab links to code - I will also try and do some testing on older versions of zarf to replicate.

[brandtkeller]

package.deploy.components would apply if you were deploying the init package with zarf package deploy.

[upics]

@brandtkeller thanks for the immediate feedback. I will try to define components under init, but still strange that was working till this specific version. (We were using v0.48.1 for while till today)

Keep you updated

[brandtkeller]

I was able to replicate your problem! I believe it comes back to our goals to remove global state.

I am debugging why you were able to perform this previously - but I would say that the way configuration files feed init with the sample I provided above was the intent - and the use of package.deploy.components was not intentional.

Let me know if this is a large pain for you to migrate from - and maybe we can evaluate the problem further.

[upics]

No problem at all, it’s enough to understand what is the correct way. Maybe could be better to clarify this point in the documentation? (https://docs.zarf.dev/ref/config-files/)

Thank you again ;)

[brandtkeller]

💯 agree! better docs are always good. I'm going to mark this issue as documentation and ready so that we can track docs improvements prior to closing.

[repairman29]

Hi! I'm interested in helping with this issue.

I have experience with index (repairman29/ai-gm-service) and think I can contribute here. Would love to discuss the approach and see if we can make this happen.

(Connected via Echeo - a platform for matching developers with open source bounties)