<@UB2EH889X> is there any appetite to have labels ...
# atmos
z
@Erik Osterman (Cloud Posse) is there any appetite to have labels be able to be an or operator also - meaning if I had a component with
deployment: stg,prd
it could be either
deployment: stg
, or
deployment: prd
, or both if that was passed in?
My gut is telling me I should have used tags instead
Or.. other solution for DAG would be.. if
--include-dependents
also was able to flow off of a dependency of a component matching a specific selector - Right now the flags will match components matching the selector, but not include dependents of the dependency components
If that makes any sense
Hmm.. that might not work either.. gotta noodle on this
e
Hrmmm, I see - maybe not a string "stg,prd", but I could imaging a list
e.g.
deployment: [stg,prd]
z
yeah, kinda hitting a problem with DAG where I have a component, but it's not really a strict dependency of anything
but I still need to deploy it
and it's shared between stg and prd, basically
A list of available values for the labels.. workable?
I can contribute a PR but just wanted to check and see what you would recommend
e
Oh, you know - you might benefit from this:
We're introducing
atmos stack *
verbs
atmos stack deploy
atmos stack create --name foo --template myapp
Copy code
atmos stack deploy --affected
z
Ahh. Could be good with a custom zarf component lol
I think we are going all on on tofu though with our uds provider
e
yeah, kinda hitting a problem with DAG where I have a component, but it's not really a strict dependency of anything
But in this case, it's a member of a stack at least
Hence the
atmos stack deploy
would handle it
z
Thats deploys a stack?
I have 3 different stacks that I want to deploy with a single label, there's just a stack at the account level that potentially needs to be deployed by 2 different selectors
e
Yes, could make that work; and actually it's a gap in that PR
Will add the label and tag filters
z
How about my initial thought for multiple values for a label key?
Otherwise I'm probably just going to make it a dependency of something arbitrary in the lower level stacks
e
CleanShot 2026-10-19 at 5.29.11 PM@2x.png
Sounds like it unnecessarily complicates it
Would like to find a simpler workaround for now
z
yep, figured, should have used tags
alright, thanks
Going to create a dummy terraform component that doesn't do anything else but list dependencies 🙃
I just realized I can mix tags and labels here, this would be the scenario
I'll just need to tweak my CI a bit..