Hi all, I was able to publish Open API spec to my ...
# pactflow
a
Hi all, I was able to publish Open API spec to my (trial) broker, but now when I publish it, in the UI, I see this error: The requested document was not found on this server. Even though on the command line, it says successfully published. Could someone help pointing the issue here? Thank you in advance!
m
Hi Anshu, what do you mean by “trial” - is this an on-prem trial or cloud trial?
error: The requested document was not found on this server.
could you please elaborate a bit more on this? What URL are you on when you see this error?
a
This is a cloud trial if I understand correctly. I suppose the on-prem trial will be the one inside the compang
*company
On the cmd line it says: Successfully published provider contract for pactflow-example-bi-directional-provider-postman version 215d0f1-master+215d0f1.SNAPSHOT.LAPTOP-CG5C2KOB to Pactflow
But I do not see the contract in the UI, it instead gives the error I mentioned
m
Can you please share more about how you have published the contract? It looks like some key info is missing. Also, note the version is
undefined
a
make ci
root@LAPTOP-CG5C2KOB:/home/n/workspace/example-bi-directional-provider-postman# echo $PACT_BROKER_BASE_URL https://jpmc.pactflow.io
And I have the token defined as well in $PACT_BEARER_TOKEN
Not sure if it is safe to post it here
m
no, don’t post the token 🙂
I’d like to see the log output though please (if you can redact any secrets)
brb
a
sure
m
thx
any chance you could please add the
--verbose
flag to the publish command?
Copy code
publish_provider_contract: .env
	@echo "\n========== STAGE: publish provider contract (spec + results) ==========\n"
	${PACTFLOW_CLI_COMMAND} publish-provider-contract \
      ${OAS_PATH} \
      --provider ${PACTICIPANT} \
      --provider-app-version ${GIT_COMMIT} \
      --branch ${GIT_BRANCH} \
      --content-type application/yaml \
      --verification-exit-code=${EXIT_CODE} \
      --verification-results ${REPORT_PATH} \
      --verification-results-content-type ${REPORT_FILE_CONTENT_TYPE}\
      --verifier ${VERIFIER_TOOL}\
	  --verbose
a
Sure, I will delete the contract and publish again
👍 1
I just did it and pasted to the same gist
👍 1
m
thanks. One theory is that it’s something strange in the version number (there is a
%
, it should be escaped, but I wonder if that’s the issue)
see if you can hard code
GIT_COMMIT
in the make file to something like
1.0.0
a
I think you mean this line
VERSION?=$(shell npx -y absolute-version)
I updated the gist after change
m
No, I mean these:
Copy code
GIT_COMMIT?=$(shell git rev-parse --short HEAD)
GIT_BRANCH?=$(shell git rev-parse --abbrev-ref HEAD)
a
Should these be env variables?
m
The gist is for postman too
a
My bad, I pasted the wrong URL. But it is not there in postman makefile either
m
ah, yes. I see I have not pulled the latest
yes,
VERSION
🙂
👍 1
a
I have to go out in a bit... Please leave the message regarding your findings.
I will reply when I am back.. maybe in couple of hours or so
👍 1
m
looks like the version is the issue, I suspect the
%
is causing the problem. It’s a UI only bug, because the
can-i-deploy
check works as you’d expect. I’ll raise a defecct
for now, use your own versioning scheme!
I’ve raised an internal defect also
a
I see, but I used my own versioning macro as in the gist
It did not resolve the issue
m
The problem is that you have characters that are not URL escaped (In your case, my guess is
+
). Can you please try a scheme that doesn’t include those for now
I just noticed your TZ - 1am! Hope you’re getting some rest!
a
Yeah I slept 🙂
😆 1
Oh right, when I removed the + and - from the version, it worked fine. Thank you for the help.
I like that I can now communicate on Slack. So I will be posting any questions that I may have over here.
🙌 1
m
FYI we’ve raised a bug and it will be fixed in the next sprint or so. Thanks for drawing attention to it, i’m surprised it wasn’t picked up when the new versioning tool was used. It obviously works on the server side, so that is probably why it wasn’t noticed.
If we ever take too long to respond or miss the question and it’s a bug, do raise with support@pactflow.io
a
Good to know. I was told that the primary mode for communication should be what company provides. So I will be using mostly the email for now.
👍 1
m
Just for clarity, the support@pactflow.io address is really for issues that customer care can help with (account issues, product bug reports etc.). Your account manager might be able to help with certain queries, but for general Pact/PactFlow advice this is the community for that.
a
I see, if I understand correctly, for Pact/Pactflow advice I should direct email to support@pactflow.io. Is that right? I am not sure who is my account manager, but I am new the team so Rejeesh might know.
I just posted multiple questions regading birectional testing to the support email and cc'ed it to your email.
m
I see, if I understand correctly, for Pact/Pactflow advice I should direct email to support@pactflow.io. Is that right? I am not sure who is my account manager, but I am new the team so Rejeesh might know.
Jason Stahl is your account manager. But more generally, I would use this community for general “advice” and use the support@pactflow.io email address for technical issues/bug reports etc.
👍 1
a
I was wondering when should I expect to hear back for my questions? Is there an SLA?
m
Hi Anshu, I don’t believe there are SLAs attached to support tickets but usually I would expect a response within 1-2 business days.
a
I see, thanks for letting me know.