This supplements the release process. We inject Github metadata into two
version.json files; the 'version' value will depend on the type of event,
for release tag events it should be the same as the release tag (i.e. the
app version). This should make version information available to the /config
endpoint on any push, and the frontend should display the backend version.
(For extra safety we will also want to get the frontend version and display
that, but this commit only supplies the barest necessities.)
Disable retries and save trace for failed tests.
💚(ci) preserve server logs
Save server logs to the same place as Playwright reports to aid debugging.
💚(ci) move back to 1 worker on CI
At least three reasons
- seems redundant with sharding
- strong suspicion it's the reason for the ValidationError issue
- that way the comment no longer tells a lie ;)
💚(ci) improve E2E tests
Log into CHANGELOG to ensure the new test results impact PR status 🤷💚(ci) make dummy data creation more robust
This is a QR (Quick Response) fix for the failures in the "Add dummy
data" step in E2E testing. Proper QC (Quality Control) needs a bit
more thought.
Currently, it is complicated to understand the navigation between mailbox
management and role management for an email domain.
This is why we add tabs with explicit naming
Pushing to crowdin from the workflow has some side
effects, if 2 branches are pushing to crowdin it
can cause conflicts and delete translations on
Crowdin side.
Better to push to crowdin manually to keep good
control over the translations.
We were starting the workflow on push tags,
it is needed for the docker-hub workflow,
but the other workflows does not need to
be triggered on push tags.
Github Actions are transitioning from Node 16 to Node 20. Make sure we use
latest Github Actions versions to clean any deprecation warnings.
The migration is upcoming.
When we restored the frontend cache, we were restoring
old code as well, we don't want that, we want to only
restore the node_modules.
This commit fixes that.
We improve the build-front caching as well, to cache
only the desk build app.
To improve the speed of the CI, we cache the frontend
install. It will even be reused between pull request
until the yarn.lock has a change.
We cache as well the desk build app, in another cache,
this cache persist only per workflow. It will increase the
speed if we have e2e flaky tests and that we have to relaunch
the e2e job.
Add a new job in the CI, which notifies ArgoCD through a webhook that a new
docker image has been pushed to the Docker registry. Thus, ArgoCD can sync
and pull the latest image.
Thus, main will be automatically deployed to staging.
build-mails job builds mails Django templates but was not persisting its
output. This steps was present in Joanie CI. It might have been removed,
when converting Circle CI worflows to Github Actions.
Artifacts are passed between build-mails and test-back jobs. test-back
job has now a dependency to build-mails.
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.
