It should have been clear that you must use a public repo. Fixed.
I still got the message: It looks like we don’t have access to your repo, but we’ll try to clone it anyway.
And it works anyway. So, the message isn’t valid…
It was hard to get things working but part of it was because my repo and content was munged. Getting cleaned up and starting to work.
Except for the erroneous message in the log, there are no other issues.
Hi @lewisl, sorry you had a hard time getting started. For future reference, you can use private repos as long as you connect them to your Render account during the service/static site creation process. Click on the GitHub or GitLab link to start the process:
Thanks. Why do you think the log still shows a message that Render thinks it can’t connect to the repo every time I build and deploy?
BTW, do you do an incremental (sync’ed) upload or a full copy? This blog has lots of images, but they never change.
I’d confirm that the Render app for GitHub is properly configured and has access to the repo. Go to https://github.com/apps/render and click Configure.
We upload a full copy of each build, in part so you can quickly rollback to a previous build: https://render.com/docs/rollbacks.
Well, it wasn’t quite what you described, but I “installed” Render into my blog repo and returned back to Render. Ran a deploy and there was no message that Render couldn’t connect. Of course, it had been connecting all along, successfully cloning the repo, building, and deploying.
Nowhere did I see any documentation indicating I should do this. Generally, you have serious shortcomings on doc. Don’t do LOTS of doc—that’s also a bit of a fail that others fall prey to. Just do the essential accurate and correct doc.
Got it on deploy. Sort of a shame because with a lot of images it’s a 1.1 gb site before expansion to deployable state so it’s a lot to deploy of stuff that doesn’t change often. But, when I’m done with lots of site design changes (converting from Ghost) then it will all settle down to creating new posts—still the whole build will be propped. Might be something to explore in the future: an option for “delta deploy”. More a curious thing than an obstacle.
Thanks for replying.
Thanks for the feedback. We recognize how important it is to have good documentation, and are working all the time to improve on this front.
The configure button doesn’t exist anywhere until AFTER
you have installed Render into a specific repository.
It is actually not at all obvious why this install into a specific repository, as opposed to authorizing Render to have access to your github account–which is absolutely necessary. If you don’t do this per repository install thing, you get a message that Render can’t connect to your repository. Then, Render merrily clone the repository, does the build, uploads and everything is perfect.
So, in addition to documentation it seems like you need to think through what the extra step does and why it is even needed.
So, then clicking configure provides a way to:
A few problems: it doesn’t help the user to be able to choose/set the specific permissions because you know what you need and that’s what you need and you shouldn’t request more. But even if I don’t do this step Render can do the minimal thing it needs, which is to clone the repo.
it seems you can do all of this from the global settings option of your github account.
So, much ado about nothing to get rid of a log message, which is harmless anyway.
Or so it seems to me (I may be wrong) because everything worked as expected, except for the log message, without performing the configure step.
Hi @lewisl , I appreciate your detailed feedback.
GitHub permissions are a little complex: there is the cloning permission as you’ve noted, and there are separate GitHub API permissions for things like listing the repositories a user owns or getting push events for new commits, which is needed for auto deploys. Render uses all these features, and it’s possible to have permission to clone a repo but not to list it, which is where you’re seeing the inconsistent messaging.
I believe the “right” solution for Render is to either 1) have guided support for partial permissions or 2) block service creation until we detect that permissions are totally set up, and guide you through what still needs configuration. Similarly to what @david said, we’ll be using your feedback to improve this messaging and the documentation to get rid of this inconsistency. Thanks for taking the time to provide it 
If you do need all the permissions, then do what makes it easy to have the user grant all of them.
Although, do note that build and deploy work with partial permissions. Still, no reason not to do what is more effective for more use cases.
