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: make subdomain testing possible #9

Merged
merged 36 commits into from
Mar 23, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
36 commits
Select commit Hold shift + click to select a range
3cfb66d
feat: make subdomain testing possible
laurentsenta Mar 7, 2023
0cc1e52
feat: subdomain with cleaner API
laurentsenta Mar 8, 2023
8a17a7f
feat: improve sugar with url rewrites, clearer
laurentsenta Mar 13, 2023
3a17974
feat: use fixtures
laurentsenta Mar 14, 2023
ea6db6c
feat: reporting + test localhost like 114 does
laurentsenta Mar 14, 2023
9c2fa4c
fix: improve reporting & fix test
laurentsenta Mar 14, 2023
37be4fb
wip: show alternatives
laurentsenta Mar 14, 2023
399b1d4
feat: add the localhost domain
laurentsenta Mar 20, 2023
e264baf
refactor: follow-up call w/Lidel
laurentsenta Mar 20, 2023
ba714b7
feat: fix 127.0.0.1 test in 114
laurentsenta Mar 20, 2023
8e60e46
feat: add missing sugar and implement 50% of 114
laurentsenta Mar 20, 2023
649f9a8
feat: nicer body with hint
laurentsenta Mar 20, 2023
d1ba558
feat: clarify tunnel and update todos
laurentsenta Mar 20, 2023
a9964a3
chore: fixes
laurentsenta Mar 21, 2023
f94c7e9
feat: subdomain-url in entrypoint
laurentsenta Mar 21, 2023
9981d52
feat: add subdomain url to gh
laurentsenta Mar 21, 2023
e8b7750
ci: enable subdomain tests
laurentsenta Mar 21, 2023
33db81f
tweak
laurentsenta Mar 21, 2023
adcd947
feat: add query and missing tests
laurentsenta Mar 21, 2023
e215caf
fix: clean fixture in 114
laurentsenta Mar 21, 2023
84f0dab
chore: last fixes
laurentsenta Mar 21, 2023
79eb4f1
fix: drop api tests (kubo legacy)
laurentsenta Mar 22, 2023
a928677
chore: remove comments after review
laurentsenta Mar 22, 2023
d1b336e
chore: remove comments
laurentsenta Mar 22, 2023
b36c487
doc: add subdomain-url doc
laurentsenta Mar 23, 2023
7ab250c
fix: drop specs & simplif makefile
laurentsenta Mar 23, 2023
9679a8a
refactor: reorg makefile
laurentsenta Mar 23, 2023
5f7479a
chore: rename ipfs to kubo
laurentsenta Mar 23, 2023
2dfced1
chore: use same defaults in action and main
laurentsenta Mar 23, 2023
50d7cb0
fix: remove dead code
laurentsenta Mar 23, 2023
68d3c50
chore: remove dead code
laurentsenta Mar 23, 2023
9bb23f4
chore: Url -> URL
laurentsenta Mar 23, 2023
fe51641
fix: Makefile disable gateway spec
laurentsenta Mar 23, 2023
93f5156
chore: rename maradona
laurentsenta Mar 23, 2023
05087c3
fix: ci script name
laurentsenta Mar 23, 2023
48c8935
fix: move readme sections
laurentsenta Mar 23, 2023
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion .github/actions/test/action.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,10 @@ inputs:
gateway-url:
description: "The URL of the IPFS Gateway implementation to be tested."
required: true
subdomain-url:
description: "The Subdomain URL of the IPFS Gateway implementation to be tested."
default: "http://example.com"
required: false
Comment on lines +7 to +10
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we being clear enough with the name/description here? I'm afraid this creates an impression that I, as an implementer, should set up something accessible at http://example.com. I think I'd assume I have to set up another gateway instance that supports the subdomain gateway spec and expose it at subdomain-url.

Also, do we think we might have non-subdomain-related tests benefitting from the proxying in the future?

Wouldn't something like local-gateway-proxy-url or internal-gateway-proxy-url reflect the intention better?

I don't want to block this, but I wanted to raise my concerns with you.

Copy link
Contributor Author

@laurentsenta laurentsenta Mar 23, 2023

Choose a reason for hiding this comment

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

I'll add a comment in the README, there's no real proxying anymore, we use that value to overwrite the request sent to the gateway, it's really subdomain-related.

Copy link
Contributor

@galargh galargh Mar 24, 2023

Choose a reason for hiding this comment

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

I see. Thanks for adding the comment. It makes things clearer. Few more thoughts that it sparked with me.

Wouldn't it make sense to always use what we now call subdomain-url. As in, all the test should talk to gateway-url in a way that thinks it's called subdomain-url? Theoretically, wouldn't that be more correct? So really, every test case should be executed 3 times (with host header, proxy, proxy with tunneling) as long as subdomain-url and gateway-url are different.

Looking more closely at how we execute the test cases with host header, I think we're not using the protocol part of gateway-url. Is that correct?

