#3686 Donate project to "Cloud Native Computing Foundation" (CNCF) or similar for longevity 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. --- • I'd be willing to implement this feature (contributing guide) Describe the user story I'd like to create this issue to propose donation to CNCF to • add more contributors to atlantis • help remove the notion that corporate interests hold back this project • keep this project going as long as possible This is for open source and for all of these companies that currently use atlantis. This is also for all the companies that cannot afford a SaaS or simply want to self-host. Describe the solution you'd like This project should be donated to an organization such as CNCF. Once it's incubating in CNCF, more contributors will join the efforts to keep this project alive. We get more benefits once it has incubated and finally graduated. The first step is to get approval from HashiCorp to submit this project to CNCF or better yet have HashiCorp submit it. 😄 NOTE:

DD

is

Due Diligence

There are so many examples of successful projects in CNCF such as kubernetes, argocd, helm, flux, etcd, prometheus, etc. Let's make atlantis part of that list! --- The current license for atlantis is Apache Licence 2.0 and there is no CLA for this repo. https://github.com/runatlantis/atlantis/blob/main/LICENSE References • https://www.cncf.io/projects/ • https://github.com/cncf/toc/blob/main/process/project_proposals.md • https://github.com/cncf/toc/blob/main/process/sandbox.md • https://enrollment.lfx.linuxfoundation.org/?project=cncf • https://www.reddit.com/r/kubernetes/comments/tqhdr2/reasons_not_to_donate_an_opensource_project_to/ runatlantis/atlantis

#5389 Atlantis runs plans on PRs even when no files matching when_modified patterns have changed Issue created by knjoroge ### 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 is running plans on all pull requests, even when no files matching the patterns in the when_modified configuration have been modified. This is causing unnecessary plan executions and blocking the auto-merging of pull requests. This configuration has been working just fine. This started occurring about a week or two ago. Have any recent updates introduced a bug? --- ### Environment details Atlantis version: 0.33.0 Deployment method: Terraform module https://github.com/runatlantis/terraform-gce-atlantis VCS: GitHub Terraform version: v1.6.3 --- ### Logs [Image](https://private-user-images.githubusercontent.com/18235897/419884927-da9b2a16-0f6c-4a7c-9592-1007cad6ee50.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDE2OTM4NjIsIm5iZiI6MTc0MTY5MzU2MiwicGF0aCI6Ii8xODIzNTg5Ny80MTk4ODQ5MjctZGE5YjJhMTYtMGY2Yy00YTdjLTk1OTItMTAwN2NhZDZlZTUwLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAzMTElMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMzExVDExNDYwMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWIxNGE0ZTc0MWM2MDUyMzMxMjNhMzNmYWM4MWViYTBiOTAwM2YyNzMxZmNjNWEwZjMyYWZlNDA0YzRmMjk2MDgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.2PIzGN4UtfMEYDPNQ_T5E9aP0mGUNbBl3R3KBxTCb_g) [Image](https://private-user-images.githubusercontent.com/18235897/419885153-85dfea25-083d-4a71-8946-fe3ba12ff80b.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDE2OTM4NjIsIm5iZiI6MTc0MTY5MzU2MiwicGF0aCI6Ii8xODIzNTg5Ny80MTk4ODUxNTMtODVkZmVhMjUtMDgzZC00YTcxLTg5NDYtZmUzYmExMmZmODBiLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAzMTElMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMzExVDExNDYwMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTk5ZTM1MGM5MWUyZGRmZTczODUwMmZiNWQyY2E5NmExZWJkYzM0OThiZWYwYTYwZDFkMTY2NGExOTU4MTAyMjEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.vE6Ljj7ngdKzOGD8ksihAtmkjI3tVttKh99H_Wt0DJk)

atlantis-server.yaml

file: repos: - id: github.com/xxxx/monorepo apply_requirements: [mergeable] allowed_overrides: [workflow]

Atlantis server flags:

ATLANTIS_SILENCE_VCS_STATUS_NO_PLANS = true
ATLANTIS_SILENCE_VCS_STATUS_NO_PROJECTS = true
ATLANTIS_SILENCE_NO_PROJECTS = true
ATLANTIS_HIDE_PREV_PLAN_COMMENTS = true
ATLANTIS_HIDE_UNCHANGED_PLAN_COMMENTS = true

atlantis.yaml

file: version: 3 projects: - name: 6-app-test-sandbox dir: infrastructure-gcp/6-app-test/environments/sandbox autoplan: when_modified: - '*.tf' - ../../modules/**/*.tf - ../../6-app-modules/**/*.tf - '**/*.tfvars' - ../../config/**/*.yaml - ../../modules/**/*.yaml workspace: default workflow: default terraform_version: v1.6.3 runatlantis/atlantis

#5391 Include the job url as a property to be used in a template Issue created by cpaloia ### 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 In certain cases, it's necessary to hide Terraform plan output in GitHub comments—such as in public repositories where the output may contain sensitive information. However, users may still need access to the plan details via a secure URL, such as one behind a firewall or ingress. By including the job URL in the GitHub comment template (in addition to the existing GitHub check link), we provide users with clear guidance on why the output is hidden and where they can access it instead. Describe the solution you'd like I would like to be able to use the job url in a github comment template Describe the drawbacks of your solution None that I can think of Describe alternatives you've considered It is a small change, so not many different options runatlantis/atlantis

#5393 If unset, env var `ATLANTIS_DATA_DIR` is empty even though there is a default 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 The

ATLANTIS_DATA_DIR

should default to

/home/atlantis/.atlantis

as per the FAQ https://www.runatlantis.io/docs/faq

Atlantis, by default, stores all locking and Terraform plans locally on disk under the --data-dir directory (defaults to ~/.atlantis).

This becomes an issue if the value is unset if you have yaml configuration file that references the env var instead of the hard coded value. The workaround is to always set the value so it can be references in the workflows yaml configs. ### Reproduction Steps Use ATLANTIS_DATA_DIR without setting it and it will throw an error because the env var is empty. ### Logs N/A ### Environment details N/A ### Additional Context N/A runatlantis/atlantis

#3741 Support OpenTofu (epic) 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. --- • I'd be willing to implement this feature (contributing guide) Describe the user story Please support usage of opentofu https://github.com/opentffoundation/opentf Describe the solution you'd like See above • #4337 • #4338 • #4339 Describe the drawbacks of your solution N/A Describe alternatives you've considered N/A runatlantis/atlantis

