- It turns out we can set it up with helm, it was just an issue with not
starting with a clean slate. I guess it probably would have been
better to just set it up from scratch and deleted the develop server,
like we intend to do in production.
- image is set configurable and set to the app version for version
control
- imagePullPolicy revert earlier changes to flatten hierarchy since helm
create uses .Values.image.pullPolicy
- update imagePullPolicy to IfNotPresent since this is the default with
helm create and fits with our strategy as well.
- Source, https://helm.sh/docs/topics/chart_best_practices/pods/
- Variables should use camel case.
- Favor flat hierarchy over nested.
- "Every defined property in values.yaml should be documented. The
documentation string should begin with the name of the property it
describes, and then give at least a one-sentence description."
- Source, https://helm.sh/docs/topics/chart_best_practices/values/
- remove namespace, since it's best practice to use the cli to add it,
@roschaefer points out
- organize templates into directories
- migrations should be ran after the backend has started...
- should init really be ran every time??
* docs(deployment): Explain how to setup metrics
close#2411close#2777
* Update docs with some info I found useful
Co-authored-by: mattwr18 <mattwr18@gmail.com>
Ok, so here is the plan. Let's give both our cucumber features and your
cypress tests a prominent place to live. That would be the root level
folder of our application. Second, let's revive formerly dead code step
by step.
Ie. move code from the former location `backend/features/` to `features/`
when it is ready. All edge cases should be tested with unit tests in
`backend/`, see my `webfinger.spec.js` as an example.
Also found:
```
Some users have raised concerns that the Neo4j image changes file permissions on the host machine.
By default, Neo4j runs as the user neo4j who only exists in the container, not on the host. That means that it's hard to set up mount folders on the host which this new user has write permissions for. We have updated the error messaging with advice about how to fix file permission errors. We also introduced writability checks and reduced the amount of file permission changes the image will perform. This has been found to interfere with some Kubernetes setups, so is currently an opt-in feature.
To enforce stricter file permissions checking you can pass this environment variable to the container:
--env SECURE_FILE_PERMISSIONS=yes
```
from https://hub.docker.com/_/neo4j
Implemented the above ☝️
- I was getting an error locally Failed: error parsing query as Extended JSON: invalid JSON input
- updating the syntax to wrap the json in single quotes, and key/values
in double quotes fixed the issue
- update memory limits
- we need to remove the whitespaces first, then check if there are still illegitimate characters in the hashtag before removing them
- this is to maintain the maximum number of hashtags imported from the legacy database as possible
I think it's beneficial to have these settings in a central location.
That way, we're not running into the danger of overwriting the
`nitro-deployment` by accident with a `kubectl apply -f ...`.
