-
Notifications
You must be signed in to change notification settings - Fork 2
Enable email for Connect integration tests #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
base: main
Are you sure you want to change the base?
Conversation
Getting warmer. Connect no longer complains about email not being configured. However, when Connect fails to deploy content and attempts to send the owner an email we get this error.
I believe this is because we're doing all of our testing via the bootstrap API and there are no actual users in the system. |
8aade44
to
99efc18
Compare
Revisiting this. I've updated the
|
1d12786
to
3dbe596
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.
Thanks for this — a few comments (some of which might open up other bigger cans of worms, so I've got this as "request changes"). The biggest question I have is that I'm a little surprised we don't have an easier / builtin way to bootstrap the stuff that we are doing in set_bootstrap_admin_email.py
here. Is that true?
integration/Makefile
Outdated
@# Change directory to the parent and create tarball with relative paths | ||
@cd .. && tar -czf ./integration/bundles/$(EXTENSION_NAME).tar.gz -C ./extensions $(EXTENSION_NAME) |
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 super consequential here, but would pushd
and popd
be a better option here?
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.
TIL about pushd
and popd
👍
$(UV) run pytest $(PYTEST_ARGS) \ | ||
--junit-xml=./reports/$(CONNECT_VERSION).xml | \ | ||
tee ./logs/$(CONNECT_VERSION).log | ||
$(SHELL) -c "set -o pipefail; \ |
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.
I'm a little surprised by the changes(?) to the shell here? What's the reason for that? It might be listed earlier in this PR and I just forgot 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.
Also, reading down below this ... is all she same as before, yeah? Other than swapping out -s http://connect:3939
for -s $(CONNECT_SERVER)
yeah? Or is my mental diffing not catching more things that are diferent?
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.
Was the only way I could get the command we inserted to create the admin email to work $(MAKE) set-bootstrap-admin-email
as it is dependent on the env vars we are setting before it.
interval: 10s | ||
interval: 5s | ||
timeout: 5s | ||
retries: 3 | ||
start_period: 5s |
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.
Do we need these changes still?
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.
Shaves ~5s from the healthcheck as checking immediately at startup with start_period: 0s
apparently fails. Could likely achieve the same with just setting interval: 5s
and leaving the others at default.
From the Docker docs:
--interval=DURATION (default: 30s)
--timeout=DURATION (default: 30s)
--start-period=DURATION (default: 0s)
--start-interval=DURATION (default: 5s)
--retries=N (default: 3)
headers = {"Authorization": f"Key {api_key}"} | ||
|
||
# Get current user (this will be the bootstrap admin since we only use the bootstrap user in these tests) | ||
user_resp = requests.get(f"{base_url}/__api__/v1/user", headers=headers) |
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.
Could we use the posit-sdk for this?
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.
We could. I'll make that change.
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.
Done.
This allows deployment error emails to be sent to a valid address, otherwise | ||
the send will fail and log an error in the Connect logs making it more | ||
difficult to debug deployment issues. |
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 this actually sending email out? Or is it that we need a valid address or else Connect will bonk and say "I can't send to this nonsense address"?
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.
Hmmm, I'll update the wording here to be more clear.
To clarify we have tackled two issues in this PR:
- Connect throws an error if Connect is not configured for email
- Connect throws an error if Connect is configured for email, but the publisher has no email configured when Connect attempts to send the content error email
With the changes in this PR Connect is physically sending the email but we have mailhog set to log only so it doesn't leave the box.
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.
Aaaah got it. Great. Thanks, yeah a slightly clearer note would be nice there
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.
Done.
I agree, we're jumping through a lot of hoops here. The documented use of boostrap is to programmatically create the first admin user that can then programmatically create "real" users via the API. However, all of this presents some challenges for us:
|
After all of the recent changes this is still working as intended and suppressing all of the email failure logging as seen in the most recent workflow run.
|
…mail" This reverts commit 86f9dc5.
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.
This is looking good to me, and it looks like you addressed all of @jonkeane's feedback. I believe they will still need to approve since they initially requested changes though.
Our previous attempt at enabling email was incorrect.
Example of mailhog CLI logging when an account email is sent from Connect.