Swagger based API docs not rendering in published portal


(Piotr Zurek) #1

Hi guys,

Our swagger based docs seem to be working fine in the read tab of the editor, but are not rendering at all in when the project is published (https://vend.docs.stoplight.io/reference/specifications/api-2-0).
What could be the reason for that?

Cheers,
Piotr


(Piotr Zurek) #2

Actually, I’ve just noticed those 2 lines in the build log:

$ [+20.14s] => Resolve Error: Error: timeout of 20000ms exceeded - https://next-api.stoplight.io/files.export?projectId=17493&branch=version%2F1.0&path=%2Fvend-api-0-9.oas2.json
$ [+20.14s] => Resolve Error: Error: timeout of 20000ms exceeded - https://next-api.stoplight.io/files.export?projectId=17493&branch=version%2F1.0&path=%2Fvend-api-2-0.oas2.json

That clearly explains what is going on. How would I fix this is not immediately clear to me. All help appreciated.

Cheers,
Piotr


(Taylor Barnett) #3

Hey @p.zurek, there was a temporary issue on our end that we are looking into it. Sorry about the confusion. It should be resolved for now.


(Piotr Zurek) #4

Hey Taylor,

Thanks for getting back to me about this. I’m afraid that the issue is still present in this project.
Below is a screenshot from a build I’ve just run. Seems like API specs are timing out while everything else is building just fine.


(Piotr Zurek) #5

In my latest attempt to get this to worked, instead of “in-situ” specs I have simply linked to raw files in a public GitHub repo. Everything seems to work this way. I think I may actually adopt that approach for all content files.


(Taylor Barnett) #6

There seems to be an isolated issue with some of your specification files. We are still looking into it and will let you know what we figure out.


(Piotr Zurek) #7

Just to let you guys know, I’ve moved all the “content” files into an external repo. The only file living in the Stoplight repo is the main.hub.yml file. I’ve also created a couple of GitHub actions which, on a push to the GH repo push the hub file (if changed) and trigger a rebuild via the API. It all works beautifully and avoids any issues with the timeouts. I love that you guys enable that kind of workflow.
It would be even better if I could just declare that my project lives in GitHub and avoid all the additional pushing but now that it’s done I don’t really care.


(Taylor Barnett) #8

That’s good to hear. Sorry for any extra trouble. We have some features coming up on the roadmap that will probably help this use case, so you are probably on a good path. :slight_smile:

Is the code for that GitHub Action public? I’d love to see it and share it. We’ve been playing around some with GitHub Actions too.


(Piotr Zurek) #9

Yup, both the source for our portal and the action are available here:


The portal contains all the content along with the definition of the GitHub Action workflow.
There are 2 actions defined:

  • one that detects changes to the hub file (repo above)
  • one that triggers the rebuild.
    The second one is a bit rubbish. I started off using the default GitHub action with a Http client and that’s a massive overkill. I’m planning to replace that with a simple curl call.

(Taylor Barnett) #10

This is awesome. So simple, but very useful. Thanks for sharing. Would you mind also posting it in the Show & Tell section? I know others would love to see it and don’t want it to get lost.