#5572 state_rm command can't be used since its not available in --allow-commands Issue created by blv-enriquejimenez ### 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. --- ### Overview of the Issue I'm using the Terragrunt command as part of a custom workflow in Atlantis and added the state_rm command as specified in the official documentation. However, when I run atlantis state_rm, I receive the following error:

Error: unknown command "state_rm". Run 'atlantis --help' for usage. Available commands(--allow-commands): version, plan, apply, unlock, approve_policies, import

If I try to add the "state_rm" to --allow-commands im getting the next error

Error: invalid --allow-commands: unknown command name: state_rm

### Reproduction Steps • Added state_rm as custom workflow (https://www.runatlantis.io/docs/custom-workflows.html#terragrunt) • Added "state_rm" to --allow-commands • run atlantis server ### Environment details • Atlantis version: atlantis v0.34.0 (commit: 551b4d0) (build date: 2025-04-02T202545.632Z) • Deployment method: ecs • If not running the latest Atlantis version have you tried to reproduce this issue on the latest version: • Atlantis flags: Atlantis server-side config file: # config file repos: - id: /.*/ branch: /master/ workflow: terragrunt apply_requirements: [mergeable] import_requirements: [mergeable] pre_workflow_hooks: - description: Generating configs run: | result=$${PWD##*/} config_file="atlantis.yaml" if [ "$result" = "default" ]; then echo "Default Workspace. Atlantis Config will be generated." terragrunt-atlantis-config generate --ignore-parent-terragrunt --ignore-dependency-blocks --create-workspace --filter live/ --automerge --output "$config_file" else echo "Not the Default Workspace. Will clone atlantis.yaml from default workspace and will skip re-generating it." ln -s ../default/"$config_file" "$config_file" fi metrics: prometheus: endpoint: "/metrics" policies: owners: teams: - infrastructure policy_sets: - name: required-tags path: /usr/share/policies/required-tags/ source: local - name: required-tags-values path: /usr/share/policies/required-tags-values/ source: local workflows: terragrunt: plan: steps: - env: name: TERRAGRUNT_TFPATH command: 'echo "terraform$${ATLANTIS_DEFAULT_TF_VERSION:1}"' - run: terragrunt plan -input=false -out=$PLANFILE - run: terragrunt show -json $PLANFILE > $SHOWFILE apply: steps: - env: name: TERRAGRUNT_TFPATH command: 'echo "terraform$${ATLANTIS_DEFAULT_TF_VERSION:1}"' - run: terragrunt apply -input=false $PLANFILE policy_check: steps: - env: name: TERRAGRUNT_TFPATH command: 'echo "terraform$${ATLANTIS_DEFAULT_TF_VERSION:1}"' - run: terragrunt show -json $PLANFILE > $SHOWFILE - policy_check: extra_args: ["--all-namespaces"] import: steps: - env: name: TERRAGRUNT_TFPATH command: 'echo "terraform$${ATLANTIS_DEFAULT_TF_VERSION:1}"' - env: name: TF_VAR_author command: 'git show -s --format="%ae" $HEAD_COMMIT' - run: terragrunt import -input=false $(printf '%s' $COMMENT_ARGS | sed 's/,/ /' | tr -d '\\') state_rm: steps: - env: name: TERRAGRUNT_TFPATH command: 'echo "terraform$${ATLANTIS_DEFAULT_TF_VERSION:1}"' - run: terragrunt state rm $(printf '%s' $COMMENT_ARGS | sed 's/,/ /' | tr -d '\\') runatlantis/atlantis

#5574 Consider general approach for per-VCS features Issue created by lukemassa ### 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 As we move towards #2496, one thing that has come up was more formal approach to the levels of support for various features. More specifically, the question came up how do we understand features that are only supported in some but not all of our VCSs. Looking at https://www.runatlantis.io/docs/server-configuration.html, per-VCS settings falls into two categories: 1. Configuring that VCS (i.e.

--gh-hostname

or

--azuredevops-user

) 2. Enabling/using per-VCS features Features that potentially fall into category 2 are: • https://www.runatlantis.io/docs/server-configuration.html#gh-allow-mergeable-bypass-apply • https://www.runatlantis.io/docs/server-configuration.html#gh-team-allowlist • https://www.runatlantis.io/docs/server-configuration.html#gitea-page-size • https://www.runatlantis.io/docs/server-configuration.html#gitlab-group-allowlist The difficulty with having VCS specific flags is it doesn't give us a path for implementing this feature on other VCSs, and more broadly doesn't explain whether this is a general feature that happens to be implemented once, or truly a per-VCS setting. I see a few possible options here (which might be different for each of the flags above) 1. Classify the flag as simply a "configuration" for that VCS 2. Introduce a new flag without the VCS-specific logic, have it be unimplemented for the other VCSs, deprecate the existing flag 3. Allow for per-VCS feature flags Describe the solution you'd like I think we should reserve

--<vcs>-*

flags for configuration of that VCS only. If there is a feature that could theoretically exist for other VCSs but isn't implemented at this point, it should be called out as such (maybe with a WARNING in the code if you specify one of these flags but are running a VCS that doesn't support it?) Describe the drawbacks of your solution This requires some work, both in the short term to clean up what we have now, as long as complicating the addition of new features that are only being implemented for one VCS (depending on the exact implementation of this, maybe it's just a tweak in how it's documented). Describe alternatives you've considered We could leave things as they are. I'm actually surprised how few of these flags there turned out to be; Atlantis works very hard to make everything work on all VCSs, one way or another. So maybe these oddities can simply be exceptions to the rule? Or maybe we should call them out explicitly? runatlantis/atlantis

#5379 Atlantis crashes on atlantis plan after redis configuration Issue created by jgatt513 ### 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. ### Overview of the Issue After configuring Atlantis Server to use redis as lockingdbtype the container gets created without any issues but on the attempt to run a plan it fails with the following:

runtime error: invalid memory address or nil pointer dereference runtime/panic.go:262 (0x472a98) runtime/signal_unix.go:917 (0x472a68) <http://github.com/runatlantis/atlantis/server/events/command_runner.go:340|github.com/runatlantis/atlantis/server/events/command_runner.go:340> (0x11539da) runtime/asm_amd64.s:1700 (0x478960)

### Reproduction Steps • add redis cluster to your kubernetes cluster and same namespace as atlantis. • set atlanits server args args: - server - --log-level={{ .Values.log.level }} - --repo-config=/atlantis-config/repos.yaml - --redis-host="atlantis-leader-headless.atlantis.svc.cluster.local" - --redis-password="" - --locking-db-type="redis" - --checkout-strategy=merge - --atlantis-url=https://{{ get (first .Values.ingress.hosts ) "host" }} - --default-tf-version={{ .Values.defaultTFVersion }} - --enable-regexp-cmd - --hide-unchanged-plan-comments - --quiet-policy-checks • Once the environment and pods are stable and healthy attempt to run a plan. ### Logs {"level":"info","ts":"2025-03-04T153705.261Z","caller":"events/events_controller.go:692","msg":"Handling 'plan' comment","json":{"repo":"alienadmin/terragrunt","pull":4185}} │ │ {"level":"info","ts":"2025-03-04T153705.261Z","caller":"events/events_controller.go:736","msg":"Running comment command 'plan' for user '712020:1ba2ddde-b573-42df-a1d4-c6a7b1a4d83b'.","json":{"repo" │ │ {"level":"error","ts":"2025-03-04T153705.262Z","caller":"events/command_runner.go:555","msg":"PANIC: runtime error: invalid memory address or nil pointer dereference\nruntime/panic.go:262 (0x472a98) ### Environment details atlantis version v.0.33.0 runatlantis/atlantis

