Added changes for IPv6 structure#1606
Conversation
peanball
left a comment
There was a problem hiding this comment.
minor suggestion to reduce the amount of code duplication / files for the PHP script. Looks good otherwise.
I have not tested all those apps yet locally.
assets/php/htdocs/.htaccess
Outdated
| @@ -0,0 +1,2 @@ | |||
| RewriteEngine On | |||
| RewriteRule ^(ipv4-test|ipv6-test|dual-stack-test)$ $1.php [L] No newline at end of file | |||
There was a problem hiding this comment.
you could technically rewrite to:
RewriteRule ^(ipv4|ipv6|dual-stack)-test$ ip-test.php?target=$1 [L]This will then translate /ipv6-test to a call to ip-test.php?target=ipv6, etc.
Then you can have a single file, and the same type of map you have like in the other tests. Instead of the request path you'd base it on the value of the $_GET["target"] parameter in PHP.
There was a problem hiding this comment.
Thanks for the provided solution. I've added the changes it and it worked.
assets/php/htdocs/ip_functions.php
Outdated
| @@ -0,0 +1,12 @@ | |||
| <?php | |||
|
|
|||
| function fetchIpAddress($url) { | |||
There was a problem hiding this comment.
you could now fold in this function into ip-test.php and remove the include there.
There was a problem hiding this comment.
Much better. Done. Thank you.
peanball
left a comment
There was a problem hiding this comment.
LGTM.
I'm not sure what the best practice is for Java based payloads, and if it should be as pre-bundled .jar or built on the fly. But that' for the cf-deployment experts to decide.
There was a problem hiding this comment.
These changes must be done in the upstream project: https://github.com/cloudfoundry/cf-test-helpers
There was a problem hiding this comment.
😅 sorry for overlooking this. Thanks @jochenehret!
There was a problem hiding this comment.
These changes must be done in the upstream project: https://github.com/cloudfoundry/cf-test-helpers
Key Updates:
Direct Output from Public Sites:
The main difference in the approach is that the apps now directly return the output from public Ips without additional processing for IP determination or success validation.
Go test Changes:
The Go app tests each buildpack listed in the script using the three main scenarios: IPv4, IPv6, and Dual-stack. I have created new function CurlAppWithStatusCode since our previously used function did not obtain the HTTP status code.
The updated function in the
app_curler.gonow modifies the curl command to retrieve both the response body and the HTTP status code. We utilize this output in the ginko tests by separating the IP address from the status code. Subsequently, we verify that the IP aligns with the scenario being validated and that the status code indicates success (HTTP 200).