fix(api): populate PullRequestStatus so apply requirements are evaluated

[gBarczyszyn]

Fixes #6534

Problem

POST /api/plan and POST /api/apply always fail with Pull request must be mergeable before running … (or the equivalent for approved) when the target repo configures apply_requirements: [mergeable] or [approved], even when the PR is in fact mergeable/approved on the VCS side.

Root cause

APIController.apiParseAndValidate builds a synthetic command.Context from the JSON body but never populates command.Context.PullRequestStatus. That zero value is propagated to every command.ProjectContext.PullReqStatus by ProjectCommandContextBuilder, so the checks in server/events/command_requirement_handler.go:

case raw.MergeableRequirement:
    if !ctx.PullReqStatus.MergeableStatus.IsMergeable { … }
case raw.ApprovedRequirement:
    if !ctx.PullReqStatus.ApprovalStatus.IsApproved { … }

read IsMergeable=false / IsApproved=false and reject the command unconditionally. The comment-driven runners do not have this issue because PlanCommandRunner / ApplyCommandRunner explicitly call pullReqStatusFetcher.FetchPullStatus(ctx.Log, pull) and assign the result before building project commands.

Change

• Add an optional PullReqStatusFetcher vcs.PullReqStatusFetcher field on APIController (no validate:"required" tag — existing direct callers still compile).
• In apiParseAndValidate, when request.PR > 0 and the fetcher is wired, call FetchPullStatus(logger, pull) and assign the result to ctx.PullRequestStatus before returning the context.
• Wire the existing pullReqStatusFetcher from server.go into APIController. The same fetcher already drives the comment flow, so no new dependency is introduced.
• Two unit tests using the generated MockPullReqStatusFetcher:
  • TestAPIController_PlanFetchesPullReqStatus — when PR > 0, fetcher is called exactly once.
  • TestAPIController_PlanSkipsPullReqStatusWhenNoPR — when PR is omitted, fetcher is never called (zero-PR callers keep their previous behavior).

Because PullReqStatus carries both MergeableStatus and ApprovalStatus, this single change unblocks both mergeable and approved requirements via the API.

Validation

• go test ./server/controllers/... ./server/... passes locally.
• go vet clean.
• Manually validated end-to-end against a real deployment: prior to the fix, /api/apply (and the equivalent MCP write tool I'm running on a fork) was returning the mergeable failure for a PR that GitHub reported as MERGEABLE. With this fix, the requirement is evaluated against actual VCS state, terraform apply runs to completion when the PR meets the requirements, and is properly rejected when it does not.

Backwards compatibility

The new field is optional. If it isn't wired (e.g. in third-party code constructing APIController directly), behavior is exactly as before. PR=0 requests also skip the fetch, matching existing behavior for branch-only API calls.

---

I'm happy to iterate on naming or split tests differently if you'd prefer. Thanks for taking a look!

---

Developed with assistance from Claude Opus 4.7 via Claude Code.

[Kryan90]

Any chance of this PR landing? "mergeable" check seems to be entirely broken currently

[chenrui333]

Any chance of this PR landing? "mergeable" check seems to be entirely broken currently

it would happen today

[chenrui333]

@gBarczyszyn thanks for your first contribution to atlantis!