test(mr): scope the mr note publish integration test to API contract
What
Trims Test_MrNotePublish_Integration to the assertions only a real GitLab instance can answer, and fixes two unchecked cleanup errors in the same file.
Why
The test was added in f12316af alongside a 244-line mocked test for the same command. Four of its assertions are already covered there, verbatim:
| Removed from the integration test | Already covered by |
|---|---|
--yes required when not running interactively |
mr_note_publish_test.go → "--yes required non-interactively" |
✓ Published 1 pending review comment. on stdout |
mr_note_publish_test.go → "bare publish sends no body fields" |
no pending review comments on a second publish |
mr_note_publish_test.go → "errors when there are no pending comments" |
mr note create --draft prints a bare numeric draft ID |
mr_note_create_test.go:815 → assert.Equal(t, "601\n", output.String()) |
What no mock can cover is the request body. mr_note_publish.go calls a deprecated SDK method under a //nolint:staticcheck:
//nolint:staticcheck // PublishAllDraftNotesWithOptions is the only way to pass note/internal/reviewer_state in SDK v3; options merge into PublishAllDraftNotes in 4.0.
_, err = o.client.DraftNotes.PublishAllDraftNotesWithOptions(...)The mocked test asserts that opts.Note, opts.Internal, and opts.ReviewerState are populated on a mock. It cannot tell you whether GitLab does anything with them. That is the coverage worth keeping here, and it is what would catch the SDK v4 migration breaking silently.
So the test publishes with --message --internal, then asserts server-side that the drafts are gone, that both note bodies landed, and that internal: true actually took effect: the summary note comes back Internal, and the published draft alongside it does not.
--reviewer-state is not exercised, because this fixture structurally cannot verify it. bulk_publish calls UpdateReviewerStateService and discards the result, returning 204 either way, and that service's assign_reviewer_on_submission? requires merge_request.author_id != current_user.id. The fixture user authors the merge request, so the lookup falls through to find_reviewer, returns nil, and the service errors with "Reviewer not found" into a void. Asserting require.NoError on that proves nothing. Verifying it would need a second account.
Reviewer notes
- This removes test assertions. The
Test disciplinerule inmr-review-instructions.yamlsays not to repurpose baseline tests, because that quietly removes coverage. The table above is the argument that nothing is actually lost: every removed assertion has a named unit-test counterpart. Happy to restore any of them if you disagree on a specific one. --internalis new to this test, and is asserted rather than merely sent. Publishing consumes every draft, so there is one publish call per fixture merge request and therefore one chance to exercise the body fields. Needs an integration run to confirm; I could not run it locally (GITLAB_TEST_HOST/GITLAB_TOKEN_TESTunset).- The two
defer→t.Cleanupchanges fix realerrcheckviolations. They were never reported because.golangci.ymlsets nobuild-tags, so no integration-tagged file in the repo is linted. Reproduce withgolangci-lint run --build-tags=integration ./internal/commands/mr/note/.... Widening lint to cover integration files is worth doing separately; I have not looked at how many other findings that surfaces. - The hand-rolled
cmdutils.NewFactorywiring is unchanged and deliberate. Every integration test that drives a command does it this way (duo/ask,issue/create,issue/update); none usescmdtest.SetupCmdForTest, which builds mocked seams.
Related
This test also creates two always-failing pipelines in cli-automated-testing/test on every run, because it deletes its glab-publish-it-* branch before a runner can fetch the ref. That is fixed separately in cli-automated-testing/test!8 (merged), and is not addressed here.
Dropping --reviewer-state from the test surfaced #8564 (closed): glab mr note publish --reviewer-state silently does nothing when you run it on your own merge request. Not caused by this MR, and not fixed here.