-
Notifications
You must be signed in to change notification settings - Fork 15
feat: use local db for integration tests #1488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
92d9af2
to
b0c5f9f
Compare
[ | ||
"maestro", | ||
"redhat", | ||
"microsoft", | ||
"broonie", | ||
"linaro", | ||
"0dayci", | ||
"syzbot", | ||
"android-mainline", | ||
"next-pending-fixes", | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels a bit weird that you are mixing origin names with tree names. Is this variable supposed to store realistic origins or just any value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any value for "fake checkouts", so I'll change to fake-origin
) | ||
builds.append(failed_build) | ||
|
||
[uncategorized_issues] = [i for i in issues if i.id == "Uncategorized"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uncategorized tests are (ironically) a category that we created just for tests that failed but had no incidents related to them, there are no issues called "Uncategorized". In other words, if a test fails but has no incidents related to it, then that test is uncategorized.
"5b4ec6e1eb7603b6d86a172d77efdf75eb741e7e", # ALLWINNER_HARDWARE | ||
"0704a15b930cf97073ce091a0cd7ad32f2304329", # ALLWINNER_HARDWARE | ||
] | ||
else random.choice( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add the possibility for null status as well please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've already changed this part, so I'm not sure which part to change, sorry. Would it be the status
?
"maestro:e602fca280d85d8e603f7c0aff68363bb0cd7993", | ||
"broonie:bb2eb9603973cb353faa8e780b304d3537220228", | ||
"linaro:30MeoIqiN9rKm6s2lQLaThEnGHF", | ||
"Uncategorized", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto no Uncategorized issues
"linaro", | ||
"0dayci", | ||
"syzbot", | ||
"android-mainline", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto origins + treeName
else BuildFactory() | ||
) | ||
) | ||
origin = factory.LazyAttribute(lambda obj: obj.build.origin) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest adding the possibility of a test having an origin that's different from the build's origin, this is something that is already happening
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be changed in the future, but for now we can follow the same origin of build.
} | ||
) | ||
|
||
status = factory.LazyAttribute( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
feels like a lot of hardcoded strings, maybe move them to variables?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you need to use docker-compose
instead of docker compose
? I believe the second one is the newer format
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove this part, it's just to test if you'd like
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto docker-compose / docker compose
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same
f3fa8d0
to
6ab213b
Compare
6ab213b
to
7470b23
Compare
- Use factories with factory boy to create mocks for all tables in local DB tests: - Checkout - Build - Test - Issues - Incidents `test_data_mapping` is used to map the data from Trees, Builds, Tests, Issues and Incidents to the factories. part of #1397
- Issues and Checkout can be changed - Build, Test and Incident are created from Checkout and Issues part of #1397
we will use a local postgresql database for integration tests instead of a remote one. We must set up the database before running the tests. With this change, we avoid problems with network issues and changes in the remote database. part of #1397
7470b23
to
7787bcd
Compare
7787bcd
to
a1684a2
Compare
- Explain the purpose of integration tests - Provide setup instructions for local database part of #1397
a1684a2
to
7978d6a
Compare
Incidents.objects.all().delete() | ||
Issues.objects.all().delete() | ||
Tests.objects.all().delete() | ||
Builds.objects.all().delete() | ||
Checkouts.objects.all().delete() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like there should be some guardrails here... We don't want to accidentally delete everything in production db
This PR introduces improvements to the integration testing workflow by moving from a remote database dependency to a fully local setup. The main updates include:
docker-compose
setup and management commands to run tests using a local PostgreSQL instance instead of relying on remote services.Related issue