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