#5740 Documentation incorrect about branch key Issue created by cwitthaus ### 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 documentation for the repo level atlantis.yaml file lists the branch parameter as being available since v0.20.0, when it was actually added in version 0.21.0. See the What's changed section in https://github.com/runatlantis/atlantis/releases/tag/v0.21.0 which states:

feat: Implement branch matching in repo-level config by @0x416e746f6e in <https://github.com/runatlantis/atlantis/pull/2522>

. The comparison for the branches also shows this change arriving in 0.21.0: v0.20.1...v0.21.0 ### Reproduction Steps Documentation issue, nothing to really reproduce. ### Logs Documentation issue, no logs. ### Environment details Documentation issue, environment is not impactful. ### Additional Context No additional context aside from links above. runatlantis/atlantis

#5747 Gitlab Cloud (18.4.0-pre) authentication issues Issue created by Papina ### 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 My Docker container running on Synology host with traefik can't authenticate with gitlab.com values atlantis-docker-compose.yml

version: "3.7"
services:

  atlantis:
    image: <http://ghcr.io/runatlantis/atlantis:latest|ghcr.io/runatlantis/atlantis:latest>
    container_name: "atlantis"
    restart: unless-stopped
    command:
      # Server Settings
      - server
      - --atlantis-url=<https://atlantis.mydomain.com>. # SSL enabled on Traefik only
      - --repo-allowlist=<http://gitlab.com/mygroup/*|gitlab.com/mygroup/*>
      - 
      # Gitlab Settings
      - --gitlab-user="${GL_USER}"
      - --gitlab-token="${GL_ATLANTIS}"
      - --gitlab-webhook-secret="${WEBHOOK}"

    # Traefik won't assign labels until the healthcheck completes, without this the container is always in 'starting' state
    healthcheck:
      test: ["CMD", "curl", "-f",  "<http://localhost:4141/healthz>"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 10s

.env

# GitLab Token
GL_ATLANTIS=glpat-somevalue        # full perms token
GL_USER=<username value from>    # <https://gitlab.com/api/v4/user>
WEBHOOK=secretvalueshere

<https://gitlab.com/api/v4/version>

works fine authenticated from the browser, but not without auth

docker-compose -f atlantis-docker-compose.yml run atlantis curl --header "PRIVATE-TOKEN: glpat-thevalue" "<https://gitlab.com/api/v4/version>"

works fine and retrieves the relevant json

docker-compose -f atlantis-docker-compose.yml config

shows the correct .env values being passed to the cli --- ### Reproduction Steps

docker-compose -f atlantis-docker-compose.yml up -d

# using above config --- ### Logs Log output (via portainer)

No files found in /docker-entrypoint.d/, skipping
Error: initializing server: GET <https://gitlab.com/api/v4/version>: 401 {message: 401 Unauthorized}

--- ### Environment details Gitlab public cloud (Free Tier) Public Repository Group Repo (I am admin of the group) Synology Host Traefik Load Balancer with working SSL (v3.5.1) Other working containers on the host :latest flag for Atlantis image (currently v0.35.1) • Atlantis version: atlantis v0.35.1 (commit: e987e33) (build date: 2025-07-31T003000.639Z • Deployment method: atlantis-docker-compose.yml (synology docker engine) Atlantis server-side config file: none, all cli flags --- ### Additional Context Running using bitbucket credentials works as expected against bitbucket repos and tokens runatlantis/atlantis

#5757 Gitea: Only fetching first page of changed files. Issue created by mhalden We're running into an issue where Atlantis is unable to plan large PRs in Gitea. The last thing logged by Atlantis related to the PR is:

Getting modified files for Gitea pull request 18

I can see in the access logs for Gitea that page one of changed files is requested repeatedly:

...
2025/09/01 13:18:59 HTTPRequest [I] router: completed GET /api/v1/repos/repo/Terraform/pulls/18/files?limit=30&page=1 for 1.2.3.4:0, 200 OK in 546.0ms @ repo/pull.go:1517(repo.GetPullRequestFiles)
2025/09/01 13:18:59 HTTPRequest [I] router: completed GET /api/v1/repos/repo/Terraform/pulls/18/files?limit=30&page=1 for 1.2.3.4:0, 200 OK in 554.9ms @ repo/pull.go:1517(repo.GetPullRequestFiles)
2025/09/01 13:19:00 HTTPRequest [I] router: completed GET /api/v1/repos/repo/Terraform/pulls/18/files?limit=30&page=1 for 1.2.3.4:0, 200 OK in 551.8ms @ repo/pull.go:1517(repo.GetPullRequestFiles)
2025/09/01 13:19:00 HTTPRequest [I] router: completed GET /api/v1/repos/repo/Terraform/pulls/18/files?limit=30&page=1 for 1.2.3.4:0, 200 OK in 562.8ms @ repo/pull.go:1517(repo.GetPullRequestFiles)
2025/09/01 13:19:01 HTTPRequest [I] router: completed GET /api/v1/repos/repo/Terraform/pulls/18/files?limit=30&page=1 for 1.2.3.4:0, 200 OK in 554.0ms @ repo/pull.go:1517(repo.GetPullRequestFiles)
...

Looking at the related code in Atlantis it seems like it fails to increment beyond page one. From what I can gather line 113 should be

page += 1

instead. atlantis/server/events/vcs/gitea/client.go Lines 112 to 114 in</runatlantis/atlantis/commit/4f19e549f525fb17d2657ef5bc8c892fb094a27f|4f19e54> | for page < nextPage { | | ----------------------------------- | | page = +1 | | listOptions.ListOptions.Page = page | When increasing the page size enough to get all changes on one page the issue observed went away. runatlantis/atlantis

#3745 Update "Enforcement" section of CODE_OF_CONDUCT.md to address change in maintainers 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. --- ### Overview of the Issue I noticed in the request to be added to CNCF (cncf/sandbox#60) a link to the Code of Conduct: https://github.com/runatlantis/atlantis/blob/main/CODE_OF_CONDUCT.md. This includes a section "Enforcement" https://github.com/runatlantis/atlantis/blob/main/CODE_OF_CONDUCT.md#enforcement, which instructs a user to reach out to

@lkysow

on Atlantis Slack. With Luke indicating he intends to step away from atlantis #3686 (comment) this should be updated in one way or another. ### Reproduction Steps N/A ### Logs N/A ### Environment details N/A ### Additional Context • cncf/sandbox#60 • https://github.com/runatlantis/atlantis/blob/main/CODE_OF_CONDUCT.md#enforcement 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=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTcxMDg1OTUsIm5iZiI6MTc1NzEwODI5NSwicGF0aCI6Ii8xODIzNTg5Ny80MTk4ODQ5MjctZGE5YjJhMTYtMGY2Yy00YTdjLTk1OTItMTAwN2NhZDZlZTUwLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA5MDUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwOTA1VDIxMzgxNVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWMyZjMxMDUzNmE3OGJlMjliYmIyMjhlMTUzZTFiYmZlMzg4ZWRjNzY1OWM5YzcyNjU1OTQ2ZjE1OWMxYmE4YTYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.-wtI_19Pp7CHWcYKBJkBuI89UeEKoBPSCze_bLaCJTE) [Image](https://private-user-images.githubusercontent.com/18235897/419885153-85dfea25-083d-4a71-8946-fe3ba12ff80b.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTcxMDg1OTUsIm5iZiI6MTc1NzEwODI5NSwicGF0aCI6Ii8xODIzNTg5Ny80MTk4ODUxNTMtODVkZmVhMjUtMDgzZC00YTcxLTg5NDYtZmUzYmExMmZmODBiLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA5MDUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwOTA1VDIxMzgxNVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWI3YWEyNDM2ZmM2MDI3MTRhNmJmMjQ4MmM3Y2M1YzBmNDlhNDdjNGVjOGE3ZGJmOWNlYzFmODU3OTM4ZGNmNWMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.TfGa7U-lAs0s1gcbIoOD8XZqlCmb4O5HRrBOxnfqzNo)

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

#5772 ignore_paths does not work in server side repo config Issue created by cspargo ### 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 This PR added the ignore_path setting #5267 and the documentation for both the server side and repository level configs was updated to show the new option. However, it's not possible for this to work if it is set only in the server side config because the code starting here only includes the repo level atlantis.yaml atlantis/server/events/project_command_builder.go Line 497 in</runatlantis/atlantis/commit/413b83617069621429560bc2c9d77ebd21925382|413b836> | repoCfgFile := p.GlobalCfg.RepoConfigFile(ctx.Pull.BaseRepo.ID()) | | ----------------------------------------------------------------- | If that's not present it falls through to line 515 and actually prints out the uninitialised repoCfg var, but it seems to be intended to print a file name. So I think two problems here: 1. Documentation is incorrect, or it's not working as intended 2. line 515 is not right. It seems intended to print a filename. ### Reproduction Steps Try applying ignore_paths in the server side repo config. It has no effect. Put the same config in atlantis.yaml and it works. It also prints messed up log message like this

{"level":"info","ts":"2025-09-09T00:09:49.623Z","caller":"events/project_command_builder.go:515","msg":"repo config file {%!s(int=0) [] map[] {<nil> {[] []} %!s(int=0) []} %!s(*bool=<nil>) %!s(*valid.AutoDiscover=<nil>) %!s(*bool=<nil>) %!s(*bool=<nil>) %!s(*bool=<nil>) %!s(*bool=<nil>) %!s(*valid.RepoLocks=<nil>) %!s(*bool=<nil>)  [] %!s(bool=false) []} is absent, using global defaults"

### Environment details Atlantis version 0.35.1 runatlantis/atlantis

#5773 Merge strategy when multiple servers are used in the same repository Issue created by SamuelMolling Hi folks, I’m running two Atlantis servers against the same repository. Each one is configured to watch a different folder (so they don’t overlap in scope). The issue is: when I open a PR that touches files from both folders, both servers run. If I trigger atlantis apply, Atlantis will merge the PR as soon as the first server finishes successfully — even if the other one fails. This is a problem because the PR gets merged while half of the changes are broken. Has anyone faced this before? Is there a way to enforce that all Atlantis servers must pass before the PR is merged? Or any best practices/workarounds to handle multi-server setups like this? Thanks in advance! runatlantis/atlantis

#5779 Allow force apply / bypass apply_requirements Issue created by filipenf ### 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 some circumstances it might be necessary to bypass the

apply_requirements

rules to be able to quickly get something merged - for example during an active incident you may not have the necessary people to review around. It would be good if atlantis allowed for "break-glass" scenarios Describe the solution you'd like The solution I currently implemented is:

workflows:
  myworkflow:
    apply:
      steps:
      - run: /data/scripts/authorize_apply.py

The authorize apply script is here And removed

apply_requirements

from my atlantis.yaml / repo config. The drawback is that I have to implement logic similar to the one atlantis uses for the apply requirements checks. This solution could be simplified by having a new stage (ie

force-apply

) that would be called when the user types

atlantis force-apply

. Additional env vars would describe the state of the PR (ie is approved/mergeable). The script then makes the decision (ie is the triggering user an admin / code owner / etc). Atlantis would use the result of it to determine if apply is allowed or not (ignoring

apply_requirements

) ## Describe the drawbacks of your solution • A poorly written script would allow users to force apply Describe alternatives you've considered • Adding the force-apply rules directly into atlantis however making it flexible enough to cover all use cases might get tricky runatlantis/atlantis

#5791 depends_on and execution_order_group not working together during global apply Issue created by hesse-nina ### 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 Hi! I am having an issue when trying to use depends_on and execution_order_group together as described in your docs here: https://www.runatlantis.io/docs/repo-level-atlantis-yaml#order-of-planning-applying. I keep getting the

Can't apply your project unless you apply its dependencies

error, even though I have confirmed the dependency has applied in a lower execution_order_group. Basically when I do a global

atlantis apply

, atlantis does not realize project dependencies have been fulfilled by the time the project needs to apply. If I run a global

atlantis apply

again, the second apply will now go through. Another user has experienced this same issue: https://luppeng.wordpress.com/2025/01/11/atlantis-repo-config-execution_order_group-and-depends_on-attributes-may-be-mutually-exclusive-in-some-cases/ Unfortunately, for an unrelated requirement, I sometimes I need abort_on_execution_order_fail to be false, so I would really need the depends_on requirement as well. Alternatively, being able to set abort_on_execution_order_fail on a project scope would also meet my requirements. ### Reproduction Steps 1. Create two projects, one of which depends on the other, and set them in separate execution_order_group:

projects:
- branch: /main/
  dir: path/to/project-1
  name: project-1
  workspace: <shared-workspace>
  plan_requirements: []
  apply_requirements: ['undiverged']
  import_requirements: ['undiverged']
  autoplan:
    when_modified:
    - '*.tf'
  workflow: <workflow>
  depends_on: []
  execution_order_group: 1
- branch: /main/
  dir: path/to/project-2
  name: project-2
  workspace: <shared-workspace>
  plan_requirements: []
  apply_requirements: ['undiverged']
  import_requirements: ['undiverged']
  autoplan:
    when_modified:
    - '*.tf'
  workflow: <workflow>
  depends_on: ['project-1']
  execution_order_group: 2

1. Open pr with change to main.tf or other .tf file 2. Run single

atlantis apply

command, and observe apply for project-2 is blocked with error

Can't apply your project unless you apply its dependencies

### Logs

Can't apply your project unless you apply its dependencies

### Environment details • Atlantis version: atlantis v0.33.0 • Deployment method: helm • If not running the latest Atlantis version have you tried to reproduce this issue on the latest version: no Repo

atlantis.yaml

file: version: 3 automerge: false parallel_plan: true parallel_apply: true abort_on_execution_order_fail: false # must be false so sandbox does not block higher envs projects: - branch: /main/ dir: path/to/project-1 name: project-1 workspace: <shared-workspace> plan_requirements: [] apply_requirements: ['undiverged'] import_requirements: ['undiverged'] autoplan: when_modified: - '*.tf' workflow: <workflow> depends_on: [] execution_order_group: 1 - branch: /main/ dir: path/to/project-2 name: project-2 workspace: <shared-workspace> plan_requirements: [] apply_requirements: ['undiverged'] import_requirements: ['undiverged'] autoplan: when_modified: - '*.tf' workflow: <workflow> depends_on: ['project-1'] execution_order_group: 2 ### Additional Context Another user had this same problem, which they layout here: https://luppeng.wordpress.com/2025/01/11/atlantis-repo-config-execution_order_group-and-depends_on-attributes-may-be-mutually-exclusive-in-some-cases/ runatlantis/atlantis

#5802 Gitea commit status is missing status id Issue created by felinira ### 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 forgejo / gitea the commit status is missing a way to identify itself (for example for branch protection rules). ### Reproduction Steps • Get atlantis to submit a status check to gitea/forgejo • visit the

/settings/branches/edit?rule_name=main

sub URL • Find an empty line under "Status checks found in the last week for this repository" with no ID ### Environment details • Atlantis version: v0.35.1 • Deployment method: docker Atlantis server-side config file: ATLANTIS_GITEA_BASE_URL: "https://git.example.net" ATLANTIS_GITEA_USER: "atlantis" ATLANTIS_GITEA_TOKEN: "<token>" ATLANTIS_GITEA_WEBHOOK_SECRET: "<secret>" ATLANTIS_REPO_ALLOWLIST: "test/atlantis" Repo

atlantis.yaml

file: --- version: 3 projects: - name: tofu branch: /main/ dir: tofu terraform_distribution: opentofu ### Additional Context

CreateStatus

seems to have a "context" field. I have not investigated this further, but it could potentially be what is missing? https://anbraten.github.io/gitea-js/interfaces/CreateStatusOption.html#context atlantis/server/events/vcs/gitea/client.go Lines 321 to 325 in</runatlantis/atlantis/commit/06840779b4e2e44b4def4d981d3652cb3b413bf0|0684077> | newStatusOption := gitea.CreateStatusOption{ | | -------------------------------------------- | | State: giteaState, | | TargetURL: url, | | Description: description, | | } | runatlantis/atlantis

#5807 Merged/Applied pull requests do not consistently unlock Issue created by vulpine ### 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 Occasionally, merged GitHub Enterprise Pull Requests do not automatically unlock. A user has to manually comment

atlantis unlock

on them. This does not happen predictably and no pattern appears to be common between PRs which do correctly unlock and those which do not. ### Reproduction Steps This is currently impossible for us to proactively cause to happen, and so specific reproduction steps are impossible. However, when this has occurred: 1. A pull request for a change is created. Atlantis automatically plans it. 2. The pull request is approved. 3. The pull request is applied through

atlantis apply

. During this, we see these log lines:

{"level":"debug","ts":"2025-09-15T14:01:15.211Z","caller":"events/pull_updater.go:27","msg":"hiding previous plan comments for command: 'Apply', directory: ''","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:15.211Z","caller":"vcs/github_client.go:272","msg":"Hiding previous command comments on GitHub pull request 32041","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:15.388Z","caller":"vcs/github_client.go:282","msg":"GET /repos/misc/terraform-code/issues/32041/comments returned: 200","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:15.388Z","caller":"vcs/github_client.go:332","msg":"Hiding comment COMMENTIDREDACTED","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:15.576Z","caller":"vcs/github_client.go:230","msg":"Creating comment on GitHub pull request 32041","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:15.929Z","caller":"vcs/github_client.go:252","msg":"POST /repos/misc/terraform-code/issues/32041/comments returned: 201","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:15.929Z","caller":"events/db_updater.go:25","msg":"updating DB with pull results","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"info","ts":"2025-09-15T14:01:15.948Z","caller":"vcs/github_client.go:920","msg":"Updating GitHub Check status for 'atlantis/apply' to 'success'","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:16.183Z","caller":"vcs/github_client.go:930","msg":"POST /repos/misc/terraform-code/statuses/bf8d6d8dad3c408c83c744bb2d0c197b7632b1d8 returned: 201","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:16.184Z","caller":"vcs/github_client.go:230","msg":"Creating comment on GitHub pull request 32041","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:16.488Z","caller":"vcs/github_client.go:252","msg":"POST /repos/misc/terraform-code/issues/32041/comments returned: 201","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"info","ts":"2025-09-15T14:01:16.488Z","caller":"events/automerger.go:32","msg":"automerging pull request","json":{"repo":"misc/terraform-code","pull":"32041"}}
{"level":"debug","ts":"2025-09-15T14:01:16.488Z","caller":"vcs/github_client.go:937","msg":"Merging GitHub pull request 32041","json":{"repo":"misc/terraform-code","pull":"32041"}}

1. The pull request is merged, closed, and Atlantis comments "Automatically merging because all plans have been successfully applied.", but does NOT comment "Locks and plans deleted for the projects and workspaces modified in this pull request..." 2. A different pull request for the same project as in (1) is created. (This can be days or even weeks later.) Atlantis cannot plan it, as a lock exists, and comments: "Apply Failed: This project is currently locked by an unapplied plan from pull #(PR of pull request from 1). To continue, delete the lock from #XXXXX or apply that plan and merge the pull request." 3. A user comments

atlantis unlock

on the pull request from (1). Atlantis deletes the locks and comments "All Atlantis locks for this PR have been unlocked and plans discarded". During this, we see these log lines:

{"level":"info","ts":"2025-09-16T23:46:01.197Z","caller":"events/events_controller.go:692","msg":"Handling 'unlock' comment","json":{"gh-request-id":"X-Github-Delivery=REQUESTIDREDACTED","repo":"misc/terraform-code","pull":32041}}
{"level":"info","ts":"2025-09-16T23:46:01.197Z","caller":"events/events_controller.go:736","msg":"Running comment command 'unlock' for user 'USERNAMEREDACTED'.","json":{"gh-request-id":"X-Github-Delivery=REQUESTIDREDACTED","repo":"misc/terraform-code","pull":32041}}

### Logs For a PR which is successfully unlocked, we see these logs: • "Initiating cleanup of pull data." • "Locks and workspace successfully deleted" For those which do not properly automatically unlock, we see only "Initiating cleanup of pull data.", without the second log line. ### Environment details • Atlantis version: atlantis 0.35.1 (commit: e987e33) (build date: 2025-07-31T002933Z) • Deployment method: Docker image to AWS ECS/EC2 • Atlantis flags:

--atlantis-url="$URL" \
  --gh-hostname="${GITHUB_HOSTNAME:-REDACTED}" \
  --gh-user="$GITHUB_USERNAME" \
  --gh-token="$GITHUB_TOKEN" \
  --gh-webhook-secret="$SECRET" \
  --repo-allowlist="$REPO_ALLOWLIST" \
  --data-dir="/data/atlantis" \
  --repo-config="/etc/repo-config.yaml" \
  --checkout-strategy=merge \
  --hide-prev-plan-comments \
  --skip-clone-no-changes \
  --parallel-pool-size=25 \
  --log-level=${ATLANTIS_LOG_LEVEL:-debug} \
  --executable-name=${EXECUTABLE_NAME:-atlantis} \
  --allow-commands="version,plan,apply,unlock,approve_policies,import,state" \
  --enable-regexp-cmd \
  --tf-download=false

atlantis.yaml - this is abbreviated as ours is very long (43282):

version: 3
automerge: true
parallel_plan: true
parallel_apply: true
projects:
- name: s3_server_access_logs/eucentral1-prod
  dir: projects/s3_server_access_logs/eucentral1-prod
  workspace: s3_server_access_logs_eucentral1-prod
  repo_locks:
    mode: on_apply
  autoplan:
    when_modified:
    - '**/*'
    - '!/**/OWNERS'
    - '!/**/README.md'
    - ../../../modules/s3_server_access_logs/**/*
    - '!/../../../modules/s3_server_access_logs/**/OWNERS'
    - '!/../../../modules/s3_server_access_logs/**/README.md'
allowed_regexp_prefixes:
- s3_server_access_logs

We recently enabled on-apply locks for all projects. Anecdotally, we have only noticed this issue occur after enabling this. ### Additional Context runatlantis/atlantis

#2685 gitlab: Atlantis apply returns `Status cannot transition via \"run\"` when updating commit check status Issue created by fazith27 ### 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 started exploring Atlantis recently. I found an issue when running

atlantis apply

. Pipeline at Gitlab end is continuously running even after applying the changes and the MR is updated with the apply successful comment. Provided atlantis logs below for reference. As per the logs, it looks like Atlantis is failing when making the Gitlab api to update the commit status and the process never ends in the backend. FYI, I am using Gitlab and Terragrunt. ### Reproduction Steps •

docker run -p 80:4141 -d --pull=always <http://registry.gitlab.com/mytestproj/tf-stack/custom-atlantis|registry.gitlab.com/mytestproj/tf-stack/custom-atlantis> server --gitlab-user=xxxxx --gitlab-token=xxxxx --repo-allowlist=<http://gitlab.com/mytestproj/tf-stack|gitlab.com/mytestproj/tf-stack> --gitlab-webhook-secret=xxxx--repo-config="/home/atlantis/repos.yaml" --silence-no-projects --checkout-strategy=merge

• Added webhook at Gitlab end to post the MR events to atlantis • Created MR in Gitlab • Commented

atlantis plan

and then

atlantis apply

3 to 4 times in the same MR with multiple changes • First apply ran successfully and after that the apply pipeline never ends in Gitlab ### Logs { "level":"warn","ts":"2022-11-14T221833.360Z", "caller":"events/apply_command_runner.go:204", "msg":"unable to update commit status: POST https://gitlab.com/api/v4/projects/mytestproj/tf-stack/statuses/8b9c4d85c3ed817d7222093412dfa37dc612d81c: 400 {message: Cannot transition status via :run from :running (Reason(s): Status cannot transition via \"run\")}", "json":{"repo":"mytestproj/tf-stack","pull":"7"}, "stacktrace":"github.com/runatlantis/atlantis/server/events.(*ApplyCommandRunner).updateCommitStatus\n\tgithub.com/runatlantis/atlantis/server/events/apply_command_runner.go:204\ngithub.com/runatlantis/atlantis/server/events.(*ApplyCommandRunner).Run\n\tgithub.com/runatlantis/atlantis/server/events/apply_command_runner.go:163\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).RunCommentCommand\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:296" } ### Dockerfile for my custom image FROM ghcr.io/runatlantis/atlantis RUN curl --output terragrunt -L https://github.com/gruntwork-io/terragrunt/releases/download/v0.40.1/terragrunt_linux_amd64 && chmod +x terragrunt && mv terragrunt /usr/local/bin/terragrunt COPY repos.yaml /home/atlantis ### Server side-config (repos.yaml) repos: - id: "/.*/" # apply_requirements: [approved] allowed_overrides: [workflow] allow_custom_workflows: true workflow: terragrunt pre_workflow_hooks: - run: chmod +x gen-atlantis-yaml.sh && ./gen-atlantis-yaml.sh post_workflow_hooks: - run: find . -type d -name ".terragrunt-cache" -prune -exec rm -rf {} \; workflows: terragrunt: plan: steps: - env: name: TERRAGRUNT_TFPATH command: 'echo "terraform${ATLANTIS_TERRAFORM_VERSION}"' - run: terragrunt plan -input=false -out=$PLANFILE - run: terragrunt show -json $PLANFILE > $SHOWFILE apply: steps: - env: name: TERRAGRUNT_TFPATH command: 'echo "terraform${ATLANTIS_TERRAFORM_VERSION}"' - run: terragrunt apply -input=false $PLANFILE ### Atlantis yaml version: 3 parallel_apply: false parallel_plan: true automerge: false workflows: terragrunt: plan: steps: - env: name: TERRAGRUNT_TFPATH command: 'echo "terraform${ATLANTIS_TERRAFORM_VERSION}"' - run: terragrunt plan -out $PLANFILE apply: steps: - env: name: TERRAGRUNT_TFPATH command: 'echo "terraform${ATLANTIS_TERRAFORM_VERSION}"' - run: terragrunt apply $PLANFILE projects: - dir: env/np/lb workflow: terragrunt - dir: env/p/lb workflow: terragrunt - dir: env/s/lb workflow: terragrunt runatlantis/atlantis

#5826 Atlantis applies plan even if merge request needs rebase (GitLab) Issue created by randrusiak ### 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 Atlantis with GitLab.com, Atlantis applies plans even if a merge request has status

need_rebase

. This happens in repositories where the merge method is set to Merge commit with semi-linear history. As a result, Atlantis treats the MR as mergeable, although GitLab requires a rebase before merge, which can lead to applies on diverged branches. This behavior was introduced after the change related to the following issue: #4390. That change made Atlantis treat

need_rebase

as a mergeable state, but in GitLab.com this is not true. • If the merge method is Merge commit, GitLab correctly returns

detailed_merge_status="mergeable"

. • For other merge methods (e.g., semi-linear history), GitLab returns

need_rebase

, which should mean "not mergeable". Removing the condition that treats

need_rebase

as mergeable (see https://github.com/runatlantis/atlantis/blob/v0.36.0/server/events/vcs/gitlab_client.go#L370) would resolve this issue. This problem was already raised before in #4025. ### Reproduction Steps 1. Configure Atlantis with the following setting in `repos.yaml`: apply_requirements: [approved, mergeable, undiverged] 1. Create a repository on GitLab.com and set the merge method to Merge commit with semi-linear history. 2. Open a merge request from a feature branch to the default branch. 3. Create additional commits on the default branch so that the merge request branch becomes outdated and GitLab marks it with

detailed_merge_status = "need_rebase"

. 4. Run Atlantis against this merge request. Result: Atlantis still applies the plan and considers the MR as mergeable. Expected: Atlantis should block the apply because the MR is not in a mergeable state (

need_rebase

should not be treated as mergeable). ### Logs

{"level":"debug","ts":"2025-09-22T12:14:37.334Z","caller":"vcs/gitlab_client.go:361","msg":"Detailed merge status: 'need_rebase'","json":{"repo":"atlantis-demo","pull":"1792"}}
{"level":"debug","ts":"2025-09-22T12:14:37.334Z","caller":"vcs/gitlab_client.go:378","msg":"Merge request is mergeable","json":{"repo":"atlantis-demo","pull":"1792"}}

### Environment details • Atlantis version: v0.35 • Atlantis flags:

- server
        - '--emoji-reaction=eyes'
        - '--enable-diff-markdown-format'
        - '--automerge'
        - '--autodiscover-mode=disabled'
        - '--log-level=debug'
        - '--disable-global-apply-lock'
        - '--hide-prev-plan-comments'
        - '--hide-unchanged-plan-comments'
        - '--parallel-pool-size=5'
        - '--parallel-plan'
        - '--parallel-apply'
        - '--use-tf-plugin-cache=false'
        - '--autoplan-modules=true'
        - '--disable-markdown-folding'

Atlantis server-side config file: --- repos: - id: /.*/ apply_requirements: [approved, mergeable, undiverged] plan_requirements: [undiverged] import_requirements: [undiverged] workflow: default allowed_overrides: [workflow] allow_custom_workflows: true delete_source_branch_on_merge: true workflows: default: plan: steps: [init, plan] apply: steps: [apply] metrics: prometheus: endpoint: /metrics ### Additional Context runatlantis/atlantis

#5722 Unexpected change in locking behaviour Issue created by marksumm ### 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 A previously working configuration consisting of several custom workflows in the same directory, all using the default workspace, but with different .tfvars files and Terraform state files for each, now encounters the famous error "the ... workspace at path ... is currently locked by another command that is running for this pull request." ### Reproduction Steps Note that this only happens when an attempt is made to run apply on multiple workflows in the same directory. It does not happen during plan or during a single apply. Also note that

parallel_plan

and

parallel_apply

are both disabled. This has nothing to do with commits in quick succession. ### Environment details • Atlantis version: 0.35.1 • Deployment method: Azure App Service ### Additional Context It seems that something has changed in very recent Atlantis versions, and this has exposed the fact that locks are not really isolated by project name. I know that an attempt was made to include the project name in the lock, but from what I can see it is not actually being included. See #4192 (comment) runatlantis/atlantis

#5829 Commit status from the Gitlab 18.5.0-pre - 403 failed to parse unknown error format Issue created by jonataneogrid-lgtm ### 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 My Atlantis server v0.33.0 and v0.36.0 is having trouble retrieving commit status from the Gitlab 18.5.0-pre API since yesterday. Error: 403 failed to parse unknown error format ### Logs

curl --header "PRIVATE-TOKEN: $ATLANTIS_GITLAB_TOKEN" <https://gitlab.com/api/v4/version>
{"version":"18.5.0-pre","revision":"dadfe024cf6","kas":{"enabled":true,"externalUrl":"<wss://kas.gitlab.com>","externalK8sProxyUrl":"<https://kas.gitlab.com/k8s-proxy>","version":"18.5.0-rc1+14cf33fb6ec9bd5d2f93613971d8b1fbdf4c2d68"},"enterprise":true}atlantis-0:/atlantis$

{"level":"info","ts":"2025-09-24T14:24:18.475-0300","caller":"vcs/gitlab_client.go:114","msg":"GitLab host '<http://gitlab.com|gitlab.com>' is running version 18.5.0","json":{}}                                                                                                                                                                                                                                         
{"level":"info","ts":"2025-09-24T14:42:12.406-0300","caller":"events/events_controller.go:768","msg":"Processing Gitlab merge request 'opened' event","json":{"repo":"mylab/mygroup/terraform-plans/example-01","pull":"67"}}                                                                                                                                                                 │
{"level":"info","ts":"2025-09-24T14:42:12.412-0300","caller":"events/command_runner.go:203","msg":"Running autoplan...","json":{"repo":"mylab/mygroup/terraform-plans/example-01","pull":"67"}}                                                                                                                                                                                               │
{"level":"info","ts":"2025-09-24T14:42:12.417-0300","caller":"vcs/gitlab_client.go:411","msg":"Updating GitLab commit status for 'atlantis/plan' to 'running'","json":{"repo":"mylab/mygroup/terraform-plans/example-01","pull":"67"}}                                                                                                                                                        │
{"level":"warn","ts":"2025-09-24T14:42:12.482-0300","caller":"events/command_runner.go:213","msg":"unable to update plan commit status: GET <https://gitlab.com/api/v4/projects/mylab/mygroup/terraform-plans/example-01/repository/commits/dr4b80814323c48ccc6a34f5399ca094fbeeec54>: 403 failed to parse unknown error format: <!DOCTYPE html><html lang=\"en-US\"><head><title>Just a moment │
{"level":"info","ts":"2025-09-24T14:42:13.555-0300","caller":"events/working_dir.go:265","msg":"creating dir '/home/atlantis/.atlantis/repos/mylab/mygroup/terraform-plans/example-01/67/default'","json":{"repo":"mylab/mygroup/terraform-plans/example-01","pull":"67"}}                                                                             │
{"level":"info","ts":"2025-09-24T14:42:15.267-0300","caller":"events/project_command_builder.go:513","msg":"successfully parsed atlantis.yaml file","json":{"repo":"mylab/mygroup/terraform-plans/example-01","pull":"67"}}                                                                                                                                                                   │
{"level":"info","ts":"2025-09-24T14:42:15.267-0300","caller":"events/project_command_builder.go:396","msg":"1 projects are to be planned based on their when_modified config","json":{"repo":"mylab/mygroup/terraform-plans/example-01","pull":"67"}}                                                                                                                                         │
{"level":"info","ts":"2025-09-24T14:42:15.272-0300","caller":"vcs/gitlab_client.go:411","msg":"Updating GitLab commit status for 'atlantis/plan: prd' to 'running'","json":{"repo":"mylab/mygroup/terraform-plans/example-01","pull":"67"}}                                                                                                                                                   │
{"level":"error","ts":"2025-09-24T14:42:15.318-0300","caller":"events/project_command_runner.go:201","msg":"updating project PR status%!(EXTRA *gitlab.ErrorResponse=GET <https://gitlab.com/api/v4/projects/mylab/mygroup/terraform-plans/example-01/repository/commits/dr4b80814323c48ccc6a34f5399ca094fbeeec54>: 403 failed to parse unknown error format: <!DOCTYPE html><html lang=\"en-US │
{"level":"info","ts":"2025-09-24T14:42:15.322-0300","caller":"events/project_locker.go:86","msg":"Acquired lock with id 'mylab/mygroup/terraform-plans/example-01/terraform/prd'","json":{"repo":"mylab/mygroup/terraform-plans/example-01","pull":"67"}}

### Environment details • Atlantis version: v0.36.0 • Deployment method: CCE Huawei Cloud Atlantis server-side config file: Repo

repos.yaml

file: --- repos: - id: /.*/ #apply_requirements: [approved] allowed_overrides: [plan_requirements, apply_requirements, import_requirements, workflow] allow_custom_workflows: true Repo

config.yaml

file: ATLANTIS_ALLOW_COMMANDS: "version,plan,apply,unlock,approve_policies,import,state,all" ATLANTIS_LOG_LEVEL: "info" ATLANTIS_ENABLE_DIFF_MARKDOWN_FORMAT: "true" ATLANTIS_ATLANTIS_URL: "https://atlantis.mylab.com" ATLANTIS_DATA_DIR: /atlantis ATLANTIS_PORT: "4141" webhooks: - event: apply kind: http url: "http://atlantis-webhook.atlantis.svc.cluster.local:8080/hooks" .env: ATLANTIS_GITLAB_TOKEN=my-token ATLANTIS_GITLAB_USER=infra.ss ATLANTIS_GITLAB_WEBHOOK_SECRET=my-Secrets ### Additional Context I saw that the task #2272 was closed with a similar error, but in my case it is only in the commit status, I have no information in GitLab about the Atlantis pipeline running and the approve rule does not work. runatlantis/atlantis

#5839 ATLANTIS_GH_ALLOW_MERGEABLE_BYPASS_APPLY blocking atlantis apply operations Issue created by AndresPinerosZen ### 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 Version: 0.35.1 When using

ATLANTIS_GH_ALLOW_MERGEABLE_BYPASS_APPLY=true

and setting the

atlantis/apply

check as required in the repository, I'm getting this message when running

atlantis apply

.

Apply Error

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

When checking the Atlantis container, there are no terraform processes running, just the atlantis server, so I'm sure there's no terraform command running for the pull request. We were running

atlantis apply

only after making sure that the plan had finished and that there was no terraform process running inside of the container. Once we removed the required check and set the variable to false, everything started working as usual. ### Reproduction Steps • Set the variable ATLANTIS_GH_ALLOW_MERGEABLE_BYPASS_APPLY=true. • Set the required check in the Terraform repository. • Open a pull request. • Wait until the automatic plan finishes. • Run

atlantis apply

• Get the error from the overview Please let me know if there are any specific atlantis.yaml configurations that are of interest to be able to understand this behavior. I don't see any extra configuration that could be linked to this. runatlantis/atlantis

#5854 Webhook notifications not triggered Issue created by hseagle2015 ### 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 Webhook notifications are not triggered on "apply" event, possibly because server-side repo config contains a workflow with custom "run" command for "apply" step. Slack nor HTTP webhook is not triggered when a user calls

atlantis apply

via GitHub comment. Atlantis logs (with debug level logging) don't mention an attempt to try sending a notification on either endpoint. By inspecting the access logs for the custom notification webhook URL endpoint, I didn't find any POST requests. ### Reproduction Steps Configure Slack or HTTP webhook notification in Atlantis server configuration. Define a custom workflow with custom "run" command for "apply" step. Open a PR on GitHub and trigger Terraform apply by commenting

atlantis apply

to the PR. Observe is Slack or HTTP webbook notification arrives. ### Logs ### Environment details • Atlantis version: 0.36.0 • Deployment method: Docker (running the official Atlantis container image) • Atlantis flags:

--config /home/atlantis/.atlantis/atlantis-server.yaml --gh-app-id ${GH_APP_ID} --gh-app-key-file /home/atlantis/gh_app_key.pem --repo-config /home/atlantis/.atlantis/repos.yaml --gh-webhook-secret ${GH_WEBHOOK_SECRET} --write-git-creds --repo-allowlist '${REPO_ALLOWLIST}' --atlantis-url ${ATLANTIS_URL}

Atlantis server-side config file: # config file log-level: "debug" slack-token: "XXXXXXXX" workflows: - event: "apply" kind: "slack" channel: "XXXXXXXXXX" - event: "apply" kind: "http" url: "https://XXXXXX" Repo-config

repos.yaml

file: # config file --- repos: - id: "github.com/[ORG]/[REPO]" apply_requirements: ["mergeable"] workflow: "sops" workflows: sops: plan: steps: - run: &terraform_init_cmd shell: "bash" command: | source /home/atlantis/.atlantis/.env.sops && /home/atlantis/.atlantis/bin/sops exec-env ../.terraform.env 'timestamp=$(date +"%Y-%m-%d_%H%M%S"); terraform init -backend-config="bucket=${TFSTATE_BUCKET}" -backend-config="region=${TFSTATE_REGION}" > /tmp/terraform_init_${timestamp}.log 2>&1 || cat /tmp/terraform_init_${timestamp}.log && rm -f /tmp/terraform_init_${timestamp}.log' - run: shell: "bash" output: strip_refreshing command: | source /home/atlantis/.atlantis/.env.sops && /home/atlantis/.atlantis/bin/sops exec-env ../.terraform.env 'terraform plan -out terraform.tfplan' apply: steps: - run: *terraform_init_cmd - run: shell: "bash" output: strip_refreshing command: | source /home/atlantis/.atlantis/.env.sops && /home/atlantis/.atlantis/bin/sops exec-env ../.terraform.env 'terraform apply -auto-approve terraform.tfplan' runatlantis/atlantis

#999 Allow VCS to specify reason mergeable failed Issue created by jpreese Atlantis currently responds to the pull request with:

Pull request must be mergeable before running apply.

If the

PullIsMergeable

check fails. But this check can fail for many reasons. It would be nice if we could bubble up the exact reason to the Pull Request (failed policy, draft mode, etc) 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

#5868 Reduce container image size of Atlatis Issue created by patrickdung ### 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 is found that the container image of atlantis is quite large (around 1GB) and for us, we need to include terragrunt and more tools in the future. Here is a finding: Inside a container image 273987739 -rwxr-xr-x 1 root root 90579096 Apr 9 13:03 terraform 273987741 -rwxr-xr-x 1 root root 90579096 Apr 9 13:03 terraform1.11.4 Same content, but the i-node is different, so it is using extra storage (~90MB in here) I think it's the same case for opentofu (another ~87MB) Describe the solution you'd like Suggestions: 1. Use of softlink/hardlink for tofu/terraform to the latest version 2. or use of other de-duplicate/hardlink tools for tofu/terraform to the latest version 3. also consider reduce the no of terraform to ship to 3 or 2 versions instead of 4 versions 4. For Debian based container image, some packages are installed but I think they are not needed, like gcc-12-base openssh-server openssh-sftp-server 5. Finally, may be also consider container image squashing (buildx/buildah) to further reduce image size? Describe the drawbacks of your solution Describe alternatives you've considered runatlantis/atlantis

#5869 Autoplan all *.tf* files Issue created by jmar043213 ### 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 infrastructure engineer, I'd like autoplan enabled to include all tf files (.tf) so that when statements are not needed at all and there will be less custom atlantis config needed. For example, the file userdata.tftpl does not trigger a plan. Describe the solution you'd like I'd like autoplan enabled to include all tf files (.tf). Describe the drawbacks of your solution It would increase the number of files that could trigger an autoplan, which may not be expected by everyone. runatlantis/atlantis

#5870 Print version of terraform in commments for plans and applies Issue created by snuggie12 ### 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 To make any auditing or historical lookup easier, it'd be nice if somewhere in the comment for plans and applies that the version of TF or whatever binary was stated. Best I could tell this does not currently exist. Describe the solution you'd like I'm open as to how it is implemented. Just somewhere in the comment. Describe the drawbacks of your solution There aren't any aside from max character restrictions being impacted. Also, you wouldn't want to paste it in a spot where it would be too frequent. Describe alternatives you've considered None runatlantis/atlantis

#5871 Missing image signature for v0.36.0 release Issue created by ryan-vance-cresta ### 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 updating to v0.36.0, our Docker image verification fails. It appears that there is no signature attached to the image. ### Reproduction Steps v0.36.0 error cosign verify \ --certificate-identity-regexp 'https://github\.com/runatlantis/atlantis/\.github/workflows/atlantis-image\.yml@refs/tags/.+' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ ghcr.io/runatlantis/atlantis:v0.36.0 Error: no signatures found error during command execution: no signatures found Previous release v0.35.1 success cosign verify \ --certificate-identity-regexp 'https://github\.com/runatlantis/atlantis/\.github/workflows/atlantis-image\.yml@refs/tags/.+' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ ghcr.io/runatlantis/atlantis:v0.35.1 Verification for ghcr.io/runatlantis/atlantis:v0.35.1 -- The following checks were performed on each of these signatures: - The cosign claims were validated - Existence of the claims in the transparency log was verified offline - The code-signing certificate was verified using trusted certificate authority certificates [...snippet...] ### Environment details Atlantis Docker image, running in Kubernetes. runatlantis/atlantis

#2712 Disable Auto planning for a specific user Issue created by tomellis91 ### 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 tools such as renovate and dependabot to raise PRs when packages and libs are out of date. This is causing Autoplan to execute and is forcing users to unlock those PRs before they can apply their changes. Describe the solution you'd like Is there a way where we can disable auto planning for a specific user? Describe the drawbacks of your solution I can't see any drawbacks as it will provide more control over the auto planning feature. I am not sure if this is possible atm but I have not seen anything in the doc's to indicate that it is. Describe alternatives you've considered Stopping the other services from raising the PRs, however this may cause upgrades to be missed. runatlantis/atlantis

#5874 Please allow atlantis to bypass if Terragrunt marked 'skip = true' for a TG resources Issue created by patrickdung ### 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 gitlab-runner Terragrunt (TG) file, we have skip=true We don't want any changes (e.g AMI changes) on the GitLab runner at this moment. Atlantis detected there is a change of the terragrunt.hcl file and consider there is a change. But in this case, when TG process it, it recognize skip = true is configured. TG exits but Atlantis did not cosider the apply is complete. This will make the whole task not being completed. That part/terragrunt file is pending to complete forever and the auto MR by Atlantis will not happen.

Going to run terragrunt init.
PWD is /atlantis/repos/patrick.dung/tg-infra-project2-dev/70/project2-dev_non-prod_eu-central-1_non-prod_gitlab-runner/project2-dev/non-prod/eu-central-1/non-prod/gitlab-runner
REPO_REL_DIR is project2-dev/non-prod/eu-central-1/non-prod/gitlab-runner
Running terragrunt init in /atlantis/repos/patrick.dung/tg-infra-project2-dev/70/project2-dev_non-prod_eu-central-1_non-prod_gitlab-runner/project2-dev/non-prod/eu-central-1/non-prod/gitlab-runner -c1
08:05:49.032 WARN   The `TERRAGRUNT_FETCH_DEPENDENCY_OUTPUT_FROM_STATE` environment variable is deprecated and will be removed in a future version of Terragrunt. Use `TG_DEPENDENCY_FETCH_OUTPUT_FROM_STATE=true` instead.
08:05:49.033 WARN   The `TERRAGRUNT_PROVIDER_CACHE_DIR` environment variable is deprecated and will be removed in a future version of Terragrunt. Use `TG_PROVIDER_CACHE_DIR=/atlantis/plugin-cache` instead.
08:05:49.045 INFO   Terragrunt Cache server is listening on 127.0.0.1:40989
08:05:49.047 WARN   Using `terragrunt.hcl` as the root of Terragrunt configurations is an anti-pattern, and no longer recommended. In a future version of Terragrunt, this will result in an error. You are advised to use a differently named file like `root.hcl` instead. For more information, see <https://terragrunt.gruntwork.io/docs/migrate/migrating-from-root-terragrunt-hcl>
08:05:49.054 INFO   Start Terragrunt Cache server
08:05:49.760 INFO   Skipping terragrunt module ./terragrunt.hcl due to skip = true.
08:05:49.760 INFO   Shutting down Terragrunt Cache server...
08:05:49.760 INFO   Terragrunt Cache server stopped

Going to run plan.
PWD is /atlantis/repos/patrick.dung/tg-infra-project2-dev/70/project2-dev_non-prod_eu-central-1_non-prod_gitlab-runner/project2-dev/non-prod/eu-central-1/non-prod/gitlab-runner
REPO_REL_DIR is project2-dev/non-prod/eu-central-1/non-prod/gitlab-runner
08:05:50.046 WARN   The `TERRAGRUNT_FETCH_DEPENDENCY_OUTPUT_FROM_STATE` environment variable is deprecated and will be removed in a future version of Terragrunt. Use `TG_DEPENDENCY_FETCH_OUTPUT_FROM_STATE=true` instead.
08:05:50.049 WARN   The `TERRAGRUNT_PROVIDER_CACHE_DIR` environment variable is deprecated and will be removed in a future version of Terragrunt. Use `TG_PROVIDER_CACHE_DIR=/atlantis/plugin-cache` instead.
08:05:50.060 INFO   Terragrunt Cache server is listening on 127.0.0.1:33887
08:05:50.061 WARN   Using `terragrunt.hcl` as the root of Terragrunt configurations is an anti-pattern, and no longer recommended. In a future version of Terragrunt, this will result in an error. You are advised to use a differently named file like `root.hcl` instead. For more information, see <https://terragrunt.gruntwork.io/docs/migrate/migrating-from-root-terragrunt-hcl>
08:05:50.065 INFO   Start Terragrunt Cache server
08:05:50.859 INFO   Skipping terragrunt module ./terragrunt.hcl due to skip = true.
08:05:50.859 INFO   Shutting down Terragrunt Cache server...
08:05:50.859 INFO   Terragrunt Cache server stopped
08:05:51.144 WARN   The `TERRAGRUNT_FETCH_DEPENDENCY_OUTPUT_FROM_STATE` environment variable is deprecated and will be removed in a future version of Terragrunt. Use `TG_DEPENDENCY_FETCH_OUTPUT_FROM_STATE=true` instead.
08:05:51.145 WARN   The `TERRAGRUNT_PROVIDER_CACHE_DIR` environment variable is deprecated and will be removed in a future version of Terragrunt. Use `TG_PROVIDER_CACHE_DIR=/atlantis/plugin-cache` instead.
08:05:51.157 INFO   Terragrunt Cache server is listening on 127.0.0.1:44329
08:05:51.163 WARN   Using `terragrunt.hcl` as the root of Terragrunt configurations is an anti-pattern, and no longer recommended. In a future version of Terragrunt, this will result in an error. You are advised to use a differently named file like `root.hcl` instead. For more information, see <https://terragrunt.gruntwork.io/docs/migrate/migrating-from-root-terragrunt-hcl>
08:05:51.179 INFO   Start Terragrunt Cache server
08:05:51.942 INFO   Skipping terragrunt module ./terragrunt.hcl due to skip = true.
08:05:51.942 INFO   Shutting down Terragrunt Cache server...
08:05:51.942 INFO   Terragrunt Cache server stopped

Searching for .tfplan files in /atlantis/repos/patrick.dung/tg-infra-project2-dev/70/project2-dev_non-prod_eu-central-1_non-prod_gitlab-runner/project2-dev/non-prod/eu-central-1/non-prod/gitlab-runner
---
Finished summarizing the plan file.

### Reproduction Steps Create TG resource and set 'skip = true' for it ### Logs ### Environment details ### Additional Context runatlantis/atlantis

#5884 Mergeability may be determined wrongfully on required workflows with multiple checks Issue created by henriklundstrom ### 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 With the

gh-allow-mergeable-bypass-apply

-flag enabled, Atlantis may conclude the mergeability of a pull request incorrectly if there is a required workflow that has multiple checks. Atlantis uses the outcome of the first check in the suite, rather than the outcome of the suite as a whole. Thus, if the first check in the suite is successful, but the suite as a whole is not, for example if a second check is in progress or failed, Atlantis will consider the workflow a success and wrongfully proceed with applying. This may lead to apply executing when it should not be allowed to, and it may also lead to Atlantis attempting to merge the pull request after apply but failing to do so since GitHub will not permit it. ### Reproduction Steps Configure a ruleset with a required workflow that has more than one check. Trigger Atlantis apply after the first check is successful, but before the workflow as a whole is completed. Alternatively, trigger Atlantis apply when the first check is successful, but the workflow as a whole is completed with failure. ### Logs ### Environment details ### Additional Context runatlantis/atlantis

#5888 404 Error when comment creation in Pull Request with Custom Workflow and Terragrunt Issue created by Leo-67 ### 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 running an

atlantis plan

in a Pull Request, the webhook is well trigger, the step well run but the output is not posted within Pull Request comment. Instead I get a 404 error in the logs. ### Reproduction Steps We do use a GitHub Enterprise Server and Atlantis installed with Helm in an Azure Kubernetes Service cluster using a GitHub App for connection between the services. We add Custom Workflow configuration in the `repos.yaml| file to handle Terragrunt following the documentation. Everything looks ok except the plan output which is not included in the Pull Request comment. [Image](https://private-user-images.githubusercontent.com/81637376/501341677-937dd19d-b78a-46f7-8178-f815f168baba.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjA1MTQ3NjEsIm5iZiI6MTc2MDUxNDQ2MSwicGF0aCI6Ii84MTYzNzM3Ni81MDEzNDE2NzctOTM3ZGQxOWQtYjc4YS00NmY3LTgxNzgtZjgxNWYxNjhiYWJhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTEwMTUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUxMDE1VDA3NDc0MVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTdmMDM1YjU0MGQ5NmFlNThkNjE5ZTllYTRmZWY0NTk5MGZhZWJkNDgxNDA5ZWFlNmM4MGNiNWFiZTRhZTA2NzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.E0sYAOVksCI4h9-SsgaY2DdlhaeZHAqqEGtOU7m7RHg) I have made several tests with other based repositories, GitHub App, Atlantis version, basic configuration with Terraform instead etc.. My results concluded that the issue is only related to Terragrunt and output plan in comments. Note that in the above screenshot atlantis can create comments with the API for all the other result types. ### Logs Here you can find the logs I get from the Atlantis pod. Logs

"vcs/instrumented_client.go:116","msg":"Unable to create comment for command plan, error: POST https://<GITHUB_SERVER>/api/v3/repos/l<OWNER>/<REPO_NAME>/issues/61/comments: 404  []","json":{"repo":"liebherr/min_landing_zone_platform","pull":"61"},"stacktrace":"<http://github.com/runatlantis/atlantis/server/events/vcs.(*InstrumentedClient).CreateComment|github.com/runatlantis/atlantis/server/events/vcs.(*InstrumentedClient).CreateComment>\n\tgithub.com/runatlantis/atlantis/server/events/vcs/instrumented_client.go:116\ngithub.com/runatlantis/atlantis/server/events/vcs.(*ClientProxy).CreateComment\n\tgithub.com/runatlantis/atlantis/server/events/vcs/proxy.go:65\ngithub.com/runatlantis/atlantis/server/events.(*PullUpdater).updatePull\n\tgithub.com/runatlantis/atlantis/server/events/pull_updater.go:51\ngithub.com/runatlantis/atlantis/server/events.(*PlanCommandRunner).run\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:264\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"}

"events/pull_updater.go:52","msg":"unable to comment: POST https://<GITHUB_SERVER>/api/v3/repos/l<OWNER>/<REPO_NAME>/issues/61/comments: 404  []","json":{"repo":"liebherr/min_landing_zone_platform","pull":"61"},"stacktrace":"<http://github.com/runatlantis/atlantis/server/events.(*PullUpdater).updatePull|github.com/runatlantis/atlantis/server/events.(*PullUpdater).updatePull>\n\tgithub.com/runatlantis/atlantis/server/events/pull_updater.go:52\ngithub.com/runatlantis/atlantis/server/events.(*PlanCommandRunner).run\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:264\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 If not already included, please provide the following: • Atlantis version: 0.36.0 • Deployment method: Helm in Azure Kubernetes Service • Other tested Atlantis version: 0.35.1 and 0.34.0 Atlantis server-side config file: repoConfig: | repos: - id: <repo_id> branch: /.*/ allowed_overrides: [workflow] allow_custom_workflows: true pre_workflow_hooks: - run: terragrunt-atlantis-config generate --output atlantis.yaml --workflow terragrunt --autoplan --automerge --parallel --create-workspace workflows: terragrunt: plan: steps: - env: name: ARM_OIDC_TOKEN_FILE_PATH command: 'echo $AZURE_FEDERATED_TOKEN_FILE' - env: name: ARM_CLIENT_ID command: 'echo $AZURE_CLIENT_ID' - run: # Allow for targeted plans/applies as not supported for Terraform wrappers by default command: terragrunt plan -input=false $(printf '%s' $COMMENT_ARGS | sed 's/,/ /g' | tr -d '\\') -no-color -out $PLANFILE output: hide - run: | terragrunt show $PLANFILE apply: steps: - env: name: ARM_OIDC_TOKEN_FILE_PATH command: 'echo $AZURE_FEDERATED_TOKEN_FILE' - env: name: ARM_CLIENT_ID command: 'echo $AZURE_CLIENT_ID' - run: terragrunt apply -input=false $PLANFILE Repo

atlantis.yaml

file: atlantis.yaml file is generated on the fly with terragrunt-atlantis-config Any other information you can provide about the environment/deployment (efs/nfs, aws/gcp, k8s/fargate, etc) ### Additional Context runatlantis/atlantis

#5894 team_authz passes teams as unquoted arguments to sh -c, and it breaks on special characters (like parentheses) causing it to return "Error: User @user does not have permissions to execute 'plan' command." Issue created by rfaurevincent-wiser ### 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

team_authz:
      command: "/etc/atlantis/scripts/admin-auth.sh"

debug log:

{
  "level": "debug",
  "ts": "2025-10-17T12:50:35.389Z",
  "caller": "runtime/external_team_allowlist_runner.go:53",
  "msg": "error: exit status 2: running \"sh -c /etc/atlantis/scripts/admin-auth.sh plan MyOrg/team-a MyOrg/Team-B MyOrg/team-b MyOrg/Developers MyOrg/developers MyOrg/Developers - Product Public Repos MyOrg/developers-product-public-repos MyOrg/Product Tech Leads MyOrg/product-tech-leads MyOrg/Product Mobile App MyOrg/product-mobile-app MyOrg/Analytics Team MyOrg/analytics-team MyOrg/Product MyOrg/product MyOrg/Engineering MyOrg/engineering MyOrg/Product Management (PM) MyOrg/product-management-pm MyOrg/Administrator MyOrg/administrator\": \nsh: syntax error: unexpected \"(\"\n",
  "json": {}
}

Atlantis comment on PR:

Error: User @user does not have permissions to execute 'plan' command.

this error should never actually be reached in normal operation. removing the user from the team with parentheses in the name restores normal functionality. ### Reproduction Steps set up any

team_authz

script (even just

echo "pass"; exit 0

) and comment

atlantis plan

with a user in a team with special characters. anything else should be irrelevant, the error is really scoped to that specific

sh -c

command. in our case the team is on github, but #5314 seems to be the same problem on gitlab. I will try to send a PR to fix this... runatlantis/atlantis

#5899 [Refactor] Rewrite the `ExecutorService` to a cron supported scheduler Issue created by ramonvermeulen ### 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 handles scheduled tasks through the ExecutorService, which manages two main functions: 1. Publishing runtime stats every 10 seconds via RuntimeStatsCollector. 2. Rotating GitHub tokens every 30 seconds via GithubTokenRotator. While this works for current needs, the scheduling capabilities are quite basic and lack cron support. Enhancing this would make it easier to implement features like: • #3245 (Drift Detection) • #916 (Plugin Cache Clean-up) For both of these features it would be beneficial to have a scheduler with cron support on the server. Describe the solution you'd like I suggest replacing the

ExecutorService

with a

ScheduleManager

singleton that uses gocron Scheduler. Jobs would be registered with the

ScheduleManager

but remain fully decoupled from it. The gocron package provides: • Cron job support • Various job types • Built-in job queues, max concurrent jobs, and more useful features (see examples) The gocron package supports a variety of Job types, including a CronJob. Also it supports built-in mechanisms for Job queues and a lot more beneficial features for scheduling server-side tasks. I did some drafting at: ramonvermeulen/atlantis@main...f/refactor-scheduler to illustrate the direction (note: this is an early proof of concept, and far from a full implementation). Describe the drawbacks of your solution • Adds a new dependency:

<http://github.com/go-co-op/gocron|github.com/go-co-op/gocron>

(a well-maintained and widely used package, but still it is a new dependency) • Requires refactoring

ExecutorService

into

ScheduleManager

, which will need thorough testing to ensure GitHub token rotation and stats publishing continue working reliably. Describe alternatives you've considered I looked at making the scheduler completely separate from the Atlantis server (multi-container setup, similar to Airflow), but this would require significant changes and doesn't align with Atlantis's single-server approach. runatlantis/atlantis

#3891 --skip-clone-no-changes does not work with fork PRs Issue created by Ulminator ### 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 --skip-clone-no-changes does not seem to work with fork PRs. ### Reproduction Steps • Start the Atlantis server • Create a fork of a base repo, matching the regex in the repos.yaml below. (VCS used: GitHub) • Create a PR against the base repo • An

atlantis.yaml

file is present that has a project defined • The files changed in this PR are not in any project directories defined in the

atlantis.yaml

. From the above, I would expect the repo to not be cloned as the changes are to files outside of the defined project. However, if you look at the Atlantis data dir you will see that the fork has been cloned. ### Logs Provide log files from Atlantis server logs can be retrieved from the deployment or from atlantis comments by adding

--debug

such as

atlantis plan --debug

Logs

{"level":"debug","ts":"2023-10-23T21:42:10.920Z","caller":"server/middleware.go:45","msg":"POST /events – from 127.0.0.1:38102","json":{}}
{"level":"debug","ts":"2023-10-23T21:42:10.920Z","caller":"events/events_controller.go:103","msg":"handling GitHub post","json":{}}
{"level":"debug","ts":"2023-10-23T21:42:10.920Z","caller":"events/events_controller.go:169","msg":"request valid","json":{"gh-request-id":"X-Github-Delivery=04fcd390-71ed-11ee-8bda-6f43a7c959e3"}}
{"level":"debug","ts":"2023-10-23T21:42:10.921Z","caller":"events/events_controller.go:423","msg":"identified event as type \"updated\"","json":{"gh-request-id":"X-Github-Delivery=04fcd390-71ed-11ee-8bda-6f43a7c959e3"}}
{"level":"debug","ts":"2023-10-23T21:42:10.921Z","caller":"server/middleware.go:72","msg":"POST /events – respond HTTP 200","json":{}}
{"level":"debug","ts":"2023-10-23T21:42:10.921Z","caller":"vcs/github_client.go:143","msg":"[attempt 1] GET /repos/<redacted_base_repo>/pulls/<pull_number>/files","json":{}}
{"level":"debug","ts":"2023-10-23T21:42:11.062Z","caller":"metrics/debug.go:52","msg":"timer","json":{"name":"atlantis.github.get_modified_files.execution_time","value":0.140859106,"tags":{"base_repo":"<redacted_base_repo>","pr_number":"<pull_number>"},"type":"timer"}}
{"level":"debug","ts":"2023-10-23T21:42:11.062Z","caller":"events/project_command_builder.go:290","msg":"1 files were modified in this pull request","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"debug","ts":"2023-10-23T21:42:11.156Z","caller":"metrics/debug.go:42","msg":"counter","json":{"name":"atlantis.github.get_modified_files.execution_success","value":1,"tags":{"base_repo":"<redacted_base_repo>","pr_number":"<pull_number>"},"type":"counter"}}
{"level":"debug","ts":"2023-10-23T21:42:11.156Z","caller":"metrics/debug.go:42","msg":"counter","json":{"name":"atlantis.github_event.pr_synchronize.success_200","value":1,"tags":{"base_repo":"<redacted_base_repo>","pr_number":"<pull_number>"},"type":"counter"}}
{"level":"debug","ts":"2023-10-23T21:42:11.160Z","caller":"events/project_command_builder.go:332","msg":"got workspace lock","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"info","ts":"2023-10-23T21:42:11.161Z","caller":"events/working_dir.go:230","msg":"creating dir \"/dir/.atlantis/repos/<redacted_base_repo>/<pull_number>/default\"","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"debug","ts":"2023-10-23T21:42:14.747Z","caller":"events/working_dir.go:262","msg":"ran: git clone --depth=1 --branch branch_name --single-branch <redacted.git> /dir/.atlantis/repos/<redacted_base_repo>/<pull_number>/default. Output: Cloning into '/root/.atlantis/repos/<redacted_base_repo>/<pull_number>/default'...","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"info","ts":"2023-10-23T21:42:14.747Z","caller":"events/project_command_builder.go:357","msg":"successfully parsed path/to/atlantis.yaml file","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"debug","ts":"2023-10-23T21:42:14.747Z","caller":"events/project_command_builder.go:364","msg":"moduleInfo for /root/.atlantis/repos/<redacted_base_repo>/<pull_number>/default (matching \"\") = map[]","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"debug","ts":"2023-10-23T21:42:14.747Z","caller":"events/project_finder.go:185","msg":"found downstream projects for \"some_file.py\": []","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"debug","ts":"2023-10-23T21:42:14.747Z","caller":"events/project_finder.go:192","msg":"checking if project at dir \"environments/env_a\" workspace \"default\" was modified","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"info","ts":"2023-10-23T21:42:14.748Z","caller":"events/project_command_builder.go:371","msg":"0 projects are to be planned based on their when_modified config","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"debug","ts":"2023-10-23T21:42:14.748Z","caller":"metrics/debug.go:52","msg":"timer","json":{"name":"atlantis.builder.execution_time","value":3.826454988,"tags":{},"type":"timer"}}
{"level":"info","ts":"2023-10-23T21:42:14.748Z","caller":"events/plan_command_runner.go:97","msg":"determined there was no project to run plan in","json":{"repo":"<redacted_base_repo>","pull":"<pull_number>"}}
{"level":"debug","ts":"2023-10-23T21:42:14.748Z","caller":"metrics/debug.go:52","msg":"timer","json":{"name":"atlantis.cmd.autoplan.execution_time","value":3.826552526,"tags":{},"type":"timer"}}
{"level":"debug","ts":"2023-10-23T21:42:15.156Z","caller":"metrics/debug.go:42","msg":"counter","json":{"name":"atlantis.builder.execution_success","value":1,"tags":{},"type":"counter"}}

### Environment details If not already included, please provide the following: • Atlantis version:

atlantis 0.24.3 (commit: 5b8ddc7) (build date: 2023-06-20T22:05:19Z)

• Deployment method: GCE • If not running the latest Atlantis version have you tried to reproduce this issue on the latest version: No • Atlantis flags: Atlantis server-side config file: repos: - id: /github\.com\/(.*?)\/repo_name/ branch: /master/ repo_config_file: path/to/atlantis.yaml plan_requirements: [] apply_requirements: [approved, mergeable, undiverged] import_requirements: [approved, mergeable, undiverged] Repo

atlantis.yaml

file: version: 3 projects: - name: env_a dir: environments/env_a autoplan: when_modified: ["*.tf", "../modules/host/*.tf", ".terraform.lock.hcl"] enabled: true Any other information you can provide about the environment/deployment (efs/nfs, aws/gcp, k8s/fargate, etc) Additional env vars:

export ATLANTIS_ALLOW_FORK_PRS=true
export ATLANTIS_RESTRICT_FILE_LIST=true
export ATLANTIS_SILENCE_NO_PROJECTS=true
export ATLANTIS_SILENCE_VCS_STATUS_NO_PLANS=true
export ATLANTIS_SKIP_CLONE_NO_CHANGES=true
export ATLANTIS_DISABLE_AUTOPLAN=false

### Additional Context I believe this is caused by the

hasRepoCfg

check always failing below. That code is located <https://github.com/runatlantis/atlantis/blob/a542aa8f2015e67957c5fdb6ec994080561aa… runatlantis/atlantis