#5397 Team names for external authz script are not quoted, also breaks for multiple teams Issue created by grit ### 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 team names can include spaces. The Atlantis Go code passes the team names unquoted to the external authz shell script without them, breaking any ACLs you might write in the script since a team like "My Team" will be passed as separate arguments "My" and "Team". Also, if a user has multiple teams, there appears to be additional breakage, but I can't figure out what's going on. To fix the quoting issue, this might be a workable solution for server/events/external_team_allowlist_checker.go:

func (checker *ExternalTeamAllowlistChecker) buildCommandString(ctx models.TeamAllowlistCheckerContext, teams []string, command string) string {

  cmdArr := append([]string{checker.Command}, checker.ExtraArgs...)

  orgTeams := make([]string, len(teams))

  for i, team := range teams {
    // Properly quote the team name

    orgTeams[i] = fmt.Sprintf("%q", fmt.Sprintf("%s/%s", ctx.BaseRepo.Owner, team))
  }

  teamStr := strings.Join(orgTeams, " ")

  return strings.Join(append(cmdArr, command, ctx.BaseRepo.FullName, teamStr), " ")
}

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

#5415 Allow merge method as configurable option in atlantis.yaml Issue created by ahatzz11 ### 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 an engineer, I'd like all of my automerged atlantis PRs to use the squash merge method without having to specify a flag on every

atlantis apply

command. Describe the solution you'd like I'd love to be able to set the automerge method alongside the automerge enabled/disabled flag in

atlantis.yaml

An ideal configuration in the

atlantis.yaml

would look like: version: 3 automerge: true automerge-method: squash projects: ... --- Right now it's possible to set the

--auto-merge-method

flag on an

atlantis apply

command when

automerge: true

. It would be awesome to be able to set the

automerge-method

in the repo file so every

atlantis apply

uses that method. Our use case here is enforcing squash commits to our main branch, but atlantis automerging currently fails because the default merge method isn't allowed. This results in this error:

Automerging failed:

merging pull request: PUT <https://api.github.com/repos/FigureTechnologies/figure-infra/pulls/530/merge>: 405 Merge commits are not allowed on this repository. []

runatlantis/atlantis

#4339 Support OpenTofu auto download 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. --- • I'd be willing to implement this feature (contributing guide) Describe the user story Please support downloading of the opentf terraform fork instead of hashicorp terraform https://github.com/opentffoundation/opentf This may already be supported using

--tf-download-url

but it would be nice to have this officially documented so people can start using opentf instead of terraform for future releases. https://www.runatlantis.io/docs/server-configuration.html#tf-download-url Describe the solution you'd like See above Describe the drawbacks of your solution N/A Describe alternatives you've considered N/A --- • epic #3741 • Previous ticket #3727 • #1776 • https://github.com/warrensbox/terraform-switcher • warrensbox/terraform-switcher#315 --- atlantis/cmd/server.go Line 173 in</runatlantis/atlantis/commit/a793620475519d19c86caa01242a8bc6a125045e|a793620> | DefaultTFDownloadURL = "https://releases.hashicorp.com" | | ------------------------------------------------------- | atlantis/server/server.go Line 405 in</runatlantis/atlantis/commit/a793620475519d19c86caa01242a8bc6a125045e|a793620> | terraformClient, err := terraform.NewClient( | | -------------------------------------------- | atlantis/server/core/terraform/terraform_client.go Lines 239 to 253 in</runatlantis/atlantis/commit/a793620475519d19c86caa01242a8bc6a125045e|a793620> | func NewClient( | | --------------------------------------------------------- | | log logging.SimpleLogging, | | binDir string, | | cacheDir string, | | tfeToken string, | | tfeHostname string, | | defaultVersionStr string, | | defaultVersionFlagName string, | | tfDownloadURL string, | | tfDownloader Downloader, | | tfDownloadAllowed bool, | | usePluginCache bool, | | projectCmdOutputHandler jobs.ProjectCommandOutputHandler, | | ) (*DefaultClient, error) { | | return NewClientWithDefaultVersion( | atlantis/server/core/terraform/terraform_client.go Line 379 in</runatlantis/atlantis/commit/3ea2914e1637066f336f64984c41f62391632223|3ea2914> | _, err = ensureVersion(log, c.downloader, c.versions, v, c.binDir, c.downloadBaseURL, c.downloadAllowed) | | -------------------------------------------------------------------------------------------------------- | atlantis/server/core/terraform/terraform_client.go Lines 555 to 562 in</runatlantis/atlantis/commit/3ea2914e1637066f336f64984c41f62391632223|3ea2914> | log.Info("Could not find terraform version %s in PATH or %s, downloading from %s", v.String(), binDir, downloadURL) | | ------------------------------------------------------------------------------------------------------------------- | | urlPrefix := fmt.Sprintf("%s/terraform/%s/terraform_%s", downloadURL, v.String(), v.String()) | | binURL := fmt.Sprintf("%s_%s_%s.zip", urlPrefix, runtime.GOOS, runtime.GOARCH) | | checksumURL := fmt.Sprintf("%s_SHA256SUMS", urlPrefix) | | fullSrcURL := fmt.Sprintf("%s?checksum=file:%s", binURL, checksumURL) | | if err := dl.GetFile(dest, fullSrcURL); err != nil { | | return "", errors.Wrapf(err, "downloading terraform version %s at %q", v.String(), fullSrcURL) | | } | atlantis/server/core/terraform/terraform_client.go Line 538 in</runatlantis/atlantis/commit/3ea2914e1637066f336f64984c41f62391632223|3ea2914> | binFile := "terraform" + v.String() | | ----------------------------------- | Listing versions atlantis/server/core/terraform/terraform_client.go Line 304 in</runatlantis/atlantis/commit/3ea2914e1637066f336f64984c41f62391632223|3ea2914> | versions, err := lib.GetTFList(url, true) | | ----------------------------------------- | --- The terraform url is constructed • url =

<https://releases.hashicorp.com>

• format string =

%s/terraform/%s/terraform_%s

, prefix, version, version •

%s_%s_%s.zip

, prefix, os, arch • full url

<https://releases.hashicorp.com/terraform/1.5.7/terraform_1.5.7_darwin_amd64.zip>

Opentofu • url =

<https://github.com/opentofu/opentofu/releases>

• format string =

%s/download/%s/tofu_%s

, prefix, version, version •

%s_%s_%s.zip

, prefix, os, arch • full url

<https://github.com/opentofu/opentofu/releases/download/v1.6.0-alpha4/tofu_1.6.0-alpha4_darwin_amd64.zip>

Seems like the following changes are needed • overriding the url string • this can be done already • overriding the format string with a new flag • simplifying default format string to use

