The CI was controlling if the traduction was made
in every PR. It makes the workflow quite grueling
when we have to change the literal, plus the synch
is complicating when we have multiple PR opened.
We remove the CI control on the traduction, we
will do dedicated PR to update the traduction.
We will add the CI control on the traduction in
the future, before a release by example.
It was quite confusing having development, production and
frontend images' names in the same Docker file. New comers
to the project would have some difficuluties when
differentiating frontend from backend images.
Try to make these naming more explicit and consistent.
Thanks @rouja for your recommendation.
This is a major issue. Docker Images were built and published with a
root user in the CI.
if a user manages to break out of the application running as root in the
container, he may gain root user access on host. In addition, configuring
container to user unprivileged is the best way yo prevent privilege
escalation attacks.
We mitigated this issue by creating a new environment variable DOCKER_USER.
DOCKER_USER is set with id -u and id -g outputs. Then, it is passed as a
build-args when running docker/build-push-action steps.
Build and push the frontend image to DockerHub. Backend an Frontend
images will be stored in separate repos: people-backend and people-frontend.
It will be cleaner than managing all images in a single repo and creating
tags to discriminate frontend and backend images.
CI code is not factorized between jobs. Frontend and backend jobs could be
a bit factorized. Hovewer it might be a bit premature, and I prefer having
them decoupled for now. @rouja suggested to introduce a custom github actions
to avoid maintaining the same logic accross different repo.
Please not as the images are built from the same Dockerfile, it's important
to precise the right target.
When we run e2e tests with the CI, we are doing lot of
calls to the backend in a short amount of time. This can
lead to a rate limit particulary on the "user/me" endpoint.
To avoid this, we will use different backend settings
for the e2e tests.
Integrate 'mozilla-django-oidc' dependency, to support
Authorization Code flow, which is required by Agent Connect.
Thus, we provide a secure back channel OIDC flow, and return
to the client only a session cookie.
Done:
- Replace JWT authentication by Session based authentication in DRF
- Update Django settings to make OIDC configurations easily editable
- Add 'mozilla-django-oidc' routes to our router
- Implement a custom Django Authentication class to adapt
'mozilla-django-oidc' to our needs
'mozilla-django-oidc' routes added are:
- /authenticate
- /callback (the redirect_uri called back by the Idp)
- /logout
Refactored 'Hub' CI job for clarity, using 'docker/build-push-action.'
This dedicated workflow efficiently manages image releases on push tag
and main branch merges events.
'Hub' job was broken by Chat GPT translation from Circle CI.
Images are pushed to a temporary Docker Hub repository,
lasuite/people.
Duplicated 'build-docker' job was removed from people workflow.
We install Jest to test our i18n package.
We tests:
- the extraction of the translations on the Desk app fo crowdin
- the formatings of the translations from crowdin to the app
- we check that all the translations are present in the app
We connect the tests to the CI.
We create a package i18n to manage the translations of the project.
It help us to extract the translations from the frontend to
be deployed to crowdin.
It also help us to format the translations from crowdin to
be used by the frontend apps.
Github secrets are difficult to maintain in time because we do not have
a way to track them efficiently. So to avoid this issue, we prefer to use
sops encrypted files to manage our secrets.
Add test-e2e to people.yml, it will run e2e tests on every PR.
Steps:
- set env vars for e2e tests
- build and start docker servers
(backend, keycloak, DB)
- install playwright
- build apps
- run e2e tests
- save reports
Install playwright, adapt the config file and add a scripts to
run the tests.
e2e testing will monitor all our frontend applications,
so we install it in the frontend folder.
It configures the base of our monorepo.
As a prove of concept, to check the full process of our token,
we create a basic feature Teams.
This feature can create a team and list all teams.
We use react-query to manage the cache and the request to the API.
Used https://github.com/openfun/joanie as boilerplate, ran a few
transformations with ChapGPT and adapted models and endpoints to
fit to my current vision of the project.