#5575 Documentation Error: Gitlab Webhook Configuration - Push Events are not required Issue created by saraangelmurphy ### 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. --- ### Overview of the Issue In the Atlantis documentation, when configuring webhooks, Atlantis tells the end user to enable push events. https://www.runatlantis.io/docs/configuring-webhooks#gitlab However, we can clearly see in handleGitlabPost and ParseAndValidate that only "Merge Request Hook" and "Note Hook" events are actually parsed. Push events have a header of "Push Hook" (see the gitlab sample docs). ### Reproduction Steps 1. Configure a gitlab webhook as per the normal instructions 2. Disable push events ### Logs ### Environment details • Atlantis version: v0.34.0 • Deployment method: helm 5.17.2 • If not running the latest Atlantis version have you tried to reproduce this issue on the latest version: • Atlantis flags: Atlantis server-side config file: irrelevant for this issue. Repo

atlantis.yaml

file: ### Additional Context runatlantis/atlantis

#5580 Atlantis plan or apply fail on every other request Issue created by petarnikolovski ### 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. --- ### Overview of the Issue When using self-hosted Gitea, and Atlantis run on Kubernetes, every other request crashes Atlantis pod. Despite Atlantis pod having unbounded CPU, and 8Gb guaranteed memory. ### Reproduction Steps 1. Make a PR with plan to execute on Gitea 2. Type

atlantis plan

after auto plan finishes 3. If this passes do

atlantis plan

once again, it should crash 4. Atlantis reports HTTP error 502 ### Logs ``` {"level":"debug","ts":"2025-05-14T105258.107Z","caller":"events/events_controller.go:113","msg":"handling Gitea post","json":{}} {"level":"debug","ts":"2025-05-14T105258.107Z","caller":"events/events_controller.go:339","msg":"Received Gitea event pull_request_comment with ID <redacted>","json":{"gitea-request-id":"<redacted>"}} {"level":"debug","ts":"2025-05-14T105258.107Z","caller":"events/events_controller.go:395","msg":"Successfully unmarshaled Gitea comment event","json":{}} {"level":"info","ts":"2025-05-14T105258.107Z","caller":"events/events_controller.go:692","msg":"Handling 'apply' comment","json":{"repo":"<redacted>","pull":<redacted>}} {"level":"info","ts":"2025-05-14T105258.107Z","caller":"events/events_controller.go:736","msg":"Running comment command 'apply' for user '<redacted>'.","json":{"repo":"<redacted>","pull":<redacted>}} {"level":"debug","ts":"2025-05-14T105258.107Z","caller":"events/events_controller.go:900","msg":"Processing...","json":{}} {"level":"debug","ts":"2025-05-14T105258.107Z","caller":"server/middleware.go:72","msg":"POST /events – respond HTTP 200","json":{}} {"level":"debug","ts":"2025-05-14T105258.107Z","caller":"gitea/client.go:85","msg":"Getting Gitea pull request <redacted>","json":{"repo":"<redacted>","pull":"<redacted>"}} {"level":"debug","ts":"2025-05-14T105258.114Z","caller":"metrics/debug.go:52","msg":"timer","json":{"name":"atlantis_cmd_comment_apply_execution_time","value":0.007115203,"tags":{},"type":"timer"}} {"level":"error","ts":"2025-05-14T105258.115Z","caller":"events/command_runner.go:555","msg":"PANIC: runtime error: invalid memory address or nil pointer dereference\nruntime/panic.go:262 (0x472a98)\nruntime/signal_unix.go:917 (0x472a68)\ngithub.com/runatlantis/atlantis/server/events/vcs/gitea/client.go:90 (0x1084819)\ngithub.com/runatlantis/atlantis/server/events/command_runner.go:425 (0x1155427)\ngithub.com/runatlantis/atlantis/server/events/command_runner.go:497 (0x1156936)\ngithub.com/runatlantis/atlantis/server/events/command_runner.go:335 (0x115382f)\nruntime/asm_amd64.s:1700 (0x478960)\n","json":{"repo":"<redacted>","pull":"<redacted>"},"stacktrace":"github.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).logPanics\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go555\nruntime.gopanic\n\truntime/panic.go785\nruntime.panicmem\n\truntime/panic.go262\nruntime.sigpanic\n\truntime/signal unix.go917\ngithub.com/runatlantis/atlantis/server/events/vcs/gitea.(*GiteaClient).GetPullRequest\n\tgithub.com/runatlantis/atlantis/server/events/vcs/gitea/client.go:90\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).getGiteaData\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:425\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).ensureValidRepoMetadata\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:497\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).RunCommentCommand\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:335"} {"level":"debug","ts":"2025-05-14T105258.115Z","caller":"gitea/client.go:138","msg":"Creating comment on Gitea pull request 105","json":{"repo":"<redacted>","pull":"<redacted>"}} panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1084f19] goroutine 257 [running]: github.com/runatlantis/atlantis/server/events/vcs/gitea.(*GiteaClient).CreateComment(0xc00098c0c0, {0x19165c8, 0xc00057a080}, {{0xc000330920, 0x10}, {0xc000330920, 0x6}, {0xc000330927, 0x9}, {0xc0004d0150, ...}, ...}, ...) github.com/runatlantis/atlantis/server/events/vcs/gitea/client.go:147 +0x1f9 github.com/runatlantis/atlantis/server/events/vcs.(*ClientProxy).CreateComment(0x0?, {0x19165c8, 0xc00057a080}, {{0xc000330920, 0x10}, {0xc000330920, 0x6}, {0xc000330927, 0x9}, {0xc0004d0150, ...}, ...}, ...) github.com/runatlantis/atlantis/server/events/vcs/proxy.go:65 +0xed github.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).logPanics(0xc0001b6400, {{0xc000330920, 0x10}, {0xc000330920, 0x6}, {0xc000330927, 0x9}, {0xc0004d0150, 0x69}, {0xc0005fa3c0, ...}, ...}, ...) github.com/runatlantis/atlantis/server/events/command_runner.go:556 +0x23f panic({0x13d8600?, 0x239d3c0?}) runtime/panic.go:785 +0x132 github.com/runatlantis/atlantis/server/events/vcs/gitea.(*GiteaClient).GetPullRequest(0xc00098c0c0, {0x19165c8, 0xc00057a080}, {{0xc000330920, 0x10}, {0xc000330920, 0x6}, {0xc000330927, 0x9}, {0xc0004d0150, ...}, ...}, ...) github.com/runatlantis/atlantis/server/events/vcs/gitea/client.go:90 +0x1d9 github.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).getGiteaData(_, {_, _}, {{0xc000330920, 0x10}, {0xc000330920, 0x6}, {0xc000330927, 0x9}, {0xc0004d0150, ...}, ...}, ...) github.com/runatlantis/atlantis/server/events/command_runner.go:425 +0xc8 github.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).ensureValidRepoMetadata(_, {{0xc000330920, 0x10}, {0xc000330920, 0x6}, {0xc000330927, 0x9}, {0xc0004d0150, 0x69}, {0xc0005fa3c0, ...}, ...}, ...) github.com/runatlantis/atlantis/server/events/command_runner.go:497 +0x617 <http://github.co… runatlantis/atlantis

#5581 Team authz missing env variables Issue created by umbo-unumed ### 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. --- ### Overview of the Issue Commands invoked by the

team_authz

are missing env. variables. According to the documentation a set of env varaibles should be available for the script that is runned by

team_authz

. Unfortunetly this does not seem to be the case. Looking at the code, the list of expected variables is set to be passed to the command, but on execution time they seem to be null ### Reproduction Steps Create a team_auth script that will be invoked and output the value of the variables defined by code.