%[2]s

to remove redundant argument • a way to search opentf versions to know which version to download • https://releases-page.opentofu-get.pages.dev/tofu/ • opentofu/opentofu#928 • opentofu/get.opentofu.org#16 • #4339 • opentofu/get.opentofu.org#22 • opentofu-enabled flag • change the name of the binary downloaded • allow a required_version block at … runatlantis/atlantis

#4338 Document custom hcl binary (such as opentofu) and version 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. --- • I'd be willing to implement this feature (contributing guide) Describe the user story Allow an easy path for opentofu for early adopters Describe the solution you'd like Document how to use a custom terraform binary whether it's open tofu or hashicorp terraform Document using native terraform without a wrapper like terragrunt/atmos/terramate Document with a wrapper Document how to download a custom version. This can on the same document if written generically. Describe the drawbacks of your solution Temporary workaround Describe alternatives you've considered N/A References • relates to user's manual opentofu steps in epic #3741 (comment) • relates to #4337 runatlantis/atlantis

#5425 bbolt : page 11 already freed Issue created by drmaciej ### 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 Every

plan

and

apply

fails the same way, with

page 11 already freed

. It fails whether or not I specify

-p

. The actual terraform

plan

and

apply

operations run fine - the problem is with posting a summary in GH and marking the "parent" GH check as successful - the check stays in e.g.

atlantis/plan Plan in progress...

. ### Reproduction Steps Just need to run a

plan

. ### Logs

2025-03-18T23:24:52.2671106Z {"level":"info","ts":"2025-03-18T23:24:52.266Z","caller":"models/shell_command_runner.go:181","msg":"successfully ran 'sh -c' '/home/atlantis/.atlantis/bin/terraform1.7.5 plan -input=false -refresh -out \"/home/atlantis/.atlantis/repos/*redacted*/*redacted*/535/*redacted*/environment/environment-*redacted*-*redacted*.tfplan\" -var-file variables/common.tfvars -var-file variables/$WORKSPACE.tfvars' in '/home/atlantis/.atlantis/repos/*redacted*/*redacted*/535/*redacted*/environment'","json":{"repo":"*redacted*/*redacted*","pull":"535","duration":73.903894794}}
2025-03-18T23:24:52.2807116Z {"level":"info","ts":"2025-03-18T23:24:52.280Z","caller":"vcs/github_client.go:923","msg":"Updating GitHub Check status for 'atlantis/plan: environment-*redacted*' to 'success'","json":{"repo":"*redacted*/*redacted*","pull":"535"}}
2025-03-18T23:24:52.7857766Z {"level":"info","ts":"2025-03-18T23:24:52.785Z","caller":"events/instrumented_project_command_runner.go:88","msg":"plan success. output available at: <https://github.com/*redacted*/*redacted*/pull/535%22,%22json%22:{%22repo%22:%22*redacted*/*redacted*%22,%22pull%22:%22535%22}}|https://github.com/*redacted*/*redacted*/pull/535","json":{"repo":"*redacted*/*redacted*","pull":"535"}}>
2025-03-18T23:24:53.6045913Z {"level":"error","ts":"2025-03-18T23:24:53.604Z","caller":"events/command_runner.go:555","msg":"PANIC: page 11 already freed\<http://ngo.etcd.io/bbolt@v1.3.11/freelist.go:175|ngo.etcd.io/bbolt@v1.3.11/freelist.go:175> (0xb649f3)\<http://ngo.etcd.io/bbolt@v1.3.11/node.go:363|ngo.etcd.io/bbolt@v1.3.11/node.go:363> (0xb68871)\<http://ngo.etcd.io/bbolt@v1.3.11/node.go:350|ngo.etcd.io/bbolt@v1.3.11/node.go:350> (0xb6877d)\<http://ngo.etcd.io/bbolt@v1.3.11/bucket.go:592|ngo.etcd.io/bbolt@v1.3.11/bucket.go:592> (0xb5cea4)\<http://ngo.etcd.io/bbolt@v1.3.11/bucket.go:559|ngo.etcd.io/bbolt@v1.3.11/bucket.go:559> (0xb5cc44)\<http://ngo.etcd.io/bbolt@v1.3.11/tx.go:164|ngo.etcd.io/bbolt@v1.3.11/tx.go:164> (0xb6b398)\<http://ngo.etcd.io/bbolt@v1.3.11/db.go:893|ngo.etcd.io/bbolt@v1.3.11/db.go:893> (0xb62109)\<http://ngithub.com/runatlantis/atlantis/server/core/db/boltdb.go:323|ngithub.com/runatlantis/atlantis/server/core/db/boltdb.go:323> (0xb73129)\<http://ngithub.com/runatlantis/atlantis/server/events/db_updater.go:26|ngithub.com/runatlantis/atlantis/server/events/db_updater.go:26> (0x115e057)\<http://ngithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:268|ngithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:268> (0x1171a25)\<http://ngithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:298|ngithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:298> (0x1172164)\<http://ngithub.com/runatlantis/atlantis/server/events/command_runner.go:401|ngithub.com/runatlantis/atlantis/server/events/command_runner.go:401> (0x115478c)\nruntime/asm_amd64.s:1700 (0x478960)\n","json":{"repo":"*redacted*/*redacted*","pull":"535"},"stacktrace":"<http://github.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).logPanics|github.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).logPanics>\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:555\nruntime.gopanic\n\truntime/panic.go:785\ngo.etcd.io/bbolt.(*freelist).free\n\tgo.etcd.io/bbolt@v1.3.11/freelist.go:175\ngo.etcd.io/bbolt.(*node).spill\n\tgo.etcd.io/bbolt@v1.3.11/node.go:363\ngo.etcd.io/bbolt.(*node).spill\n\tgo.etcd.io/bbolt@v1.3.11/node.go:350\ngo.etcd.io/bbolt.(*Bucket).spill\n\tgo.etcd.io/bbolt@v1.3.11/bucket.go:592\ngo.etcd.io/bbolt.(*Bucket).spill\n\tgo.etcd.io/bbolt@v1.3.11/bucket.go:559\ngo.etcd.io/bbolt.(*Tx).Commit\n\tgo.etcd.io/bbolt@v1.3.11/tx.go:164\ngo.etcd.io/bbolt.(*DB).Update\n\tgo.etcd.io/bbolt@v1.3.11/db.go:893\ngithub.com/runatlantis/atlantis/server/core/db.(*BoltDB).UpdatePullWithResults\n\tgithub.com/runatlantis/atlantis/server/core/db/boltdb.go:323\ngithub.com/runatlantis/atlantis/server/events.(*DBUpdater).updateDB\n\tgithub.com/runatlantis/atlantis/server/events/db_updater.go:26\ngithub.com/runatlantis/atlantis/server/events.(*PlanCommandRunner).run\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:268\ngithub.com/runatlantis/atlantis/server/events.(*PlanCommandRunner).Run\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:298\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).RunCommentCommand\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:401"}

