#spacelift (2023-08)

settings.spacelift.depends_on

(we need to consolidate it with settings.depends_on since 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

ouch

wait…i could use anchors to not duplicate so might not be too bad

note that 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 settings.depends_on

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 settings.spacelift.depends_on?

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:

      settings:
        depends_on:
          cluster:
            component: platform-ecs-cluster
          ecs-tasks-mirror:
            component: ecs-tasks-mirror
          vpc:
            component: vpc

I know we definitely take advantage of it

Is that not desired?

Cc @matt

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…

cancel[run.id] {
	run := input.in_progress[_]
	run.type == "PROPOSED"
	run.state == "QUEUED"
	run.branch == input.pull_request.head.branch
}

https://docs.spacelift.io/concepts/policy/push-policy/index.html#canceling-in-progress-runs