Debugging Tina on Gatsby Cloud

I noticed that Gatsby isn’t a heavy focus right now but wanted to try to help save time for anyone working through trying to get a editing environment configured on Gatsby Cloud.

TLDR: Pushing from a deployed Tina dev server on Gatsby Cloud fails without a debuggable error. I can see my SSH_KEY for deployment in my Github isn’t being used but can’t seem get more information than that.


It’s been a bumpy road attempting to follow the article about how to setup a Tina interactive editing environment on Gatsby Cloud. Tina is amazing and I was really excited after getting a basic site setup.

Firstly, after following the tutorial and getting really excited about Tina I hit a wall when trying to setup the editing environment. It took a while to debug but eventually I figured out I needed to enable a specific CMS environment in the Gatsby Cloud before it would show up as expected. I was unclear on this during my read.

However, now that I was up on Gatsby Cloud I hit another wall where none of my commits nor pushes could be merged. I was getting the generic error: Git Operation failed: Check the logs for more details but was unable to access the logs because Gatsby Cloud doesn’t seem to expose any logging around the CMS Preview process.

After reviewing the source code for @tinacms/api-git I discovered that committing was actually also triggering a push via the pushOnCommit flag., Only the /__tina/push endpoint and path was really throwing errors

Now that I had things narrowed down I needed to figure out how to debug what was happening. The default endpoint doesn’t expose any details and ignores the caught exception. I couldn’t reproduce locally so I figured I could override the functionality of @tinacms/api-git to return the git error from /__tina/push.

Editing a forked copy of @tinacms/api-git, building it and then loading that custom copy in to my node_modules with a postinstall script, I returned the thrown error object to see that the git error result is {}. Thinking this might be a serialization error I tried returning the Object.keys() of the returned object which returned []. Looks like simple-git doesn’t return an error code from the last task attempted. (This renders a series of TODO comments unnecessary because as far as I can tell, as nothing will ever be returned. Perhaps that should be noted instead)

Around this time after some trial and error I figured out that @tinacms/gatsby-tinacms-git relies on process.env.TINA_CEE to call configureGitRemote. If this isn’t set, as it was in my testing locally, none of the other gatsby configurations for sshKey or gitRemote will be used. This wasn’t intuitive to me and lead to further difficulty debugging what was going on.

gatsby develop doesn’t take any debug variables so I don’t think there’s a way to get at the output. (I’d love to learn about some way to drop debug output into a file if someone has a clever way but this shouldn’t have to be clever.) I thought of trying gatsby develop > debug.txt and then outputting that value with simple-git but decided against it for the time being.

My final attempt was to update the version of simple-git in hopes of an actual exposed error message. Updating to 2.31.0 actually returned an error value but nothing that was helpful

{
    "status": "failure",
    "error": "{\"task\":{\"commands\":[\"push\",\"-u\",\"origin\",\"master\",\"--verbose\",\"--porcelain\"],\"format\":\"utf-8\"}}"
}

I’m at the point where I think I have 10/100 of my builds left for Gatsby Cloud (ridiculously low number of builds to support even a personal CMS for testing). I’m going to try out NextJS and try things out there.


Thanks for coming to my TED talk. Hopefully this short-circuits some debugging and please follow up if this setup is currently working for you

2 Likes

Thanks for taking the time to share your experience and sorry you had to put up such effort for a poor result, we’ll learn from it :blush:

1 Like