settings.depends_on is the atmos stack dependency. This does not work for creating spacelift dependencies.
What’s the official way to create dependencies in spacelift?
(we need to consolidate it with
settings.depends_on was added recently and Spacelift modules/components were not updated to use it)
which one is going to win the battle? both?
if we moved to the spacelift version, will the atmos dependency cli runs still work?
settings.depends_on will be used, but for this all Spacelift odules and components will have to be updated
right. any timeline on that or is that not a planned update yet?
not a high priority for us. Please use both for now.
settings.depends_on for the CLI, and
settings.spacelift.depends_on for Spacelift, and add
TODO to the code so you’ll update it later
wait…i could use anchors to not duplicate so might not be too bad
settings.depends_on is used only in this command (which was added not too long ago) https://atmos.tools/cli/commands/describe/dependents, and nowhere else
since it was added not to long ago, all other things were not updated to use
Spacelift has been using
settings.spacelift.depends_on for years
yeah, i did a full audit of
depends_on and consolidated on
settings.depends_on after upgrading Atmos.
I saw the page you linked and compared to https://atmos.tools/integrations/spacelift/#stack-configuration which does not mention
depends_on so I thought the above link was the right way for spacelift
if you are using it just for spacelift, use the old way
cc @matt @Dan Miller (Cloud Posse) if @johncblandii is using the GHA to detect affected stacks, he should probably define both, no?
it’s not related to
atmos describe affected, it’s related to
atmos describe dependents
but we need to update our spacelift components to use the new way of describing dependencies to make everything consistent (b/c stacks deps are not only related to Spacelift stacks, and the command
atmos describe dependents uses it to describe the dependencies using the CLI)
is there ever a case where
settings.depends_on would differ from
documentation on atmos.tools would be helpful too; specifically https://atmos.tools/integrations/spacelift/#stack-configuration
they have diff formats. The old one
settings.spacelift.depends_on (which our Spacelift components are using) is a list
settings.depends_on is a map to support deep-merging and inheritance, and make the config DRY
yuppers. we stopped using
1: blah and started doing this for ease of overrides:
Hey folks – with the spacelift-automation module / component, is there new functionality since
0.49.5 that will cancel stacked “trigger-policy” runs? As in it will do something similar to the below screenshot where if many runs are triggered due to dependencies, only the last will actually be planned?
I know we definitely take advantage of it
Is that not desired?
I’m interested in avoiding having to manually cancel the stacked runs to not bog down the Spacelift runs with clean plans. That’s what I’m getting at. Just wondering if there was ever an enhancement that made it in that helped avoid that. Haha I should probably just look at the release notes. I’ll dig into them sometime this week.
This should be a simple policy update…you can do something like the following…
run := input.in_progress[_]
run.type == "PROPOSED"
run.state == "QUEUED"
run.branch == input.pull_request.head.branch
Collaborative Infrastructure For Modern Software Teams