### Environment details We run Atlantis on Azure App Service, as a Web App. Atlantis version: v0.33.0 (commit: 618d5ac) (build date: 2025-02-03T202138.676Z) Deployment method: Terraform. ### Additional Context This appears to have started happening on December 6, while we were on v0.30.0. We then tried v0.31.0, v0.32.0 and v0.33.0 - the issue persists. The last PR that was fine was actually us removing two repos from the allowlist and leaving just one repo in there. Following the change, we have:

ATLANTIS_REPO_ALLOWLIST=<http://github.com/*redacted*/azure-*redacted*|github.com/*redacted*/azure-*redacted*>

runatlantis/atlantis

#5433 [feature request] indicate which project/dir is changed in `Plan Summary` Issue created by sc-yan ### 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 at the end of the output from atlantis (not the result from each dir), we have something like this:

110. dir: vpc/us_west_2 workspace: default

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

Plan Summary

110 projects, 2 with changes, 107 with no changes, 1 failed

it would be great that the output also indicate which project is changed. otherwise we have to go over the whole output of each project and it's kind of cumbersome. the reason why we have so many projects planned is because the PR is created by renovate to upgrade the version of some provider. Describe the solution you'd like the output be something like this:

Plan Summary

110 projects, 1 with changes, 109 with no changes, 0 failed
changed projects:
2. dir: iam/us_west_2 workspace: default
56. dir: iam/us_west_1 workspace: default
failed projects:
101. dir: s3/us_west_1 workspace: default

Describe the drawbacks of your solution I don't see too much of a drawback. when atlantis runs, it would save the output list in the memory anyway. Describe alternatives you've considered I understand there were similar issues and efforts before, e.g. #1267 https://github.com/runatlantis/atlantis/pull/2983/files but these changes are for single dir, not the whole

plan summary

runatlantis/atlantis

#5445 Support redis cluster and sentinel mode Issue created by javking07 ### 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 user, I want to enable the redis `locking-db-type`with a multi node redis deployment, but am limited to standalone redis deployment. Describe the solution you'd like atlantis to support multiple redis deployment types, specifically: • single node • multi node cluster • sentinel via enhanced configuration options. This could look like: redis-db-type: <single-node,cluster, sentinel> The single node client being created here would instead be one of client, cluster client or sentinel client. Based on the value of

redis-db-type

. Describe the drawbacks of your solution Additional config complexity if this was to be accepted, and down the road folks want to add more redis settings that are only specific to certain redis-db-types. Describe alternatives you've considered • Adding a new locking db type that targets a database other than redis, such as postgres. • Adding a new locking db type that targets object storage implementation like s3. • Instead of an atlantis change, adding a file sync tool on the server I'm using to deploy atlantis. runatlantis/atlantis

#5450 Support project-level webhook configuration Issue created by tkasuz ### 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 only supports webhook configuration based on branches and workspaces. I need the ability to configure different webhook settings for individual Atlantis projects. Describe the solution you'd like To enable project-specific webhook configurations, I'd like to propose a new project-regex parameter within the webhooks section. This parameter would allow configuring different webhooks based on project names. webhooks: - event: apply workspace-regex: .* branch-regex: .* project-regex: .* kind: slack Describe the drawbacks of your solution Describe alternatives you've considered runatlantis/atlantis

#5453 Enable setting scrollback for log UI Issue created by dbmurphy ### 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 I have a substantial plan or apply output, I can exceed the hardcoded value as a user. It would be helpful to expose a helm or environment variable to let the system override this value to one that makes sense for individual implementations. Describe the solution you'd like Add a variable to the template file used or the UI page already so it's more flexible Describe the drawbacks of your solution This adds a variable to maintain, but it would still leave the existing value as the default, so there would be no impact unless a team overrides it. If someone makes it large, it could consume much more browser memory. Describe alternatives you've considered You can use the Chrome Dev console to re-run the script with changed values, but this presents UI artifacts, so making this more configurable seemed better. runatlantis/atlantis

#5187 Download multiple versions of OpenTofu in container by default, including 1.6.2, 1.7.1, and 1.8.2 Issue created by obscurerichard ### 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 an Atlantis user, I would like multiple versions of OpenTofu to be available in the container, so that I might follow the OpenTofu migration guides as conservatively as possible. I'm so glad Preinstall opentofu in containers #4337 brought in

tofu

. However, inspecting the container for v0.31.0 (commit: 245044c) (build date: 2024-11-22T175820.688Z) shows multiple versions of Terraform preinstalled, but not for OpenTofu. See this terminal transcript for evidence: / # tofu --version OpenTofu v1.8.5 on linux_amd64 / # tofu tofu tofu1.8.5 / # which tofu /usr/local/bin/tofu / # ls -l /usr/local/bin/tofu* -rwxr-xr-x 1 root root 82448384 Nov 4 20:16 /usr/local/bin/tofu -rwxr-xr-x 1 root root 82448384 Nov 4 20:16 /usr/local/bin/tofu1.8.5 / # ls /usr/local/bin atlantis terraform terraform1.8.5 tofu1.8.5 conftest terraform1.6.6 terraform1.9.8 docker-entrypoint.sh terraform1.7.5 tofu / # (See also Dockerfile#L121-L130 - fixing this would be really, really easy) atlantis/Dockerfile Lines 121 to 130 in</runatlantis/atlantis/commit/b5b95a7edf8491c178ec2bd7cec333e2eb214105|b5b95a7> | RUN ./download-release.sh \ | | -------------------------------------------------- | | "terraform" \ | | "${TARGETPLATFORM}" \ | | "${DEFAULT_TERRAFORM_VERSION}" \ | | "1.6.6 1.7.5 1.8.5 ${DEFAULT_TERRAFORM_VERSION}" \ | | && ./download-release.sh \ | | "tofu" \ | | "${TARGETPLATFORM}" \ | | "${DEFAULT_OPENTOFU_VERSION}" \ | | "${DEFAULT_OPENTOFU_VERSION}" | Describe the solution you'd like I'd like it if Atlantis pre-installed these versions per the migration instructions for migrating from various versions of Terraform to OpenTofu: 1. 1.6.2 for Migrating from Terraform 1.5.x or lower and Migrating from Terraform 1.6.x 2. 1.7.1 for Migrating from Terraform 1.7.x 3. 1.8.2 for Migrating from Terraform 1.8.x Describe the drawbacks of your solution This would make the Dockerfile slightly more complicated, and would bloat the container image size by a couple hundred megabytes. Describe alternatives you've considered • Maybe installing the latest minor version of OpenTofu would be sufficient, but I haven't tested the migration instructions with different versions yet. • If #5167 gets merged, and if it solves #4339 this could be a non-issue. runatlantis/atlantis

