Skip to content

feat: dynamic autoplan via OUTPUT_MODIFIED_FILES_FILE in pre-workflow hooks#6298

Draft
Copilot wants to merge 3 commits intomainfrom
copilot/dynamic-autoplanning-uncommitted-files
Draft

feat: dynamic autoplan via OUTPUT_MODIFIED_FILES_FILE in pre-workflow hooks#6298
Copilot wants to merge 3 commits intomainfrom
copilot/dynamic-autoplanning-uncommitted-files

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Mar 10, 2026

Tools like Atmos generate tfvars from stack YAML — those regenerated files are uncommitted and invisible to Atlantis, so affected projects never get planned. Pre-workflow hooks can now write repo-relative file paths to $OUTPUT_MODIFIED_FILES_FILE (one per line), and Atlantis will append them to the modified files list before project discovery.

Changes

  • command.Context — adds ExtraModifiedFiles []string field
  • pre_workflow_hook_runner — exposes OUTPUT_MODIFIED_FILES_FILE env var to hook scripts (parallel to existing OUTPUT_STATUS_FILE), pointing to a file in repoDir
  • pre_workflow_hooks_command_runner — reads OUTPUT_MODIFIED_FILES_FILE after all hooks complete; populates ctx.ExtraModifiedFiles
  • project_command_builder — appends ExtraModifiedFiles to the modified files list in buildAllCommandsByCfg; also bypasses the skip-clone optimization when extra files are present
  • docs — new "Dynamic Autoplan with Uncommitted Files" use case section; OUTPUT_MODIFIED_FILES_FILE added to env vars reference

Example

repos:
  - id: /.*/
    pre_workflow_hooks:
      - run: |
          # Write affected tfvars paths (repo-relative, one per line)
          atmos describe affected --output-path "$OUTPUT_MODIFIED_FILES_FILE"
        description: Compute affected stacks
        commands: plan

The paths written to OUTPUT_MODIFIED_FILES_FILE flow through the normal autoplan.when_modified matching, so only projects whose patterns match will be planned.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • custom.domain
    • Triggering command: /tmp/go-build8081991/b599/gitlab.test /tmp/go-build8081991/b599/gitlab.test -test.paniconexit0 -test.timeout=10m0s -test.count=1 .o rg/toolchain@v0.-errorsas 0.1-go1.25.4.lin-ifaceassert ux-amd64/pkg/tool/linux_amd64/vet s-through=-lgcc s-through=-lgcc_-test.paniconexit0 s-through=-lpthr-test.timeout=10m0s ux-amd64/pkg/too-test.count=1 s-th�� s/models/commit_status.go s/models/models.go 0.1-go1.25.4.linux-amd64/pkg/tool/linux_amd64/vet --gdwarf-5 --64 (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Original prompt

This section details on the original issue you should resolve

<issue_title>Dynamically autoplanning with uncommitted files</issue_title>
<issue_description><!--- Please keep this note for the community --->

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.

Describe the user story

I have implemented the atmos documentation to setup autoplanning but it only autoplans all components when a component terraform file is modified. It doesn't take into account stack yaml. When the stack yaml is modified, it changes the uncommitted tfvars file. perhaps only one instance is updated instead of all 100 instances of a component. We'd only want a single instance to autoplan in that case instead of all 100.

Describe the solution you'd like

Id like atlantis to come up with a clever solution, either with the existing feature set, or something native to dynamically trigger only modified component-stacks that were affected by stack yaml changes.

One solution could be to generate tfvars from the base branch, then generate tfvars from the pr branch, diff them, if there are differences, trigger a plan for those. Perhaps we can run some kind of hook that can run a custom script and its output can be the projects it triggers.

workarounds

  • Create a custom file that matches the full component-stack slug, in each project autoplan in atmos.yaml. then run atmos describe affected stacks in a GitHub action and commit a modified file matching that slug within the component directory e.g. s3-test-bucket-ue1-dev.txt
  • Commit the tfvars file per component-stack

</issue_description>

<agent_instructions>Think deeply. Be creative. Think of a creative solution. Think of multiple solutions. Which one is the most scalable and easiest to implement. Use the PR template. Use semantic commits. Use a semantic PR title. Document the feature and perhaps update the atmos documentation on the website.</agent_instructions>

Comments on the Issue (you are @copilot in this section)


💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
…c autoplan

Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
Copilot AI changed the title [WIP] Implement dynamic autoplanning with uncommitted files feat: dynamic autoplan via OUTPUT_MODIFIED_FILES_FILE in pre-workflow hooks Mar 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Dynamically autoplanning with uncommitted files

2 participants