If so, isn't what we really need from the user these two pieces of info:

  • What are you calling/want to call your gateway? Please give us the full URL with a domain name. That would be https://dweb.link for example or http://example.com. You could give us http://127.0.0.1:8080 here as well BUT there's no way for you to support sudomains on that URL so you'll have to disable subdomain-gateway spec.
  • Where is your gateway hosted? Please give us the host we should contact when we're making requests to the URL you provided in the previous step. If you don't, we're just going to use the host from the URL. It's fine if you give us a host with IP or a host with domain. This would be 127.0.0.1 for example or 127.0.0.1:8080 or foo.bar.example.com.

That would come together to something like this - main...gateway-host (note that I intentionally skipped modifying test/config code; I just wanted to get the idea across).

There's absolutely no rush with replying to this. And it's completely possible that I'm missing the point a bit - still trying to wrap my head fully around this. I just want to understand what might be most straight-forward way for those running the tests to provide us all the information we need.

json:
description: "The path where the JSON test report should be generated."
required: true
Expand Down Expand Up @@ -33,14 +37,15 @@ runs:
uses: pl-strflt/docker-container-action@v1
env:
URL: ${{ inputs.gateway-url }}
SUBDOMAIN: ${{ inputs.subdomain-url }}
JSON: ${{ inputs.json }}
SPECS: ${{ inputs.specs }}
with:
repository: ${{ steps.github.outputs.action_repository }}
ref: ${{ steps.github.outputs.action_ref }}
dockerfile: Dockerfile
opts: --network=host
args: test --url="$URL" --json="$JSON" --specs="$SPECS" -- ${{ inputs.args }}
args: test --url="$URL" --json="$JSON" --specs="$SPECS" --subdomain-url="$SUBDOMAIN" -- ${{ inputs.args }}
- name: Create the XML
if: (inputs.xml || inputs.html || inputs.markdown) && (failure() || success())
uses: pl-strflt/gotest-json-to-junit-xml@v1
Expand Down
13 changes: 9 additions & 4 deletions .github/workflows/test.yml
Original file line number Diff line number Diff line change
Expand Up @@ -11,8 +11,6 @@ jobs:
run:
shell: bash
steps:
- uses: ipfs/download-ipfs-distribution-action@v1
- uses: ipfs/start-ipfs-daemon-action@v1
- name: Setup Go
uses: actions/setup-go@v3
with:
Expand All @@ -24,17 +22,24 @@ jobs:
uses: ./gateway-conformance/.github/actions/extract-fixtures
with:
output: fixtures
- uses: ipfs/download-ipfs-distribution-action@v1
- name: Configure Kubo Gateway
run: |
ipfs init;
./gateway-conformance/kubo-config.example.sh;
- uses: ipfs/start-ipfs-daemon-action@v1
- name: Provision Kubo Gateway
run: find ./fixtures -name '*.car' -exec ipfs dag import {} \;
run: |
find ./fixtures -name '*.car' -exec ipfs dag import {} \;
- name: Run the tests
uses: ./gateway-conformance/.github/actions/test
with:
gateway-url: http://127.0.0.1:8080
subdomain-url: http://example.com
json: output.json
xml: output.xml
html: output.html
markdown: output.md
specs: -subdomain-gateway
args: -skip TestGatewayCar
- name: Set summary
if: (failure() || success())
Expand Down
21 changes: 12 additions & 9 deletions Makefile
Original file line number Diff line number Diff line change
@@ -1,26 +1,29 @@
all: test-kubo

test-cargateway: provision-cargateway fixtures.car gateway-conformance
./gateway-conformance test --json output.json --gateway-url http://127.0.0.1:8040 --specs -subdomain-gateway

test-kubo-subdomains: provision-kubo gateway-conformance
./kubo-config.example.sh
./gateway-conformance test --json output.json --gateway-url http://127.0.0.1:8080 --subdomain-url http://example.com:8080

test-kubo: provision-kubo fixtures.car gateway-conformance
./gateway-conformance test --json output.json --gateway-url http://127.0.0.1:8080 --specs -subdomain-gateway

provision-cargateway: ./fixtures.car
# cd go-libipfs/examples/car && go install
car -c ./fixtures.car &

test-cargateway: provision-cargateway
GATEWAY_URL=http://127.0.0.1:8040 make _test

provision-kubo:
find ./fixtures -name '*.car' -exec ipfs dag import {} \;

test-kubo: provision-kubo
GATEWAY_URL=http://127.0.0.1:8080 make _test

# tools
fixtures.car: gateway-conformance
./gateway-conformance extract-fixtures --merged=true --dir=.

gateway-conformance:
go build -o ./gateway-conformance ./cmd/gateway-conformance

_test: fixtures.car gateway-conformance
./gateway-conformance test --json output.json --gateway-url ${GATEWAY_URL}

