Determine how we can verify a page was migrated successfully about docs-website HOT 2 CLOSED

We have confirmed that Gatsby will only throw an error for the first instance of an error and will not list all of the pages that are not working. We are going to look into what our options are to get more rich set of information.

from docs-website.

Unfortunately, there does not seem to be a way to easily determine all the pages that are not building successfully. Here's a recap of things we have tried:

npm run build
This will fail on the first occurrence of an issue and does not provide insight into what other pages are having issues.

Ping pages locally for HTTP status
I created a script that would ping all the pages found on the sitemap. The thinking was that a failing page might throw a 400-level status code we could use to determine if a page was failing. Unfortunately, the issue is purely client side and happens after the original page load (so we couldn't scrape the page content either).

Compare built files to expected files
When we run npm run build, static HTML files get generated in the public folder. We thought about comparing this to the expected output, but this also does not work due to Gatsby's fail-on-first-bad-file mechanism.

My suggestion would be to catch errors before we get to Gatsby. During the sanitize and normalize step, we should make sure to capture and errors. When it comes time to build the site post-migration, we should keep an eye out for patterns. If we find that we have to fix the same error multiple times, we should update the migration code and run it again.

Lastly, we may have the option to use the raw HTML with Gatsby instead of pasting it into the MDX file. This has it's own set of challenges, but is an option.

I'm going to close this ticket as I believe we have identified all that we can given the current setup.

from docs-website.