- This means that systemd sandbox will be in effect even during development. We
won't miss out on bugs in sandbox configuration.
- We won't have disable systemd sandbox features just because we can test
properly on development setup. Such as JoinsNamespaceOf=.
- This also leads to significant reduction in hacky code for setting up for
development and functional tests.
- One disadvantage is that first setup is run before user gets a chance to
interact with the started container/VM. However, this is okay since first setup
can be re-run easily by removing the /var/lib/plinth/plinth.sqlite3 file and
also the need for doing this is rare.
Tests:
- Start a fresh container and run functional tests with './container run-tests'
on it. The tests run as expected (succeed or fail).
- While first setup is in progress, running the command 'make
wait-while-first-setup' waits while printing dots. After the first setup is
done, it exists.
- Running the command freedombox-logs shows FreedomBox logs for both the web and
privileged services.
- Changing a source code file in the /freedombox directory (or on the host)
leads to a restart of the Plinth web service.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- These is no need to set sudo related configuration for running actions.
- We need to enable and start freedombox-privileged daemon.
- Use 'make provision-dev' to simplify all setup.
- Update the check for 'setup finished' message.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
- Using `--dist=loadscope` splits the tests based on module, thus
ensuring each app's tests get assigned to one worker only.
- Though app servers run in 2 separate VMs, the pytest-xdist workers
simply run in two Python subprocesses (`-n 2`). This allows us to
generate a unified test report.
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
See 550f9192ae4e5c4dd486ba08738ecee322929fce.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
[sunil: Rely fully on running the install.sh script remove the pip3 rerun]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
This commit alone doesn't fix the problem of our functional tests timing
out. It is harmless to increase the timeout.
The maximum timeout for shared runners in Salsa is 3h according to this:
https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md#set-build-timeout
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
This is a temporary fix until Splinter addresses the breaking changes in Selenium 4.3.0
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- The GitLab CI Runner no longer directly runs AWS CLI commands
- The Runner calls two AWS Lambda functions for running or terminating the app servers
- The Lambda functions invoke AWS APIs using the Python boto3 library
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- Added an additional build job called 'build-backports'
- Added a separate stage for functional tests in order to avoid
depending on multiple jobs
- Improved readability of long commands in YAML files
- Depending on GitLab username 'weblate' instead of a RE2 regexp (untested)
- Increased job timeout to 2h 30m
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Functional tests are run in parallel on Debian testing and Debian
unstable using the latest freedombox package built in the pipeline.
Commits by Weblate are ignored.
Fixesfreedombox-team/infrastructure#34Closesfreedombox-team/infrastructure!48
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
