GitHub
08/21/2025, 1:07 PMGitHub
08/25/2025, 1:18 PMGitHub 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
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/atlantisGitHub
08/26/2025, 1:36 AM--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
{"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/atlantisGitHub
08/26/2025, 2:27 PM--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/atlantisGitHub
08/26/2025, 3:34 PMfeat: 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/atlantisGitHub
08/28/2025, 4:21 AMversion: "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/atlantisGitHub
09/01/2025, 1:50 PMGetting 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/atlantisGitHub
09/03/2025, 8:21 PM@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/atlantisGitHub
09/05/2025, 9:38 PMatlantis-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/atlantisGitHub
09/09/2025, 2:55 AM{"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/atlantisGitHub
09/09/2025, 1:29 PMGitHub
09/10/2025, 9:08 PMapply_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/atlantisGitHub
09/12/2025, 3:59 PMCan'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/atlantisGitHub
09/15/2025, 12:59 PM/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/atlantisGitHub
09/17/2025, 4:47 PMatlantis 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/atlantisGitHub
09/18/2025, 8:27 PMatlantis 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/atlantisGitHub
09/22/2025, 1:02 PMneed_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/atlantisGitHub
09/23/2025, 4:03 PMparallel_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/atlantisGitHub
09/24/2025, 6:49 PMcurl --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/atlantisGitHub
09/26/2025, 5:51 PMATLANTIS_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/atlantisGitHub
10/03/2025, 12:57 PMatlantis 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/atlantisGitHub
10/06/2025, 3:08 AMPull 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/atlantisGitHub
10/07/2025, 3:20 AM/bin/sh: 1: apk: not foundI 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
GitHub
10/07/2025, 6:34 PMGitHub
10/07/2025, 6:34 PMGitHub
10/07/2025, 8:14 PMGitHub
10/07/2025, 10:07 PMGitHub
10/08/2025, 9:34 AMGitHub
10/09/2025, 8:23 AMGoing 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/atlantisGitHub
10/13/2025, 11:47 AMgh-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