[Bug][e2e] Several plugin e2e tests fail on a fresh database because they depend on tables created by other tests
Maintainer antworten meist innerhalb von 2 Tagen
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Start with e2ehelper.DataFlowTester and the failing TestCalculateCLTimeDataFlow in plugins/dora/e2e/, then check scripts/e2e-test-go-plugins.sh to see the shared-database order. Reproduce on an empty database with go test -count=1 ./plugins/<plugin>/e2e/..., and make each test create the tables its subtasks read or write. Done means every listed package and test passes alone on a fresh database.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Search before asking
- I had searched in the issues and found no similar issues.
What happened
Several Go plugin e2e tests fail when they run on a fresh, empty database, for example when you run one plugin's e2e package or one test on its own:
--- FAIL: TestCalculateCLTimeDataFlow
panic: failed to batch fetch first reviews (500)
Wraps: (3) Error 1146 (42S02): Table 'lake_test.accounts' doesn't exist
e2ehelper.DataFlowTester runs no migrations. A test only has the tables it flushes or imports. Some tests run subtasks that read or write other tables, for example a converter that deletes old board_issues rows, or a query that joins accounts. Those tables exist in CI only because an earlier test created them: scripts/e2e-test-go-plugins.sh runs every plugin's e2e package in go list order on one shared database.
Packages that fail on their own (fresh database per package):
| Package | Missing table | Test |
|---|---|---|
dora/e2e |
accounts |
TestCalculateCLTimeDataFlow (the first review query joins accounts since #9000) |
customize/e2e |
board_issues |
TestImportIssueChangelogDataFlow, TestImportIssueCommitDataFlow |
gitlab/e2e |
issue_labels |
TestGitlabIssueDataFlow |
opsgenie/e2e |
board_issues |
TestIncidentDataFlow |
pagerduty/e2e |
board_issues |
TestIncidentDataFlow |
teambition/e2e |
board_sprints |
TestTeambitionSprints |
Tests that fail with go test -run <Test> (fresh database per test), because an earlier test in the same package created the tables:
customize:TestImportIssueWorklogDataFlowgitlab:TestGitlabMrDataFlow,TestGitlabMrDetailDataFlow,TestGitlabMrNoteDataFlowteambition:TestTeambitionTaskbitbucket:TestCommentDataFlowgithub:TestMilestoneDataFlow,TestPrReviewDataFlowjira:TestEpicDataflow,TestIssueRelationshipDataFlow,TestIssueSubtaskWithoutMappinglinear:TestLinearIssueHistoryDataFlowtapd:TestTapdBugCustomizeDueDate,TestTapdStoryCustomizeDueDate,TestTapdTaskCustomizeDueDate
Some of these tests also read data that an earlier test left behind, not only the table:
- The bitbucket issue comment converter joins
_tool_bitbucket_issues, whichaccount_test.gofills. - The tapd due date tests use the statuses and workitem types that the test before them imports.
Also, the DORA fixture has no bot account, so nothing in the e2e tests covers the bot exclusion added in #9000.
What do you expect to happen
Each e2e package and each e2e test passes on a fresh database. A test sets up every table its subtasks use and does not depend on the order tests run in.
How to reproduce
- Create an empty MySQL database.
- From
backend/:
export E2E_DB_URL='mysql://merico:[email protected]:3306/lake_test?charset=utf8mb4&parseTime=True&loc=UTC'
TZ=UTC go test -count=1 ./plugins/dora/e2e/...
The other packages fail the same way. For the per-test failures, run e.g. go test -count=1 -run '^TestCommentDataFlow$' ./plugins/bitbucket/e2e/ on an empty database.
Anything else
CI passes today only because of the order the tests run in. It would break if the e2e tests ran in parallel or on a database per package.
Version
main (4ad2f66df)
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
- Vorherrschende Sprache
- Go
- Sterne
- 3.2k
- Forks
- 824
- Ø Merge
- 2 T. 22 Std.
- Gemergte PRs (30 T.)
- 43
Entwicklungsumgebung
Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Kein Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/devlake
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
Maintainer antworten meist innerhalb von 2 Tagen
-
[Bug][Project] Invalid metric plugin options are accepted on project save and only fail at the next pipeline runEvtl. vergeben @chenwei791129 hat das vor 2 Tagen übernommen. Offen
Schwierigkeit 3/5 Ein halber Tag Anfängerfreundlichkeit 22/100
Maintainer antworten meist innerhalb von 2 Tagen
-
[Bug][Dashboard] Engineering Throughput PR time panels count PRs without a project_pr_metrics row as 0 hoursEvtl. vergeben @chenwei791129 hat das vor 2 Tagen übernommen. Offen
Schwierigkeit 3/5 Ein halber Tag Anfängerfreundlichkeit 22/100
Maintainer antworten meist innerhalb von 2 Tagen
-
[Feature][dora] Allow filtering which pull requests count toward Lead Time for Changes by branch nameEvtl. vergeben @chenwei791129 hat das vor 1 Tag übernommen. Offen
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 15/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 3/5 Ein halber Tag Anfängerfreundlichkeit 62/100
Maintainer antworten meist innerhalb von 2 Tagen
Ähnliche Issues
-
bug frontend grammar sev-3
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 63/100
-
connector docs good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
soma-intelligence/open-health-sync#134 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug frontend
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Maintainer antworten meist innerhalb von 3 Tagen
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
oss/0 pending team/container-integrations
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
DataDog/datadog-agent#58323 ·
Maintainer antworten meist innerhalb von 1 Tag