Feat: Dedicated variable for import commands

[Dilergore]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

• I'd be willing to implement this feature (contributing guide)

Describe the user story
Currently, as per the discussion (#2783 (comment)) the ADDRESS and ID in the import command is only available as part of the COMMENT_ARGS workflow variable. It would be great to have a dedicated variable for this so we could better handle customizations.

Describe the solution you'd like
Dedicated custom workflow variables for ADDRESS and ID to customize import.

Describe the drawbacks of your solution
I am not aware of any.

Describe alternatives you've considered
Currently, I am using the COMMENT_ARGS. That said, this variable is supposed to hold commands after --.

[Dilergore]

@krrrr38 - As discussed, opened the feature request. Thanks!

[krrrr38]

As just a idea, we can introduce new ARGS environment into run step.

For example, atlantis import -d dir -w workspace ADDR ID -- -var-file=vars.tfvars provides following envs into run step

• $ARGS: ADDR ID
• $COMMENT_ARGS: -var-file=vars.tfvars

On the other hand, COMMENT_ARGS is escaped by this reason. I'm not sure we should escape ARGS or not by adding another solution.

[Dilergore]

I do not think that escaping is a problem, we probably need escaping for the proposed ARGS as well.

I think the problem is the logic itself:
COMMENT_ARGS is supposed to store input only after the --. Currently, there is no dedicated variable which supposed to hold information like ADDRESS and ID.

To keep the standard I think what you are proposing above makes sense.

ps: I think this would be needed for state rm as well.