#repos.yaml
...
team_authz:
  command: "/scripts/team_auth.sh"

#team_auth.sh

#!/bin/sh

echo "[DEBUG] BASE_BRANCH_NAME:$BASE_BRANCH_NAME"
echo "[DEBUG] BASE_REPO_NAME:  $BASE_REPO_NAME"
echo "[DEBUG] BASE_REPO_OWNER: $BASE_REPO_OWNER"
echo "[DEBUG] COMMENT_ARGS:    $COMMENT_ARGS"
echo "[DEBUG] HEAD_BRANCH_NAME:$HEAD_BRANCH_NAME"
echo "[DEBUG] HEAD_COMMIT:     $HEAD_COMMIT"
echo "[DEBUG] HEAD_REPO_NAME:  $HEAD_REPO_NAME"
echo "[DEBUG] HEAD_REPO_OWNER: $HEAD_REPO_OWNER"
echo "[DEBUG] PULL_AUTHOR:     $PULL_AUTHOR"
echo "[DEBUG] PULL_NUM:        $PULL_NUM"
echo "[DEBUG] PULL_URL:        $PULL_URL"
echo "[DEBUG] USER_NAME:       $USER_NAME"
echo "[DEBUG] COMMAND_NAME:    $COMMAND_NAME"
echo "[DEBUG] PROJECT_NAME:    $PROJECT_NAME"
echo "[DEBUG] REPO_ROOT:       $REPO_ROOT"
echo "[DEBUG] REPO_REL_PATH:   $REPO_REL_PATH"

### Environment details runatlantis/atlantis

#5583 TF_PLUGIN_CACHE_DIR is not present in custom steps Issue created by leonnicolas ### 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. ### Overview of the Issue Not sure if this is intended or not, but it seems that most environment variables are propagated from the caller (atlantis) to the callee (custom step), except TF_PLUGIN_CACHE_DIR because this variable is never in the environ. If this is indeed not intended, I am happy to "fix" it. Otherwise it would be nice to add some note in the documentation. ### Reproduction Steps Don't disable the plugin cache (default behavior). Override the init step with a custom run:

- run: terraform$ATLANTIS_TERRAFORM_VERSION init -input=false

TF_PLUGIN_CACHE_DIR

is not in the process's environ. :(( runatlantis/atlantis

#5585 Github update status error is logged with empty URL as if there were misconfiguration Issue created by maximmasiutin ### 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. --- ### Overview of the Issue GitHub update status error is logged with empty URL as if there were misconfiguration, for example:

{"level":"debug","ts":"2025-05-16T11:41:29.109Z","caller":"vcs/github_client.go:871","msg":"Updating status on GitHub pull request 2421 for '1/1 projects policies checked successfully.' to 'success'","json":{"repo":"mycompany/myrepository","pull":"2421"}}
{"level":"debug","ts":"2025-05-16T11:41:29.186Z","caller":"vcs/github_client.go:881","msg":"POST /repos/mycompany/myrepository/statuses/afa7161234d5643db7e994b6583846b365517fca returned: 404","json":{"repo":"mycompany/myrepository","pull":"2421"}}
{"level":"error","ts":"2025-05-16T11:41:29.186Z","caller":"vcs/instrumented_client.go:221","msg":**"Unable to update status at url: , error: POST <https://api.github.com/repos/mycompany/myrepository/statuses/afa7165350d5643db7e994b6583846b365517fca>: 404 Not Found []"**,"json":{"repo":"mycompany/myrepository","pull":"2421"},"stacktrace":"<http://github.com/runatlantis/atlantis/server/events/vcs.(*InstrumentedClient).UpdateStatus|github.com/runatlantis/atlantis/server/events/vcs.(*InstrumentedClient).UpdateStatus>\n\tgithub.com/runatlantis/atlantis/server/events/vcs/instrumented_client.go:221\ngithub.com/runatlantis/atlantis/server/events/vcs.(*ClientProxy).UpdateStatus\n\tgithub.com/runatlantis/atlantis/server/events/vcs/proxy.go:89\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommitStatusUpdater).UpdateCombinedCount\n\tgithub.com/runatlantis/atlantis/server/events/commit_status_updater.go:82\ngithub.com/runatlantis/atlantis/server/events.(*ApprovePoliciesCommandRunner).updateCommitStatus\n\tgithub.com/runatlantis/atlantis/server/events/approve_policies_command_runner.go:104\ngithub.com/runatlantis/atlantis/server/events.(*ApprovePoliciesCommandRunner).Run\n\tgithub.com/runatlantis/atlantis/server/events/approve_policies_command_runner.go:89\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).RunCommentCommand\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:389"}

### Reproduction Steps Have a GitHub token or a GitHub app that does not have permission to update status on pull requests ### Logs See above the logs ("bold" emphasis mine). ### Environment details This does not depend on the environment, but happens with Github private repos. ### Additional Context Atlantis tries to log an URL, but the URL may be empty by design of the function calls, for example:

func (d *DefaultCommitStatusUpdater) UpdateCombined(logger logging.SimpleLogging, repo models.Repo, pull models.PullRequest, status models.CommitStatus, cmdName command.Name) error {
	src := fmt.Sprintf("%s/%s", d.StatusName, cmdName.String())
	var descripWords string
	switch status {
	case models.PendingCommitStatus:
		descripWords = genProjectStatusDescription(cmdName.String(), "in progress...")
	case models.FailedCommitStatus:
		descripWords = genProjectStatusDescription(cmdName.String(), "failed.")
	case models.SuccessCommitStatus:
		descripWords = genProjectStatusDescription(cmdName.String(), "succeeded.")
	}
	return d.Client.UpdateStatus(logger, repo, pull, status, src, descripWords, "")
}

# Conclusion This bug report details an issue where updating a GitHub pull request’s status in a private repos causing an error misleadingly shows an empty URL. runatlantis/atlantis

#5589 Feature Request: Supporting repo-level log level configuration via atlantis.yaml Issue created by kapillamba4 ### 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, Atlantis log levels can only be configured globally using the --log-level flag at server startup. In multi-project or multi-repo setups, it would be nice to support repo- or project-level control over log verbosity — for instance, enabling debug logs for a specific project while keeping the default info level for others. Describe the solution you'd like Introduce support for setting the log level via the atlantis.yaml configuration file, scoped to a project. For example: version: 3 projects: - name: default dir: default log_level: debug Describe the drawbacks of your solution Not sure how feasible the implementation would be. Describe alternatives you've considered Passing & Setting TF_LOG in custom workflows could be a viable workaround, but it's not applicable in environments where custom workflows are disabled at server side atlantis config. runatlantis/atlantis

#4121 Github credentials leak in logs Issue created by alanbover ### 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. --- ### Overview of the Issue Atlantis can leaks Github credentials in logs. See an example of a log leaking some:

getting remote update failed: error: could not lock config file .git/config: File exists
fatal: could not set 'remote.head.url' to 'https://<redacted>:ghp_<redacted>@github.com/<redacted>/<redacted>.git'

This happens because, when using a github user and token, the remote is being configured as

https://<GH_user>:<GH Token>@github.com/<org>/<repo>.git

