Write e2e test

[ehmatthes]

Tasks

• Create a DO droplet
• Pull ip addr
• Set env vars
• Run deploy
• Run functionality tests
• Destroy droplet
• Destroy ssh entries
• Merge
• Video?

[ehmatthes]

DO CLI

DO has a CLI! This may simplify some other work, but it might be better not to require the CLI?

Resources

• Main CLI docs
• Installation
• Reference
• Repo

Tasks

• Run current e2e test template without errors.
• Install
• Authenticate
• Create droplet in e2e test script
• Destroy droplet in e2e test script

[ehmatthes]

Current e2e test

• Check that DO CLI is installed. (May update this later to support a wider range of VPS hosts for e2e tests, probably by required flag, so user is explicitly about what host they want new resources created for.)
  • Exit if not installed.
  • If installed, make sure authenticated.
• $ pytest tests/e2e_tests --plugin dsd_vps -s --automate-all
  • paramiko ssh error, because there's no vps instance to connect to, and no env vars for the connection. Create droplet.

[ehmatthes]

Working notes

• Configure a new droplet in DO admin panel, then click the "Create with CLI command". Good way to get a correct command?
  • Run this command manually. What's the output? Can I capture anything that will help for destroying the droplet after the test?
• How can I write the e2e tests so it will work for any number of VPS hosts?
• Functionality test is failing because of an http/https issue, even with an http-based URL. (Use verify=False in each request call if http. Consider prompting whether this is okay.)
• Current integration tests (test_caddyfile) fails when DSD_HOST_ env vars are set.
  • Both, or just one? (DSD_HOST_IPADDR causes failure)
  • Fix: when tests are running, set server ip address to None in _add_caddyfile().

[ehmatthes]

Create droplet

This command works, but it emails a login password that must be changed:

$ doctl compute droplet create dsd-e2e-test --image ubuntu-25-04-x64 --size s-1vcpu-1gb --region nyc3

• Droplet name should have a unique string appended to this. We should also get a list of existing droplets, and make sure there is no name collision. A collision should never happen, but we should bail if there is already a droplet with this name.
• Set up an SSH key, and document how to do this.
  • Created key pair, not sure if it's in correct location.
  • Created droplet in web portal.
  • When creating through CLI, do I get the IP address in the output?
  • Works: ssh <username>@<ipaddress> -i <path/to/key>
• Create a droplet with doctl using key.
• Pass the key when creating the droplet.
• Include a timestamp in the droplet name.
• Figure out command to destroy droplet.
• Support key-based ssh droplets in regular usage, then come back to e2e testing. Support key-based ssh for droplets #18