Has anyone been able to run provider verification ...
# pact-js
t
Has anyone been able to run provider verification inside an AWS Lambda function? I'm running into the following error while trying to use
new Verifier(opts).verifyProvider()
Copy code
[17:16:10.532] DEBUG (8): pact-core@15.1.0: binding path #0: : attempting to load native module from: 
- /prebuilds/linux-x64 
source: pact-js-core binding lookup 
- You can override via PACT_PREBUILD_LOCATION
[17:16:10.590] DEBUG (8): pact-core@15.1.0: binding path #1: : attempting to load native module from: 
- /var/task/prebuilds/linux-x64 
source: pact-js-core binding lookup 
- You can override via PACT_PREBUILD_LOCATION
[17:16:10.591] DEBUG (8): pact-core@15.1.0: Supported platforms are: 
- darwin-arm64
- darwin-x64
- linux-arm64
- linux-x64
- win32-x64
[17:16:10.592] ERROR (8): pact-core@15.1.0: Failed to find native module for linux-x64: TypeError: Cannot read properties of undefined (reading 'pactffiInitWithLogLevel')
[17:16:10.592] DEBUG (8): pact-core@15.1.0: We looked for a supported build in this location /prebuilds/linux-x64
[17:16:10.592] DEBUG (8): pact-core@15.1.0: We looked for a supported build in this location /var/task/prebuilds/linux-x64
[17:16:10.593] DEBUG (8): pact-core@15.1.0: Tip: check there is a prebuild for linux-x64
m
hmmm why are you doing this? Does your CI run within a lambda?
It’s probably just not detecting the runtime correctly. You can see it thinks it’s linux x64. Have fun debugging this given you don’t have easy access to the file system 😛
😆 1
My usual goto would be to use
ld
to check the dynamic library it’s looking for (the “native module” to see if it recognises the format and any dependencies are resolved. This is a share core library Pact JS is using. You can see the paths it’s trying
That would be the starting point
t
Hey Matt, doing this to handle the contract-requiring-verification webhook payload
I'll try running the same code in a custom Docker
👍 1
m
I'm not sure why it needs to run in a lambda tho?
t
Our webhook endpoint is an API Gateway with a Lambda backend
Is there a better service to use if we're entirely on AWS?
m
Normally the webhook would trigger a CI build. What CI do you use - code pipeline?
y
it looks like it is loading from
/prebuilds/linux-x64
instead of from the prebuilds folder which is located 2 folders before src/ffi/index.ts. Try setting PACT_PREBUILD_LOCATION to whereever the prebuilds are (they are contained in the pact-core npm package)
💡 1
t
Thanks Yousaf, I'll give that a go
m
I’m still confused, what do you use for CI and why are you running this check in lambda?
t
For our (provider) CI, we use AWS CodeBuild and we run verification in there. But for the webhook that fires when new consumer contracts require verification, we have an API Gateway with a Lambda behind it, and we want to run verification in there too, rather than have the API kick off a CodeBuild job (seems overkill just to run a single verification)
Wait, maybe I've not been clear - this is all provider-side stuff. The only webhook we're interested in is when our consumers publish new contracts and we need to verify them
👍 1
m
Thanks. That’s clear, I’m not sure I’d make the same call but if it works it’s up to you. For example, will you lose some visibility over the build activity this way? Why not just create a smaller codepipeline job, that just runs the verification job (and nothing else) You would also now need to manage this separate build which deviates from the other, so you might be creating additional work. That being said, I never liked CodePipeline (maybe it’s better now?) and maybe it’s hard to trigger a build remotely? So I can see why you may want to avoid that 😆 .
👍 1
t
I think that's probably what I'll end up doing - Yousaf's suggestion looks like it'll work but Lambda isn't making it easy...
👍 1