, and logged git command errors that reference to this remote will end up accidentally leaking the credentials. Here we can see how the command error is directly logged atlantis/server/events/working_dir.go Line 188 in</runatlantis/atlantis/commit/1035d9263a687e6a43a102fa44030f3f4c93f579|1035d92> | w.Logger.Warn("getting remote update failed: %s", string(output)) | | ----------------------------------------------------------------- | Atlantis should parse the output first and figure out if the token is being leaked. In that case, it should redact it. ### Reproduction Steps I don't have specific instructions to reproduce the problem. The specific error we see (getting remote update failed: error: could not lock config file .git/config: File exists) seems to happen due to a non-parallelizable git operation, so I guess it happens when many plans are created for the same PR. ### Logs ### Environment details • Atlantis version: 0.27.0 • Deployment method: k8s objects directly (kustomize) • If not running the latest Atlantis version have you tried to reproduce this issue on the latest version: • Atlantis flags: ### Additional Context runatlantis/atlantis

#5590 `atlantis testdrive` failed to create a tunnel even though `ngrok` is authenticated Issue created by thisjdzhang ### 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. --- ### Overview of the Issue

atlantis testdrive

fails to create a secure tunnel even though

ngrok

is authenticated and configured with a valid token. ### Reproduction Steps

ngrok config add-authtoken {your_token}

then

atlantis testdrive

### Logs

solis-venv ❯ atlantis testdrive
Welcome to Atlantis testdrive!

This mode sets up Atlantis on a test repo so you can try it out. We will
- fork an example terraform project to your username
- install terraform (if not already in your PATH)
- install ngrok so we can expose Atlantis to GitHub
- start Atlantis

Press Ctrl-c at any time to exit


<http://github.com|github.com> username: {redacted}

To continue, we need you to create a GitHub personal access token
with "repo" scope so we can fork an example terraform project.

Follow these instructions to create a token (we don't store any tokens):
<https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#creating-a-fine-grained-personal-access-token>
- use "atlantis" for the token description
- add "repo" scope
- copy the access token

GitHub access token (will be hidden):
=> forking repo
=> fork completed!
=> terraform found in $PATH at /usr/local/bin/terraform
=> ngrok found in $PATH at /usr/local/bin/ngrok
=> creating secure tunnel
Error: creating ngrok tunnel: timeout, logs:
t=2025-05-20T16:49:47-0400 lvl=info msg="open config file" path=/var/folders/8c/7r9h5zl90yq4jd12zbt5k5z40000gp/T/atlantis-testdrive-ngrok-config3555034180 err=nil
t=2025-05-20T16:49:47-0400 lvl=info msg="starting web service" obj=web addr=localhost:41414 allow_hosts=[]
t=2025-05-20T16:49:48-0400 lvl=eror msg="failed to reconnect session" obj=tunnels.session err="authentication failed: Usage of ngrok requires a verified account and authtoken.\n\nSign up for an account: <https://dashboard.ngrok.com/signup>\nInstall your authtoken: <https://dashboard.ngrok.com/get-started/your-authtoken\r>\n\r\nERR_NGROK_4018\r\n"
t=2025-05-20T16:49:48-0400 lvl=eror msg="session closing" obj=tunnels.session err="authentication failed: Usage of ngrok requires a verified account and authtoken.\n\nSign up for an account: <https://dashboard.ngrok.com/signup>\nInstall your authtoken: <https://dashboard.ngrok.com/get-started/your-authtoken\r>\n\r\nERR_NGROK_4018\r\n"
t=2025-05-20T16:49:48-0400 lvl=info msg="received stop request" obj=app stopReq="{err:{Remote:true Inner:{Inner:0xc00069e1e0}} restart:false}"
t=2025-05-20T16:49:48-0400 lvl=eror msg="terminating with error" obj=app err="authentication failed: Usage of ngrok requires a verified account and authtoken.\n\nSign up for an account: <https://dashboard.ngrok.com/signup>\nInstall your authtoken: <https://dashboard.ngrok.com/get-started/your-authtoken\r>\n\r\nERR_NGROK_4018\r\n"
t=2025-05-20T16:49:48-0400 lvl=warn msg="failed to check for update" obj=updater err="Post \"<https://update.equinox.io/check\>": context canceled"
t=2025-05-20T16:49:48-0400 lvl=info msg="no more state changes" obj=tunnels.session
t=2025-05-20T16:49:48-0400 lvl=crit msg="command failed" err="authentication failed: Usage of ngrok requires a verified account and authtoken.\n\nSign up for an account: <https://dashboard.ngrok.com/signup>\nInstall your authtoken: <https://dashboard.ngrok.com/get-started/your-authtoken\r>\n\r\nERR_NGROK_4018\r\n"
ERROR:  authentication failed: Usage of ngrok requires a verified account and authtoken.
ERROR:
ERROR:  Sign up for an account: <https://dashboard.ngrok.com/signup>
ERROR:  Install your authtoken: <https://dashboard.ngrok.com/get-started/your-authtoken>
ERROR:
ERROR:  ERR_NGROK_4018
ERROR:  <https://ngrok.com/docs/errors/err_ngrok_4018>
ERROR:

### Environment details ### Additional Context runatlantis/atlantis

#5592 can not find existing workspace to init Issue created by thisjdzhang ### 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. --- ### Overview of the Issue I use TF cloud and one of my project is configured to use that remote backend and a workspace. I recently integrate that project with atlantis but during the

terraform init

, it says

running 'sh -c' 'terraform init' in '/home/atlantis/.atlantis/repos/{redacted}': exit status 1: running "terraform init" in "/home/atlantis/.atlantis/repos/{redacted}: 
Initializing the backend...

Successfully configured the backend "remote"! Terraform will automatically
use this backend unless the backend configuration changes.
╷
│ Error: Error loading state: Error creating workspace {redacted}: invalid attribute
│ 
│ Name has already been taken
│ 
│ 
╵

Basically I have this workspace in the TF cloud already, but atlantis still tries to create one. I also tried "default" workspace and it has the same thing. Am I doing something wrong or it's a bug? My

atlantis.yaml

file is like this

version: 3
projects:
  - name: monitoring
    dir: bootstrap/monitoring
    workspace: my-monitoring
    terraform_version: v1.10.0
    autoplan:
      when_modified: ["*.tf"]
      enabled: true
    apply_requirements: [approved]
    workflow: custom

workflows:
  custom:
    plan:
      steps:
        - run: terraform init
        - run: terraform plan
    apply:
      steps:
        - run: terraform init
        - run: terraform apply

I have

TF_TOKEN_app_terraform_io

set as the env var. ### Reproduction Steps 1. Add a project that has remote backend configured and use an existing

workspace

2. trigger a push ### Logs ### Environment details ### Additional Context runatlantis/atlantis

#5593 Atlantis server doesn't do anything after `terraform init` Issue created by thisjdzhang ### 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. --- ### Overview of the Issue I have a custom workflow

version: 3
projects:
  - name: monitoring
    dir: bootstrap/monitoring
    workspace: my-monitoring
    terraform_version: v1.10.0
    autoplan:
      when_modified: ["*.tf"]
      enabled: true
    apply_requirements: [approved]
    workflow: custom

workflows:
  custom:
    plan:
      steps:
        - run: terraform init
        - run: terraform plan
    apply:
      steps:
        - run: terraform init
        - run: terraform apply

Based on logs, the terraform server doesn't do anything after running the

terraform init

The github checks just hang there. ### Reproduction Steps ### Logs

{
  "level": "info",
  "ts": "2025-05-22T17:52:22.709Z",
  "caller": "models/shell_command_runner.go:181",
  "msg": "successfully ran 'sh -c' 'terraform init' in '/home/atlantis/.atlantis/repos/{redacted}/bootstrap/monitoring'",
  "json": {
    "repo": "{redacted}",
    "pull": "605",
    "duration": 3.925247448
  }
}

Latest comment is ^^ and nothing gets printed after that. ### Environment details ### Additional Context runatlantis/atlantis

#5594 Atlantis falsely claims a workspace is locked while it's not Issue created by thisjdzhang ### 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. --- ### Overview of the Issue Atlantis raise error claiming a workspace is locked but in the TF cloud UI, the workspace is not locked at all.

Ran Plan for dir: bootstrap/monitoring workspace: monitoring

Plan Error

the monitoring workspace at path bootstrap/monitoring is currently locked by another command that is running for this pull request.
Wait until the previous command is complete and try again

### Reproduction Steps ### Logs ### Environment details ### Additional Context runatlantis/atlantis

#5595 Case sensitivity / preservation feature for Azure DevOps Organizations older than 2018 Issue created by leonardocaylent ### 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 As a developer, I want to create an environment variable called

ATLANTIS_AZUREDEVOPS_LEGACY_URL_ISSUE

to convert the Azure Devops Organization name to lower case in all type of service hooks (v1.0 & v2.0) Describe the problem in detail Not moving to the new Azure DevOps URL causes the Atlantis service hooks to have different folder names on these 2 scenarios:

A)Pull Request Comments  (Using Service hook v2.0)
B)Pull Request Updates/Creates (Using Service hook v1.0)

