## 🍰 Pullrequest
This will migrate our assets to an objectstorage via S3.
Before this PR is rolled out, the S3 credentials need to be configured in the respective infrastructure repository. The migration is implemented in a backend migration, i.e. I expect the `initContainer` to take a little longer but I hope then it's going to be fine. If any errors occcur, the migration should be repeatable, since the disk volume is still there.
### Issues
The backend having direct access on disk.
### Todo
- [ ] Configure backend environment variables in every infrastructure repo
- [ ] Remove kubernetes uploads volume in a future PR
Commits:
* refactor: follow @ulfgebhardt
Here: https://github.com/Ocelot-Social-Community/Ocelot-Social/pull/8545#pullrequestreview-2846163417
I don't know why the PR didn't include these changes already, I believe I made a mistake during rebase and lost the relevant commits.
* refactor: use typescript assertions
I found it a better way to react to this comment: https://github.com/Ocelot-Social-Community/Ocelot-Social/pull/8545/files#r2092766596
* add S3 credentials
* refactor: easier to remember credentials
It's for local development only
* give init container necessary file access
* fix: wrong upload location on production
* refactor: follow @ulfgebhardt's review
See: https://github.com/Ocelot-Social-Community/Ocelot-Social/pull/8545#pullrequestreview-2881626504
* refactor(backend): types for global config
I saw merge conflicts in these files for #8463 so let's get some parts of this PR into `master` already.
I believe this fixes a small bug. They guard clause didn't ensure that all of REDIS_ configurations were set.
* remove old email mechanism
* refactor(backend: react to @ulfgebhardt's review
See: https://github.com/Ocelot-Social-Community/Ocelot-Social/pull/8485#pullrequestreview-2813528327
* build(backend): optional commit
@ulfgebhardt this is how I tested the configurations. We don't need to include this commit but I wouldn't expect to send out real emails from a `docker-compose` setup.
---------
Co-authored-by: Moriz Wahl <moriz.wahl@gmx.de>
* feat(other): major improvement of deployment
Motivation
----------
Kubernetes:
* backend becomes a statefulset (exclusive volume mount)
See: https://spacelift.io/blog/statefulset-vs-deployment
* implement neo4j backup with job
Docker:
* consistent targets across all dockerfiles
* remove redundant labels
* remove unnecessary build args
* remove obsolete networks
* remove development dependencies for production
Rebranding:
* add image tags for local tagging and pulling
* use Github's docker build workflows
* use Github container registry
* ONBUILD to simplify caller Dockerfiles
* docker compose for branding
Tooling:
* same node --version as in dockerfile
Docs:
* missing step in README.md
* refactor: remove submodules
It's better to keep them all in a separate repository
* improve kubernetes chart
* better image tag defaults
* split neo4j into its own chart (for re-use)
* use application defaults where possible
* optional resources for all pods
* remove obsolete key/value pair from secrets
* remove obsolete build argsand
and add labels for neo4j enterprise
* env vars for webapp
* allow to define redirect domains
Define a list of Domains that redirect to the domain of the project. The
idea is to provide the ability to redirect eg. www.domain.tld to
domain.tld
* remove maintenance part regarding database
* move backup job outside template folder
* name the ingress
* updated ingress
* handle empty case of middlewares
* try to default the ingress
* use quote
* restore todo-next-update
* fix docu check
* fix naming
* try using prod:migrate
* try using override config
* copy src folder
* try using base as image instead of build
* fix test build
* force build
* comment for the problem
* fix webapp tests (potentially)
---------
Co-authored-by: Ulf Gebhardt <ulf.gebhardt@webcraft-media.de>
https://github.com/Human-Connection/Human-Connection/pull/1543#pullrequestreview-287593264
Thinking about it, I really ask myself why I did not find this solution
earlier 🙈
Of course, you don't want to share the generated `buildDir`
with the host system. If you happen to share the `webapp/` folder,
simply point NuxtJS to a build directory somewhere else. Easy!
* Use `production` docker images for cypress tests. As one of our contributors
pointed out: It is bad practice to end-to-end test sth. else than the actual
production images.
* Have a dedicated `docker-compose.travis-integration.yml` to test
backend integration tests. The backend *needs* a database when doing
integration tests. So there is no way around using docker-compose. But
we could stop using the `build-and-test` stage when we do cypress tests.
* Remove a couple of unused ports and DRY `docker-compose.override.yml`
* Build and tag all images first and then run `docker-compose .. up` - I
hope this will not rebuild the image.
* Reduce docker image size
Here are the issues
* webapp was built with `NODE_ENV=production` but started with
`NODE_ENV=development`
* using the provided `docker-compose.travis.yml` the command `yarn run
start` would look in the wrong folder
* removed duplicate environment definition
