Hi, is the atmos manifest schema updated with each release? I'm running 1.219.0 and I can see

required_providers

in the output from

atmos describe stacks

so I found the page mentioning this (a blog post) but can't seem to find anything in the actual documentation nor do I see the fields in the manifest schema, so after adding the providers as per the example, atmos describe stacks is tripping up because the stack yamls no longer validate against the manifest schema at https://atmos.tools/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json Edit to clarify manifest schema, not json schema. I know I can comment out the schema from my atmos.yaml to bypass the error, but just curious how often is the online schema updated?

required_providers

is not in the schema https://atmos.tools/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json - it's an omission, we'll add it, thanks for reporting. (all new fields should be aded to the schema if they implemented in code - we should also add an AI skills/agent for that)

I'm going to open an issue related to this. I had an idea that there might be

<https://atmos.tools/schemas/atmos/atmos-manifest/1.219.0/atmos-manifest.json>

(one per atmos release) Use-case: We have a repo that a few teams contribute to but one team (my team) is responsible for. We generally try to keep the atmos binary pretty up-to-date in our CI image, but want to prevent the other teams from arbitrarily adding new features to their stacks until we can review. Being able to pin the manifest to a lower version than the binary we're using would help because the validation will fail much like it did for me today, if they add something that's supported by the binary but not by the chosen schema version.

thanks

Quick update: the first example in @Erik Osterman (Cloud Posse)'s blog post from December appears to be incorrect. After commenting out the manifest configuration in atmos.yaml, I had copilot double check the

describe stacks

output and it confirmed they are still empty. Upon digging further, it uncovered that the

required_version

and

required_providers

fields are at:

components:
  terraform:
    <component-name>:
      metadata:
      vars:
      required_version:
      required_providers:

While the very first example has it nested under a

terraform

sub-key as in:

components:
  terraform:
    <component-name>:
      metadata:
      vars:
      terraform:
        required_version:
        required_providers:

Running

atmos describe stacks

against the latter leads to no error but empty values in the output, while running it against the former populates the outputs as expected.

While the very first example has it nested under a

terraform

sub-key as in:

This was unintentional