Evidence:

1)Pull request commented on (version 2.0)
2)Pull request updated (version 1.0)
3)Pull request created (version 1.0)

1)<https://dev.azure.com/MYCompany/1234567-abcd-abcd-abcd-987654321/_apis/git/repositories/1234abcd-9876-1234-a123-123456789/pullRequests/000001>
2)<https://mycompany.visualstudio.com/1234567-abcd-abcd-abcd-987654321/_apis/git/repositories/1234abcd-9876-1234-a123-123456789/pullRequests/000001>
3)<https://mycompany.visualstudio.com/1234567-abcd-abcd-abcd-987654321/_apis/git/repositories/1234abcd-9876-1234-a123-123456789/pullRequests/000001>

This is creating 2 different folders for the plans:

/home/atlantis/.atlantis/repos/MYCompany/terraform-modules/terraform-live/000001/default/c1/us-east-01/base
/home/atlantis/.atlantis/repos/mycompany/terraform-modules/terraform-live/000001/default/c1/us-east-01/base

So the plan triggered by opening the Pull request on "3)PullRequestCreated" creates the auto-plan at /mycompany/ and when i run atlantis apply it tries to find apply the plan at /MYCompany/, which it doesn't exist at that moment Checking some old issues, it seems that this is related to a previous migration where Azure Devops changed the URL and preserved the old name to use in the different service hooks. Describe why this is important to have We are doing this because of the impact that other pipelines/webhooks/CICD/and others could have if we turn on the setting "Use the new URL" Describe the solution you'd like -As this is only affecting a reduced number of users, the idea is to put some logic on the current code to convert the

Azure Devops Organization Name

to lowercase so the plans coming from both service hooks (v1.0 & v2.0) can be saved in the same folder. In order to achieve this, the plan is to have an environment variable called

ATLANTIS_AZUREDEVOPS_LEGACY_URL_ISSUE

= true (I'm totally open to suggestions to change this name if needed) and the users affected will have this value on true. -For unaffected users the variable value will be false by default if it's not specified. -We'll include some logic to do the conversion of the ADOrganization to lowercase, if it's on false, nothing will happen.(I'll update the ticket with more details when I get to the Azure Controller Code, didn't explore it yet) Describe the drawbacks of your solution The drawback is that this effort won't be useful if Azure forces the migration to the new url in the future. The migration was announced back on 2018 (Article here) but more than 6 years passed and there is no official date where they are going to enforce the usage of the new url. Since that is not going to happen in the near future it seems like a really small risk. Also this feature could and should be easily removed if that happens in the near future. Describe alternatives you've considered Alternatives to this issue are enabling the New URL Setting on the Azure Devops Organization but this is a big risk since it can affect:

1. Git remotes
2. CI/CD pipelines
3. Service connections (OAuth or service connections that use hardcoded repository/project URLs may break or need manual updates)
4. Webhooks and integrations
5. Manual bookmarks, documentation, or wikis
6. API consumers / scripts
7. Azure Repos badges
8. Git submodules

Image Link The Current Hotfix: If you are being affected by this issue, the best thing to do is disabling the

2)Pull request updated (version 1.0) and 3)Pull request created (version 1.0)

service hooks. Considerations: you will loose the ability to auto-plan and auto-unlock the PRs automatically. But you can easily solve this by running

atlantis plan

when the PR is created, and

atlantis unlock

after you applied and merged your PR What happens when I disable service hooks for v1.0? Atlantis uses the same folder for all operations

/home/atlantis/.atlantis/repos/MYCompany/

to save the plans and doesn't have any errors How this feature will be developed 1)I will rely on the Atlantis community, first looking and understanding the code and the controllers that could help on solving this issue 2)I will propose 1 or more ideas to solve this issue 3)I will create a Pull Request to get reviews and feedback 4)I will test this issue before merging the PR on 1 Azure Devops Organization that is having this issue with a testing connected repository to create a terraform resource and confirm that the solution works as expected runatlantis/atlantis

#5318 Atlantis does not set Env variables when `output: hide` in multienv Issue created by hkobayash ### 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. --- ### Overview of the Issue When using the multienv command in a custom workflow, if

hide

is set for

multienv.output

, the environment variables will not be set. ### Reproduction Steps workflows: default: plan: steps: - multienv: command: echo TF_VAR_TEST1=test1 output: show - multienv: command: echo TF_VAR_TEST2=test2 output: hide - run: echo $TF_VAR_TEST1 - run: echo $TF_VAR_TEST2 ### Logs Ran Plan for project:

test

dir:

test

workspace:

default

Dynamic environment variables added: TF_VAR_TEST1 test1 • 🔁 To plan this project again, comment: atlantis plan -p test ### Environment details • Atlantis version: v0.33.0 • Deployment method: ecs ### Additional Context https://www.runatlantis.io/docs/custom-workflows#multiple-environment-variables-multienv-command runatlantis/atlantis

#5601 Atlantis panics if you plan or apply on an issue Issue created by jasonodonnell ### 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. --- ### Overview of the Issue If you

atlantis plan

or

atlantis apply

on an issue by accident, it causes a panic:

runtime error: invalid memory address or nil pointer dereference
runtime/panic.go:262 (0x4776d8)
runtime/signal_unix.go:925 (0x4776a8)
<http://github.com/runatlantis/atlantis/server/events/event_parser.go:576|github.com/runatlantis/atlantis/server/events/event_parser.go:576> (0x121b7b3)
<http://github.com/runatlantis/atlantis/server/events/command_runner.go:414|github.com/runatlantis/atlantis/server/events/command_runner.go:414> (0x120ea61)
<http://github.com/runatlantis/atlantis/server/events/command_runner.go:485|github.com/runatlantis/atlantis/server/events/command_runner.go:485> (0x121030a)
<http://github.com/runatlantis/atlantis/server/events/command_runner.go:335|github.com/runatlantis/atlantis/server/events/command_runner.go:335> (0x120d3cf)
runtime/asm_amd64.s:1700 (0x47cfc0)

### Reproduction Steps Comment

atlantis plan

or

atlantis apply

on an issue. runatlantis/atlantis

#5602 Hide projects with no steps in their workflows from Atlantis output Issue created by maschsyn ### 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 We use Terraform workspaces for different deployment environments like dev, staging, and prod. We want

atlantis plan

to plan all of these environments to give us as much confidence as possible that pull requests will roll out safely, but we want

atlantis apply

