feat: add status for plan/apply to commits - #941
Open
DjinnS wants to merge 12 commits into
Open
Conversation
Contributor
Author
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #941 +/- ##
==========================================
+ Coverage 47.62% 47.79% +0.17%
==========================================
Files 99 102 +3
Lines 6163 6532 +369
==========================================
+ Hits 2935 3122 +187
- Misses 3022 3185 +163
- Partials 206 225 +19 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
DjinnS
force-pushed
the
feat/commit_statuses_v2
branch
3 times, most recently
from
July 10, 2026 15:45
1d24fd3 to
47cbbe1
Compare
Adds two related improvements to the pull request lifecycle:
- Post a comment on the pull/merge request once Burrito applies the
merged changes, reporting success or failure per affected layer
(internal/controllers/terraformpullrequest/comment/apply.go). The
TerraformPullRequest resource is kept alive after merge (annotated
with the merge date instead of being deleted) so its controller can
track layer applies and post that comment once they complete.
- Report plan and apply status via the GitHub Commit Statuses API and
GitLab External Commit Statuses (internal/controllers/terraformpullrequest/status,
APIProvider.SetStatus in the github/gitlab/mock providers). The
status is set to pending when a phase starts and updated to
success/failure based on the actual outcome:
- plan: pending when temp layers are created, success/failure once
the comment is posted, based on whether every layer produced a
plan.
- apply: pending while waiting for the merged layers to apply,
success/failure once they all have, based on LastApplyDate vs a
failed TerraformRun created after the merge.
Status updates are best-effort and never fail the reconciliation loop.
…anch Commits pushed straight to a repository's base branch never go through a TerraformPullRequest, so no plan/apply commit status was ever posted for them. The terraformrun controller now posts one itself when a run's layer isn't pull-request-managed, disambiguated per layer since there's no PR to aggregate multiple layers under a single status context.
DjinnS
force-pushed
the
feat/commit_statuses_v2
branch
from
July 10, 2026 16:23
a21eab3 to
3c10a6e
Compare
4 tasks
… whole run lifecycle Commit statuses were only ever posted once plan/apply had already finished, and aggregated across all layers on a pull request (or not posted at all on a direct push). Every layer now gets its own status as soon as a run is decided (pending: needed), when its pod starts (pending: in progress), and on completion (success/failure) — for both pull-request-managed and base-branch layers alike. The now-redundant PR-level aggregate statuses and merge-commit resolution are removed.
…sult The description now mirrors the layer's "Last Result" field (the short plan/apply summary, or a placeholder like "Layer has never been planned") instead of repeating the phase/outcome already carried by the native pending/success/failure state and the context. Truncated to GitHub's 140-character limit, with no emoji (GitHub rejects 4-byte UTF-8 there).
Adds a "Details" link on plan/apply commit statuses pointing at the matching layer/run logs page, gated behind a new server.publicUrl config value (defaults to empty, which omits the link entirely).
…ding
GitLab's commit status is a real state machine (pending -> running ->
success/failed) and rejects posting "pending" twice in a row with a 400
("Cannot transition status via :enqueue from :pending") — which is exactly
what happened once a run's pod started right after it was decided. GitHub
has no such restriction and no "running" state, so its provider folds the
new state back into "pending".
Retrying a validation error (422) or a provider-side cap (e.g. "maximum number of statuses reached") three times with backoff was pure waste — it would never succeed. Only retry on what's actually transient: 5xx, 429, or a plain network failure with no HTTP response at all. Logging moves into commitstatus.Post itself, with a message that says whether the failure was given up on immediately or only after exhausting retries, replacing the generic "Error while setting commit status" logged by each provider.
apply always wrote a hardcoded "Apply Successful" as its short result,
unlike plan which summarizes the diff ("Plan: X to create, Y to update,
Z to delete"). Reuse the same summary, computed from the JSON plan
artifact that was actually applied, falling back to the old placeholder
when that artifact is missing or unparseable.
…e Details link The dashboard's hide-PR-layers filter defaults to on. Following a commit status's "Details" link without hidepr=false could land on a filtered-out, empty layer list.
Fixes GHSA-hrxh-6v49-42gf (gRPC-Go xDS RBAC and HTTP/2 vulnerabilities), flagged by the Trivy vulnerability scan.
Contributor
Author
TestsGithubPR
Details link show the layer in Burrito Merge
GitlabMR
The job send to Burrito and show the layer 
(same as Github) Merge
|
It posts to a repository provider (GitHub/GitLab), so it belongs next to providers/, credentials/ and types/ rather than under internal/controllers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.