test-docker: fixtures.car gateway-conformance
docker build -t gateway-conformance .
docker run --rm -v "${PWD}:/workspace" -w "/workspace" --network=host gateway-conformance test
Expand Down
18 changes: 17 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,7 @@ The `test` command is the main command of the tool. It is used to test a given I
| Input | Availability | Description | Default |
|---|---|---|---|
| gateway-url | Both | The URL of the IPFS Gateway implementation to be tested. | http://localhost:8080 |
| subdomain-url | Both | The Subdomain URL of the IPFS Gateway implementation to be tested. | http://example.com |
| json | Both | The path where the JSON test report should be generated. | `./report.json` |
| xml | GitHub Action | The path where the JUnit XML test report should be generated. | `./report.xml` |
| html | GitHub Action | The path where the one-page HTML test report should be generated. | `./report.html` |
Expand All @@ -45,6 +46,19 @@ If you provide a list containing both prefixed and unprefixed specs, the prefixe

This input should be used sparingly and with caution, as it involves interacting with the underlying internal processes, which may be subject to changes. It is recommended to use the `args` input only when you have a deep understanding of the tool's inner workings and need to fine-tune the testing process. Users should be mindful of the potential risks associated with using this input.

#### Subdomain Testing and `subdomain-url`

The `subdomain-url` parameter is utilized when testing subdomain support in your IPFS gateway. It can be set to any domain that your gateway permits.
During testing, the suite keeps connecting to the `gateway-url` while employing HTTP techniques to simulate requests as if they were sent to the subdomain.
This approach enables testing of local gateways during development or continuous integration (CI) scenarios.

A few examples:

| Use Case | gateway-url | subdomain-url |
|----------|-------------|---------------|
| CI & Dev | http://127.0.0.1:8080 | http://example.com |
| Production | https://dweb.link | https://dweb.link |

#### Usage

##### GitHub Action
Expand Down Expand Up @@ -148,4 +162,6 @@ Please let us know if you would like to see this feature implemented directly in
## In Development

- How to deal with subdomains & configuration (t0114 for example)?
- Some test relies on querying URLs like `http://$CIDv1.ipfs.example.com/`. While `http://$CIDv1.ipfs.localhost/` works by default, do we need / want to test with `.example.com`?
- Some test relies on querying URLs like `http://$CIDv1.ipfs.example.com/`. While `http://$CIDv1.ipfs.localhost/` works by default, do we need / want to test with `.example.com`?
- Debug logging
- Set the environment variable `GOLOG_LOG_LEVEL="conformance=debug"` to toggle debug logging.
12 changes: 12 additions & 0 deletions cmd/gateway-conformance/main.go
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,7 @@ func copyFiles(inputPaths []string, outputDirectoryPath string) error {

func main() {
var gatewayURL string
var subdomainGatewayURL string
var jsonOutput string
var specs string
var directory string
Expand All @@ -78,6 +79,12 @@ func main() {
Value: "http://localhost:8080",
Destination: &gatewayURL,
},
&cli.StringFlag{
Name: "subdomain-url",
Usage: "The Subdomain URL of the IPFS Gateway implementation to be tested.",
Value: "http://example.com",
Destination: &subdomainGatewayURL,
},
&cli.StringFlag{
Name: "json-output",
Aliases: []string{"json", "j"},
Expand Down Expand Up @@ -107,6 +114,11 @@ func main() {
cmd := exec.Command("go", args...)
cmd.Dir = tooling.Home()
cmd.Env = append(os.Environ(), fmt.Sprintf("GATEWAY_URL=%s", gatewayURL))

if subdomainGatewayURL != "" {
cmd.Env = append(cmd.Env, fmt.Sprintf("SUBDOMAIN_GATEWAY_URL=%s", subdomainGatewayURL))
}

cmd.Stdout = out{output}
cmd.Stderr = os.Stderr
testErr := cmd.Run()
Expand Down
Binary file modified fixtures/t0114-gateway_subdomains.car
Binary file not shown.
12 changes: 12 additions & 0 deletions kubo-config.example.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
#! /usr/bin/env bash
ipfs config --json Gateway.PublicGateways '{
"example.com": {
"UseSubdomains": true,
"Paths": ["/ipfs", "/ipns", "/api"]
},
"localhost": {
"UseSubdomains": true,
"InlineDNSLink": true,
"Paths": ["/ipfs", "/ipns", "/api"]
}
}'
4 changes: 2 additions & 2 deletions tests/t0113_gateway_symlink_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ func TestGatewaySymlink(t *testing.T) {
{
Name: "Test the directory listing",
Request: test.CRequest{
Url: fmt.Sprintf("ipfs/%s?format=raw", fixture.MustGetCid()),
Path: fmt.Sprintf("ipfs/%s?format=raw", fixture.MustGetCid()),
laurentsenta marked this conversation as resolved.
Show resolved Hide resolved
},
Response: test.CResponse{
StatusCode: 200,
Expand All @@ -24,7 +24,7 @@ func TestGatewaySymlink(t *testing.T) {
{
Name: "Test the symlink",
Request: test.CRequest{
Url: fmt.Sprintf("ipfs/%s/bar", fixture.MustGetCid()),
Path: fmt.Sprintf("ipfs/%s/bar", fixture.MustGetCid()),
},
Response: test.CResponse{
StatusCode: 200,
Expand Down
Loading