to apply only dev workspaces because we roll out changes to the other environments on a delayed and predictable schedule for reliability reasons. We are currently achieving this by configuring the projects for non-dev workspaces to use a “plan-only” custom workflow that has

apply = { steps = [] }

. This seems to basically work fine; the projects are planned but not applied. In fact, the documentation indicates that this usage is supported:

If the steps key is empty, no steps will be run for this stage.

However, when

atlantis apply

is run, the projects with no-op apply stages are still displayed in the output, accompanied by the following text:

Found no template. This is a bug!

This causes confusion for some users, who see that staging and prod projects were “applied”, not understanding that these applications are not actually doing anything. It also makes it harder to tell exactly what was applied. Describe the solution you'd like If no steps are provided for a stage for a project’s workflow, doesn’t it make sense to elide the project entirely from the output for that stage since there is nothing useful to say? In fact, if possible I think it would even make sense to prune such projects from the list before any work is done -- as though, from the perspective of that stage, those projects never existed in the first place. Describe the drawbacks of your solution In certain circumstances, hiding projects from the output may cause more confusion rather than less. If this is a concern, an alternative idea would be to add an extra argument to the

Stage

object like

hide_output: true

, allowing the user to explicitly decide whether output should be shown for that custom workflow or not. It’s quite possible there are some side effects of pruning projects from a stage that make it impractical or undesirable. I don’t understand Atlantis’s internals well enough to guess what those might be. Describe alternatives you've considered The alternative is to simply deal with the empty output of the no-op apply steps showing up in Atlantis’s output. This is a minor usability nuisance but doesn’t interfere with the core functionality. Another option is to not use Atlantis for plan-only workflows and do the plan validation with a separate script instead. This is unfortunate, as a large part of Atlantis’s attraction is in the way it centralizes the information in the pull request comments. runatlantis/atlantis

#5603 Atlantis compatibility with Github merge queue Issue created by helennzhang ### 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 Github released support for a merge queue back in 2023. https://github.blog/news-insights/product-news/github-merge-queue-is-generally-available/ Unfortunately, with the way the merge queue is implemented, it requires running the same status checks pre-merge as in the merge queue. This means that if Atlantis is configured as a pre-merge branch status check, it will also be a required status check in the queue. One major issue with this is that Atlantis doesn't currently process the type of webhook that a merge queue emits. Merge queues emit

merge_group

and

push

webhooks. Currently, Atlantis only supports

pull_request

and

comment

webhooks. This means that Atlantis ignores the merge queue request for status checks entirely and leaves PRs in the queue in a hanging state. This makes it impossible to use Atlantis with a Github merge queue. Describe the solution you'd like Have Atlantis also consume merge_group webhooks from Github and send an immediate status check success response back to Github. Describe the drawbacks of your solution Doesn't provide any additional logic/things to actually check on PRs in the queue. It will make the atlantis check essentially a no-op Describe alternatives you've considered I don't know if there is an alternative to this if we want to enable a merge queue in Github? runatlantis/atlantis

#5604 Atlantis directory is ignored if explorer.excludeGitIgnore is true on VSCode settings. Issue created by rafaeldasilva ### 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. --- ### Overview of the Issue The setting explorer.excludeGitIgnore described at issue enable Explorer to hide files and folder based on .gitignore file. The

git clone <https://github.com/runatlantis/atlantis>

will use the repository name (atlantis) to name it's directory by default. Since it is ignored on .gitignore it will disappear from Explorer. ### Reproduction Steps Enable the explorer.excludeGitIgnore on VSCode settings Clone the repo with default name

git clone <https://github.com/runatlantis/atlantis>

Click on the "atlantis" folder on the VSCode Explorer ### Environment details • Atlantis version: v0.34.0 • VSCode version: 1.100.3 runatlantis/atlantis

#5614 renovate is no longer working after recent config migration Issue created by nitrocode ### 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. --- ### Overview of the Issue ### Reproduction Steps Not a single pr was created since apr 30 https://github.com/runatlantis/atlantis/pulls/app%2Frenovate I manually kicked off a specific pr creation today and it did create a pr. But why wont it auto create? This pr #5613 kicked off and i see these errors

/bin/sh: 1: apk: not found

I wonder if the prs arent getting created due to failing pr checks ### Logs Log of job manually kicked off https://developer.mend.io/github/runatlantis/atlantis/-/job/01975e13-d6a7-7765-9517-c9792d246820 Log of last job that was not manually kicked off ### Environment details ### Additional Context • This issue is leading to manual PRs like this #5611 runatlantis/atlantis

#5615 Atlantis should post Pre Workflow Hooks failures if FailOnPreWorkflowHook is enabled Issue created by mowirth ### 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 If a preworkflow hook fails, its status is currently reported to the VCS Provider. However, the reason for the failure is not reported back to the end user, making it very hard to debug issues leading to the failure of the pre-workflow hook without having access to the atlantis logs. Describe the solution you'd like Atlantis should be able to post the output of the pre-workflow errors to the VCS provider (for example, Github). This would allow developers to see the failure reason, and that there was a failure and atlantis did not just crash without ever generating a plan. This feature can be protected by a feature flag, in case the pre-workflow hook result may contain sensitive information. ## Describe the drawbacks of your solution Describe alternatives you've considered Only relying on pipeline status is not sufficient, as it is very quickly overlooked and potentially hidden behind hundreds of other pipeline statuses. Furthermore, the pipeline status does not provide additional information about the failure reason. runatlantis/atlantis

#5616 Cloudformation stacks in terraform containing list items can show up as line removals due to the diff replacement regex Issue created by nitrocode ### 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. --- ### Overview of the Issue Cloudformation stacks in terraform containing list items can show up as line removals due to the diff replacement regex e.g. This yaml from a wiz stackset ManagedPolicyArns: - Fn:Sub arn:${AWS:Partition}iam:awspolicy/job-function/ViewOnlyAccess - Fn:Sub arn:${AWS:Partition}iam:awspolicy/SecurityAudit gets converted to this incorrectly ManagedPolicyArns: - Fn:Sub arn:${AWS:Partition}iam:awspolicy/job-function/ViewOnlyAccess - Fn:Sub arn:${AWS:Partition}iam:awspolicy/SecurityAudit However, this gets converted semi-correctly - isOrg: - AllowedValues: - - Enabled - - Disabled - Default: Disabled - Description: Enable org deploy - Type: String - orgId: - Default: "" - Description: The OU ID of the AWS Organization where we should deploy, preferably the root OU. This value is mandatory when isOrg is Enabled. You can submit one value, or a space separated list of multiple OUs - Type: String + # isOrg: + # AllowedValues: + # - Enabled + # - Disabled + # Default: Disabled + # Description: Enable org deploy + # Type: String + # orgId: + # Default: "" + # Description: The OU ID of the AWS Organization where we should deploy, preferably the root OU. This value is mandatory when isOrg is Enabled. You can submit one value, or a space separated list of multiple OUs + # Type: String to this - isOrg: + # isOrg: - AllowedValues: + # AllowedValues: - - Enabled + # - Enabled - - Disabled + # - Disabled - Default: Disabled + # Default: Disabled - Description: Enable org deploy + # Description: Enable org deploy - Type: String + # Type: String - orgId: + # orgId: - Default: "" + # Default: "" - Description: The OU ID of the AWS Organization where we should deploy, preferably the root OU. This value is mandatory when isOrg is Enabled. You can submit one value, or a space separated list of multiple OUs + # Description: The OU ID of the AWS Organization where we should deploy, preferably the root OU. This value is mandatory when isOrg is Enabled. You can submit one value, or a space separated list of multiple OUs - Type: String + # Type: String ### Reproduction Steps I'm having trouble reproducing this Here is the related code atlantis/server/events/models/models.go Lines 428 to 441 in</runatlantis/atlantis/commit/a7c712b921d9c4de15bd70d035c95be9a667a4c2|a7c712b> | var ( | | ---------------------------------------------------------------------------------------------------------------------------- | | diffKeywordRegex = regexp.MustCompile(

