Skip to content
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

Merged
merged 27 commits into from
Mar 27, 2024

Conversation

BlairCurrey
Copy link
Contributor

@BlairCurrey BlairCurrey commented Mar 19, 2024

Changes proposed in this pull request

  • updates all urls to use service-based hostname (e.g. http://cloud-nine-wallet-test-backend:3000)
  • adds hosts (if not already set) automatically in test/integration/scripts/run-tests.sh

Context

fixes #2555

Checklist

  • Related issues linked using fixes #number
  • Tests added/updated
  • Documentation added
  • Make sure that all checks pass
  • Bruno collection updated

Copy link

netlify bot commented Mar 19, 2024

Deploy Preview for brilliant-pasca-3e80ec canceled.

Name Link
🔨 Latest commit 3ab2a58
🔍 Latest deploy log https://app.netlify.com/sites/brilliant-pasca-3e80ec/deploys/65fdce77977dd30008fe8624

Comment on lines 27 to 36
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
}
Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

@BlairCurrey BlairCurrey marked this pull request as ready for review March 19, 2024 20:57
@BlairCurrey
Copy link
Contributor Author

BlairCurrey commented Mar 19, 2024

With this change you can remove the 127.0.0.1 host.docker.internal entry from /etc/hosts (once merged). Doesn't hurt anything if you don't though.

@sabineschaller
Copy link
Member

there are still some host.docker.internal in the docker-compose files. I'm assuming that is intentional because those are not referring to the webhook and the exchange rate urls?

@BlairCurrey
Copy link
Contributor Author

BlairCurrey commented Mar 20, 2024

there are still some host.docker.internal in the docker-compose files. I'm assuming that is intentional because those are not referring to the webhook and the exchange rate urls?

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 extra_hosts: host.docker.interal but maybe I should return it. It works without for me but @mkurapov suggested it may be necessary for linux, if I recalled correctly. I will read up on that a bit and probably just return it to be safe.

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

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Comment on lines 27 to 36
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
}
Copy link
Member

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?

@mkurapov
Copy link
Contributor

mkurapov commented Mar 22, 2024

@BlairCurrey I think we only need to keep

    extra_hosts:
      - 'host.docker.internal:host-gateway'  

in the backend services (I don't think auth needs to call the host machine)

Comment on lines 31 to 34
if hostile list | grep -q "127.0.0.1 $hostname"; then
echo "$hostname already set"
else
sudo hostile set 127.0.0.1 "$hostname"
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
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?

Copy link
Contributor Author

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

@github-actions github-actions bot added the type: ci Changes to the CI label Mar 22, 2024
@BlairCurrey
Copy link
Contributor Author

BlairCurrey commented Mar 22, 2024

For adding hosts in CI, we can't just remove the Setup hosts step.

Just removing the setup host step fails because root doesn't find pnpm:

sudo: pnpm: command not found

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:

  1. keeping the setup host step
  2. removing the setup host step and passing in a pnpm binary path to the script for us in CI? like pnpm --filer integration run-tests -p /home/runner/setup-pnpm/node_modules/.bin/pnpm or maybe just -p $(which pnpm)
  3. removing the setup host step and adding a step to add pnpm to the binary path somehow

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.

@github-actions github-actions bot removed the type: ci Changes to the CI label Mar 22, 2024
@github-actions github-actions bot added the type: ci Changes to the CI label Mar 22, 2024
@mkurapov
Copy link
Contributor

Keeping the setup host step in CI is the most straightforward solution.

@BlairCurrey BlairCurrey merged commit 78b5574 into main Mar 27, 2024
23 checks passed
@BlairCurrey BlairCurrey deleted the bc/2555/hostnames-integration-test branch March 27, 2024 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: ci Changes to the CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix Hostnames in Integration Tests
3 participants