It turns out that the initial approach of overwriting certain configuration
from the command-line did not work at all, because Traefik insists on only receiving
configuration in one way. Either of config file, command-line or env variables.
The best thing to overwrite separately in a docker setup is environment variables,
so the configuration has been turned towards environment variables now.
Relocate CI workflows from the nested blocknote/hocuspocus/.github/
(which GitHub ignores) to root .github/workflows/ with path filters
so they run independently of core OpenProject CI. Update Docker
workflow tag pattern to hocuspocus-v* to avoid collisions with
OpenProject version tags, and set build context to ./blocknote/hocuspocus.
Also update all references from the old standalone repo
(opf/op-blocknote-hocuspocus) to monorepo paths, including
dependabot, package.json metadata, static_links, README badges/
instructions, docker-compose dev volume mount, and documentation.
- validation script used unmaintained npm package
- switched to actively maintained package from same maintainer
- pipe full output to stdout
- bump node major version in development backend Dockerfile
- fix two api spec errors and two random warnings - boyscout, hell yeah
Making the CA configuration a bit more flexible, so that
choosing between Let's encrypt and Step CA is possible.
This only makes sense when not using *.local hostnames.
during https://community.openproject.org/wp/67403
What do you want to accomplish?
This should make it easy for people to spin up a "local S3" so they
can develop the API flow for uploading files to S3. Since this flow
is more complex than the upload to a local storage, it should be
easy to try it out locally.
- Use published docker image for local dev setup.
- Handle a case when Setting.collaborative_editing_hocuspocus_url is set to invalid URI.
- Remove unneedd CSS.
- Add some tests.
The latest upgrades to our frontend stack prohibited access through the
openproject.local hostname and also caused trouble with the previous setup
where the frontend stack would proxy requests to the backend.
Thus the default setup was now changed so that both frontend and backend
are exposed to the browser via different hostnames. The main service to start
will be the backend, which will redirect requests to certain assets to the frontend
service (this was already integrated into the rails routes previously).
Jan Sandbrink