(?m)^( +)([-+~]\s)(.*)(\s=\s\|\s->\s|<<|\{|\(known after apply\)| {2,}[^ ]+:.*)(.*)

) | | diffListRegex = regexp.MustCompile(

(?m)^( +)([-+~]\s)(".*",)

) | | diffTildeRegex = regexp.MustCompile(

(?m)^~

) | | ) | | | | // DiffMarkdownFormattedTerraformOutput formats the Terraform output to match diff markdown format | | func (p PlanSuccess) DiffMarkdownFormattedTerraformOutput() string { | | formattedTerraformOutput := diffKeywordRegex.ReplaceAllString(p.TerraformOutput, "$2$1$3$4$5") | | formattedTerraformOutput = diffListRegex.ReplaceAllString(formattedTerraformOutput, "$2$1$3") | | formattedTerraformOutput = diffTildeRegex.ReplaceAllString(formattedTerraformOutput, "!") | | | | return strings.TrimSpace(formattedTerraformOutput) | | } | Here is the regexr reproduction using 1. DiffKeywordRegex https://regexr.com/8fdf9 2. DiffListRegex https://regexr.com/8fden I believe the above contents are getting picked up by the former. ### Logs ### Environment details • Atlantis version: 0.34.0 • Deployment method: eks • If not running the latest Atlantis version have you tried to reproduce this issue on the latest version: • Atlantis flags: n/a ## options 1. Improve the regex to exclude yaml lists somehow 2. Exempt aws_cloudformation_stack resources from the diff conversion 3. Use hcl instead of diff and don't modify the terraform output at all ### Additional Context • aws_cloudformation_stack • #2438 runatlantis/atlantis

#5620 no effected states after atlantis unlock Issue created by Slevy35 ### 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. --- ### Overview of the Issue after creating a PR, atlantis recognize the effected states and run plan. but after running

atlantis unlock

and immediately after

atlantis apply

which cause atlatis to think there's no effected states. we also enable auto merge after apply, which merged the PR. ### Reproduction Steps • create a PR • comment

atlantis unlock

• comment

atlantis apply

### Logs ### Environment details • Atlantis version: v0.34.0 • Atlantis flags: auto merge ### Additional Context [Image](https://private-user-images.githubusercontent.com/35378572/456127804-ae3871e1-db48-4942-95cd-75b96b3cc042.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTAxODExODQsIm5iZiI6MTc1MDE4MDg4NCwicGF0aCI6Ii8zNTM3ODU3Mi80NTYxMjc4MDQtYWUzODcxZTEtZGI0OC00OTQyLTk1Y2QtNzViOTZiM2NjMDQyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA2MTclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNjE3VDE3MjEyNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTFlYmI0YmU3MWUyYTYxMTFhNDA1N2FjYjgxYmIyYTUyMTgwMDg1OGRiYzljZTMwZDcxYjM5YjQ1M2M0ZmE2MGYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.1I5L_nwzgHSU0ymLlnHACtHrHYNNZzESLkdTMbSa77g) [Image](https://private-user-images.githubusercontent.com/35378572/456127738-4eab8b52-2e23-4d5b-a184-989d08d1ec00.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTAxODExODQsIm5iZiI6MTc1MDE4MDg4NCwicGF0aCI6Ii8zNTM3ODU3Mi80NTYxMjc3MzgtNGVhYjhiNTItMmUyMy00ZDViLWExODQtOTg5ZDA4ZDFlYzAwLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA2MTclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNjE3VDE3MjEyNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTM3NDBjNjBjNzY0NDQ2NTAwYThkMTk5ZjMzMDMyYjY5YTk2MzlmODcyZmExZDQ0Mjk0MzM4MTA3NjZlMWFkMjMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.nFxlYwGvp920Omuk8ot1QVy8dan85CMTapmF0YUuaRg) runatlantis/atlantis

#5627 Make `-parallelism` a command flag Issue created by norman-zon ### 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 There are some cases, where I know that it will lead to race conditions when running

apply

in parallel. One example being Terraform resources that create git commits. But this are a rare exception in my repo, so I want to set

ATLANTIS_PARALLEL_POOL_SIZE<0

and

ATLANTIS_PARALLEL_APPLY=true

for my server/repo and also be able to overwrite the behaviour when invoking atlantis for this single PR. Describe the solution you'd like I would like to be able to use something like

atlantis apply -parallelism 1

to be able to apply all plans, but sequentially. Describe the drawbacks of your solution It would be sensible to not allow to set

-parallelism

higher than

ATLANTIS_PARALLEL_POOL_SIZE

to not let the user overload the instance. Aside from this I see no issues. Describe alternatives you've considered Technically it would be possible to set

parallel_apply: false

in the repo config, for a single PR and revert it afterwards, but that's far from ideal. runatlantis/atlantis

#5568 Atlantis lock issue Issue created by yasinlachiny ### 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. --- ### Overview of the Issue In our current Atlantis setup, we explicitly configure Atlantis to lock on apply only — not on plan. This behavior is intentional to ensure that once a user has applied changes, no one else can override or interfere with those changes until the PR is merged. However, we've encountered an edge case: if a user runs atlantis plan or rebases the branch after apply but before merging the PR, the original apply lock is silently removed. This unlocks the PR and allows further plans or applies by others, violating the expected safety of the post-apply lock. This is not the intended behavior. Even though plan should not trigger a lock, we do not expect it to clear an existing apply lock. The lock should persist until the PR is merged, regardless of whether a new plan is executed. ### Reproduction Steps Open a PR and run atlantis plan. Run atlantis apply – this locks the PR (as per our config). Before merging the PR: Run atlantis plan again Observe that the lock is removed and the PR becomes unlocke ### Logs ### Environment details ### Additional Context runatlantis/atlantis

#773 Atlantis apply all after a failed apply; outputs Ran Apply for 0 projects Issue created by mlehner616 I have a repo that uses the default workspace but there are a number of different project folders. Atlantis version: 0.8.3 Terraform version: v0.12.8

version: 3
projects:
  - name: qa
    dir: qa_acct/qa_env
    terraform_version: v0.12.8
    autoplan:
      when_modified: ["../../projects/*", "*.tf*", "../../modules/*"]
      enabled: false
  - name: staging
    dir: prod_acct/staging_env
    terraform_version: v0.12.8
    autoplan:
      when_modified: ["../../projects/*", "*.tf*", "../../modules/*"]
      enabled: false
  - name: prod
    dir: prod_acct/prod_env
    terraform_version: v0.12.8
    autoplan:
      when_modified: ["../../projects/*", "*.tf*", "../../modules/*"]
      enabled: false

Plans are generated for all three projects as normal after commenting exactly

atlantis plan

. Immediately afterword, commenting

atlantis apply

attempts to apply all three environments as expected. In this case, there was an apply error due to an AWS IAM policy being misconfigured and the plans were not successfully applied. A commit was pushed to fix this issue and another

atlantis apply

was submitted. Note, there was not another

atlantis plan

after the fix commit was pushed. Atlantis behaved as if it had forgotten about the failed plans and assumed they had been applied successfully when, in fact, they had not been. I believe the expected behavior should be to reject the apply since new commits were made and force another plan be run, correct? The result was the following:

Ran Apply for 0 projects:

Automatically merging because all plans have been successfully applied.

