importing upstream
This commit is contained in:
parent
d372224ed6
commit
dddf50bc09
@ -1,47 +0,0 @@
|
|||||||
---
|
|
||||||
title: Setting up PostHog EE
|
|
||||||
sidebar: Handbook
|
|
||||||
showTitle: true
|
|
||||||
---
|
|
||||||
|
|
||||||
Rough instructions on how to "get the EE version running in all its glory".
|
|
||||||
|
|
||||||
Currently for internal use only.
|
|
||||||
|
|
||||||
### Getting it up and running
|
|
||||||
`docker-compose -f ee/docker-compose.ch.yml up`
|
|
||||||
|
|
||||||
### Fixing broken frontend build
|
|
||||||
`docker run ee_web yarn build`
|
|
||||||
|
|
||||||
### Running Python + Webpack locally
|
|
||||||
- Run all the services
|
|
||||||
- Stop local kafka, clickhouse and zookeeper instances if you have them
|
|
||||||
- Same for redis, though it doesn't really matter much
|
|
||||||
- `docker-compose -f ee/docker-compose.ch.yml up db redis zookeeper kafka clickhouse`
|
|
||||||
- Add to `/etc/hosts`:
|
|
||||||
- `127.0.0.1 kafka` (setting KAFKA_URL later doesn't seem to work)
|
|
||||||
- Run the frontend
|
|
||||||
- `yarn build`
|
|
||||||
- `yarn start` or click "▶️" next to `"start"` in the scripts section of package.json.
|
|
||||||
- Run the backend
|
|
||||||
- `export DEBUG=1`
|
|
||||||
- `export PRIMARY_DB=clickhouse`
|
|
||||||
- `export DATABASE_URL=postgres://posthog:posthog@localhost:5439/posthog` (note the `9` in `5439`)
|
|
||||||
- Run migrations: `python manage.py migrate && python manage.py migrate_clickhouse`
|
|
||||||
- Run the app: `python manage.py runserver` (or set it up via your IDE)
|
|
||||||
- Run the worker: `./bin/start-worker`
|
|
||||||
- Setting up PyCharm debugging
|
|
||||||
- Copy the env when needed:
|
|
||||||
- `;DEBUG=1;PRIMARY_DB=clickhouse;DATABASE_URL=postgres://posthog:posthog@localhost:5439/posthog`
|
|
||||||
- Backend config:
|
|
||||||
- Set up a `Django Server`
|
|
||||||
- For django support, set the project folder to the project root
|
|
||||||
- Settings: `./posthog/settings.py`
|
|
||||||
- Worker config:
|
|
||||||
- Set up a python configuration
|
|
||||||
- script_path `./env/bin/celery` (replace `.` with the project dir)
|
|
||||||
- parameters `-A posthog worker -B --scheduler redbeat.RedBeatScheduler`
|
|
||||||
- Tests:
|
|
||||||
- All the same, except skip `DEBUG=1` in the env settings.
|
|
||||||
- Set as the "target" in run configuration `ee/clickhouse`
|
|
||||||
@ -1,99 +0,0 @@
|
|||||||
---
|
|
||||||
title: Website MDX Setup
|
|
||||||
sidebar: Handbook
|
|
||||||
showTitle: true
|
|
||||||
---
|
|
||||||
|
|
||||||
import { Spin } from 'antd'
|
|
||||||
|
|
||||||
What better way to document MDX than with MDX?
|
|
||||||
|
|
||||||
## Rationale
|
|
||||||
|
|
||||||
There were a few moving parts involved with setting up MDX so it might make sense to have them written down.
|
|
||||||
|
|
||||||
## What's MDX?
|
|
||||||
|
|
||||||
Not in scope here - but it's essentially React in Markdown.
|
|
||||||
|
|
||||||
## How do we make it work?
|
|
||||||
|
|
||||||
### Plugin
|
|
||||||
|
|
||||||
The first thing we need is `gatsby-plugin-mdx`. That's configured in `gatsby-config.js`.
|
|
||||||
|
|
||||||
We also need `gatsby-source-filesystem` but we already use that for Markdown remarking.
|
|
||||||
|
|
||||||
### createPages
|
|
||||||
|
|
||||||
There is a plugin that creates MDX pages for you, but it was a bit limiting with regards to templates. Hence, we implement page creation ourselves
|
|
||||||
in `gatsby/createPages.js`.
|
|
||||||
|
|
||||||
That does 2 GraphQL queries - one for Markdown files, and the other for MDX files.
|
|
||||||
|
|
||||||
The response is almost the same, with a few differences.
|
|
||||||
|
|
||||||
Here, for the MDX part, we pass the page (node) `id` as part of the context for the template to process each page. More on this later.
|
|
||||||
|
|
||||||
### MDX Template
|
|
||||||
|
|
||||||
`TemplateMdx.tsx` is almost the same as our traditional post template, however, it queries MDX pages based on their ID
|
|
||||||
which we passed via the `createPages` context.
|
|
||||||
|
|
||||||
The GraphQL query will return everything we need, from content to frontmatter, and we use the component
|
|
||||||
`MDXRenderer` to render the body, and `MDXProvider` to pass some context that is available to all MDX pages.
|
|
||||||
|
|
||||||
In this case, we pass references to components that can then be used without imports directly on MDX pages, like this hedgehog:
|
|
||||||
|
|
||||||
<BasicHedgehogImage />
|
|
||||||
|
|
||||||
Because of the components passed to `MDXProvider`, I can include this hedgehog by just adding `<BasicHedgehogImage />` in my
|
|
||||||
MDX file - no import needed.
|
|
||||||
|
|
||||||
However, if I want to include something from a module, I can also do so. Here's a spinner component from AntD:
|
|
||||||
|
|
||||||
<Spin />
|
|
||||||
|
|
||||||
<br />
|
|
||||||
<br />
|
|
||||||
|
|
||||||
|
|
||||||
```js
|
|
||||||
|
|
||||||
import { Spin } from 'antd'
|
|
||||||
|
|
||||||
## Some Markdown
|
|
||||||
|
|
||||||
<Spin />
|
|
||||||
|
|
||||||
```
|
|
||||||
|
|
||||||
### mdxImportGen
|
|
||||||
|
|
||||||
The `mdxImportGen.js` script handles global MDX imports automatically. This is currently a quick implementation that can improve
|
|
||||||
and be made more robust in the pre-commit process. Essentially, it prepares a file based on all the components in our `src/components` directory
|
|
||||||
which is then used to pass the components to `MDXProvider`, making them available everywhere.
|
|
||||||
|
|
||||||
Doing globally available imports this way was important for 3 main reasons:
|
|
||||||
|
|
||||||
- Relative imports in MDX can be annoying
|
|
||||||
- Keeping MDX files clean
|
|
||||||
- Making MDX a nice experience even for less technical people that update our website
|
|
||||||
|
|
||||||
### CodeBlock
|
|
||||||
|
|
||||||
To create syntax-highlighted code blocks in Markdown, we use a plugin that handles it automatically.
|
|
||||||
|
|
||||||
However, this plugin does not work for MDX. As such, we establish a `CodeBlock` component passed alongside the others
|
|
||||||
as a prop to `MDXProvider`. It operates on `pre` tags.
|
|
||||||
|
|
||||||
This component leverages the `prism-react-renderer` module, which does not have the Okaidia theme that we use on Markdown pages.
|
|
||||||
|
|
||||||
As such, we could either switch themes or port the Okaidia CSS into the acceptable format. The latter was done and
|
|
||||||
the ported theme styles can be found in `src/lib/okaidia/index.js`.
|
|
||||||
|
|
||||||
## Final note
|
|
||||||
|
|
||||||
A final point is that a lot of this setup was done this way because we want to keep Markdown alongside MDX for now.
|
|
||||||
|
|
||||||
However, it could be worth considering migrating entirely in the future to simplify things, if MDX meets our needs entirely.
|
|
||||||
@ -1,12 +0,0 @@
|
|||||||
---
|
|
||||||
title: Tech Talks
|
|
||||||
sidebar: Handbook
|
|
||||||
showTitle: true
|
|
||||||
---
|
|
||||||
|
|
||||||
We encourage engineers to give tech talks on topics they're interested in/knowledgeable about.
|
|
||||||
|
|
||||||
## Previous talks
|
|
||||||
|
|
||||||
- PostHog Cloud Infrastructure ("Infra Brown Bag") by [James Greenhill](/handbook/people/team#james-greenhill-software-engineer)
|
|
||||||
- [Let's Talk About PyCharm](https://drive.google.com/file/d/1GV08S638NzY1H0DI7w9ZHNSE4CcVbe6y/view?usp=sharing) by [Marius Andra](/handbook/people/team#marius-andra-software-engineer)
|
|
||||||
Loading…
Reference in New Issue
Block a user