Consistent CI Tests about lua-resty-acme

[UXabre]

I also noticed the ci test issues and had a hard time getting something to work, in the end i singled out my test and at least I can sleep...
I'm new on the acme service side of life, but from your proposals I think pebble looks promising.
Perhaps a "smoke test" hybrid can be made in which ngrok is simply used to verify compatibility and all other tests could use pebble?
Just my 2 cents :-)

[fffonion]

I agree moving to use pebble is the right way to go. I intially choose frp to avoid a lock-in with ngrok,
which doesn't have a clear status of how long its free services will last.

But on the other hand either ngrok or frp should not make the test itself flakky, so the failing tests may indicates
some bugs in code, but I haven't been able to figure out yet.

[UXabre]

Is there any guide on setting up FRP together with this? Otherwise I'm willing to try and help figure out why some tests are flaky?

[fffonion]

@UXabre Yes I can share the example used in current CI. You will need a server that's accessible on public internet.
On server side, the config is:

[common]
bind_port = 7000
vhost_http_port = 80
authentication_method = token
token = <token>
subdomain_host = test.mydomain.com

Then you will have *.test.mydomain.com resolve to your server's IP. Most DNS provider allows you
to do wildcard resolving I think.

When running test suite, pass envrionment variable to it:

FRP_SERVER_HOST=<ip_of_your_server> FRP_SERVER_PORT=7000 FRP_TOKEN=<token> DOMAIN=<subdomain> t/prepare_travis.sh

prepare_travis.sh will prepare all client side environment and frpc configs and choose a random subdomain.

But on the other side, I doubt that the flaky-ness is caused by frp (right now you can't run frp-based test
suite in a PR since github doesn't expose secrets to it, but that's a different story). That means, if there's
a transient bug in code, we should be able to reproduce with ngrok as well.

[fffonion]

Closing this as tests have been moved to pebble.