🚀 Enhancements
test(describe-affected): accept all three valid Source values in TestResolveBase_PullRequest_Closed @aknysh (#2388)
## whatFix a CI-blocking test bug in `pkg/ci/providers/github/base_test.go` introduced silently by PR #2380.
`TestResolveBase_PullRequest_Closed` passes on PR runs (where `merge-base` or `HEAD~1` is reachable) but fails on post-merge runs to `main` (where only the documented `event.pull_request.base.sha` fallback is available):
- https://github.com/cloudposse/atmos/actions/runs/25254046463/job/74053358101
- https://github.com/cloudposse/atmos/actions/runs/25254046463/job/74053358088
why
The assertion
```go
assert.Contains(t, res.Source, "merge-base", "HEAD~1")
```
has a silent bug: testify treats the 4th positional argument to `assert.Contains` as the failure message, not an alternate value to match. So the test only ever checked for `"merge-base"`, and quietly passed on PR runs (where `merge-base` or `HEAD~1` was reachable) while failing on post-merge runs to `main` (where the GitHub Actions checkout depth and missing `origin/` fetch leave only the third documented fallback, `event.pull_request.base.sha`).
`ResolveBase()`'s closed-PR fallback chain in `pkg/ci/providers/github/base.go` documents three valid Sources:
- `"merge-base(HEAD, origin/)"`
- `"HEAD~1 (merged PR, merge-base unavailable)"`
- `"event.pull_request.base.sha"`
Replace the broken `Contains`-with-msg call with an explicit OR over the three substrings. The fix matches the test's own existing comment ("merge-base and HEAD~1 may or may not work; either way we get a valid resolution") -- the bug was that the assertion didn't actually check for "either way."
No production code change -- `ResolveBase()` already implements all three fallback paths correctly.