Custom Component Types

[MichaelReubenDev]

Describe the Feature

I would like the ability to add custom component types into Atmos. Currently Atmos will only recognise supported types like Terraform or Helmfile I want the ability to extend this with other types that fit my use case and that I can build my own custom implementations off of. I only really need Atmos to add the stacks and components for these custom types so that I can use the atmos cli to pull details from them but having the ability to add custom implementation commands for these would be really cool also though defo not necessary for what I'm asking.

Expected Behavior

Custom components should show up when listing components and stacks.

Use Case

There are a lot of different use cases for this solution basically managing anything that is not natively supported with atmos. The ones that I have in mind are Anisble and templated K8 manifest files. I am well aware that both of these can be done either through terraform or things like helmfiles however managing ansible and kubernetes resources in terraform has always been a mixed bag and I usually prefer to manage them in there own respective tooling.

Describe Ideal Solution

In the atmos.yaml I should be able to define something like:

components:
  terraform:
    base_path: "./components/terraform"
    ...

  helmfile:
    base_path: "./components/helmfile"
    ...

  my_custom_type:
    custom: true
    base_path: "./components/manifest"
    ...

Then in a given stack file I should be able to define stacks.my_custom_type. These should then show when I run commands like: atmos list components atmos list stacks etc...

Alternatives Considered

Currently I can add components but they need to be done through an existing component type like terraform and I use some setting or property to exclude them from terraform actions. This however is illogical as they are not terraform resources.

Additional Context

I would be happy to contribute this sort of feature to the codebase with my own PR but I do not want to develop it only to be told that is does not fit with the project philosophy or something like that. If the team would be happy with this I'd love to iron out how the solution should take shape and develop the feature.

[osterman]

Support for custom components is something we would like to support, and coupled with the concept of "custom commands"

We've receively refactored atmos to make adding new components easier (in Go), but being able to define components through configuration, is something we're still gathering requirements on.