#5457 Fast retry on GitHub mergeability `unknown` Issue created by mikebryant ### 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 user of Atlantis on a repo that moves quickly (A large monorepo with many independent Atlantis states, and other merges from various automated toolking), I frequently hit issues where Atlantis reports

Pull request must be mergeable before running plan

When I look at the PR in the GitHub UI, the

Merge

button is available, which leaves me confused about why Atlantis has a different opinion on the matter. I believe the underlying issue here is a merge happening around the same time means the github mergeability state temporarily at unknown, which results in Atlantis deciding the PR is not mergeable. It takes a while before the various plans all come back as a failure, and I can try again. Describe the solution you'd like If Atlantis gets back an

unknown

value, I'd like it to have a small amount of exponential backoff/retry here. This would mean that if the mergeability is computed shortly (which is normally the case), Atlantis can proceed, instead of forcing the user to wait and retry the command. Describe the drawbacks of your solution This might mean a slightly longer time to wait for the result - but this should be mitigated by the fact that the retries are only happening on

unknown

, so it should get a result shortly, and this is better than making the user wait much longer to do a full command retry. Describe alternatives you've considered This could also be done by checking the documented mergeable attribute, which is

null

if mergeability is currently being calculated. runatlantis/atlantis

#5507 getting pull request: json: cannot unmarshal number Edit into Go struct field GitCommitDiffs.changeCounts of type azuredevops.VersionControlChangeType Issue created by Froostx ### 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 upgraded my atlantis image to 0.34.0 and now i get this error when i try to atlantis plan in my Azure Devops PullRequest. getting pull request: json: cannot unmarshal number Edit into Go struct field GitCommitDiffs.changeCounts of type azuredevops.VersionControlChangeType ### Reproduction Steps Upgrade to 0.34.0 ### Environment details • Atlantis version: 0.34.0 • Deployment method: ecs/eks/helm/tf module runatlantis/atlantis

#5509 Drop team name support in `--gh-team-allowlist` Issue created by ricardbejarano ### 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

--gh-team-allowlist

flag accepts both team names and team slugs in its rules. Sources: docs and code. This is for historical reasons: first it used just names, then slug support was added and names were never dropped. This could become a security concern if someone who's not supposed to be allowed to run a given command, has permissions to create a GitHub team within your organization, since they could configure the name (which need not be unique) to the that of the team that's configured in the allowlist. Slugs, on the other hand, are unique across a GitHub organization. This is also a problem even if you use slugs in your allowlist. The underlying logic that matches teams to rules does a logical OR of name and slug, meaning a would-be intruder could just name their new team with the slug of the allowed team to escalate their privilege into running restricted Atlantis commands. The

--gitlab-group-allowlist

flag is not affected. Its group matching logic is slugs only. Sources: docs and code. At the time of writing, no other supported VCS provider supports command allowlisting. Sources: Azure DevOps, BitBucket Cloud and Server, Gitea, ### Reproduction Steps 1. Run Atlantis with

--gh-team-allowlist='*:plan, Appliers:apply'

. 2. Create a GitHub team with slug

appliers

and name

Appliers

. Don't add yourself to it. 3. Create another team with slug

intruders

and name

Appliers

. Add yourself to this one. 4. Trigger

atlantis apply

on an open PR. ### Additional Context This issue has been previously discussed in Slack and the preferred solution is to drop GitHub team names support from the

--gh-team-allowlist

flag, allowing only slugs to be used. runatlantis/atlantis

#5511 Atlantis tries to plan an empty directory when moving to contents to a different directory 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 I noticed that when migrating files into a subdirectory such as parent/*.tf to parent/subdir/*tf, it will try to plan the empty parent/ dir even though there aren’t any matching *.tf files and fail to plan. Anyone know of a configuration fix for this or is this a bug? To get around this, I’m thinking of updating the workflow to check if the directory is empty before the init workflow and if it is, just do an early exit 0 This issue makes refactoring more difficult. ### Reproduction Steps 1. Find a directory of terraform files e.g.

parent/*.tf

2. Create a new directory within that directory

parent/subdir

3. Move the contents of

parent/*.tf

to

parent/subdir

4. Create a PR Atlantis will try to plan both

parent/

and

parent/subdir

. The latter will succeed and the former will fail because there are no terraform files here. ### Logs ### Environment details ### Additional Context • Must be a bug in auto discovery. The directory shouldn't even show up if there aren't any terraform files in there. See #3038 runatlantis/atlantis

#5513 CNCF Sandbox to Incubating stage 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. --- • I'd be willing to implement this feature (contributing guide) Describe the user story It would be nice for atlantis tongo from Sandbox to Incubating stage Describe the solution you'd like Reaching the next milestone of cncf graduation which is Incubating Describe the drawbacks of your solution N/A Describe alternatives you've considered N/A ## references • https://github.com/cncf/toc/blob/main/process/README.md#applying-to-become-an-incubating-or-graduating-project • https://github.com/cncf/toc/blob/main/.github/ISSUE_TEMPLATE/template-incubation-application.md runatlantis/atlantis

#5528 Migrate off of archived gopkg.in/yaml.v3 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 Archived Apr 1 2025 https://github.com/go-yaml/yaml/tree/v3.0.1 atlantis/go.mod Line 54 in</runatlantis/atlantis/commit/a992ab47240c94fb8839b33afc3ef55328eb71f1|a992ab4> | gopkg.in/yaml.v3 v3.0.1 | | ----------------------- | Maintained alternative • https://github.com/goccy/go-yaml - supports tags and good error checking • https://github.com/kubernetes-sigs/yaml - doesn't support tags ### Reproduction Steps N/A ### Logs N/A ### Environment details N/A ### Additional Context • #2795 runatlantis/atlantis

#5536 Migrate off of website dep js-yaml 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 Migrate off of website dep js-yaml It's the most popular js library and it's unmaintained and hasn't been updated in 4 years. This is the more up to date package https://www.npmjs.com/package/yaml ### Reproduction Steps N/A ### Logs ### Environment details ### Additional Context • #2795 runatlantis/atlantis

#5540 Cannot define multiple workflows for the same repo ID – needs branch-based disambiguation Issue created by kimjanghyun1010 I want to configure multiple workflows for a single repo by using different branch filters. Currently, Atlantis requires each repos.id to be unique, which makes it impossible to define separate workflows for different branches (e.g., main, develop) under the same repo. repos: - id: /.*my-repo.*/ branch: "/^main$/" workflow: production - id: /.*my-repo.*/ branch: "/^develop$/" workflow: staging runatlantis/atlantis

