Before:
The docs lint action doesn't run properly on forks because it tries to
use the branch name to identify the PR for updating, but the branch name is adapted on forks, so it is not `branch-name`, but `forking-account:branch-name`.
After:
Use the PR number instead to identify the PR instead.
* chore(studio): move Query to pgMeta add tests
- Move the Query builder from studio to pgMeta
- Add e2e tests over the generated sql to ensure syntax and runtime
result over pg database
- fix bug with orde by for table with undefined column
* chore: fix query import path
* chore: set ES target for lint
* chore: add github action for pg-meta test package
* chore: add tsconfig to sparse checkout
Partials are currently defined via MDX includes. This PR switches to pre-compile-time partials, which have a new syntax:
```
<$Partial path="path/to/file.mdx" />
```
## Rationale
This produces two improvements:
1. Partial substitution can occur in pipelines that don't use MDX compilation. For example, we can now do partial substitution before building the search index, so partial content will also be indexed.
2. After the App Router migration, the MDXProviders should've been deprecated, but were kept around for the sole reason of making partials work, and leading to us shipping unnecessary client-side code. We get a minor decrease in overall client bundle size (5.74 MB to 5.6 MB) by getting rid of the Providers.
## Breaking changes
Besides the change to partial syntax, the arguments are also less powerful than before because we are doing string substitution and don't have the full power of JS. Defining string variables is still possible (documented in the Contributing guide), and since that's all we actually do in practice, this shouldn't be too cumbersome. There is always the escape hatch of making a custom component for more complex content reuse cases.
Conditional and required checks don't mix well on GitHub -- if a required check is skipped it still hangs, preventing PRs from getting merged indefinitely. Instead, we need to to run the action on every PR, but bail early if no docs content changes were made.
Since the logic for when/how this action runs is getting a bit convoluted, I also split up the tests against master (run against all files, no conditional checks) from the tests aginst PRs (run against changed files, with conditional checks)
* add logic to remember last route
* add default redirect
* move logic to index page
* Simplify logs page redirect logic
* missing }
* fix wrong }
* wait 2s for page to redirect
* use latest version in local studio cli test
* rm timeouts looks like it takes longer in ci
* Clean up
* Fix broken commands
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
* Set up E2E tests for staging
* update
* Update
* Update .env.staging.example
* Fix node modules
* Fix
* Attempt to swap local-studio-tests to use the new studio-tests directory
* Omit storage state if running tests for local self host
* Fix test:local command
* Deprecate local-studio-test folder
* Rename local studio tests GH action to E2E test
* Fix some missing and duplicate dependencies.
* Fix the types for jest in ai-commands package.
* Replace all npm commands with pnpm. Add pnpm files and workspace links.
* Fix rimraf to work with pnpm.
* Refactor the github actions to work with pnpm.
* Delete package-lock.json.
* Fix the tailwind configs to not include node_modules.
* Fix random files.
* Add preinstall scripts to all packages.
* Fix the Dockerfile to work with pnpm.
* Update the DEVELOPERS documentation.
Docs lint errors can make it into master through a race condition:
- PR with lint configuration changes is made
- Separately, a PR that is incompatible with the new configuration (but _is_ compatible with the old one) is merged
This can be annoying for downstream PRs, so lint post-merge, and create a PR with auto-fixes if possible.
PR to start introducing Linter V2!
Primary improvements from this linter:
Better parsing of MDX (fewer false positives)
More flexibility
And suggested autofixes! (see auto-generated PR comment below for how that works)
Turning this on for only a small portion of the repo at first to avoid an avalanche of alerts, will slowly expand from there.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
When a troubleshooting entry is created or updated in this repo, sync it to GitHub. This creates a new troubleshooting discussion if one does not exist, and updates the content on an existing troubleshooting discussion if it has changed.
To preserve the connections between GitHub discussions and Markdown files, record the discussion ID and URL to the database. The database ID is then written to the Markdown file, and a new PR is generated to commit the new Markdown with ID.
There is currently no mechanism to delete outdated discussions. That will be a follow-up.
Add the ability to embed code samples from GitHub into tutorials, so we can have a single source of truth for the source code.
Introduces the <$CodeSample /> syntax, which is a special syntax and not a real React component (see the directives/README.md for why on earth I did it this way -- in this specific case, CodeHike adjusts the MDX syntax tree before it gets compiled, and we need to adjust it ourselves before CodeHike sees it, so we need to get down to the level of manipulating the AST in order to make this work with CodeHike).
Adjusted one of the example tutorials to use this new feature as a test.
Migrates client SDK References to App Router. (Management and CLI API references aren't migrated yet, nor are self-hosting config references.)
Some notes:
Big changes to the way crawler pages are built and individual section URLs (e.g., javascript/select) are served. All of these used to be SSG-generated pages, but the number of heavy pages was just too much to handle -- slow as molasses and my laptop sounded like it was taking off, and CI sometimes refuses to build it all at all.
Tried various tricks with caching and pre-generating data but no dice.
So I changed to only building one copy of each SDK+version page, then serving the sub-URLs through a response rewrite. That's for the actual user-visible pages.
For the bot pages, each sub-URL needs to be its own page, but prebuilding it doesn't work, and rendering on demand from React components is too slow (looking for super-fast response here for SEO). Instead I changed to using an API route that serves very minimal, hand-crafted HTML. It looks ugly, but it's purely for the search bots.
You can test what bots see by running curl --user-agent "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" <URL_OF_PAGE>
Also added some smoke tests to run against prod for the crawler routes, since we don't keep an eye on those regularly, and Vercel config changes could surprise-break them. Tested the meta images on Open Graph and all seems to work fine.
With this approach, full production builds are really fast: ~5 minutes
Starts using the new type spec handling, which is better at finding params automatically, so I could remove some of the manually written ones from the spec files.
We don't need this for migration pushes since the Supabase integration will do
it instead. Removing it makes this action less brittle since embedding updates
get blocked on CLI problems.
Etienne Stalmans