manifoldco / grafton Goto Github PK

grafton test --product=test --plan=free --client-id=21jtaatqj8y5t0kctb2ejr6jev5w8 \
--client-secret=3yTKSiJ6f5V5Bq-kWF0hmdrEUep3m3HKPTcPX7CdBZw \
--connector-port=3001 --new-plan=startup --region=aws::us-east-2 http://localhost:3000 \ 
--exclude sso --resource-measures='{"test": 0}'

Both --exclude and --resource-measures are ignored for test. If possible we should warn about unused flags and how to fix that.

https://github.com/manifoldco/grafton/blob/master/specs/provider.yaml#L143-L146

Please mention that the values of the query params must be url-encoded, not decoded.

This matters for the endpoint GET /integrations/manifold/v1/resources/<resource_id>/measures where the period_end and period_start parameters contain colon characters that need to be url-encoded.

Over here we always suffix the URL with v1:

https://github.com/manifoldco/grafton/blob/master/cmd/test.go#L185-L188

	// Always append the '/v1' to the path
	if !strings.HasSuffix(purl.Path, "/v1") {
		purl.Path = path.Join(purl.Path, "/v1")
	}

What is the reason for this?

My API URL will be .../v1/manifold, but this logic means it's trying to test against /v1/manifold/v1/resources... for example.

I'm happy to remove it if that's an acceptable solution. I'm not able to change my API URL just for Manifold, unfortunately.

Dependabot couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: github.com/go-openapi/[email protected] requires
	gopkg.in/[email protected]: unrecognized import path "gopkg.in/check.v1" (parse https://gopkg.in/check.v1?go-get=1: no go-import meta tags ())

View the update logs.

It appears that grafton always returns an exit code of 0 even when the test suite fails. It would be super if it returned an actual error code like rspec does so CI tooling tell the difference between a successful run and an unsuccessful one.

Place a warning in the Grafton documentation /sso endpoint warning people about Docker in dev mode and make sure they are running on the same ip address.

more details:
Grafton seems to only listen to localhost for connections, not all ips addresses, so if a user uses their own IP address to connect, it won't listen / connect.

Alternatively, change code to listen to more then localhost

Hello 👋

It looks like the last release with compiled binaries attached (on GitHub) was v0.15.2, the subsequent releases only have source code attached.

Grafton returns HTTP 200 on connector API /v1/oauth/tokens but the actual connector API returns HTTP 201 as per API specifications.

We used the node-restify-sample-provider as reference and you can see on this line that it checks for if not HTTP 200 as error handling. Grafton's connector API returns HTTP 200 which would give a successful green check mark. However, this wouldn't work on the actual integration since connector API actually returns an HTTP 201.

Just a nitpick but this can save future providers some time when they encounter the same problem in the future.

Hi team,

I've been told that it's possible for us to have our provisioning and credentials API on one domain while having our SSO endpoint on another domain.

It doesn't look possible to test this setup using Grafton, because:

• Grafton doesn't have an argument for the SSO domain
• If I run Grafton on my SSO domain instead of my API domain it doesn't run the SSO test, since the provisioning test fails

Ideally I could do this:

• grafton test ... --exclude sso http://api.myservice.com/manifold
• grafton test ... --include sso http://auth.myservice.com/manifold

I also chucked a cheeky feature request in there for the --include argument, can be ignored for this issue, but it is very difficult to isolate specific tests using the --exclude flag, especially when tests are co-dependent.

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

github.com/mitchellh/[email protected]: reading github.com/mitchellh/go-homedir/go.mod at revision v1.1.0: unknown revision v1.1.0

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

When returning plain text for example, the error from grafton/swagger isn't clear we expect a json response:

credentials: Create a credential set
    Default case
      Expected a successful provision of Credentials
      &{<nil>} (*credential.PutCredentialsIDNotFoundBody) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface

Per the docs, adding a space-delimited list of strings to the --exclude flag seems to cause the last parameter, the host, to be gobbled by the array. Singly the --exclude seems to work.

I tested this against a new Rails server with nothing in the routes except failure statuses expecting to be able to isolate specific routes as I implemented them. For example:

# GET /resources/:id/measures
def measures
	render :json => {:message => "Not yet implemented"}, :status => :not_implemented
end

Single param working example:

grafton test --product=bonnets --plan=small --region=aws::us-east-1 \
    --client-id=21jtaatqj8y5t0kctb2ejr6jev5w8 \
    --client-secret=3yTKSiJ6f5V5Bq-kWF0hmdrEUep3m3HKPTcPX7CdBZw \
    --connector-port=3001 \
    --new-plan=large \
    --exclude plan-change sso \
    http://localhost:3000

The above works great!

However if you add additional exclusions the host is lost

> grafton test --product=bonnets --plan=small --region=aws::us-east-1 \
     --client-id=21jtaatqj8y5t0kctb2ejr6jev5w8 \
     --client-secret=3yTKSiJ6f5V5Bq-kWF0hmdrEUep3m3HKPTcPX7CdBZw \
     --connector-port=3001 \
     --new-plan=large \
     --exclude plan-change sso \
     http://localhost:3000

cleanup: Remove dangling resource due to failed provision
  Default case
    Expected a successful provision of a resource
    http: no Host in request URL
  Default case ✗
provision: Provision a resource
  Default case
    Expected a successful provision of a resource
    http: no Host in request URL
  Default case ✗

2 features, 2 failures

Just getting started as a provider, good stuff here.
Currently our team is looking at going through the process of reviewing and possibly building a provider app for the Manifold marketplace. I have a couple nice-to-haves I thought I'd make note of as I go.

1. It would be great to have a Homebrew package for the Debian OSX build.
2. Currently the --version seems to be hard coded to "dev"

   grafton/cmd/version.go

   Line 9 in 1e28a9e

   var version = "dev"

• Fill out README
• Add a travis.yaml & connect to travis
• Add topics
• Remove projects
• Connect to CLA assistant Using this CLA:
  https://gist.github.com/b4bcef36cfdbf127ed897aac8470e9ab

Some improvements that would be useful to have:

• Make grafton easy to install with go get - This would require moving /cmd/* in /cmd/grafton/.
• Make grafton installable using homebrew, scoop and snaps (https://goreleaser.com/)
• Make grafton runnable as a docker container

Dependabot couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: github.com/golangci/[email protected] requires
	honnef.co/go/[email protected]: unrecognized import path "honnef.co/go/tools" (parse https://honnef.co/go/tools?go-get=1: no go-import meta tags ())

Right now grafton version always returns dev. It should return the correct version it was tagged with.