#5544 --tf-download-url is not respected since 0.28.2 Issue created by daftping ### 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 refactoring in this PR #4494 the

--tf-download-url

flag is no longer respected. ### Reproduction Steps Configure custom terraform download URL

- server
- --tf-download-url="<https://artifactory.company.com/artifactory/hashicorp-remote>"

Trigger the Atlantis plan for the version which needs to be downloaded. ### Logs

atlantis-0 atlantis {"level":"debug","ts":"2025-04-23T04:34:06.361Z","caller":"tfclient/terraform_client.go:306","msg":"Found required_version setting of \"1.11.4\"","json":{"repo":"Org/repo","pull":"105"}}
atlantis-0 atlantis {"level":"error","ts":"2025-04-23T04:34:16.363Z","caller":"tfclient/terraform_client.go:326","msg":"error listing available versions: Get \"<https://releases.hashicorp.com/terraform/index.json\>": context deadline exceeded","json":{"repo":"Org/repo","pull":"105"},"stacktrace":"<http://github.com/runatlantis/atlantis/server/core/terraform/tfclient.(*DefaultClient).DetectVersion|github.com/runatlantis/atlantis/server/core/terraform/tfclient.(*DefaultClient).DetectVersion>\n\tgithub.com/runatlantis/atlantis/server/core/terraform/tfclient/terraform_client.go:326\ngithub.com/runatlantis/atlantis/server/events.(*DefaultProjectCommandContextBuilder).BuildProjectContext\n\tgithub.com/runatlantis/atlantis/server/events/project_command_context_builder.go:127\ngithub.com/runatlantis/atlantis/server/events.(*CommandScopedStatsProjectCommandContextBuilder).BuildProjectContext\n\tgithub.com/runatlantis/atlantis/server/events/project_command_context_builder.go:66\ngithub.com/runatlantis/atlantis/server/events.(*DefaultProjectCommandBuilder).buildAllCommandsByCfg\n\tgithub.com/runatlantis/atlantis/server/events/project_command_builder.go:542\ngithub.com/runatlantis/atlantis/server/events.(*DefaultProjectCommandBuilder).BuildPlanCommands\n\tgithub.com/runatlantis/atlantis/server/events/project_command_builder.go:276\ngithub.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).BuildPlanCommands.func1\n\tgithub.com/runatlantis/atlantis/server/events/instrumented_project_command_builder.go:38\ngithub.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).buildAndEmitStats\n\tgithub.com/runatlantis/atlantis/server/events/instrumented_project_command_builder.go:71\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/events.(*PlanCommandRunner).run\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:186\ngithub.com/runatlantis/atlantis/server/events.(*PlanCommandRunner).Run\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:299\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).RunCommentCommand\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:401"}

### Environment details ### Additional Context I tracked it down to this call stack, which uses the default URL. https://github.com/runatlantis/atlantis/blob/main/server/core/terraform/distribution.go#L128 https://github.com/hashicorp/hc-install/blob/main/releases/versions.go#L61 https://github.com/hashicorp/hc-install/blob/main/internal/releasesjson/releases.go#L59 runatlantis/atlantis

#5549 Per-project automerge Issue created by sevagh ### 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 can set

autoplan: true|false

for specific project paths/directories in the YAML config, but we can only turn automerge on or off completely. Can we be able to disable automerge for a specific project directory? Describe the solution you'd like

version: 3
automerge: true
parallel_plan: true
parallel_apply: true
projects:
  - dir: project/i/dont/want/automerge
    automerge: false
  - dir: project/i/want/automerge
  - dir: ...

Describe the drawbacks of your solution If autoplan can be set per-project, why can't automerge? Describe alternatives you've considered runatlantis/atlantis

#5556 Another Potential Issue With Quick, Successive Commits Issue created by nujonathan ### 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 Hey team, First of all, I want to say this is an awesome project, and to keep up the great work! It's so important to have a collaborative, peer-reviewed approach to IaC with predictable results, and this project fills that role marvellously. I've come to understand that, unless parallel planning is enabled, that only one plan may run at a time for a given repo, dir, and workspace. This is indicated as much here. Further, the essence of this issue seems to be that, even within the same PR, the behaviour is to block commit 2's Atlantis workflow, if commit 1's workflow is still running (...and some people would prefer a configurable abort of commit 1's workflow). Serialized planning is what I'm after and I think the default behaviour is perfectly acceptable. It makes sense to be notified as much with the following PR comment:

the default workspace is currently locked by another command that is running for this pull request–wait until the previous command is complete and try again

However, I'm noticing that, with my configuration, at least, Atlantis appears to be pulling the rug out from under commit 1's workflow, because the

.terraform/

dir is being deleted for the autoplan started by commit 2's workflow, prior to initialization. I'm reasonably confident it's happening here during command building. So, really, it's not just

.terraform/

, but the entire working dir that's being deleted: { "level": "debug", "ts": "2025-04-29T185419.093Z", "caller": "events/working_dir.go:136", "msg": "repo was already cloned but is not at correct commit, wanted 'XYZ' got 'ZYX'", "json": { "repo": "...", "pull": "999" } } The effect, is that commit 1's workflow invariably dies due to a Terraform dependency (provider or module) going missing. Commit 2's workflow posts the aforementioned comment, and then commit 1's workflow comes back with something like:

│ Error: Failed to install provider
│ 
│ Error while installing hashicorp/aws v5.96.0: failed to make target path
│ .terraform/providers/registry.terraform.io/hashicorp/aws/5.96.0/linux_amd64
│ absolute: getwd: no such file or directory

or

│ Error: Invalid function argument
│ 
│   on .terraform/modules/loki-aws.eks-loki.loki_datasource/main.tf line 106, in locals:
│  106:   yaml_file = templatefile("${path.module}/templates/datasource.yml", local.datasource_vars)
│     ├────────────────
│     │ while calling templatefile(path, vars)
│     │ path.module is ".terraform/modules/loki-aws.eks-loki.loki_datasource"
│ 
│ Invalid value for "path" parameter: no file exists at
│ ".terraform/modules/loki-aws.eks-loki.loki_datasource/templates/datasource.yml";
│ this function works only with files that are distributed as part of the
│ configuration source code, so if this file will be created by a resource in
│ this configuration you must instead obtain this result from an attribute of
│ that resource.

Those are just a couple examples. The exact outcome and error message depends on where Terraform was in the plan. IMO, both are side effects of the working dir being refreshed. I've confirmed this by watching the filesystem during quick, successive commits to a PR. I expected the lock notice in the PR, but didn't expect commit 1's workflow to fail. I couldn't find another issue where this particular behaviour was identified, but because these circumstances don't seem particularly difficult to stumble into, I'm suspicious there's something I'm doing with my configuration that's causing the issue. So, I guess my questions are: 1. Is this expected behaviour, given my configuration? I get the cloning logic needs to resync with remote when it's out of sync -- which is what happens when a new commit rolls in -- but I would have thought that a working dir lock would be obtained by commit 1's workflow and that commit 2's workflow would respect that lock before it refreshed the working directory and attempted to execute the plans. FWIW, this log message is what makes me think commit 2's workflow gets all the way to command execution before the working dir lock is found: { "level": "error", "ts": "2025-04-28T193518.756Z", "caller": "events/instrumented_project_command_runner.go:78", "msg": "Error running plan operation: the default workspace at path ... is currently locked by another command that is running for this pull request...", "json": { "repo": "...", "pull": "999" }, "stacktrace": "github.com/runatlantis/atlantis/server/events.RunAndEmitStats..." } 2. If the above is expected, is there a known configuration strategy to avoid this behaviour? I'm not seeing anything obvious. Admittedly, there's more debugging I could do, but at this point, I feel like there's either an issue or something more obvious I'm missing. Thanks very much for your time, and I appreciate any guidance you can offer. Also let me know if more information is needed, and/or if this is more appropriate for discussion. As it stands, it seems like a potential bug. ### Reproduction Steps 1. Configure

v0.34.0

server per provided config (policy checks probably aren't necessary). 2. Open a PR or push a commit on an existing one. 3. Before the plan from step 2 can finish, push another commit. ### Logs See overview ### Environment details • Atlantis version:

v0.34.0

• Deployment method: https://registry.terraform.io/modules/terraform-aws-modules/atlantis/aws/latest (ECS + fargate) • If not running the latest Atlantis version have you tried to reproduce this issue on the latest version: NA • Atlantis flags: nothing custom Atlantis server-side config file: repos: - id: /.*/ apply_requirements: [approved, mergeable] workflow: custom allowed_overrides: [workflow] allow_custom_workflows: true policies: owners: users: ["someonerelevant"] policy_sets: - name: all_standard_policies path: policy/ source: local workflows: custom: plan: steps: - init - plan - run: | # some tending to a git cache... policy_check: steps: - run: | # policy check prep... - show - policy_check: extra_args: ["--all-namespaces"] Repo

atlantis.yaml

file: version: 3 - name: myproject dir: path/to/project terraform_version: v1.10.5 ### Additional Context runatlantis/atlantis

#5558 Custom conftest command output in policy checks is not parsed correctly Issue created by kirecek ### 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 Documentation suggest to use a custom

run

command to run policy_check againts source files. However, when doing so, atlantis is not able to marshal stdout output resulting in check error in the PR.

__Policy Check Error__

unable to unmarshal conftest output

To fix the output, I set

custom_policy_check: true

which worked and policy check exited sucessfuly:

Policy Check Failed: Some policy sets did not pass.
Policy Set: Custom

1 test, 1 passed, 0 warnings, 0 failures, 0 exceptions

❗ but, policy was incorrectly interpreted as failing because it checks only for "fail" string in

0 failures

. https://github.com/runatlantis/atlantis/blob/main/server/events/project_command_runner.go#L531 ### Reproduction Steps 1.) run atlantis with attached server config 2.) run atlantis plan 4.) policy check fails because of invalid output 5.) set custom_policy_check to true in server config 6.) run atlantis again 7.) output will be parsed but policy result will be treated incorectly ### Environment details Atlantis server-side config file: repos: - id: /.*/ workflow: custom delete_source_branch_on_merge: true custom_policy_check: false policy_check: true workflows: custom: plan: steps: - init - plan policy_check: steps: - run: conftest test --no-fail *.tf # or is this one to avoid creating policy files # - run: conftest test --update git::github.com/kirecek/policy-test?ref=main --no-fail main.tf policies: policy_sets: - name: policy-test path: /var/run/atlantis/policies source: local Repo

atlantis.yaml

file: version: 3 automerge: true projects: - name: main dir: atlantis-tests workspace: default autoplan: enabled: true when_modified: ["*.tf", "*.tf*", ".hcl", "atlantis.yaml"] execution_order_group: 1 ### Additional Context To be honest I am not sure if this is user error and we should handle conftest outputs somehow ourselves or if atlantis output parser should be more flexible. WDYT? runatlantis/atlantis

#5559 Use AWS API Gateway to Replace Load Balancer for Atlantis on Fargate Issue created by xiaoronglv The Atlantis team has kindly provided a AWS fargate deployment approach to save developers cost. While this approach reduces compute costs compared to EC2 or EKS, it still requires an application load balancer (ALB), which adds a recurring monthly expense. https://www.runatlantis.io/docs/deployment.html#aws-fargate graph TD A[Github PR is created] --> B[Webhook event sent to application load balancer] B --> C[Trigger Atlantis run in AWS Fargate] Loading ## Proposal I am wandering would it be possible to replace the load balancer with AWS API Gateway? Since AWS Gateway provides 1 million free tier, making it an attractive alternative for low-traffic use cases. graph TD A[Github PR is created] --> B[Webhook event sent to AWS API Gateway] B --> C[Trigger Atlantis run in AWS Fargate] Loading This approach could significantly reduce the cost of hosting Atlantis, which might encourage engineers from small team to adopt it without needing to persuade their employers. It may also attract more engineers to Atlantis over GitHub Actions. ## AWS Organization Context Many companies structure their AWS organizations with multiple accounts, typically including: • A corporate AWS account • A production AWS account • A staging AWS account • A development AWS account • Additional accounts as needed Atlantis is often used as a shared resource for managing infrastructure. In most cases, teams deploy the Atlantis instance in the corporate AWS account. Provisioning a dedicated application load balancer for this may not be the most efficient use of resources. ## Cost of Atlantis • Run Atlantis • A Kubernetes cluster, costing at least $72 per month • or an EC2 which takes 30-40 dollars • or fargate which takes $10-20. • A load balancer, costing around $20 per month For small team, traffic to Atlantis tends to be low since infrastructure changes are infrequent. Replacing the load balancer with API Gateway could eliminate one of the key fixed costs in this setup. Describe the drawbacks of your solution Describe alternatives you've considered ### 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) ## Reference 1. Q&amp;A: Using Atlantis with serverless deployment platforms, how? 2. terraform-aws-modules/terraform-aws-atlantis runatlantis/atlantis

#5563 syntax errors in TF files make autoplan fail without posting the error Issue created by glasser ### 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 autoplan is enabled on a repository and a syntax error exists in a TF file, autoplan fails and reports

Ran Plan for 0 projects

in the GitHub comment; you have to go to Atlantis logs to find out about the syntax error. ### Reproduction Steps My apologies: I have not created a detailed reproduction. I added a syntax error (adding a git merge conflict market such as

<<<<<<< HEAD

to a random line). We enable autoplan with

ATLANTIS_AUTOPLAN_MODULES=true

on our Atlantis. Atlantis posts a comment saying

Ran Plan for 0 projects:

and the GitHub status checks atlantis/apply and atlantis/plan are resolved successfully (0/0 projects). This reproduces with v0.34.0 as well as older versions. See logs for the error stack trace which comes from autoplan. ### Logs Logs

{
  "level": "warn",
  "ts": "2025-05-01T18:24:42.150Z",
  "caller": "events/project_command_builder.go:387",
  "msg": "error(s) loading project module dependencies: infrastructure/saf.tf:13 - Invalid expression: Expected the start of an expression, but found an invalid expression token.",
  "json": {
    "repo": "mdg-private/apollo-terraform",
    "pull": "1123"
  },
  "stacktrace": "<http://github.com/runatlantis/atlantis/server/events.(*DefaultProjectCommandBuilder).getMergedProjectCfgs|github.com/runatlantis/atlantis/server/events.(*DefaultProjectCommandBuilder).getMergedProjectCfgs>\n\tgithub.com/runatlantis/atlantis/server/events/project_command_builder.go:387\ngithub.com/runatlantis/atlantis/server/events.(*DefaultProjectCommandBuilder).buildAllCommandsByCfg\n\tgithub.com/runatlantis/atlantis/server/events/project_command_builder.go:518\ngithub.com/runatlantis/atlantis/server/events.(*DefaultProjectCommandBuilder).BuildAutoplanCommands\n\tgithub.com/runatlantis/atlantis/server/events/project_command_builder.go:257\ngithub.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).BuildAutoplanCommands.func1\n\tgithub.com/runatlantis/atlantis/server/events/instrumented_project_command_builder.go:29\ngithub.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).buildAndEmitStats\n\tgithub.com/runatlantis/atlantis/server/events/instrumented_project_command_builder.go:71\ngithub.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).BuildAutoplanCommands\n\tgithub.com/runatlantis/atlantis/server/events/instrumented_project_command_builder.go:26\ngithub.com/runatlantis/atlantis/server/events.(*PlanCommandRunner).runAutoplan\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:86\ngithub.com/runatlantis/atlantis/server/events.(*PlanCommandRunner).Run\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:297\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).RunAutoplanCommand\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:237"
}

### Environment details I don't have a full minimized config here. We are running v0.34.0 via Helm. ### Additional Context As a workaround, we've added a non-Atlantis CI check as a GH action (a TF formatter https://github.com/devops-infra/action-format-hcl) which means that something will fail on our PR when there are syntax issues. runatlantis/atlantis

#5565 error: 401 Must authenticate to access this API when deploying via Kustomize on GKE connected to a self-hosted Github Enterprise Server Issue created by alan707 ### 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 Atlantis

v0.33.0

is deployed against a GitHub Enterprise Server (GHES) instance, it repeatedly fails to post comments on pull requests with: 401 Must authenticate to access this API Despite: 1. Generating and validating a GitHub App JWT (returns HTTP 200 from /api/v3/app). 2. Exchanging that JWT for an installation access token (manually via curl). 3. Confirming the App has Read & Write permissions on Issues and Pull Requests and is installed on the target repo. 4. Mounting the private key and webhook secret correctly via a Kubernetes Secret. 5. Setting both ATLANTIS_GH_APP_KEY_FILE and ATLANTIS_GH_WEBHOOK_SECRET in the pod environment. Restarting the StatefulSet after every configuration change. #### What does work I’ve verified that posting an atlantis help comment on a PR in the allowed repository successfully appears in the pod’s logs. ### Reproduction Steps 1. Deploy Atlantis via

kubectl apply

2. Bootstraped the GitHub App via Atlantis

gtihub-app/setup

URL 3. Store credentials in Kubernetes secrets encoding them via base64 (including app-key file contents) 4. Confirmed Github Enterprise server can ping atlantis 5. Create a PR in the allowed repo and create a comment

atlantis help

### Logs ### Environment details • Atlantis version:

v0.33.0

• Deployment method: Kustomization via GKE • Atlantis flags: None • Env Vars: - name: ATLANTIS_DATA_DIR value: /atlantis - name: ATLANTIS_PORT value: "4141" - name: ATLANTIS_GH_USER value: fake # recommended by Atlantis docs: https://www.runatlantis.io/docs/access-credentials.html#github-app - name: ATLANTIS_GH_TOKEN value: fake # recommended by Atlantis docs: https://www.runatlantis.io/docs/access-credentials.html#github-app - name: ATLANTIS_GH_ORG value: readacted_org - name: ATLANTIS_ATLANTIS_URL value: https://<ATLANTIS_URL> - name: ATLANTIS_LOG_LEVEL value: debug - name: ATLANTIS_REPO_ALLOWLIST value: URL/REPO - name: ATLANTIS_GH_HOSTNAME value: "HOSTNAME" - name: ATLANTIS_GH_APP_ID value: "redacted" - name: ATLANTIS_GH_APP_KEY_FILE value: /etc/atlantis/gh-app-key.pem - name: ATLANTIS_GH_WEBHOOK_SECRET valueFrom: secretKeyRef: name: atlantis-vcs key: webhook-secret # must generate this with base64 encode ### Additional Context Decided to use an

ATLANTIS_GH_APP_KEY_FILE

but I also tried just passing the value for

ATLANTIS_GH_APP_KEY

directly from the Kubernetes secret. That failed to authenticate as well. runatlantis/atlantis