Locks and plans deleted for the projects and workspaces modified in this pull request:

* dir: `prod_acct/prod_env` workspace: `default`
* dir: `prod_acct/staging_env` workspace: `default`
* dir: `qa_acct/qa_env` workspace: `default`

runatlantis/atlantis

#4850 `/api/plan` throws 500 error when using GitHub App Issue created by marcus-rev ### 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. --- ### Overview of the Issue I have some automation that's firing off a POST to

/api/plan

but is receiving a 500 error back. When checking the logs of Atlantis server, I see that Atlantis is trying to pull

pull/0/head

which doesn't work. We're also using the

merge

checkout strategy. To fix this issue, I believe we should add the

c.pr.Num > 0

condition to this if check, as the pr number is an optional parameter to plan/apply API endpoints: atlantis/server/events/working_dir.go Line 334 in</runatlantis/atlantis/commit/42e2dc706b97cf542137c9c076f56d48f57cb23c|42e2dc7> | if w.GithubAppEnabled { | | ----------------------- | ### Reproduction Steps Set ATLANTIS_CHECKOUT_STRATEGY=merge Note that the PR parameter is optional, and as such, is omitted:

curl --request POST 'https://<ATLANTIS_HOST_NAME>/api/plan' \
--header 'X-Atlantis-Token: <ATLANTIS_API_SECRET>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "Repository": "repo-name",
    "Ref": "main",
    "Type": "Github",
    "Paths": [{
      "Directory": ".",
      "Workspace": "default"
    }],
}'

### Logs

[
    {
        "level": "info",
        "ts": "2024-08-16T14:33:16.101Z",
        "caller": "events/working_dir.go:235",
        "msg": "creating dir '/atlantis-data/repos/<myorg/my-repo-name>/0/default'",
        "json": {}
    },
    {
        "level": "error",
        "ts": "2024-08-16T14:33:18.541Z",
        "caller": "events/instrumented_project_command_builder.go:75",
        "msg": "Error building plan commands: running git fetch origin pull/0/head:: fatal: couldn't find remote ref pull/0/head\n: exit status 128",
        "json": {},
        "stacktrace": "<http://github.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).buildAndEmitStats|github.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).buildAndEmitStats>\n\tgithub.com/runatlantis/atlantis/server/events/instrumented_project_command_builder.go:75\ngithub.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).BuildPlanCommands\n\tgithub.com/runatlantis/atlantis/server/events/instrumented_project_command_builder.go:35\ngithub.com/runatlantis/atlantis/server/controllers.(*APIRequest).getCommands\n\tgithub.com/runatlantis/atlantis/server/controllers/api_controller.go:67\ngithub.com/runatlantis/atlantis/server/controllers.(*APIController).apiPlan\n\tgithub.com/runatlantis/atlantis/server/controllers/api_controller.go:148\ngithub.com/runatlantis/atlantis/server/controllers.(*APIController).Plan\n\tgithub.com/runatlantis/atlantis/server/controllers/api_controller.go:93\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2171\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\tgithub.com/gorilla/mux@v1.8.1/mux.go:212\ngithub.com/urfave/negroni/v3.(*Negroni).UseHandler.Wrap.func1\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:59\ngithub.com/urfave/negroni/v3.HandlerFunc.ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:33\ngithub.com/urfave/negroni/v3.middleware.ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:51\ngithub.com/runatlantis/atlantis/server.(*RequestLogger).ServeHTTP\n\tgithub.com/runatlantis/atlantis/server/middleware.go:70\ngithub.com/urfave/negroni/v3.middleware.ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:51\ngithub.com/urfave/negroni/v3.(*Recovery).ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/recovery.go:210\ngithub.com/urfave/negroni/v3.middleware.ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:51\ngithub.com/urfave/negroni/v3.(*Negroni).ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:111\nnet/http.serverHandler.ServeHTTP\n\tnet/http/server.go:3142\nnet/http.(*conn).serve\n\tnet/http/server.go:2044"
    },
    {
        "level": "warn",
        "ts": "2024-08-16T14:33:18.541Z",
        "caller": "controllers/api_controller.go:261",
        "msg": "{\"error\":\"failed to build command: running git fetch origin pull/0/head:: fatal: couldn't find remote ref pull/0/head\\n: exit status 128\"}",
        "json": {},
        "stacktrace": "<http://github.com/runatlantis/atlantis/server/controllers.(*APIController).respond|github.com/runatlantis/atlantis/server/controllers.(*APIController).respond>\n\tgithub.com/runatlantis/atlantis/server/controllers/api_controller.go:261\ngithub.com/runatlantis/atlantis/server/controllers.(*APIController).apiReportError\n\tgithub.com/runatlantis/atlantis/server/controllers/api_controller.go:81\ngithub.com/runatlantis/atlantis/server/controllers.(*APIController).Plan\n\tgithub.com/runatlantis/atlantis/server/controllers/api_controller.go:95\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2171\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\tgithub.com/gorilla/mux@v1.8.1/mux.go:212\ngithub.com/urfave/negroni/v3.(*Negroni).UseHandler.Wrap.func1\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:59\ngithub.com/urfave/negroni/v3.HandlerFunc.ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:33\ngithub.com/urfave/negroni/v3.middleware.ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:51\ngithub.com/runatlantis/atlantis/server.(*RequestLogger).ServeHTTP\n\tgithub.com/runatlantis/atlantis/server/middleware.go:70\ngithub.com/urfave/negroni/v3.middleware.ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:51\ngithub.com/urfave/negroni/v3.(*Recovery).ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/recovery.go:210\ngithub.com/urfave/negroni/v3.middleware.ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:51\ngithub.com/urfave/negroni/v3.(*Negroni).ServeHTTP\n\tgithub.com/urfave/negroni/v3@v3.1.0/negroni.go:111\nnet/http.serverHandler.ServeHTTP\n\tnet/http/server.go:3142\nnet/http.(*conn).serve\n\tnet/http/server.go:2044"
    }
]

### Environment details • Atlantis version: latest • Deployment method: eks • If not running the latest Atlantis version have you tried to reproduce this issue on the latest version: • Atlantis flags:

ATLANTIS_CHECKOUT_STRATEGY=merge

runatlantis/atlantis

#5629 --default-tf-version does not take precedence over require_version &gt;= Issue created by eneves-emarketer When using atlantis 0.33.0, even with the flag "--default-tf-version" (actually ATLANTIS_DEFAULT_TF_VERSION in docker compose set to v1.9.8 and ATLANTIS_ALLOW_TERRAFORM_DOWNLOADS = true), the terraform version that was being used in tf plan and apply was 1.12.2 (having required_version = ">= 1.1.0" in the terraform code). No terraform flag enforced in the atlantis.yaml file. As per the documentation the flag to enforce the default tf version should enforce the expected version. runatlantis/atlantis

#5630 Autoplan creates pending GitHub Check regardless of project changes since v0.33 Issue created by artych ### 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. --- ### Overview of the Issue Starting from v0.33, we've observed that a GitHub CI check is deliberately created in the "pending" state during the autoplan run, regardless of whether any projects have changed files. Prior to v0.33, a check status was only created if changes were detected in one or more projects. Looking at the v0.33 changes, we suspect this behavior is a side effect of PR #5242. Previously, the creation of the check status was gated behind the condition

if len(projectCmds) > 0

, but this logic appears to have been removed in that update. Perhaps this is an intentional change, but we haven’t found any mention or documentation of it in the release notes or related discussions. Clarification would be appreciated. ### Reproduction Steps Reproducing the issue should be straightforward. We've consistently seen the

atlantis/plan

check remain in a pending state on every pull request since upgrading to v0.33. runatlantis/atlantis