Skip to content

Conversation

LucasSantos27
Copy link
Collaborator

@LucasSantos27 LucasSantos27 commented Sep 15, 2025

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:

  • Added a new docker-compose setup and management commands to run tests using a local PostgreSQL instance instead of relying on remote services.
  • Implemented factory-based mocks and seeding commands to simplify the creation of test data across Checkouts, Builds, Tests, Issues, and Incidents.
  • Updated the CICD to adopt the local database approach.
  • Added a guideline on how to run integration tests locally, including setup and usage instructions.

Note: Please check the new documentation to better understand the changes and make the review process easier.

Related issue

Comment on lines 58 to 68
[
"maestro",
"redhat",
"microsoft",
"broonie",
"linaro",
"0dayci",
"syzbot",
"android-mainline",
"next-pending-fixes",
]
Copy link
Collaborator

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?

Copy link
Collaborator Author

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"]
Copy link
Collaborator

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(
Copy link
Collaborator

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

Copy link
Collaborator Author

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",
Copy link
Collaborator

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",
Copy link
Collaborator

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)
Copy link
Collaborator

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

Copy link
Collaborator Author

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(
Copy link
Collaborator

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?

Copy link
Collaborator

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

Copy link
Collaborator Author

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

Copy link
Collaborator

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

@LucasSantos27 LucasSantos27 force-pushed the integration-tests-using-local-db branch from f3fa8d0 to 6ab213b Compare September 17, 2025 19:09
- Create a backend and db services in new docker-compose to
run integration tests with local db.

part of #1397
it will be useful for integration tests with local db

part of #1397
this command change the django setting modules to
`test_settings` which uses a local postgresql database

part of #1397
@LucasSantos27 LucasSantos27 force-pushed the integration-tests-using-local-db branch from 6ab213b to 7470b23 Compare September 18, 2025 11:32
- 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
@LucasSantos27 LucasSantos27 force-pushed the integration-tests-using-local-db branch from 7470b23 to 7787bcd Compare September 18, 2025 14:02
@LucasSantos27 LucasSantos27 changed the title WIP: Integration tests using local db feat: use local db for integration tests Sep 18, 2025
@LucasSantos27 LucasSantos27 marked this pull request as ready for review September 18, 2025 14:04
@LucasSantos27 LucasSantos27 force-pushed the integration-tests-using-local-db branch from 7787bcd to a1684a2 Compare September 18, 2025 14:17
- Explain the purpose of integration tests
- Provide setup instructions for local database

part of #1397
@LucasSantos27 LucasSantos27 force-pushed the integration-tests-using-local-db branch from a1684a2 to 7978d6a Compare September 19, 2025 13:41
Comment on lines +75 to +79
Incidents.objects.all().delete()
Issues.objects.all().delete()
Tests.objects.all().delete()
Builds.objects.all().delete()
Checkouts.objects.all().delete()
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use local DB for CI tests
2 participants