-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Run faucet integration tests in CI #7125
Conversation
5c77531
to
ac1c1eb
Compare
8ff8283
to
50d3b97
Compare
50d3b97
to
4429c61
Compare
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.
Can this all be run locally?
Or to the point, how much of this can we extract from the workflow and into a useful local tool?
4429c61
to
a8facc0
Compare
7d71409
to
1b1955d
Compare
1b1955d
to
6c36d86
Compare
I addressed Perry's feedback, as much as possible into a script. As for the performance, when the Rust cache is hot the whole workflow takes about 9 minutes, so I think having it on the GH runners is fine. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
✅ Forge suite
|
Thanks you. |
Description
This PR adds CI for running the faucet integration tests. Because we want to test the faucet against both devnet and testnet I use an action. Currently I use the action once in two separate jobs to make it faster, but this is also wasteful because I build the faucet for tests twice with no shared cache (I think). I'll ask the CI experts the best option.
Given the faucet changes rarely these tests might be sort of wasteful, but I figure that's already the case for many tests and the real fix is a target determinator. I'm using ubuntu-latest so it's not our runners. Of course, this means I have to build everything from scratch so this takes like 45 minutes total. Though later runs should be faster because we use
rust-cache
in ourrust-setup
action. The alternative would be to either use high-perf-docker, or even more invasively, add these tests torust-smoke-test
, but then I'd have to spin up a local testnet and Redis in that CI, which is not ideal. Hence why I've chosen this route.Note: I need #7126 to land into devnet / testnet first. Update: Done.
Test Plan
CI.