Skip to content

Conversation

@stalowyjez
Copy link
Contributor

@stalowyjez stalowyjez commented Dec 5, 2025

Problem

telio-firewall tests which depend on libfirewall.so should be moved to gitlab

Solution

Make them integration tests and then run all of the integration tests on gitlab

☑️ Definition of Done checklist

  • Commit history is clean (requirements)
  • README.md is updated
  • Functionality is covered by unit or integration tests

@stalowyjez stalowyjez force-pushed the LLT-6813-move_icmp_tests_to_libfirewall branch from b89f0ba to 4347ad3 Compare December 5, 2025 16:47
@stalowyjez stalowyjez force-pushed the LLT-6812-move_libfirewall_dependent_tests_to_gitlab branch from 752768d to 9178835 Compare December 5, 2025 16:55
@stalowyjez stalowyjez force-pushed the LLT-6812-move_libfirewall_dependent_tests_to_gitlab branch from 9178835 to c9dbfbd Compare December 5, 2025 16:59
@stalowyjez stalowyjez force-pushed the LLT-6812-move_libfirewall_dependent_tests_to_gitlab branch from c9dbfbd to 230adb4 Compare December 8, 2025 11:14
Base automatically changed from LLT-6813-move_icmp_tests_to_libfirewall to main December 8, 2025 11:56
@stalowyjez stalowyjez force-pushed the LLT-6812-move_libfirewall_dependent_tests_to_gitlab branch from 230adb4 to 5f5d9e9 Compare December 11, 2025 20:36
Copy link
Collaborator

@jjanowsk jjanowsk left a comment

Choose a reason for hiding this comment

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

How about moving firewall tests to the separate test target. You can do it by adding:

name = "firewall_tests"
path = "tests/integration_tests.rs"
test = false

to the Cargo.toml. This way you can run only those tests separately by running cargo test --test firewall_tests

This way if we want to have other integration tests still run here we can. (E.g. dns integration tests were the victim of current approach)

I have not tested this on telio-firewall so maybe there are some caveats but in theory it should work.

@stalowyjez
Copy link
Contributor Author

@jjanowsk Hmm, I considered that, but in the end it seemed that making the split that unit tests run on github while crate/integration test run on gitlab it kinda cleaner than making and exception for libfirewall - but if you think that would be much better, I can limit it to firewall tests only

@jjanowsk
Copy link
Collaborator

Personally I prefer separate target just for firewall tests. You can ask someone else for the 3rd opinion :)

@mathiaspeters
Copy link
Contributor

I also like the idea of a separate target. It will be slightly more complex, but I think it makes sense that since this is an open source repo we should keep as much open as we can

@stalowyjez stalowyjez force-pushed the LLT-6812-move_libfirewall_dependent_tests_to_gitlab branch from 5f5d9e9 to 876cad9 Compare December 15, 2025 11:50
@stalowyjez stalowyjez force-pushed the LLT-6812-move_libfirewall_dependent_tests_to_gitlab branch from 5b3c96c to 876cad9 Compare December 15, 2025 13:32
@stalowyjez
Copy link
Contributor Author

@jjanowsk @mathiaspeters reduced the scope of the tests run on gitlab to firewall ones

@stalowyjez stalowyjez force-pushed the LLT-6812-move_libfirewall_dependent_tests_to_gitlab branch from 876cad9 to 260ccfa Compare December 16, 2025 23:58
@stalowyjez stalowyjez force-pushed the LLT-6812-move_libfirewall_dependent_tests_to_gitlab branch from 260ccfa to 5fc3dc5 Compare January 7, 2026 11:56
@LukasPukenis
Copy link
Collaborator

LukasPukenis commented Jan 7, 2026

+1

The PR looks fine to me but if I understand correctly, the current approach requires libtelio-build to be aware of firewall_integration_tests name in order to run it.

A more generic solution could be to use a feature so we could gatekeep multiple tests(if needed) to run only in CI with a single feature.

Though, given that this is currently only for libfirewall tests there probably is not much difference at the moment.

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.

5 participants