Use --break-system-packages option as the new pip3 claims:
error: externally-managed-environment
...
note: If you believe this is a mistake, please contact your
Python installation or OS distribution provider. You can
override this, at the risk of breaking your Python
installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
Change-Id: I11b29dfe31a5404779b732923b6703670073a365
Since we are mounting in read-only mode the code, we are getting
warnings from pytest executions not able to generate .pytest_cache
directory.
Just define CACHE_DIR in a volumen that is mounted as read-write
Change-Id: I115f4ebcff78172fa809d0a9fdba02f923fb6ecb
Provide django command line jbi_files. The cleanup action
will archive build files of missing builds on database.
This will help to cleanup the huge amount of files we keep
right now in JBI_FILES
Change-Id: Ideb5a939807c41c411fa3883c0566221d7221189
We are storing some build artifact files indefinitely.
Implement removal of stored build artifacts on JenkinsBuildInfo
record deletion. So when a record in the database gets removed
the related files of that build will get relocated from JBI_FILES
to JBI_ARCHIVE
Change-Id: Ia1fcba2948bb3d0b50209fe29c1daa3f293cf59e
As of django-structlog v6.0.0, our django application fails with:
| Traceback (most recent call last):
| File "/var/lib/repoapi/venv_prod/lib/python3.9/site-packages/django/utils/module_loading.py", line 20, in import_string
| return getattr(module, class_name)
| AttributeError: module 'django_structlog.middlewares' has no attribute 'CeleryMiddleware'
Quoting from
https://django-structlog.readthedocs.io/en/latest/upgrade_guide.html#upgrading-to-6-0:
| (If you use celery) Make sure you use DJANGO_STRUCTLOG_CELERY_ENABLED = True
|
| It is only applicable if you use celery integration.
|
| django_structlog.middlewares.CeleryMiddleware has been remove in favor of a django settings.
|
| MIDDLEWARE += [
| "django_structlog.middlewares.RequestMiddleware",
| # "django_structlog.middlewares.CeleryMiddleware", # <- remove this
| ]
|
| DJANGO_STRUCTLOG_CELERY_ENABLED = True # <-- add this
Instead of forcing usage of an older django-structlog version,
let's make sure we have 6.0 or newer and update configuration
accordingly.
Change-Id: I0449c05db682ace22438b8b0ad8d8a4a1dfca71a
* migrate periodic task definition to database
via configuration
Be aware that we are getting hit by this issue:
https://github.com/celery/django-celery-beat/issues/647
Solution is not yet released:
2798e36fd8
Change-Id: Id72130bdd5fe97be3824f5d9d7a3905af44d3597
When invoking `virtualenv --python=python3 virtualenv` to deploy the
virtual environment, installing the python-debian wheel, and then
re-executing `virtualenv --python=python3 virtualenv` once again, we
might end up without the virtualenv/lib/python*/site-packages/debian
directory, resulting in:
| Traceback (most recent call last):
| File "<string>", line 1, in <module>
| ModuleNotFoundError: No module named 'debian'
This is a bug in setuptools >=51.3.3-1, see
https://bugs.debian.org/1041091 for the details, so currently affecting
all systems with Debian/bookworm.
By excluding installation of setuptools (via --no-setuptools), we would
be able to work around this bootstrapping problem itself, though then
installation of django-jsonify (which we depend on) fails with:
| ModuleNotFoundError: No module named 'setuptools'
Let's take this as a chance to switch from virtualenv to the more
lightweight venv, quoting https://docs.python.org/3/library/venv.html:
| Changed in version 3.5: The use of venv is now recommended for creating virtual environments.
Change-Id: Iad06bf8c49abd96441ab04bb9b7e3917acd1ee59
This reverts commit 1e2026769e.
This isn't a problem with python-debian, but in setuptools
itself, see https://bugs.debian.org/1041091
Change-Id: I0cef0bc444aa07060b07a1d7ca5a2301c77cd602
Instead of overwriting the install.log, let's append the output,
to make sure we capture all its output during our deployments.
Change-Id: I104694573cb5d94e33772df01d3d693539b188b5
> root@repoapi2:/usr/share/repoapi# source /var/lib/repoapi/venv_prod/bin/activate
> root@repoapi2:/usr/share/repoapi# export DJANGO_SETTINGS_MODULE=repoapi.settings.prod
Generate new apikey values, db is not changed!! This is just in order to
produce a apikey.json file:
> root@repoapi2:/usr/share/repoapi# ./manage.py apikey generate
> key:AsAPINOl.D7pq6PRT4hjpnb13LIMmjjafqoUJN8JN prefix:AsAPINOl hashed_key:pbkdf2_sha256$260000$EqQMpCFxh4Bk6nWMApv3PA$+8ZbfG+MXpBSOrXmc33fgBZZ7rUI4ywInOfUry+SKec=
Validate if a hash and key matches:
> root@repoapi2:/usr/share/repoapi# ./manage.py apikey verify --key AsAPINOl.D7pq6PRT4hjpnb13LIMmjjafqoUJN8JN --value 'pbkdf2_sha256$260000$EqQMpCFxh4Bk6nWMApv3PA$+8ZbfG+MXpBSOrXmc33fgBZZ7rUI4ywInOfUry+SKec='
Generate a hash from key:
> root@repoapi2:/usr/share/repoapi# ./manage.py apikey hash --value AsAPINOl.D7pq6PRT4hjpnb13LIMmjjafqoUJN8JN
pbkdf2_sha256$260000$i2AeV5mIwaKKAcisHZHTl4$ZvxWMfFJSXfkbf6SDUG2Ilv0MOtXq/Cy0PG6NNA48po=
Change-Id: I06bfe2f4e8cf08d3d75066cecf7e3fbf4c39680d
The python binary is gone, and use and support python3 instead.
Fixes:
| Setting up repoapi (0.4.6+0~20230705093550.1012+bookworm~1.gbp7c23af) ...
| /var/lib/dpkg/info/repoapi.postinst: 21: python: not found
| dpkg: error processing package repoapi (--configure):
| installed repoapi package post-installation script subprocess returned error exit status 127
Change-Id: I54c02826da75fb2a01ee307aeab850978034c9da
Automate the process of cleaning up the Gerrit info we keep.
We query Gerrit server and check if review is merged or abandoned.
If so, we remove data from database and query Jenkins to remove
the related PPA.
Ideally this should not be needed but it seems there are some
cases/scenarios that we don't manage properly.
* will be executed each 15th day of the month at 7:30
* add timezone info to Gerrit fixtures to reduce warning
Change-Id: Ic5ddc3b646532257bd7747443a6fdead4ff28544
Victor Seva
Guillem Jover
Mykola Malkov
Marco Capetta
Michael Prokop