https://www.runatlantis.io/ logo
Join Slack
Powered by
# github-issues
  • g

    GitHub

    08/21/2025, 1:07 PM
    #4268 Atlantis unlock displays false message Issue created by ChrisFraun ### 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 Whenever we perform 'atlantis unlock' the lock gets removed. However, we also get the false message of 'Failed to delete PR locks'. Has anybody encountered a similar issue or knows how to get rid of it? Since we just recently updated from verison v0.24.2 to v0.27.1, our suspect is that this issue is located in the new versions. ### Reproduction Steps For us its happening every time we perform 'atlantis unlock'. ### Environment details runatlantis/atlantis
    • 1
    • 1
  • g

    GitHub

    08/25/2025, 1:18 PM
    #5734 Confusing webhook doc notes for GitHub app Issue created by jreslock Per a slack thread I am submitting this issue and will be creating a PR to address it. The current documentation for access-credentials.md contains two conflicting "notes" regarding webhook configuration requirements for the GitHub App setup that are confusing. Here:
    Copy code
    GitHub App handles the webhook calls by itself, hence there is no need to create webhooks separately. If webhooks were created manually, those should be removed when using GitHub App. Otherwise, there would be 2 calls to Atlantis resulting in locking errors on path/workspace.
    Then also here
    Copy code
    Webhooks must be created manually for repositories that trigger Atlantis.
    This is somewhat confusing as the actual behavior is as follows: The GitHub App can be configured to manage webhooks or not. If the app is configured to manage webhooks, the user should not create or manage the webhooks manually as this will cause locking errors and general instability. I propose a new, combined note which explains this behavior in a more direct and clear way. ### 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 ### Logs ### Environment details ### Additional Context runatlantis/atlantis
    • 1
    • 1
  • g

    GitHub

    08/26/2025, 1:36 AM
    #5736 Markdown template overrides not working despite correct configuration Issue created by SaberSHO ### Community Note • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. • 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
    --markdown-template-overrides-dir
    flag appears to be non-functional. Despite having correctly configured custom markdown templates with proper file structure, permissions, and content, Atlantis continues to use the built-in default templates instead of the custom overrides. I have verified: • ✅ The flag is correctly set and appears in the process arguments • ✅ Template files exist at the specified path with correct permissions (644, owned by atlantis:atlantis) • ✅ All template dependencies are included (no missing template references) • ✅ Template syntax is valid (exact copies of default templates with minimal modifications) • ✅ Files are regular files (not symlinks) to avoid any parsing issues • ✅ All 39 templates are present (complete override set) The custom templates are never used, and there are no error messages in the logs indicating template parsing failures. ### Reproduction Steps 1. Configure Atlantis with custom template directory: atlantis server --markdown-template-overrides-dir="/home/atlantis/templates" 2. Create custom templates with test content: # Example: single_project_plan_success.tmpl {{ define "singleProjectPlanSuccess" -}} TEST TEMPLATE WORKING {{ $result := index .Results 0 -}} Walked {{ .Command }} for {{ if $result.ProjectName }}project:
    {{ $result.ProjectName }}
    {{ end }}dir:
    {{ $result.RepoRelDir }}
    workspace:
    {{ $result.Workspace }}
    # ... rest of template identical to default 3. Verify template files are accessible: # Files exist and are readable $ ls -la /home/atlantis/templates/ -rw-r--r-- 1 atlantis atlantis 641 single_project_plan_success.tmpl # ... 38 other templates # Content is correct $ head -3 /home/atlantis/templates/single_project_plan_success.tmpl {{ define "singleProjectPlanSuccess" -}} TEST TEMPLATE WORKING {{ $result := index .Results 0 -}} 4. Trigger Atlantis plan command 5. Expected: See "TEST TEMPLATE WORKING" in the output Actual: Default template is used, no custom content appears ### Logs Atlantis Server Startup Logs
    Copy code
    {"level":"info","ts":"2025-08-26T00:45:23.697Z","caller":"server/server.go:342","msg":"Supported VCS Hosts: Github","json":{}}
    {"level":"info","ts":"2025-08-26T00:45:23.969Z","caller":"server/server.go:503","msg":"Utilizing BoltDB","json":{}}
    {"level":"info","ts":"2025-08-26T00:45:24.020Z","caller":"vcs/git_cred_writer.go:29","msg":"wrote git credentials to /home/atlantis/.git-credentials","json":{}}
    {"level":"info","ts":"2025-08-26T00:45:24.023Z","caller":"vcs/git_cred_writer.go:71","msg":"successfully ran git config --global credential.helper store","json":{}}
    {"level":"info","ts":"2025-08-26T00:45:24.026Z","caller":"vcs/git_cred_writer.go:77","msg":"successfully ran git config --global url.<https://x-access-token@github.com.insteadOf> <ssh://git@github.com%22,%22json%22:{}}|ssh://git@github.com","json":{}}>
    {"level":"info","ts":"2025-08-26T00:45:24.026Z","caller":"policy/conftest_client.go:168","msg":"failed to get default conftest version. Will attempt request scoped lazy loads DEFAULT_CONFTEST_VERSION not set","json":{}}
    {"level":"info","ts":"2025-08-26T00:45:24.027Z","caller":"scheduled/executor_service.go:51","msg":"Scheduled Executor Service started","json":{}}
    {"level":"info","ts":"2025-08-26T00:45:24.027Z","caller":"server/server.go:1111","msg":"Atlantis started - listening on port 4141","json":{}}
    Process Arguments Verification $ ps aux | grep atlantis atlantis server --disable-markdown-folding --markdown-template-overrides-dir="/home/atlantis/templates" Template Directory Contents $ ls -la /home/atlantis/templates/ | wc -l 39 # All 39 templates present $ find /home/atlantis/templates -name "*.tmpl" | wc -l 39 # All files have .tmpl extension $ grep -c "define \"" /home/atlantis/templates/*.tmpl | wc -l 39 # All templates have valid define statements Notable: No template-related error messages appear in logs when using
    grep -i "template\|error\|fail\|parse"
    . ### Environment details • Atlantis version: v0.35.1 (commit: e987e33) (build date: 2025-07-31T003000.639Z) • Deployment method: Kubernetes/Helm • Running latest version: Yes (v0.35.1) • Atlantis flags:
    --disable-markdown-folding --markdown-template-overrides-dir="/home/atlantis/templates"
    Atlantis server-side config file: # Using Helm chart with extraArgs configuration extraArgs: - --disable-markdown-folding - --markdown-template-overrides-dir="/home/atlantis/templates" # Additional settings enableDiffMarkdownFormat: true hidePrevPlanComments: false Repo
    atlantis.yaml
    file:
    # No repo-level configuration (using global defaults) Additional deployment details: • Kubernetes cluster on Linux • Templates mounted via initContainer copying from ConfigMap to emptyDir volume • Files verified as regular files (not symlinks) with correct ownership • No storage constraints or permission issues ### Additional Context Investigation performed: 1. Verified template loading code in
    server/events/markdown_renderer.go
    lines 158-162 2. Confirmed feature exists via PR #2647 (merged Nov 2022) 3. Tested multiple approaches: minimal templates, comprehensive templates, different mount strategies 4. Verified all dependencies: included all 39 templates to prevent silent parsing failures 5. Added test strings to ALL plan-related templates: Added "TEST TEMPLATE WORKING" messages to
    singleProjectPlanSuccess
    ,
    planSuccessUnwrapped
    ,
    planSuccessWrapped
    ,
    singleProjectPlanUnsuccessful
    ,
    multiProjectPlan
    ,
    multiProjectHeader
    , and
    multiProjectPlanFooter
    templates to definitively test if ANY template overrides work - none appeared in output Code analysis suggests the issue may be: • Silent failure in
    template.ParseGlob()
    on line 159 of
    markdown_renderer.go
    • No error logging when template parsing fails • Fallback to embedded templates without indication Related issues/PRs: • PR #2647 - Original implementation • PR #2541 - Earlier attempt (closed) The lack of any error messages or debug output makes it difficult to determine if templates are being parsed at all or if there's a silent failure in the override mechanism. runatlantis/atlantis
  • g

    GitHub

    08/26/2025, 2:27 PM
    #5739 Docs: `policy_check` is not a command, but must be allowlisted for it to work Issue created by ribejara-te ### 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 We are using Atlantis with
    --gh-team-allowlist='*:plan, *:unlock, sre:apply'
    , and we wanted to enable conftest policy checking, so we configured it and added
    *:approve_policies
    to our team allowlist so that policy owners are allowed to run the command (everyone is, but if they're not a policy owner they'll get rejected later down the line). In our testing, this worked on autoplans, but not on
    atlantis plan
    commands. Autoplans would run policy checks, but plan commands wouldn't. ### Reproduction Steps 1. Run Atlantis with conftest policy checking enabled and with
    --gh-team-allowlist='*:plan, *:unlock, *:approve_policies, *:apply'
    . 2. Raise a PR to trigger an autoplan, it will plan and run the policy checks. 3. Now commant
    atlantis plan
    , it will plan but it will NOT run the policy checks. ### Solution After digging through the code, we found this bit over here which makes sure that whoever is running the
    plan
    command, is also allowed to run the
    policy_check
    command, which is not a command per se in documentation, but is treated as such for the purposes of allowlist evaluation. And sure thing, we added
    *:policy_check
    to our allowlist, and now policy checks always run, as expected. As far as I could tell, this is not documented anywhere, and given that
    policy_check
    is not a command, it's pretty unintuitive that it has to be allowlisted for it to work. This is extra confusing because autoplans do work (autoplans don't have a user associated with it, and thus always pass allowlist evaluation even for the
    policy_check
    command). runatlantis/atlantis
  • g

    GitHub

    08/26/2025, 3:34 PM
    #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
    • 1
    • 1
  • g

    GitHub

    08/28/2025, 4:21 AM
    #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
    Copy code
    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
    Copy code
    # 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)
    Copy code
    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
    • 1
    • 1
  • g

    GitHub

    09/01/2025, 1:50 PM
    #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:
    Copy code
    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:
    Copy code
    ...
    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
  • g

    GitHub

    09/03/2025, 8:21 PM
    #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
    • 1
    • 1
  • g

    GitHub

    09/05/2025, 9:38 PM
    #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:
    Copy code
    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
    • 1
    • 1
  • g

    GitHub

    09/09/2025, 2:55 AM
    #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
    Copy code
    {"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
    • 1
    • 1
  • g

    GitHub

    09/09/2025, 1:29 PM
    #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
    • 1
    • 1
  • g

    GitHub

    09/10/2025, 9:08 PM
    #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:
    Copy code
    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
  • g

    GitHub

    09/12/2025, 3:59 PM
    #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:
    Copy code
    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
  • g

    GitHub

    09/15/2025, 12:59 PM
    #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
  • g

    GitHub

    09/17/2025, 4:47 PM
    #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:
    Copy code
    {"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:
    Copy code
    {"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:
    Copy code
    --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):
    Copy code
    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
  • g

    GitHub

    09/18/2025, 8:27 PM
    #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
    • 1
    • 1
  • g

    GitHub

    09/22/2025, 1:02 PM
    #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
    Copy code
    {"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:
    Copy code
    - 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
    • 1
    • 1
  • g

    GitHub

    09/23/2025, 4:03 PM
    #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
    • 1
    • 1
  • g

    GitHub

    09/24/2025, 6:49 PM
    #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
    Copy code
    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$
    Copy code
    {"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
    • 1
    • 1
  • g

    GitHub

    09/26/2025, 5:51 PM
    #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
    .
    Copy code
    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
  • g

    GitHub

    10/03/2025, 12:57 PM
    #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
  • g

    GitHub

    10/06/2025, 3:08 AM
    #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
    • 1
    • 1
  • g

    GitHub

    10/07/2025, 3:20 AM
    #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
    • 1
    • 1
  • g

    GitHub

    10/07/2025, 6:34 PM
    #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
  • g

    GitHub

    10/07/2025, 6:34 PM
    #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
    • 1
    • 1
  • g

    GitHub

    10/07/2025, 8:14 PM
    #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
  • g

    GitHub

    10/07/2025, 10:07 PM
    #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
  • g

    GitHub

    10/08/2025, 9:34 AM
    #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
    • 1
    • 1
  • g

    GitHub

    10/09/2025, 8:23 AM
    #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.
    Copy code
    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
  • g

    GitHub

    10/13/2025, 11:47 AM
    #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