-
Notifications
You must be signed in to change notification settings - Fork 90
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
feat: use real hostnames & auto edit host file #2586
Conversation
✅ Deploy Preview for brilliant-pasca-3e80ec canceled.
|
addHost() { | ||
local hostname="$1" | ||
|
||
# check first to avoid sudo prompt if host is already set | ||
if hostile list | grep -q "127.0.0.1 $hostname"; then | ||
echo "$hostname already set" | ||
else | ||
sudo hostile set 127.0.0.1 "$hostname" | ||
fi | ||
} |
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.
If hosts aren't present you will be prompted for your password so it can write to /etc/hosts
. If hosts are present, it will not prompt you. hostile set
does nothing if the host is already present but it still prompts, hence the check.
In CI, there is a step before running tests that adds them so we dont need to navigate sudo here in ci. #2569 (comment)
Note that we didnt need sudo-prompt here. Unless I misunderstood the original suggestion, its just not necessary for this purpose. Correct me if I'm missing something though.
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.
Note that we didnt need sudo-prompt here.
So why do we include it?
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's not included. I'm referring to this npm package https://www.npmjs.com/package/sudo-prompt, not the use of sudo
here.
With this change you can remove the |
there are still some |
Good catch, should have pointed that out. Yes, that's exactly right. That's so our backend services can reach the test's server on the hostmachine. On that note, I removed the EDIT: Actually I did not remove them. 😁 Guess I just intended to at one point. |
this.server = this.app.listen(port, () => { | ||
console.log(`Integration server listening on port ${port}`) | ||
}) | ||
this.server = this.app.listen(port) |
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.
Is removing thing console.log part of us not wanting to console.log things anymore but wanting to do proper logging in the future?
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.
Somewhat I guess - I added it initially when I was debugging service to this test server requests.
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.
On that note I don think using pino logger here or anywhere else that is dev only would have any benefit. They aren't run with our other services and aren't going to be consumed by some sort of log aggregator or cloud logging viewer. Just development.
I'm mainly concerned about readability which pino-pretty would largely resolve. Jest has it's own "prettyfied" logs though so if using pino-pretty
we should not pipe it and instead add it in code to preserve jest's output formatting.
I think there is 1 remaining "unknown webhook event" (or similar) log in the tests here FWIW.
addHost() { | ||
local hostname="$1" | ||
|
||
# check first to avoid sudo prompt if host is already set | ||
if hostile list | grep -q "127.0.0.1 $hostname"; then | ||
echo "$hostname already set" | ||
else | ||
sudo hostile set 127.0.0.1 "$hostname" | ||
fi | ||
} |
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.
Note that we didnt need sudo-prompt here.
So why do we include it?
@BlairCurrey I think we only need to keep
in the backend services (I don't think auth needs to call the host machine) |
if hostile list | grep -q "127.0.0.1 $hostname"; then | ||
echo "$hostname already set" | ||
else | ||
sudo hostile set 127.0.0.1 "$hostname" |
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.
if hostile list | grep -q "127.0.0.1 $hostname"; then | |
echo "$hostname already set" | |
else | |
sudo hostile set 127.0.0.1 "$hostname" | |
if pnpm hostile list | grep -q "127.0.0.1 $hostname"; then | |
echo "$hostname already set" | |
else | |
sudo pnpm hostile set 127.0.0.1 "$hostname" |
right? or did I not install it correctly?
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.
pnpm i
is all you need to do and I can reproduce this now. Looks like we're calling it differently.
I was running with pnpm --filter integration run-tests
(added after moving to run-tests.sh
to ./test/integration/scripts
). But if it can be called directly that would be good too. If I make your changes I can only get it to work if running ./scripts/run-test.sh
from the context of ./test/integration
.
Adding a pnpm command and using pnpm --filter has it working in all contexts for me now (root using pnpm --filter
, calling script directly from root, calling script directly from package). ec8d5ab
For adding hosts in CI, we can't just remove the Just removing the setup host step fails because root doesn't find pnpm:
https://github.com/interledger/rafiki/actions/runs/8392609267/job/22985668877?pr=2586 Doesn't happen locally, and I can only conclude this is because of differences in installing (npm/corepack vs. pnpm/action-setup). I see these options:
At this point I think sticking with 1 makes sense. No matter what we do this isn't going to "just work" without either passing in the path or doing some extra setup. Other than that, 3 seemed like the obvious fix but I made some attempts at adding pnpm to the root path but did not get it working (82678cd, 645ef16, 9e24ebb). I believe 645ef16 in particular should have correctly set it but the pnpm command still was not found. Thus the option to pass it in, which should work because here it is working with the ci path hardcoded: 5302a0f. |
Keeping the setup host step in CI is the most straightforward solution. |
Changes proposed in this pull request
http://cloud-nine-wallet-test-backend:3000
)test/integration/scripts/run-tests.sh
Context
fixes #2555
Checklist
fixes #number