feat: enabling pending apply status when any of the projects has changes to…

[rjmsilveira]

What

This MR restores the ability to set commit status to pending when there are planned Terraform changes that haven't been applied yet. This feature is now:

GitLab-specific (controlled by the --gitlab-pending-apply-status flag)

Opt-in (defaults to false to maintain backward compatibility)
Provides better visibility into MR readiness by blocking merges until all applies are completed

Why

When enabled, this feature prevents GitLab merge requests from being merged prematurely by setting the commit status to pending when:

• atlantis plan detects changes that need to be applied
• Not all projects have been successfully applied

The status transitions:

• ✅ Success: All projects applied or show no changes
• ⏳ Pending: Planned changes exist but haven't been applied yet
• ❌ Failed: Apply errors occurred

This addresses a common workflow requirement where teams want to ensure all infrastructure changes are actually applied before allowing the MR to merge, preventing situations where planned changes are approved but never executed.

Why GitLab-only and opt-in?

The original implementation (#2053) caused issues (#2138) with race conditions where apply status would appear before plans completed, leading to confusion and stuck PRs. The feature was reverted in #2173.

Since then, Atlantis has significantly improved its event ordering and status update handling. However, to ensure maximum safety and backward compatibility, this restoration:

Limits scope to GitLab - where the feature is most requested and tested
Requires explicit opt-in - prevents unexpected behavior changes for existing users
Preserves existing behavior - when disabled or on other VCS platforms, no status updates occur for unapplied plans
Tests
Added comprehensive test coverage in TestPlanCommandRunner_GitlabPendingApplyStatus:

✅ GitLab + flag enabled + unapplied plans → Pending status
✅ GitLab + flag disabled + unapplied plans → No status update (backward compatible)
✅ GitLab + all plans applied → Success status
✅ GitHub/Bitbucket + flag enabled → No status update (GitLab-only feature)
✅ GitLab + apply errors → Failed status
All existing tests pass, ensuring backward compatibility is maintained.

References

Original feature (2021): https://github.com/runatlantis/atlantis/pull/2053/files
Issue reports (race conditions): https://github.com/runatlantis/atlantis/issues/2138
Feature revert (2022): https://github.com/runatlantis/atlantis/pull/2173/files

Key improvements since the original implementation:

The latest Atlantis codebase now handles event ordering much more reliably. The race condition issues that caused the original revert (where apply status would appear before plans properly finished) have been resolved through improved event sequencing. This makes it safe to reintroduce the feature with proper safeguards (opt-in flag + VCS-specific implementation).

Configuration:

See updated documentation in server-configuration.md.

This approach provides the requested functionality while learning from past issues and ensuring a smooth, safe rollout for teams that need this workflow enforcement.

[joelbatistaferreira]

This feature is a must-have for me.
Thank you Ricardo for re-enabling this.

[Aliantez]

Thanks for adding this, I like it.

[lukemassa]

By the time this variable is being used it's no longer a "flag", a better name might be just PendingApplyStatus.