spoffy/fix-import-error-s3-no-redis
dependabot/npm_and_yarn/express-4.20.0
latest_candidate
main
spoffy/webdriver-logs
dependabot/npm_and_yarn/webpack-5.94.0
dependabot/npm_and_yarn/dompurify-3.1.3
latest
dependabot/npm_and_yarn/elliptic-6.5.7
dependabot/npm_and_yarn/axios-1.7.4
dependabot/npm_and_yarn/micromatch-4.0.8
berhalak/build-test
ignore-alert
link-to-issue-templates
spoffy/rename-candidate-action-job
dependabot/npm_and_yarn/fast-xml-parser-4.4.1
spoffy/playwright
spoffy/grist-ee-defaults
dependabot/npm_and_yarn/ws-8.17.1
dependabot/npm_and_yarn/tar-6.2.1
dependabot/npm_and_yarn/braces-3.0.3
jordigh/native-arm64
paulfitz/preview
paulfitz/smoosh
test-server-reset
dsagal-readme-gvisor
readme-update-dec2023
paulfitz/bundle-widget-prep
jv-linkstate-bubbles-tooltips
jv-linkstate-bubbles-base
jv-bidirectional-tests
preview
bidirectional
chainlink-fix
alex/skip-fstrings-3.9
alex/upgrade-pyodide
alex/3.11-tests
alex/_importParsedFileAsNewTable
poc-engine-data-layer
poc-engine
sponsors-section
removing-missing-key-error
friendly-locale
messytables-requirements
add-page-name
markdown-cells
v1.1.12
v1.1.11
v1.1.10
v1.1.9
v1.1.8
v1.1.7
v1.1.6
v1.1.5
v1.1.4
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.9
v1.0.8
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3
v0.7.9
v0.7.8
v0.7.7
v0.7.6
v0.7.5
v0.7.4
v0.7.1
v0.7.2
v0.7.3
v1.1.13
v1.1.14
v1.1.15
v1.1.16
v1.1.17
v1.1.18
${ noResults }
2 Commits (903c81d34898e54cdc04877ac4cd660565e3728a)
Author | SHA1 | Message | Date |
---|---|---|---|
Jarosław Sadziński | 2438a63255 |
(core) Moving widget tests to core
Summary: - Custom widget tests are now in grist-core - Adding buildtools for grist-plugin-api.js Test Plan: Existing tests Reviewers: paulfitz Reviewed By: paulfitz Differential Revision: https://phab.getgrist.com/D3617 |
2 years ago |
Paul Fitzpatrick | e6983e9209 |
(core) add machinery for self-managed flavor of Grist
Summary: Currently, we have two ways that we deliver Grist. One is grist-core, which has simple defaults and is relatively easy for third parties to deploy. The second is our internal build for our SaaS, which is the opposite. For self-managed Grist, a planned paid on-premise version of Grist, I adopt the following approach: * Use the `grist-core` build mechanism, extending it to accept an overlay of extra code if present. * Extra code is supplied in a self-contained `ext` directory, with an `ext/app` directory that is of same structure as core `app` and `stubs/app`. * The `ext` directory also contains information about extra node dependencies needed beyond that of `grist-core`. * The `ext` directory is contained within our monorepo rather than `grist-core` since it may contain material not under the Apache license. Docker builds are achieved in our monorepo by using the `--build-context` functionality to add in `ext` during the regular `grist-core` build: ``` docker buildx build --load -t gristlabs/grist-ee --build-context=ext=../ext . ``` Incremental builds in our monorepo are achieved with the `build_core.sh` helper, like: ``` buildtools/build_core.sh /tmp/self-managed cd /tmp/self-managed yarn start ``` The initial `ext` directory contains material for snapshotting to S3. If you build the docker image as above, and have S3 access, you can do something like: ``` docker run -p 8484:8484 --env GRIST_SESSION_SECRET=a-secret \ --env GRIST_DOCS_S3_BUCKET=grist-docs-test \ --env GRIST_DOCS_S3_PREFIX=self-managed \ -v $HOME/.aws:/root/.aws -it gristlabs/grist-ee ``` This will start a version of Grist that is like `grist-core` but with S3 snapshots enabled. To release this code to `grist-core`, it would just need to move from `ext/app` to `app` within core. I tried a lot of ways of organizing self-managed Grist, and this was what made me happiest. There are a lot of trade-offs, but here is what I was looking for: * Only OSS-code in grist-core. Adding mixed-license material there feels unfair to people already working with the repo. That said, a possible future is to move away from our private monorepo to a public mixed-licence repo, which could have the same relationship with grist-core as the monorepo has. * Minimal differences between self-managed builds and one of our existing builds, ideally hewing as close to grist-core as possible for ease of documentation, debugging, and maintenance. * Ideally, docker builds without copying files around (the new `--build-context` functionality made that possible). * Compatibility with monorepo build. Expressing dependencies of the extra code in `ext` proved tricky to do in a clean way. Yarn/npm fought me every step of the way - everything related to optional dependencies was unsatisfactory in some respect. Yarn2 is flexible but smells like it might be overreach. In the end, organizing to install non-core dependencies one directory up from the main build was a good simple trick that saved my bacon. This diff gets us to the point of building `grist-ee` images conveniently, but there isn't a public repo people can go look at to see its source. This could be generated by taking `grist-core`, adding the `ext` directory to it, and pushing to a distinct repository. I'm not in a hurry to do that, since a PR to that repo would be hard to sync with our monorepo and `grist-core`. Also, we don't have any licensing text ready for the `ext` directory. So leaving that for future work. Test Plan: manual Reviewers: georgegevoian, alexmojaki Reviewed By: georgegevoian, alexmojaki Differential Revision: https://phab.getgrist.com/D3415 |
2 years ago |